I'm having the weirdest problem. I have a web app hosted on an IIS server that won't work in IE8, which is the standard browser at this company. It works in chrome. I've also put identical files hosted on my google drive, and it works there, even in IE8. It also works when the files are just on my desktop, even in IE8.
It turns out that the problem is specifically caused by the fact that when the app is hosted on that server, javascript in IE8 won't parse strings. Here is some example code:
<!doctype html>
<html>
<body>
<script type="text/javascript">
var test='test';
console.log(test[2]);
</script></body>
</html>
That's it. The entire document. When I host this on the IIS server and open IE8's console, instead of logging s like it should, I get
LOG: undefined
In chrome, I get s When I host the file anywhere else, I get s even in IE8. But when it's viewed in IE8 and hosted on this server, I get undefined. What's going on here?
Turns out it was a compatibility view issue. Code works with compatibility view is off. Since all our computers view intranet sites in compatibility view I added <meta http-equiv="X-UA-Compatible" content="IE=8" /> to the html head to prevent compatibility view. The app works now.
IE8 may not support a string as an array of chars. See this question
How do you get a string to a character array in JavaScript?
It may even be down to your server changing the compatibility mode of the browser.
Instead do
window.console&&console.log(test.charAt(2));
I am adding the window.console&& to not get an error in IE8 when the console is not open
Related
I have been working an a static website for my job. It is currently being deployed for use and I'm running into a few problems. The link that points to the site opens it in IE (and most people here use IE as their browser) and by default it runs in Compatibility Mode. Because of this, the site isn't displayed properly. I found a solution to add
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
to my header and it works great. The only problelm is that I would have to add it to each page which is not feasible.
I decided it would be better to check for the IE browser and provide an alert message with a link to instructions on how to turn off Compatibility Mode.
The code works fine, my only issue is that even when Compatibility Mode is turned off by the user, the alert will still appear.
After playing around, I noticed in the browser's console that there's an info message:
HTML1202: < site > is running in Compatibility View because 'Display intranet sites in Compatibility View' is checked.
and after testing, it does go away after following the instructions I provided to the user.
My question is: would it be possible to read the console or store its log and check for this specific message so I can modify my code to only show the alert when the message appears?
I have deployed my website to an external server and when I connect to it on IE, it doesn't render my page correctly unless I add the host to my trusted websites. It renders fine on chrome. Any idea what could cause this? I link the css/js on the top of the html like this:
<link rel="stylesheet" href="css/display.css">
<script type="text/javascript" src="javascript/jquery-2.1.1.min.js"></script>
<script type="text/javascript" src="javascript/jquery-ui.js"></script>
One thing I noticed about IE 7 and IE 8 is you will need to use jquery-1.11.1.min.js instead of jquery-2.1.1.min.js. jquery-2.1.1.min.js is only supported by IE 9+. That is most likely the problem.
Many corporations have company-wide security policies set on Internet Explorer. These settings are usually the responsibility of your SysAdmins, or IT Ops guys (titles vary). The reason it differs from your IE at home is due to these extra security settings, and depending on the policy of your company it may be possible to add your external host to everyone's trusted sites list in one action by the SysAdmins. If not, then you will have to find alternatives. Locally hosted css and js should not matter in this case, the problem is more the unrecognized domain name.
The site works in Chrome because these settings are tied to Windows and Chrome does not integrate with those (a major reason why some companies for all non-developers to use IE for everything). Good luck, this problem falls under "battling the bureaucracy" as opposed to actual honest-to-goodness programming, but hopefully you'll prevail.
Yes it is true that due to security reasons IE asks the user if it should access scripts from untrusted domain. If it is jquery( jquery 2 not supported by IE8 use 1.11 or earlier ) that is being blocked by IE, try using jquery from Google cdn. Google is trusted host I am sure.
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.
I've been pulling my hair out trying to solve this problem. We support IE8 and use a company called "Marketo" for some analytics. When I load their Javascript file as an external, then try to instantiate the class within the file, it throws a Javascript "Object expected" error in IE8. It does not cause this in Firefox or Safari.
However, when I manually paste the contents of the external inside a <script> tag, the class instantiates fine! It's only when the Javascript file is external that the problem is caused. I must use an external because Marketo updates their code regularly and I can't keep on top of the copying/pasting.
Here is the external: http://munchkin.marketo.net/munchkin.js
Here is how I load the file:
<script type="text/javascript" src="http://munchkin.marketo.net/munchkin.js"></script>
Here is how I instantiate the class:
<script type="text/javascript">
mktoMunchkin("300-EOJ-215");
</script>
Using setTimeout() doesn't help anything (I thought maybe it was a slow server causing a timing issue):
<script type="text/javascript">
setTimeout(function() {
mktoMunchkin("300-EOJ-215");
}, 5000);
</script>
Any ideas?
UPDATE: Figured out what the problem was. We were delivering our webpage over HTTPS and pulling the Marketo munchkin.js file over HTTP, which for whatever reason IE8 (and not Firefox, Safari, etc.) had a problem with. Switched the URL to https://munchkin.marketo.net/munchkin.js and it was fine.
We experienced very similar problem this morning for IE7 and IE8 on Windows. Links on web pages built with aspx that have Marketo's munchkin.js Javascript fail, without throwing an error.
Web pages built with asp DO work. Chrome, Firefox and IE9 on Windows work fine. Safari on Macs work fine. Disabling "Active Scripting" in IE8 restores functionality.
We phoned Marketo Support, who said an update that they pushed out yesterday (22 Feb 2012) apparently caused the problem. Support became aware of the problem this morning and their engineering group is actively working on a fix.
This happened to us also. Every link on our site was disabled in IE7 and IE8.
We have had to remove all Marketo from our website and redeploy.
Marketo has admitted to the problem only after we worked like crazy to find it.
We couldn't even get notification because the support link was not working.
Ugly...
Jeff
Figured out what the problem was. We were delivering our webpage over HTTPS and pulling the Marketo munchkin.js file over HTTP, which for whatever reason IE8 (and not Firefox, Safari, etc.) had a problem with. Switched the URL to https://munchkin.marketo.net/munchkin.js and it was fine.
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