Bug 422561 - [Browser] implement XULRunner 24 support
Summary: [Browser] implement XULRunner 24 support
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.3   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 4.4 M5   Edit
Assignee: Grant Gayed CLA
QA Contact:
URL:
Whiteboard:
Keywords: plan
: 327696 428930 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-11-26 06:51 EST by Lakshmi P Shanmugam CLA
Modified: 2014-04-02 17:01 EDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lakshmi P Shanmugam CLA 2013-11-26 06:51:49 EST
Support for Xulrunner 24 is planned for eclipse 4.4. The implementation
work is complete and is waiting for the legal clearance from the Eclipse Foundation.
Comment 1 Grant Gayed CLA 2013-12-10 16:58:50 EST
Legal approval has been received for this.  I will merge it into master after the current milestone has passed.
Comment 5 Grant Gayed CLA 2014-01-07 10:10:38 EST
The comment 4 commit is not complete, this ensures that the library builds on hudson: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=14d3ce4da57b33221606a768f517941e568c2e57 .
Comment 6 Arun Thondapu CLA 2014-01-23 09:11:33 EST
Marking the bug as Fixed in M5.
Comment 7 Grant Gayed CLA 2014-02-19 12:51:20 EST
*** Bug 327696 has been marked as a duplicate of this bug. ***
Comment 8 Erdal Karaca CLA 2014-02-19 15:06:37 EST
Thanks for the work! Does the new integration also support WebGL?
Comment 9 Paul Webster CLA 2014-02-24 11:51:12 EST
*** Bug 428930 has been marked as a duplicate of this bug. ***
Comment 10 Paul Webster CLA 2014-02-24 14:24:18 EST
*** Bug 428930 has been marked as a duplicate of this bug. ***
Comment 11 Grant Gayed CLA 2014-03-21 10:04:50 EDT
(In reply to Erdal Karaca from comment #8)
> Thanks for the work! Does the new integration also support WebGL?

I've looked into this, and the apparent non-support seems to be due to a difference between the xulrunner 24 and firefox 24 binaries from mozilla.org.  In particular, the common layout/build/nsLayoutModule.cpp:1140-1143 has:

  { "@mozilla.org/content/canvas-rendering-context;1?id=experimental-webgl", &kNS_CANVASRENDERINGCONTEXTWEBGL_CID },
#ifdef MOZ_PHOENIX // Not MOZ_FENNEC or MOZ_B2G yet.
  { "@mozilla.org/content/canvas-rendering-context;1?id=webgl", &kNS_CANVASRENDERINGCONTEXTWEBGL_CID },
#endif

The purpose of the "#ifdef MOZ_PHOENIX" is to ensure that full WebGL compliance is not claimed for their builds that target mobile, where there are presumably technical limitations to achieving this.  Unfortunately this #ifdef is precluding XULRunner since it also does not define MOZ_PHOENIX.

That being said, I think the only difference between canvas.getContext("webgl") and canvas.getContext("experimental-webgl") is that the latter comes with a caveat that the full set of compliance tests was not passed by the renderer.  It does not reduce its abilities per se, and I believe that XULRunner 24's WebGL rendering abilities are actually identical to those in Firefox 24, they just are only accessible through canvas.getContext("experimental-webgl").  https://bugzilla.mozilla.org/show_bug.cgi?id=870232 indicates that the abilities here vary by platform, not by product.

FWIW I notice that in their trunk this line has changed to "#ifdef MOZ_WEBGL_CONFORMANT", so depending on which builds they set this for, it's quite possible that newer XULRunner releases do now give an answer for canvas.getContext("webgl").
Comment 12 Matt Painter CLA 2014-04-02 09:55:26 EDT
It seems that the security context that the javascript executes under has now changed, as I used to be able to execute code like:

window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils).getOuterWindowWithId(99).QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIWebNavigation).QueryInterface(Components.interfaces.nsIDocShell).allowJavascript=false;

I'm not sure that this change (presuming it is intentional) is documented anywhere currently? Is there a recommended migration for running chrome code from SWT?
Comment 13 Grant Gayed CLA 2014-04-02 17:01:18 EDT
(In reply to Matt Mising name from comment #12)

This difference is not intentional, something has changed in XULRunner between their 10 and 24 releases.  I've logged bug 431839 for this.