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.
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
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
I just realized that what is a nice and working layout of a form with a webresource in on-line version, looses some (but not all) of the formatting when accessed via Outlook. It looks ugly and, I also get errors.
It's somehow related to the JavaScript added to the solution. Or, rather, the web resources, I'd say. Any suggestions on how to debug? F12 doesn't show the console when run from Outlook. I haven't done much with that version so any hint might be of help.
Are you able to narrow down your problem to a part of the script? Could you for instance disable and enable parts of the script(s) to see what works and what does not?
Since the layout is also being influenced, I think you are doing some (or a lot of?) DOM manipulation. This page on MSDN states:
HTML DOM manipulation is not supported
But there should not be that much of a problem (heard that one before...) using Outlook: Dynamics CRM 2011 Outlook client and browser rendering
Edit:
Just to prevent people overlooking the link to a related post from the comments: Random JavaScript Errors in CRM 2011 Outlook Client
Although the page you see in the CRM-Outlook is indeed rendered by IE, it's being served from another version of the engine than what is used to browse. During the rendition process it's "picturized" (lacking a better word for it) so what you see originates in a webpage but isn't one.
I don't think there's a way to debug that version. You can only rely that the development you've tested will work as supposed to. Note that there's no connected process of IE run at the same time as the Outlook client.
I'll gladly stand corrected but as far I've tried (and I've tried a lot, a lot), there's no way to get there.
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?)