Bugzilla – Full Text Bug Listing
| Summary: | Embedded IE11 browser shows webpages in Quirks(IE5)-Mode | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | tr | ||||||||||
| Component: | SWT | Assignee: | Niraj Modi <niraj.modi> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | major | ||||||||||||
| Priority: | P3 | CC: | arunkumar.thondapu, grant_gayed, niraj.modi, sptaszkiewicz | ||||||||||
| Version: | 4.2.2 | Flags: | arunkumar.thondapu:
review+
|
||||||||||
| Target Milestone: | 4.4.2 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows 7 | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
tr
4.5 I20141014-0800 and also previous releases. This happens also on newer IE versions including IE10 and it happens for me every time. The biggest problem is that modern webpages (usually those using AJAX) may no longer work if in the quirks mode because many features were not available in IE5. FWIW, "5" is the lowest numeric value corresponding to the document mode used to display webpages so it is quite draconian that you can get "5" instead of the expected "10". See also http://msdn.microsoft.com/en-us/library/jj676915%28v=vs.85%29.aspx Steps to reproduce: 1. Create a test.html file with the following content: <html> <head> </head> <body> <script> alert(document.documentMode); </script> </body> </html> 2. Open the file in external IE10. => The dialog contains "10". 3. Open the file in Internal Web Browser or use org.eclipse.swt.browser.Browser.setUrl(String) to open it programmatically. => When the file is loaded, a dialog with "5" appears which confirms that document mode of the same file/webpage is different when displayed in the embedded IE. Niraj, please investigate... Created attachment 248077 [details] Workaround - BrowserSnippet which explicitly specify documentMode. I could see this issue in SWT embedded IE browser where the documentMode comes up as 5 with embedded IE11, where as with stand-alone IE11 the documentMode is 11. Sharing a workaround that worked for me, where you could explicitly specify the document compatibility mode in the HTML itself, like below: <html> <head> <meta http-equiv='x-ua-compatible' content='IE=11' /> </head> <body> <script>alert(document.documentMode);</script> </body> </html> Note: In the meta entry for content, there is an '=' sign between IE & documentMode, which seems to be missing in comment 0. Hi Grant, Do you recall any reason for embedded IE 'documentMode' always pointing to version '5' ? (In reply to Niraj Modi from comment #4) > Hi Grant, > Do you recall any reason for embedded IE 'documentMode' always pointing to > version '5' ? No, AFAIK the embedded IE should only end up in quirks mode if it thinks a site wants/needs it. Supposed criteria for "needs" are discussed at http://en.wikipedia.org/wiki/Quirks_mode#Triggering_different_rendering_modes . If stand-alone IE doesn't show the same behaviour then it must be doing something to override the native renderer. (In reply to Grant Gayed from comment #5) > (In reply to Niraj Modi from comment #4) > > Hi Grant, > > Do you recall any reason for embedded IE 'documentMode' always pointing to > > version '5' ? > > No, AFAIK the embedded IE should only end up in quirks mode if it thinks a > site wants/needs it. Supposed criteria for "needs" are discussed at > http://en.wikipedia.org/wiki/ > Quirks_mode#Triggering_different_rendering_modes . If stand-alone IE > doesn't show the same behaviour then it must be doing something to override > the native renderer. Thanks Grant for the quick reply. With further exploration, it looks like HTML pages without DOCTYPE defaults to Quirks mode('5') documentMode: http://stackoverflow.com/questions/21135029/for-ie10-why-the-webbrowser-controls-default-quirks-mode-is-internet-explorer http://blogs.msdn.com/b/ie/archive/2011/12/14/interoperable-html5-quirks-mode-in-ie10.aspx http://stackoverflow.com/questions/5374099/how-do-i-force-internet-explorer-to-render-in-standards-mode-and-not-in-quirks Seems with embedded IE we have to explicitly specify the documentMode in HTML. SWT FAQ also makes a mention about compatibility mode @ http://www.eclipse.org/swt/faq.php#browsernativeie Suggesting a more generic way of specifying documentMode in HTML(tested with IE11 & IE8) Instead of specifying the exact documentMode value as in comment 3, you could specify the value as 'IE=edge': <html> <head> <meta http-equiv='x-ua-compatible' content='IE=edge' /> </head> <body> <script>alert(document.documentMode);</script> </body> </html> "Starting with IE11, edge mode is the preferred document mode; it represents the highest support for modern standards available to the browser." - http://msdn.microsoft.com/en-us/library/ie/bg182625%28v=vs.85%29.aspx#docmode OK, got to the root of this issue.. From IE8 and onwards version, Microsoft supports two IE version values to be used as registry value for below key: 'HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION' e.g. IE11 there are two possible values: - '11001' Webpage is displayed in IE11 documentMode(regardless of the !DOCTYPE directive.) - '11000' Webpage will be displayed as per !DOCTYPE directives and if !DOCTYPE is missing Quirks(5) documentMode is used. Current behavior SWT specifies 11000 as version value for IE11 in registry and HTML as reported in current bug(without !DOCTYPE) leads to Quirks(5) documentMode. Proposed solution: For IE8 and onwards, SWT will set the IE version value in Registry to point to the latest documentMode(regardless of !DOCTYPE directive) Current value used in SWT are IE8-8000, IE9-9000, IE10-10000 and IE11-11000 New values to be used are IE8-8888, IE9-9999, IE10-10001 and IE11-11001 Complete list of possible value for this registry key on below MSDN link: http://msdn.microsoft.com/en-us/library/ie/ee330730%28v=vs.85%29.aspx#browser_emulation With this change if user want to use legacy documentMode, for example on IE11 user want to use IE10 documentMode, then user need to specify below meta tag HTML header: <head><meta http-equiv='x-ua-compatible' content='IE=10' /></head> Created attachment 248305 [details]
Potential fix patch.
Fix working with embedded IE11.
Hi Szymon,
Will you be able to test this fix (attachment 248307 [details]) on IE10 at your end ?
Thanks!
(In reply to Niraj Modi from comment #9) > Hi Szymon, > Will you be able to test this fix (attachment 248307 [details]) on IE10 at your end ? > Thanks! Sorry one correction, refer attachment 248305 [details]. (In reply to Niraj Modi from comment #9) > Hi Szymon, > Will you be able to test this fix (attachment 248307 [details]) on IE10 at > your end ? > Thanks! Thanks for the quick update, Niraj. I have tested the fix with N20141102-2000 and IE10 and it does not solve the problem - document mode is still 5. Created attachment 248716 [details] Revised fix patch works with IE10 as well (In reply to Szymon Ptaszkiewicz from comment #11) > (In reply to Niraj Modi from comment #9) > > Hi Szymon, > > Will you be able to test this fix (attachment 248307 [details]) on IE10 at > > your end ? > > Thanks! > > Thanks for the quick update, Niraj. I have tested the fix with > N20141102-2000 and IE10 and it does not solve the problem - document mode is > still 5. Thanks Szymon, for trying out the patch, I am attaching a revised fix patch that works with IE10 as well. Can you also test this at your end ? Resolution for IE10 and previousIE: Based on below MSDN article it seems we are required to configure 2 set of registry key/value pairs to default the IE documentMode to the latest: https://social.msdn.microsoft.com/Forums/en-US/51f51217-72f0-44a2-a374-91919138506b/winform-webbrowser-control-problem?forum=winforms (In reply to Niraj Modi from comment #12) > Thanks Szymon, for trying out the patch, I am attaching a revised fix patch > that works with IE10 as well. Can you also test this at your end ? Thanks, Niraj! I have tested the fix on top of N20141117-2000 with IE10 and it works fine - I can see document mode is 10. I have observed just one side effect: if I close the Internal Web Browser view when some specific page is currently visible I get a GPF and JVM crashes but I am not sure if this is related to the fix itself. The GPF comes from C:\windows\System32\jscript9.dll which means it is related to the JavaScript exectued as part of the page. After the crash, the registry entries are not removed and I need to removed them manually to clean up. If I load a different page like eclipse.org before closing the view, there is no crash and the registry entries are removed correctly. Created attachment 248721 [details] javacore produced during GPF Here is the javacore from the crash mentioned in comment 13. (In reply to Szymon Ptaszkiewicz from comment #13) > The GPF comes from C:\windows\System32\jscript9.dll which means it is related > to the JavaScript exectued as part of the page. Correction: the javacore contains this line: org/eclipse/swt/browser/IE$6.handleEvent(IE.java:406) which means GPF occurs when calling this line: execute ("window.location.href='about:blank'"); not when executing scripts loaded by the page. (In reply to Szymon Ptaszkiewicz from comment #14) > Created attachment 248721 [details] > javacore produced during GPF > > Here is the javacore from the crash mentioned in comment 13. This looks the same as Bug 354641, which at least initially resolved to a native IE bug. MS issued a fix that was confirmed to fix the original case in bug 354640. Is there any possibility you don't have the Windows updates? Do you see the problem for any site that's open in the browser, or only for certain sites (if I remember correctly the crash only happened when some sites were open in the browser)? (In reply to Grant Gayed from comment #16) > This looks the same as Bug 354641, which at least initially resolved to a > native IE bug. MS issued a fix that was confirmed to fix the original case > in bug 354640. Is there any possibility you don't have the Windows updates? It is possible although I have IE10 so I think this problem should be fixed there because bug 354640 was opened against IE9. But I may be wrong. > Do you see the problem for any site that's open in the browser, or only for > certain sites (if I remember correctly the crash only happened when some > sites were open in the browser)? It happens only in case of one site which is our internal company site and it's always reproducible. I have pushed the fix that works for latest IE-11 and defaults the 'documentMode' to 11 as proposed in attachment 248305 [details], via below git patch: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ea2d29ea4c024a608cde22f9f485e4382812e9cf Hi Szymon, As per MSDN above changes should have worked for all IE versions, but that doesn't seems to be the case and it works for latest IE11 only. We will keep the second(revised) patch(attachment 248716 [details]) on-hold which fixes the 'documentMode' for IE10 too, but introduces UN-stability for some sites in embedded IE10 as a side effect. Comment on the 2nd Answer below, second your observation w.r.t. to IE10: http://stackoverflow.com/questions/21135029/for-ie10-why-the-webbrowser-controls-default-quirks-mode-is-internet-explorer Resolving this bug as the fix works for latest IE11. Created another bug 454372 for investigation on older versions of IE i.e. 10 and before. Verified the fix in build: I20141208-2000 Reopening this bug for back-port to 4.4.2 release. Back-ported the change to 'R4_4_maintenance' branch via below patch: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R4_4_maintenance&id=ebeb45cf4ec2570be7e06717f77aa068bb542ece Hi Arun, for your review. (In reply to Niraj Modi from comment #22) > Back-ported the change to 'R4_4_maintenance' branch via below patch: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?h=R4_4_maintenance&id=ebeb45cf4ec2570be7e06717f77aa068bb542ece Verified the fix in below 4.4.2 M-build: M20150122-0430 |