We're using a third party content management system built on ASP.NET. The pages seem to display in IE9 mode on IE11. I used the MS IE10 compat inspector tool http://blogs.msdn.com/b/ie/archive/2012/01/20/ie10-compat-inspector.aspx to try and work out why the page is not displaying in IE10 or Edge mode. (The HTML5 feature that I'm trying to use should display in IE10 or 11.) The only warnings the tool gives are about Javascript which is using window.navigator to do browser sniffing.
The code that is using window.navigator is in a file called webresource.axd:
var __nonMSDOMBrowser = (window.navigator.appName.toLowerCase().indexOf('explorer') == -1);
which itself seems to be part of ASP.NET.
There are no javascript warnings or errors. Here's one of the pages:
https://secure.wycliffe.org.uk/NetCommunity/SSLPage.aspx?pid=283. This is with IIS6 on Windows Server 2003.
Could this be the cause of the IE9 mode problem? (I have <!DOCTYPE html> at the top of the document.)
Is MS's own tool really complaining about bad practise in it's own software?
Ah ha! It's because your server is sending the pages down with an X-UA-Compatible header, telling Internet Explorer to use IE9 mode.
To see it, open https://secure.wycliffe.org.uk/NetCommunity/SSLPage.aspx?pid=283 in IE10, and press F12 to bring up the developer tools. Switch to the Network tab, press Start and refresh the page. Once it's loaded, double-click on the first item, then switch to the Response Headers tab.
You should see a header in there: X-UA-Compatible: IE=9.
To force IE to use the latest rendering mode, go into the IIS configuration, find where it's being applied, and either remove it, or change it to a newer version, e.g. IE=10. Alternatively, IE=edge will always use the latest version's standards mode rendering engine. Be aware it's probably there for a reason, though! We've had to use that header in the past as a short-term workaround for IE10 issues in legacy .net applications.
See MSDN: Defining document compatibility for more information.
Related
I have a .net web app that uses Telerik Reporting, and I'm having trouble running their new version on my intranet site. Even with the meta tag for IE edge set or set in web.config, this puts the document into IE11 mode, but compatibility mode still picks it up for being in the intranet zone.
It's getting a javascript error promise undefined, and works fine if I manually add the site to Trusted Sites on my local browser to get it out of intranet compatibility mode.
I've been reading that this is the document mode vs the browser mode, so this is running in IE11 document mode, but the browser mode is still whatever compatibility mode is trying to set it down to for intranet, which looks to be IE5 if I don't have the meta tag. I was also reading that the document mode should determine what javascript engine IE11 uses, not the browser mode, but maybe this isn't true? Telerik says they don't support compatibility view, so I've been trying to force it to 11/edge, but this browser mode is killing me. Any other suggesions?
I don't want to keep my site in trusted sites either because I also want Windows Authentication on but it's defaulted off, and even if I wanted to try to get them to push out a group policy change to all browsers, there are a bunch of other sites in trusted sites and I'm not sure if turning windows auth on for everything might cause other problems for other sites.
Here is a screenshot of the console showing the javascript error even though doc mode is 11.
I'm working on a legacy application which has the unfortunate need to rely on older version of IE to function correctly. Within this application I have added a page that uses HTML5/CSS3 and modern JavaScript libraries to render and function. This page has been given the meta tag: http-equiv="X-UA-Compatbile" content="IE-Edge"
Unfortunately this page does not render correctly. The application is an older ASP.Net system that I'm running on localhost IIS. The path for the app is http://localhost/csa/myappname and to the problematic page the path is http://localhost/csa/myappname/Responsive_Dashboard.aspxI have attempted the following:
Set the browser document mode to Edge using the F12 developer tools. This works for my page but breaks the rest of the application.
Updated the local sites.xml file with the Enterprise Mode Site List Manager, giving older browser compatibility to the http://localhost/csa/myappname and IE11 document mode to my page at http://localhost/csa/myappname/Responsive_Dashboard.aspx then set the browser profile to Enterprise using the F12 developer tools. In this case, the application works fine except for my page, which does not change the document mode.
Set the browser compatibility mode for localhost via the IE Compatibility View settings, and changed the browser profile to desktop. The results here are the same as in item #2.
Is there a way to set my page at http://localhost/csa/myappname/Responsive_Dashboard.aspx to use the latest rendering engine while leaving the rest of the application/site alone? The only way I can get this to work is to use the F12 menu to switch the document mode back and forth. This would not be an acceptable solution for my business partners. Thank you.
I discovered a workaround for this - what I am doing is opening the page in a new window / new tab and the functionality is working fine. It seems that the page was being wrapped in another page when navigating to it directly, which was causing the issue.
EDIT August 22, 2022 - After an update to the Edge browser that again broke this page, the team found a fix by adding the page to the sitelist.xml file.
I hava situation where some javascript a web page works fine in Safari and Chrome, but fails in IE11. Unfortunately due to issues with confidentiality I cannot put the javascript up here.
In IE11 the web page's java script fails to operate correctly. By that I mean some of the javascript works and some doesn't. With no errors displayed or any other indication of whats wrong.
If I try to debug the page using IE's developers tools, all the javascript works perfectly without any errors or issues.
Searching on the net I found many people with the same IE problem - fails normally, works when debugging. The main issues they talk about is the console.log(...) statement. I checked my javascript and don't have any console.log(...) statements.
I then saw a stackoverflow thread where adding a cache:false to the $.ajax({... calls solved the issue. I added the same flag but the problem still persists.
Are there any other bugs I've not found?
The web page is using jQuery to handle most of it's manipulation of the DOM with a single $.ajax... call and a series of $.get(... calls polling the server.
How to debug your web pages.....IE11 tips.
All modern web browsers suppress scripting error messages and warnings by default. (In the early days web browsers would halt page loading/rendering and display a script error message with an alert statement)... this gives the best user experience who isn't concerned with the internal workings of web site code.
So, scripting errors will only BREAK execution if:
1. The browser debug tool is opened. and
2. The developer tools' Debug tab setting for Break on Exceptions has been turned on.
So to debug your web pages.
1. navigate to about:blank to start a testing cycle.....press f11 to display the dev tool, select "Break on all exceptions" from the dropdown (looks like a stop sign). Pin the dev tool to the bottom of the browser.
2. Return to the browser address bar and navigate to your test site (typed address of paste and go)...
The dev tool will now break on ALL exceptions and you will list them in the console tab.
IE has built-in content blocking and has ActiveX filtering (ad blocking) which can affect outcomes. You need to configure Internet Options so that the IE dev tool console will record any blocked content or security (XSS) errors.
Tools>Internet Options>Advanced tab, check "Always record developer console messages".
Also on the Emulation tab of the IE dev tool you will find the Emulation Mode (aka documentMode) that IE is using, and how it was established eg. x-ua meta, Enterprise site mode list, user Compatibility View list, etc
If you are developing an internal company website, the emulation mode used by IE may be for an earlier version of IE.. (IE8 on XP).. you should include this information with your questions.
You should also include the IE security zone that your site has been mapped to.. File>Properties menu in IE.... eg. Intranet zone as this can have different security and blocked content outcomes.
finally, the first step in troubleshooting web browser issues is to test in noAddons mode (for IE, winkey+r>iexplore.exe -extoff ). IE has built-in form-fillers and popup blockers... third-party addons can affect the outcomes expected.
I've set up a central WebApi site that will provide general CRUD capability for various sites across our domain. I've configured the whole shebang to utilize CORS with the standard jquery ajax httprequest or, in the case of older IE versions, XDomainRequest. So far, everything checks out, it works splendidly. My problem is that I can't seem to find a machine with IE8 in order to complete user agent testing. The site works wonderfully when I go into the developer tools on IE 11 and set it to emulate IE8 but I'm not ready to pop the champagne cork just yet.
My question is: will the developer tools' IE8 mode fully emulate that browser's behavior, down to the way it handles cross domain requests or do I need to either find a user with IE8 and have them test it or spin up a VM with it?
You can download a virtual machine with IE8 from Microsoft's modern.ie site at http://dev.modern.ie/tools/vms/ and test your site with that.
I have a web application that puts the outlook web app inside an iframe.
This works quite well in most browsers, but it fails in IE9, with an error in outlook’s javascript:
SCRIPT438: Object doesn't support property or method '__defineGetter__'
uglobal.js, line 1 character 975667
What seems to be happening is that the __defineGetter__ function is deprecated and is not present in IE9, though most other browsers support it. The mail app usually runs in IE7 standards mode – if I open web mail on it’s own and press F12 (dev tools) I see Browser Mode: IE9, Document Mode: IE7 standards and there are no problems.
However when I run the app that has outlook mail in an iframe, I see Browser Mode: IE9, Document Mode: IE9 standards. That applies to the outside site, there's no obvious way to find out how the iframe is rendering in IE9.
The frame source has the headers that I would expect:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "ht`tp://www.w3.org/TR/html4/strict.dtd">
It looks like the JavaScript inside the iframe is running as if it's not as regards the version. Of course it’s still isolated so I can't monkeypatch this function in as per this hack.
How can I force the iframe contents to run JavaScript in IE7 mode, differently from the rest of the website? We don't want to edit the code inside the iframe? We don't want to do that since it's just stock outlook web app. And if we do have to go there, we would just go for fixing their JavaScript not fixing the metadata.
I'll answer my own question, based on what we know today.
We essentially have been caught in the malign interaction of a few unwelcome features.
1) As per this post, IE9 ignores the doctype of pages inside iframes, and always uses the parent page's doctype instead.
IE9 forces the child page to the same DOCTYPE as the parent page. No
matter what. ... Microsoft's response is that it's working as designed.
I hope someone can confirm or deny this information, one forum post isn't much to go on, but it fits with what we have seen.
2) The MS Outlook web app, the 2011 version (Version: 14.1.287.0), is not compatible with Internet Explorer 9. To show this, try the following: find a running Outlook web app, e.g. http://mail.mycompany.com connect to it with IE9. Log in. Press F12 to bring up the developer tools. Note that at the top right you have "Document Mode: IE7 standards". IE9 is emulating IE7 in order to run the site.
You can change this mode: click it and select "Document Mode: IE9 standards". Note that the Console tab now shows an error mentioned above about the missing __defineGetter__ method and that parts of the web app don't work - clicking on messages in the list or clicking on the reply button does nothing now.
Thanks, Outlook team for not using standards and for not targeting the current version of your own browser.
3) The __defineGetter__ method does not work in IE9. It is deprecated, and defineProperty should be used instead. That is fair enough, but __defineGetter__ is still present in current versions of Firefox and Chrome, and so Outlook works. In IE9 it is absent unless IE9 is pretending to be an older version of IE.
You just have to put this meta in your page/masterpage :
<meta http-equiv="X-UA-Compatible" content="IE=8" />
Xam666
Review these. Meta tags can help
http://blogs.msdn.com/b/askie/archive/2009/03/23/understanding-compatibility-modes-in-internet-explorer-8.aspx
The docs are for IE8. should give pointers for IE9 as well.
Webpage can specify compatibility mode either by using a Meta tag or by sending a http header. Meta tag takes precedence over http header when both are present.
1) META Tag - You can place the following HTML tag in the HEAD element of your web page:
2) HTTP Header - You can configure your server so that the following HTTP Header is sent with each page
X-UA-Compatible: IE=7