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?
Related
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 have an application deployed in three environments, that use the LinkedIn JS API to open the LinkedIn authentication window. In two of those environments, when the LinkedIn window opens, it immediately tries to close itself with a prompt, in IE and Edge (works correctly in Chrome and Firefox, and in all browsers (including IE and Edge) in the third environment):
If you answer "Yes" to this prompt, the window closes and the user can't authenticate. If you answer "No", then a LinkedIn 404 page is shown.
I tried changing permissions for the associated API keys, and generating new API keys entirely, but none of those changes caused the error to go away in the two environments that are failing, or caused the error to appear in the environment where there are currently no issues.
Disabling Protected Mode in IE 11 fixes the issue, and re-enabling it causes the issue to return, but there is no such option in Edge. Disabling extensions with iexplore.exe -extoff {url} does not fix the problem.
You can reproduce the issue in IE or Edge on: https://jobs.sap.com/job/Palo-Alto-Senior-Quality-Specialist-Job-CA-94301/338144501/ by clicking Apply Now > Apply with LinkedIn, entering a fake e-mail address, and clicking Start. The self-closing window should appear. You should find that doing the same on https://sap.valhalla.qa.jobs2web.com/job/San-Mateo-Support-Account-Manager-Job-CA-94401/2160465700/ works correctly, where the LinkedIn authentication window appears, ready for user input.
This has been replicated by others, both on and off of the network I'm working on. I don't see any errors or warnings in the developer tools console. There aren't any browser plug-ins, etc. installed that might be blocking something.
Any ideas as to what I can check to try to resolve this issue?
We have a web portal product and contains multiple iframes, js files and css files. Every time I visit the portal using IE11, the browse mode becomes 8, as shown in F12.
The weird thing is, I checked ALL requests and responses in Network in F12 Developer Tools, and only three response headers contains x-ua-compatible. The values are
IE=Edge
IE=EmulateIE7
IE=EmulateIE7
I have no idea where IE8 comes from?
Also in our DEV portal, the same product, it shows Browse Mode = Edge, even the same three values also present. It seems the browser mode is changed somewhere else outside Network/F12. I guess it is not javascript. But what can change IE's document mode?
Could this be related to Enterprise Mode? I think this is something that network administrators can set up.
If your product is accessible from the internet, I'd try using IE11 on a computer outside of work and see what happens.
https://technet.microsoft.com/en-us/itpro/internet-explorer/ie11-deploy-guide/what-is-enterprise-mode
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
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