Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 344597

Summary: Error when returning null values from Javascript evaluations in IE 9 using SWT Browser
Product: [Eclipse Project] Platform Reporter: Martin Woodward <martin.woodward>
Component: SWTAssignee: Grant Gayed <grant_gayed>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: eclipse.felipe, martin.woodward, martinwo, Silenio_Quarti
Version: 4.1Flags: Silenio_Quarti: review+
Target Milestone: 3.7 RC1   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Attachments:
Description Flags
SWT Snippet to reproduce issue. Fails when ran on Windows system with IE9. Works on all other platforms and browser versions
none
patch none

Description Martin Woodward CLA 2011-05-03 11:22:15 EDT
Build Identifier: M20110210-1200

Evaluating JavaScript expressions that return null or an undefined value using the SWT Browser control against Internet Explorer 9 (IE9) will result in an SWT Exception.  I will attach a repro snippet or you can simply in an SWT Browser control execute something like:

    Object result = browser.evaluate("alert('evalute something that returns null')");

On Windows with IE9 RTM installed you get:

  org.eclipse.swt.SWTException: Return value not valid

On all other platforms (including Windows with prior version of IE including IE9 Beta), a null value is returned.

The reason for this is that IE 9 has a new Javascript engine with significantly improved performance, however they also changed some behaviour which has resulted in a change to the way the COM interface works for null or undefined values.

GetIDsOfNames on an Javascript Array’s IDispatch pointer now returns valid ids for the items in the array. If you have a single item array with the one item in it that is undefined or null, the old engine would return DISP_E_UNKNOWNNAME for this item, and so the SWT Browser code in the WebSite class simply skips over this element.  However, the item does exist (albeit it is undefined), and so IE9 now return a valid dispid. SWT then tries to query for the item, and IE9 returns a VARIANT with its type set to VT_EMPTY which we’re then not handling in the SWT Browser code.  (As VT_EMPTY was never returned by the older versions of IE the SWT Browser code never had to handle this condition before).

I believe the correct fix would be to have the org.eclipse.swt.browser.WebSite.convertToJava() method handle the new VT_EMPTY Variant, i.e.

Object convertToJava (Variant variant) {
	switch (variant.getType ()) {
		case OLE.VT_EMPTY:      // IE9 can return VT_EMPTY for null
		case OLE.VT_NULL: return null;
		case OLE.VT_BSTR: return variant.getString ();
		...

Let me know if you agree and I can send along a patch accordingly as it is a simple one-line fix.    I’ve checked with the folks this side and I have permission to contribute this simple fix to improve the interoperability of Eclipse and IE9.

The only workaround I can find without the fix is to make sure that any Javascript you do execute never returns null or undefined (i.e. you can OR the result of the call that could return null with an empty string to ensure that the result coming back via IDispatch is always a non-null value)

Let me know if there is anything else I can do to help.


Reproducible: Always

Steps to Reproduce:
1. Execute a browser.evaluate() call that returns null or undefined results from the Javascript expression when running with IE9

Actual result:
SWTException

Expected result:
null value returned.
Comment 1 Martin Woodward CLA 2011-05-03 11:28:56 EDT
Created attachment 194601 [details]
SWT Snippet to reproduce issue.  Fails when ran on Windows system with IE9.  Works on all other platforms and browser versions

A quick SWT Snippet showing how to repro the discussed issue against IE9 on Windows.
Comment 2 Grant Gayed CLA 2011-05-03 12:55:54 EDT
Thanks for the report and for investigating this.  A patch isn't necessary, it looks straghtforward.
Comment 3 Martin Woodward CLA 2011-05-03 13:00:16 EDT
Thanks Grant.  Let me know if you need anything else, more information from our side or help verifying any fix.


(In reply to comment #2)
> Thanks for the report and for investigating this.  A patch isn't necessary, it
> looks straghtforward.
Comment 4 Grant Gayed CLA 2011-05-03 15:08:04 EDT
Created attachment 194630 [details]
patch
Comment 5 Grant Gayed CLA 2011-05-04 15:26:20 EDT
fixed > 20110504
Comment 6 Martin Woodward CLA 2011-05-04 15:37:11 EDT
Fantastic - thanks Grant!