Community
Participate
Working Groups
When attempting to evaluate or execute JavaScript on the browser widget with IE9 installed on windows 7, some pages can cause a JVM crash. This did not happen before my upgrade to IE 9.
Created attachment 201412 [details] snipet Here is a snippet that exhibits this behavior if you click on any link on the site. Changing the url to be a different site may or may not have crashing behavior.
Do you have a page that will force that behaviour that doesn't require a logon - or does the crash happen in the logon screen that you get redirected to from the "https://na7.salesforce.com/00O/o" page used in the snippet?
*** Bug 354641 has been marked as a duplicate of this bug. ***
The OLE-only snippet below shows the crash, no Browser control required. It crashes at the call marked "<-", within which it invokes GetTypeInfo() on the pVarResult IDispatch. I don't know why this call would crash. As an experiment I preceded it with a GetTypeInfoCount() call and it answered 1, which is as expected. public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); OleControlSite controlSite; try { OleFrame frame = new OleFrame(shell, SWT.NONE); controlSite = new OleControlSite(frame, SWT.NONE, "Shell.Explorer"); controlSite.doVerb(OLE.OLEIVERB_INPLACEACTIVATE); } catch (SWTError e) { System.out.println("Unable to open activeX control"); return; } shell.open(); final OleAutomation webBrowser = new OleAutomation(controlSite); int[] ids = webBrowser.getIDsOfNames(new String[]{"Navigate", "URL"}); Variant[] rgvarg = new Variant[] {new Variant("http://fogbugz.stackexchange.com/questions/8474/why-do-i-suddenly-have-access-to-fogbugz-7-3-6")}; int[] rgdispidNamedArgs = new int[]{ids[1]}; webBrowser.invoke(ids[0], rgvarg, rgdispidNamedArgs); display.timerExec(9999, new Runnable() { /* time to allow page to load */ public void run() { int[] rgdispid = webBrowser.getIDsOfNames(new String[] {"Document"}); int dispIdMember = rgdispid[0]; Variant pVarResult = webBrowser.getProperty(dispIdMember); OleAutomation document = pVarResult.getAutomation(); rgdispid = document.getIDsOfNames(new String[]{"parentWindow"}); /* get IHTMLWindow2 */ dispIdMember = rgdispid[0]; pVarResult = document.getProperty(dispIdMember); System.out.println("pVarResult VT type: " + pVarResult.getType()); OleAutomation ihtmlWindow2 = pVarResult.getAutomation(); // <- crash } }); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } }
This is reproducible with a minimal C++ BHO, I've logged a report with MS at https://connect.microsoft.com/IE/feedback/details/694548/regression-ie9-can-crash-when-getting-itypeinfo-from-an-ihtmlwindow2 .
Grant, is there any chance that this will get fixed in SR2?
The underlying problem is in the jscript used by IE, hence the report that was logged with MS. The vast majority of pages do work fine when evaluating JS in IE9, so I've been looking for clues to predict when a page will crash. This would at least allow the Browser to run away in such cases, but I have not found any such clues. In both the working and crashing cases the COM object provided by IHTMLDocument2's parentWindow is a valid IDispatch that we can QI to an IHTMLWindow2, so we are getting the expected object. I can't find a way to avoid the crash short of disabling all JS evaluations when IE9 is embedded, which is too drastic given that most pages work fine. MS needs to fix this in jscript. If there's a way to detect a page that will cause this crash then running away from such cases would be a reasonable workaround to make in the meantime, but at this point I don't know of a way to determine this. Closing report as NOT_ECLIPSE. As a side note (you are likely already aware of), the Browser can embed IE in an older emulated mode, see http://www.eclipse.org/swt/faq.php#browsernativeie . This can provide a workaround if IE9's capabilities are not strongly relied on.
We’ve investigated this issue and determined the bug is in IE’s js engine. The IE team is looking into releasing the fix in an IE9 update later this summer. Martin Sawicki Principal Program Manager Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation
Yay!
Great news, thanks Martin.
Ditto, cheers to you and your team, Martin.
*** Bug 380690 has been marked as a duplicate of this bug. ***
My report in comment 5 just received the following: " This issue was resolved in Internet Explorer 10 Platform Preview 6 on Windows 8 Release Preview released on 5/31/2012. " I have not verified it yet, and will be away over the next three weeks. I'll verify it upon my return, unless someone beats me to it (it looks like a Windows 8 Release Preview is needed).
Microsoft has also just shipped the update to IE9 that includes the fix for this issue. The article associated with the update is http://support.microsoft.com/kb/2722913 (since it’s a minor fix, it is not called out in the docs explicitly, as typically these updates are intended for critical security fixes.)
Verified that it works on my IE, no more crashes - great work! Thanks for pushing it through and letting us know Martin.
(In reply to comment #5) > This is reproducible with a minimal C++ BHO, I've logged a report with MS at > https://connect.microsoft.com/IE/feedback/details/694548/regression-ie9-can- > crash-when-getting-itypeinfo-from-an-ihtmlwindow2 . Any idea if this problem exists in IE8? I get an error clikcing on link above.
(In reply to comment #16) > Any idea if this problem exists in IE8? I get an error clikcing on link above. This problem did not happen with IE8.
I still see what I believe is this crash using a fully up-to-date IE9, but I can make it go away by adding this line in the <head> section of my HTML: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8">
(In reply to comment #18) > I still see what I believe is this crash using a fully up-to-date IE9, but I The test cases in this report's initial comments are all fine for me now. Is there a particular site that's crashing for you?
It started crashing when I upgraded my own web application from Dojo 1.6.1 to Dojo 1.7.3.
A reproducible case is needed since this report's original cases are now working. It's possible that you're seeing a different problem.
2 workarounds work for me: 1. Add a line <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8"> inside the <head> section of my HTML page. 2. Display my real page inside an <iframe> in a wrapper HTML page.
I found another workaround if using dojo (I'm using 1.7.2). Ensure you use a compressed and built dojo distribution (by default it should be but I found mine wasn't and using one stopped IE crashing). A strange side-effect, but it worked for me.
*** Bug 373578 has been marked as a duplicate of this bug. ***
