I have a strange problem with IE 10. Many jQuery scripts that are working fine on IE 8, 9, Chrome, firefox and safari but broken on IE 10. Issue came into light only when some users switch to IE 10.
Easiest solution I found to add
<meta http-equiv="X-UA-Compatible" content="IE=9" />
in <head></head>.
The problem is site has a lot of pages and most pages don't have inherited master page.
So is there any way to add this through javascript, as we have a common referenced js in all webpages.
No, there is no way to do that in Javascript. At least, not in a way that would actually achieve anything -- the rendering mode is fixed when the page is loaded, so there's nothing you can do to change it in JS from within the page.
An alternative solution would be to add the X-UA-Compatible flag as an HTTP header. This would set it on all pages across your site without requiring any HTML changes.
You've mentioned that you're using IIS. This page should help you configure it for your site.
However, the real solution would always be to fix the site so that it works in IE10. This is likely to be the best solution for you because IE10 is actually pretty good at being standards compliant; if you've got something that works in IE8 and IE9 but not IE10, then it's near certain that it is actually something wrong in your page rather than anything wrong in IE10.
This in turn means that even if it works today in other browsers, there is likely to be a bug in your code that could break in future versions of other browsers.
The other problem with using IE's compatiblity mode is that it really isn't an accurate copy of the old IE version it's supposed to be compatible with. This is particularly the case with IE10's compatibility modes, because there are some old features that have been removed from IE10 completely, and which are therefore not available in compatiblity mode either. This means that IE8 and IE9 might work, but IE10 in IE9-compat mode might not work. It depends what the actual issue is, but you'll need to test it just as thoroughly in compat mode as you would in real IE10 mode.
And then there's the question of how you deal with the site going forward into the future. What about IE11 and beyond? Compat mode removes new features that IE might have, so by sticking with IE9 mode you'll be stopping yourself from being able to use features like text shadow or CSS transitions. You'll want to use those features eventually, so you will need to fix the site at some point; why not now?
Thanks everyone for responses and help.
What I was looking for was like adding below code in web.config:
<httpProtocol>
<customHeaders>
<clear/>
<!--This setting will make document mode to highest mode available we need have mode 8 and above-->
<add name="X-UA-Compatible" value="IE=IE9"/>
</customHeaders>
</httpProtocol>
in <system.webServer> section.
JavaScript is run after the page load, this means you will not be able to modify the meta response from the server to the client afterwards. It might be easier to address the issues with IE 10 instead if there are no common headers
var m = document.createElement("meta");
m.setAttribute("http-equiv", "X-UA-Compatible");
m.setAttribute("content", "IE=9");
document.getElementsByTagName("head")[0].appendChild(m);
But as Teemu hinted, it will most likely not show any effect.
It is hard to figure out (from the question) that what is actually being broken? Can you tell which JavaScript code is being broken?
Anyways, one solution may be changing the document mode, what you have stated above. Another solution may be changing the browser's JavaScript version (if the problem is due to in-compatible JavaScript).
You can change the browser's JavaScript version be adding a browser configuration file to App_Browser folder in you asp.net application. Or to do it automatically, add this nu-get package and modify it.
install-package App_BrowsersUpdate
https://nuget.org/packages/App_BrowsersUpdate
Related
I have a strange problem with IE 10. Many jQuery scripts that are working fine on IE 8, 9, Chrome, firefox and safari but broken on IE 10. Issue came into light only when some users switch to IE 10.
Easiest solution I found to add
<meta http-equiv="X-UA-Compatible" content="IE=9" />
in <head></head>.
The problem is site has a lot of pages and most pages don't have inherited master page.
So is there any way to add this through javascript, as we have a common referenced js in all webpages.
No, there is no way to do that in Javascript. At least, not in a way that would actually achieve anything -- the rendering mode is fixed when the page is loaded, so there's nothing you can do to change it in JS from within the page.
An alternative solution would be to add the X-UA-Compatible flag as an HTTP header. This would set it on all pages across your site without requiring any HTML changes.
You've mentioned that you're using IIS. This page should help you configure it for your site.
However, the real solution would always be to fix the site so that it works in IE10. This is likely to be the best solution for you because IE10 is actually pretty good at being standards compliant; if you've got something that works in IE8 and IE9 but not IE10, then it's near certain that it is actually something wrong in your page rather than anything wrong in IE10.
This in turn means that even if it works today in other browsers, there is likely to be a bug in your code that could break in future versions of other browsers.
The other problem with using IE's compatiblity mode is that it really isn't an accurate copy of the old IE version it's supposed to be compatible with. This is particularly the case with IE10's compatibility modes, because there are some old features that have been removed from IE10 completely, and which are therefore not available in compatiblity mode either. This means that IE8 and IE9 might work, but IE10 in IE9-compat mode might not work. It depends what the actual issue is, but you'll need to test it just as thoroughly in compat mode as you would in real IE10 mode.
And then there's the question of how you deal with the site going forward into the future. What about IE11 and beyond? Compat mode removes new features that IE might have, so by sticking with IE9 mode you'll be stopping yourself from being able to use features like text shadow or CSS transitions. You'll want to use those features eventually, so you will need to fix the site at some point; why not now?
Thanks everyone for responses and help.
What I was looking for was like adding below code in web.config:
<httpProtocol>
<customHeaders>
<clear/>
<!--This setting will make document mode to highest mode available we need have mode 8 and above-->
<add name="X-UA-Compatible" value="IE=IE9"/>
</customHeaders>
</httpProtocol>
in <system.webServer> section.
JavaScript is run after the page load, this means you will not be able to modify the meta response from the server to the client afterwards. It might be easier to address the issues with IE 10 instead if there are no common headers
var m = document.createElement("meta");
m.setAttribute("http-equiv", "X-UA-Compatible");
m.setAttribute("content", "IE=9");
document.getElementsByTagName("head")[0].appendChild(m);
But as Teemu hinted, it will most likely not show any effect.
It is hard to figure out (from the question) that what is actually being broken? Can you tell which JavaScript code is being broken?
Anyways, one solution may be changing the document mode, what you have stated above. Another solution may be changing the browser's JavaScript version (if the problem is due to in-compatible JavaScript).
You can change the browser's JavaScript version be adding a browser configuration file to App_Browser folder in you asp.net application. Or to do it automatically, add this nu-get package and modify it.
install-package App_BrowsersUpdate
https://nuget.org/packages/App_BrowsersUpdate
This might not have anything to do with ExtJS, but I have to provide all information in order to get a proper answer :D.
I have an application that uses ExtJS 4.1 for displaying some grid panels.
When I run the application on localhost, everything looks as it should.
When I deploy the application on a remote server, the grids are no longer displayed as required in IE8: all the information is squeezed in the table, irrespective of the column alignment(the column headers are good, but the other cells are overlapping).
To make things more general:
The same application runs good on localhost(no matter on what computer), but when I deploy it on a server, IE8 doesn't display things as it should. This happens because of the CSS or JavaScript files(probably both related to ExtJS).
Why?
Per the OP's request to post this as an answer:
By default, IE runs with Compatibility View enabled for Intranet sites. The reasoning for this was probably that most intranet sites using IE were written specifically for IE, and thus would break when IE began adhering more closely to standards.
This potentially causes a difference between what is viewed locally versus on an intranet (and on the internet). This can be changed across the board with a Windows group policy; some organizations are receptive to this, some can't/won't make a change.
If declaring meta http-equiv="X-UA-Compatible" content="IE=edge" doesn't fix the behavior (as stated in the comments), I would start by checking that compatibility view actually is the problem.
Other Possibilities
I'm assuming that you have the correct doctype in place (e.g. HTML 5 or HTML 4 strict, though I believe others will work fine too). This works in conjunction with the "X-UA-Compatible" declaration.
Malformed markup can trigger Quirks Mode, which looks atrocious in almost any scenario. That's probably not the case, since it looks fine locally but it's easy to check. Make sure that your document is reasonably valid and--more importantly--that there are no leading characters before your DTD (which confuses the parser). Incorrect server code can cause data to be written to the response stream before the HTML, leading to this behavior.
Lastly, reduce the problem to its simplest form, i.e. find the most basic markup which causes the behavior. If this doesn't give you any insight, post the broken code in a JS Fiddle.
If it is IE8, check in developer tools document mode, it might be going to quirks mode.
Firefox has a certain tolerance when rendering bad HTML. This means even if a closing tag is left out, the HTML will be displayed as if everything was fine. This tolerance aspect is particularly relevant when one is using JavaScript to manipulate or add content in the current page.
Since I use Firefox as my main testing/developing browser, I've been troubled more than once by this behavior of which the consequences are loss of functionality in "more strict" browsers. For instance the same code in Microsoft Internet Explorer failed to produce any visible output due to the mentioned missing tag on the added content.
Now the question is, is there any way of telling Firefox to be more strict about the accepted HTML and fail instead of "guessing a fix" for it (specially when the HTML is being added via JavaScript)?
PS: I've tried playing with the DOCTYPE but the results were the same.
Don't use browsers to check your HTML; they're very much not designed to do that. Use an actual validator, such as the W3C's validator. There appear to be lots of Firefox extensions which will validate the page with a click or automatically, though I'm not familiar with them since I don't use Firefox as my primary browser.
All parsers are forgiving to some degree. Most mainstream sites have errors (not that this makes it excusable, just saying). If you develop with a debugger attached, you will catch script errors much more quickly. I also catch script errors by using a minifier in my build process (which will fail on major syntax issues). I valid my HTML markup using Visual Studio 2010's real-time warnings (which aren't always perfect) and periodically use the w3 validator service.
For browser choice, I usually develop across the board; in one sitting I literally may switch between IE7/8/9 modes, Chrome, and Firefox. Safari and Opera usually work if the aforementioned browsers are covered. This way I don't get too far down an erroneous path.
BTW, DOCTYPE is important (even if it doesn't always seem that way).
I've found that it is best to just break down and do your primary work in IE.
If you use a good doctype ( < !DOCTYPE html > ) and set the x-ua-compatible header to IE8 mode, the extra work you have to do to make an app work/look good in other browsers is minimal.
I'm testing a fairly complex Javascript-based web application in Internet Explorer 8 on Windows Vista. After loading the application, IE is in "standards" browser mode and "IE 8 standards" document mode. While the application is running, IE will sometimes reload the page and display a message saying something like "A display problem with (URL) has caused Internet Explorer to reload the page in compatibility view" (not the exact message, I'm on a non-English version of Vista). After the reload, the browser is in Quirks mode.
Debugging the Javascript code has been an exercise in futility since the problem can't be reliably reproduced or narrowed down, so I'd appreciate any insight into what could cause this behavior.
There must be a problem with the markup you are serving/creating via innerHTML. Here's an article from the IE team which includes details of IE's auto-recovery from markup that is impossible to parse correctly in IE8-standards-mode:
...there are particular code paths within the new layout engine where, should an error occur, the layout process can’t gracefully recover and we’ve kept assertions around these paths... We refined this experience further in the released version of IE8 by recovering layout “hard asserts” using Compatibility View. In other words, we believe that showing a page the way IE7 would have offers a better user experience than showing no content at all.
Note that using innerHTML invokes the HTML parser, so it could trigger this problem even after the page is loaded if fed an HTML string it can't make head nor tail of.
check here ..
basically. per-page, you can add a meta tag
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
or, site-wide add this to header:
X-UA-Compatible: IE=EmulateIE7
Sounds like Automatic Crash Recovery occurring in the renderer itself. That's a bug in IE itself rather than your scripts, so debugging is going to be tough indeed.
Does this happen on all IE8 installs? Is IE8 updated with the latest patches? (Could it be an unreliable third-party extension?)
Our website uses the superfish jQuery plug-in for our menus (http://users.tpg.com.au/j_birch/plugins/superfish/), and they work fine in Firefox, IE6, IE7, Safari, Chrome, etc. ... and even in MOST IE8 installations. The problem is, in some IE8 installations, the menus don't work (they highlight on mouseover but don't drop-down the menu).
This has me baffled. In addition to a couple customer complaints, I've got one (Windows XP) machine in-house that reproduces the issue. However, I also have another Win XP/IE8 machine in-house which doesn't experience the problem. I'm used to dealing with JS/CSS issues between different browsers, but this issue between two machines on the exact same OS and browser is a bit much.
Oh, and just to further obfuscate the matter, the machine that is reproducing the issue shows no errors, Javascript or otherwise (even when I go in to developer mode). So ... does anyone have any suggestions on what could be going on?
As far as I know neither of my two "test" machines have any special plug-ins or anything which would cause the problem, they're identical in terms of everything that matters, and there's no JS error occurring that I can check the stacktrace of or anything. But this isn't just some crazy problem that's unique to my test machine, because as I said some customers have reported it too.
Any help would be appreciated.
Can you try setting the IE7 compatibility mode and see whether the problem persists?
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
(into the head of the document, best would be directly after <head>)
If it works then, you'll definitely know that it is some IE8 specific rendering issue. My first bet would be that your menu uses CSS hacks to set certain IE specific settings, unaware that IE 8 (fortunately) behaves differently and more standards-compatibly than its predecessors. If that is the case, you would have to use an IE8 specific CSS hack (or, better, specific style sheet) to "re-fix" those settings.
But first, check whether this really is the problem using the compatibility view.
Try turning off compatibility view: Tools -> Compatibility View -> Uncheck. I too struggled with this for the better part of an afternoon until I just tried this on a whim and it worked!
Try clearing Internet Explorers cache. Go to Tools -> Internet Options -> Browsing History section -> Delete ... -> Temporary Internet Files -> Delete.
For reasons unbeknownst to me, I've seen all IE versions start behaving strangely when the cache has been full or not cleared for a long time.
I have a Windows 7 64bit Home premium. The laptop encountered an issue called SupperFish.
First I tried resetting home page to different URL’s. IE8 kept returning to SuperFish.com.
Look in Add and remove programs, was not there, Not in startup or MSCONFIG (startup).
Third cleared Cookies then History. No help. Forth ran Microsoft Security Essentials, SpyBot S&D, Norton Constant Guard , Ad Aware. Problem is still there, Looked in C:\Program Files and found a folder called SuperFish, in that folder there was an Uninstall executable. I ran the Uninstall using a administrator account, and the problem is no longer showing up, after several hours of use.
not sure if it is a solution and that this is what you meant by not knowing how to fix it... but I cleared all my cache/history/cookies etc. from IE8 and if immediately worked (looking the same as other browsers).
maybe a fix for now but that worked...
This issue wound up going away without us ever figuring out what caused it, so now even if we did want to figure it out we can't (as we can't replicate). Therefore I can't really mark any of the above answers as correct, but since they exist I can't delete this issue either. So, I guess the best I can do is file this answer, but it's a rather unsatisfying one; sorry.