Bugzilla – Full Text Bug Listing
| Summary: | [Browser] implement support for xulrunner >= 4.0 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Grant Gayed <grant_gayed> | ||||
| Component: | SWT | Assignee: | Grant Gayed <grant_gayed> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Grant Gayed <grant_gayed> | ||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | aelmahmoudy, akurtakov, apascual, aurel.visan, bartnll33, bpasero, c.sell, carlo.salinari, carsten.pfeiffer, chriss.dev, chrriis, costinarsene, david, dermot, dgolovin, dmaliarevich, Dominik.Hoelzl, dread_k2002, eclipse, eostroukhov, erdal.karaca.de, eric.charles, gregory.amerson, khoroshilov, konstantin.steblovtsev, krzysztof.daniel, lshanmug, markward.schubert, mpcarl, overholt, pchuong, peter.karena, remy.suen, thilo.schwarz, thilo.schwarz, vstevanovic, yahorr | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | 4.4 M5 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
*** Bug 343889 has been marked as a duplicate of this bug. *** *** Bug 343047 has been marked as a duplicate of this bug. *** Additional use case: having access to a WebGL/html5 canvas from an eclipse app. Additional use case: organization has apps tuned to either, but not both, of IE and Mozilla. Need to switch. Updating report title, mozilla changed their XULRunner numbering scheme mid-way through the 1.9.2.x fix releases to align with Firefox's version numbers. This does not change the request in any functional way. (In reply to comment #5) > Updating report title, mozilla changed their XULRunner numbering scheme mid-way > through the 1.9.2.x fix releases to align with Firefox's version numbers. This > does not change the request in any functional way. Does that change the fact that this feature request will most probably not be resolved in the short term? :-) (In reply to comment #6) > (In reply to comment #5) > > Updating report title, mozilla changed their XULRunner numbering scheme mid-way > > through the 1.9.2.x fix releases to align with Firefox's version numbers. This > > does not change the request in any functional way. > > Does that change the fact that this feature request will most probably not be > resolved in the short term? :-) Oops, I should have read the last sentence of your comment... does moving up to a newer xulrunner version mean that JavaXPCOM interfaces are also provided? My understanding is that JavaXPCOM has been abandoned by the Mozilla folks due to lack of manpower Correct, mozilla is not producing JavaXPCOM jars anymore. The Browser's existing JavaXPCOM support is not changed by adding support for a newer XULRunner release, but for an app to use JavaXPCOM it needs to ship a XULRunner that provides the JavaXPCOM jar. The latest such version is 3.6.26. What about to just implement a basic XULRunner support (like one which exists for IE and WebKit), without JavaXPCOM? Is it easier/possible? As I understand this, these nsI* interfaces are not really necessary. Nearly everything what is possible using JavaXPCOM is also possible using the Browser.execute() method and the BrowserFunction class. The lack of support of new XULRunner is a big step backward and a highway to the cross-browser-compatibility hell. XULRunner was the only browser engine which could be shipped together with SWT applications, since it is open-sourced and its bundles are available for all major platforms. Current situation forces SWT developers to use IE on Windows (I don't count Safari, it requires additional installation) and WebKit on Mac OS X and Linux. In addition, these browsers cannot be bundled and there is no possibility to select a browser version, which also forces developers to support different browsers versions. The Browser does not require JavaXPCOM in order for it to work, it just exposes it to apps that want to use it themselves through its getWebBrowser() method. The lack of the JavaXPCOM jar in recent XULRunner releases does not preclude the Browser from supporting them. The current plan is for support for XULRunner 10 to be added to the Browser control. the use of JavaXPCOM does require, however, a version of JavaXPCOM that is compatible withe the underlying browser. For xulrunner 10, such a version does not exist, because JavaXPCOM is broken since Gecko 4, and not bein maintained. If SWT does not depend on JavaXPCOM, and SWT is shipped with a xulrunner version for which no JavaXPCOM is available, what kind of object (of what class) would browser.getWebBrowser() return? SWT won't ship a XULRunner, it's up to an app that knows that it creates SWT.MOZILLA-style Browsers to do this. As of Eclipse/SWT 3.7.x the first native renderer that is attempted for SWT.NONE-style Browsers is WebKit, and if this is not found then the Linux distro is old enough to provide one of the "old" supported XULRunner versions (1.8.x - 3.6.x). An SWT.MOZILLA-style Browser whose underlying XULRunner does not provide a JavaXPCOM jar (eg.- XULRunner 10) will just return null. If the underlying XULRunner does provide this jar (ie.- XULRunner 1.8.1.2 - 3.6.x) then getWebBrowser() will continue to answer its nsIWebBrowser. is there already a target milestone set for xulrunner 10+ integration? This bug is only about "investiating". also: if we were to get JavaXPCOM running again, do you see any roadblocks to getting it set up with SWT as well? This should be in for the 3.8/4.2 release, unless any significant problems are encountered. If the XULRunner being embedded provides the JavaXPCOM jar corresponding to its internal interfaces (ie.- not just taken from some other XULRunner release) then the Browser should be able to return a useful object from getWebBrowser() and JavaXPCOM should be usable. Hi Grant, I am very interested for this enhancement and would like to try it out. Is this fix committed to 3.8 git repo? Would you be able to provide a bit more detail for which 3.8M release will have this enhancement? thanks! This work should be merged into the master branch tomorrow, so it will be in 3.8M6. Some notes: - It currently will not run on Linux as a result of Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=720682 . If this bug is not fixed in their 10.0.x stream then the Browser has a way of working around it with a little help from the embedding app. But for now the Browser's side of this workaround is not released, because this really should be fixed in XULRunner. - BrowserFunction does not currently work. This is being investigated in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=373253 . - The Browser's XULRunner auto-detection functionality will not attempt to find a XULRunner 10, the embedding app MUST explicitly point at it as described in http://www.eclipse.org/swt/faq.php#specifyxulrunner . > - The Browser's XULRunner auto-detection functionality will not attempt to find
> a XULRunner 10
Why? It does not, it cannot, or it is not yet implemented?
> Why? It does not, it cannot, or it is not yet implemented?
It likely would work, though it has not been tried.
The goal of the XULRunner auto-detect functionality was to make creating a SWT.NONE-style Browser on Linux "just work" by detecting an eligible XULRunner to use that had shipped with the Linux distro. To support this approach, the Browser supported every release from XULRunner 3.6.x back to Mozilla 1.4, which was somewhat doable at the time.
However SWT.NONE-style Browsers now default to using WebKit on Linux, so attempting to support every XULRunner release is no longer necessary, nor is reasonable. With Mozilla shipping new releases every six weeks, the odds of just finding a distro-shipped XULRunner 10 (not 9, not 11, etc.) to create an SWT.MOZILLA-style Browser are pretty low. So an app that creates such a Browser can no longer count on an eligible XULRunner being found on any OS, and needs to ship its own (this was already the case on Windows and OS X). Once an app is shipping a XULRunner, explicitly pointing at it should not be an issue.
The changes for this are now merged into master. re: Linux If Mozilla fixes https://bugzilla.mozilla.org/show_bug.cgi?id=720682 in their 10.0.x stream in the near future then the minimum supported XULRunner 10 version will be increased accordingly to get this fix. If Mozilla does not fix this in 10.0.x then additional Browser changes will be needed, along with instructions for the embedding app. Either way an update comment will be added here. Please log new reports for any bugs that are found. Note that the mouse pointer not updating on OS X is logged as bug 373585. I tried DisplayMozillaVersion (from the FAQ) with VM arguments: -Dorg.eclipse.swt.browser.XULRunnerPath="C:\Program Files (x86)\Mozilla Firefox\xpcom.dll" under eclipse 3.8M6. I get: XULRunner path: C:\Program Files (x86)\Mozilla Firefox\xpcom.dll\xpcom.dll >>>This failed with the following error: org.eclipse.swt.SWTError: XPCOM error 0x80004005 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:2607) at org.eclipse.swt.browser.Mozilla.initXULRunner(Mozilla.java:2573) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:672) at org.eclipse.swt.browser.Browser.<init>(Browser.java:99) at DisplayMozillaVersion.main(DisplayMozillaVersion.java:13) Snippet creating SWT.NONE-style Browser >>>succeeded Is this the expected behavior? (In reply to comment #21) > I tried DisplayMozillaVersion (from the FAQ) with VM arguments: > -Dorg.eclipse.swt.browser.XULRunnerPath="C:\Program Files (x86)\Mozilla > Firefox\xpcom.dll" I forgot to say Firefox is version 11. (In reply to comment #21) > I tried DisplayMozillaVersion (from the FAQ) with VM arguments: > -Dorg.eclipse.swt.browser.XULRunnerPath="C:\Program Files (x86)\Mozilla > Firefox\xpcom.dll" > > under eclipse 3.8M6. The XULRunnerPath should point to the XULRunner directory and not to the xpcom.dll. For eg, it should be "C:\Program Files (x86)\Mozilla Firefox". Also, XULRunner version that is supported now by SWT Browser is XULRunner 10. (In reply to comment #23) > Also, XULRunner version that is supported now by SWT Browser is XULRunner 10. I see, thanks. Are there any plans to support version 11, or to follow new xulrunner releases in general? (In reply to comment #24) > Are there any plans to support version 11, or to follow new xulrunner releases > in general? XULRunner 10.0.x is the latest release that will be supported by SWT 3.8/4.2. It's possible that a similar plan item could appear on the Eclipse 4.3 plan (eg.- support XULRunner 20.0.x), but this plan will not be made until after the 3.8/4.2 release, so it's too early to say for now. Created attachment 212954 [details]
snippet opening a SWT.MOZILLA Browser an checking webgl support
Is the latest SWT.MOZILLA Browser supposed to support webgl (see Comment 3)? I've tried with 3.8M6 (see attached code snippet, Comment 26), but I get this: "Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card." I tried putting: user_pref("webgl.disabled", false); user_pref("webgl.prefer-native-gl", false); user_pref("webgl.force-enabled", true); into C:\Users\carlo\AppData\Roaming\Mozilla\eclipse\prefs.js and it worked, but with two serious drawbacks: 1. the prefs.js settings are lost each time the program is executed (and this is probably only due to my ignorance of xulrunner: I don't know where I'm supposed to put the prefs.js file for my SWT.MOZILLA Browser) 2. the VM crashes on program exit: Problem signature: Problem Event Name: APPCRASH Application Name: javaw.exe Application Version: 7.0.30.5 Application Timestamp: 4f2cba03 Fault Module Name: Opengl32.dll Fault Module Version: 6.1.7600.16385 Fault Module Timestamp: 4a5bdadb Exception Code: c0000005 Exception Offset: 0000417f OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789 (could this second one be an SWT issue?) I have tested on Mac OS X (Snow Leopard) the following Snippet128 on eclipse 3.8M6 / JDK1.6 (starting with -XstartOnFirstThread to avoid cocoa thread issue) and got: org.eclipse.swt.SWTError: XPCOM error 0x80040111 at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:2607) at org.eclipse.swt.browser.Mozilla.initXULRunner(Mozilla.java:2573) at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:672) at org.eclipse.swt.browser.Browser.<init>(Browser.java:99) at aos.moz.Snippet128.main(Snippet128.java:40) Looking at http://git.eclipse.org/c/cbi/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT%20Mozilla/common/org/eclipse/swt/browser/Mozilla.java#n2607 does not clearly shows where the issue could be. Any hint welcome :) Thx, Eric public class Snippet128 { static { System.setProperty("org.eclipse.swt.browser.XULRunnerPath", "/Users/echarles/opt/xulrunner-12.0b1.en-US.mac-x86_64.sdk/bin"); } public static void main(String [] args) { System.out.println(System.getProperty("org.eclipse.swt.browser.XULRunnerPath")); Display display = new Display(); final Shell shell = new Shell(display); FillLayout layout = new FillLayout(); shell.setLayout(layout); final Browser browser; try { browser = new Browser(shell, SWT.MOZILLA); } catch (SWTError e) { e.printStackTrace(); display.dispose(); return; } shell.open(); browser.setUrl("http://get.webgl.org/"); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } } This is an addon on comment-28. I have retried with exactly the same environment/code, except using xulrunner 10 instead of xulrunner 12.0b1. It works fine! Thx to have brought back the eclipse/xulrunner operational (at least with xulrunner 10). Eric More tests: It also works here on Eclipse 3.7.1 (Build id: M20110909-1335) with XulRunner 10 (mac os x snow leopard, jdk7) (In reply to comment #30) > More tests: It also works here on Eclipse 3.7.1 (Build id: M20110909-1335) > with XulRunner 10 (mac os x snow leopard, jdk7) This should not be possble, I think you're either running with SWT 3.8M6, or are picking up a different installed XULRunner with version < 4. To see which XULRunner is being used insert as the first line of your snippet: "Device.DEBUG = true". (In reply to comment #27) > Is the latest SWT.MOZILLA Browser supposed to support webgl (see Comment 3)? The rendering capabilities of embedded XULRunner 10 should ideally match those of Firefox 10, so if WebGL works on your same machine with Firefox then it should work with XULRunner as well. Please log a new report for this issue. The Browser can turn the WebGL preferences on easily, but the crash you're seeing needs further investigation. (In reply to comment #31) > (In reply to comment #30) > > More tests: It also works here on Eclipse 3.7.1 (Build id: M20110909-1335) > > with XulRunner 10 (mac os x snow leopard, jdk7) > > This should not be possble, I think you're either running with SWT 3.8M6, or > are picking up a different installed XULRunner with version < 4. To see which > XULRunner is being used insert as the first line of your snippet: "Device.DEBUG > = true". True Grant, I am in fact launching from eclipse 3.7.1 with a declared dependency to org.eclipse.swt.cocoa.macosx.x86_64_3.8.0.v3823a.jar. Sorry, I was too short in my report. However, XPCOM error 0x80040111 with xulrunner is still the case. Eric Side note: I am upgrading a few project to latest xulrunner and missing the javaxpcom jars . After crawling and found (I think) everything that was possible to found on the removal of javaxpcom from mozilla code base, I am now looking to bring back the build, at least on mac os x platform. Any pointers, or additional information that could help me such as someone now working on this on a public repository... ? There is interest in getting JavaXPCOM back. I was in contact with Benjamin Smedberg (the Mozilla embedding maintainer) about this. He is willing to create a public repository on hg.mozilla.org. His advice is "rewriting" the Java code generation based on the new Python xpidl generator (xpidl.py) because the old C-based xpidl generator is dead. So basically you would take a xulrunner SDK release and let the Java xpidl generator run over it to generate the Java classes and build a JNI JavaXPCOM DLL. Here's the last Mozilla revision with JavaXPCOM: http://hg.mozilla.org/mozilla-central/file/8ad43371c469/extensions/java/xpcom (In reply to comment #32) > (In reply to comment #27) > > Is the latest SWT.MOZILLA Browser supposed to support webgl (see Comment 3)? > > The rendering capabilities of embedded XULRunner 10 should ideally match those > of Firefox 10, so if WebGL works on your same machine with Firefox then it > should work with XULRunner as well. Please log a new report for this issue. They don't match. I downloaded firefox 10.0.2 from: http://mirror.informatik.uni-mannheim.de/pub/mirrors/mozilla.org/firefox/releases/10.0.2/win32/en-US/ and pointed it to http://get.webgl.org/. I got this: "Your browser supports WebGL However, it indicates that support is experimental; you might see issues with some content." And the spinnig cube. So this doesn't seem like a problem with my machine. It appears that xulrunner and firefox (same release number) are shipped with different settings, regarding webgl. > The Browser can turn the WebGL preferences on easily, but the crash you're > seeing needs further investigation. I'm available for testing. BTW How do I turn webgl on from the Browser object? (In reply to comment #34) Thx Carsten, I was just thinking to the following process: - diff between the current and one of the latest version to see which configuration/build directives must be reenabled - I am now doing this. - Reinject the conf for javaxpcom based on the C xpidl, and correct the build errors to adapt the the newest APIs - Eventually migrate to the new xpidl.py But we are hijacking this bugzilla with unrelated content... Do you have another mozilla issue where we could follow the discussion? Thx, Eric > There is interest in getting JavaXPCOM back. I was in contact with Benjamin > Smedberg (the Mozilla embedding maintainer) about this. He is willing to create > a public repository on hg.mozilla.org. > > His advice is "rewriting" the Java code generation based on the new Python > xpidl generator (xpidl.py) because the old C-based xpidl generator is dead. > > So basically you would take a xulrunner SDK release and let the Java xpidl > generator run over it to generate the Java classes and build a JNI JavaXPCOM > DLL. > > Here's the last Mozilla revision with JavaXPCOM: > http://hg.mozilla.org/mozilla-central/file/8ad43371c469/extensions/java/xpcom (In reply to comment #36) There is the mozilla.dev.embedding newsgroup on news.mozilla.org. That's probably the best place for now. But putting back the C-based xpidl is not going to get us very far, I'm afraid. To update, a workaround for mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=720682 has been released, so the XULRunner 10 support now works on Linux (patch: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=ff8ec8fc1484c7eedcc70981458ecc23d5a64f37 ). Contrary to what I previously suggested, there are no additional steps required by SWT clients to get this to work, just use it as-is. I tried using xulrunner_10.0.2, the BrowserFunction to enable JavaScript callback into Java doesn't seems to work anymore, it works for previous xulrunner. Should I file a new bug for this issue? (In reply to comment #39) > I tried using xulrunner_10.0.2, the BrowserFunction to enable JavaScript > callback into Java doesn't seems to work anymore, it works for previous > xulrunner. Should I file a new bug for this issue? Are you using swt fetched directly from git today? This is the only way you can have the latest content because eclipse.org hasn't produced any real builds since 3.8/4.2M6. And if so, which platform are you using? I was using 3.8M6 build, now that I updated to the latest content from eclipse.org, this issue is fixed. Thanks for the advice to pull the latest content. I'm testing now integration of the SWT (3.8M6/3826 win32-x86) with XULRunner 10.0. I can reproduce problems with focus transfer within browser window using the TAB-key. Actually there is no reaction to this key at all. Could you guess if this bug will be fixed in the final build of 3.8? (In reply to comment #42) > I can reproduce problems with focus transfer within browser window using the > TAB-key. Actually there is no reaction to this key at all. This is now fixed, I've logged bug 376183 for tracking. I am seeing strange behavior for drag and drop support. I have couple dojo widgets hosted in the browser, the drop event for these widgets are not fired when the page is loaded within eclipse's Mozilla browser, but it works as expected for the standalone Firefox browser. Other events, such as dragover, dragenter, etc.. works. The strange thing is that sometime I do get the drop event. Want to download build v3828 from http://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/ It's not possible because of error. Could you look at it? Thank you for implementing this item. I can't seem to get any BrowserFunction (Javascript to Java bridge) working, i've tried with XULRunner 1.9.2, 10 and 10.02. This is with swt 3.8m6. When not specifying SWT.MOZILLA -or- if using swt 3.7 same code runs fine (callback code is reached in java). Also A note on the IsPre_4 flag in Mozilla class, there are now 2 checks done to set it: 1. Based on GRE_InitEmbedding2 presence (during initXPCOM) 2. Based on presence of interface (NS_IDOCSHELL_10_IID) 2nd method is problematic because of Mozilla un-freezing all interfaces, NS_IDOCSHELL_10 IID changes over time, as it did in Gecko12. This can now cause inconsistent state, since then IsPre_4 becomes set 'true' again, while nsISupports.IsXULRunner10 is also set 'true'. Not a big issue, since the end result is that getWebBrowser will return null because of IsPre_4 causing the wrong interface to be requested in getWebBrowser()(which it should as xul12 is not supported since interfaces changed). In short: the end result is 'correct', but the reasoning behind it maybe not and this doesn't seem future-proof should later on new xulrunner version support arise for SWT. Maybe just the GRE_InitEmbedding2 check is sufficient? Never mind the BrowserFunction part, I overlooked Bug 373253 Has anybody been able to successfully use WebGL with the current implementation of the Browser widget (version > 3.8M6)? So what's the status/plans for JavaXPCOM support? Will nsI* interfaces be supported for manual use (as Java classes)? (In reply to comment #49) > So what's the status/plans for JavaXPCOM support? I'd really like to see this, but the resources are not here to get the JavaXPCOM jars building again anytime soon. Apparently there's been significant breakage between their 3.6.x and 10.x releases that's relevant to this area, and a lot of effort is needed to make it work again. I _may_ have an opportunity to have a closer look in the fall, but not before then. If someone was to get them building again then effort would be made to ensure that XULRunner 10-based Browsers could use them. I want to update my XULRunner because my current version (1.9.2) crash the vm in some cases. Which version is the latest stable i can use for eclipse 3.7? (In reply to comment #51) > Which version is the latest stable i can use for eclipse 3.7? Eclipse/SWT 3.7.x has support for up to XULRunner 1.9.2.x. If you're seeing crashes with Eclipse/SWT 3.8.x or 4.2.x then please log a bug report, ideally with reproducible steps. Is it planned that the SWT.Browser will support newer XULRunner versions than version 10, like version 27? XULRunner 24 is already supported with Eclipse 4.4M5. See Bug 422561 (don't know why this bug isn't a duplicate of that one) (In reply to Christian Sell from comment #54) Makes sense, closing report as a duplicate. *** This bug has been marked as a duplicate of bug 422561 *** |
This could be useful for clients requiring an embedded cross-platform browser that exposes more of its internals than is typically available via JS. For example: String string = "var httpRequestObserver = {observe: function(subject, topic, data) {alert('called!');}};" + "var observerService = Components.classes[\"@mozilla.org/observer-service;1\"].getService(Components.interfaces.nsIObserverService);" + "observerService.addObserver(httpRequestObserver, \"http-on-modify-request\", false);" + "observerService.addObserver(httpRequestObserver, \"http-on-examine-request\", false);"; browser.execute(string); Note: Time-permitting item, not currently on the plan for 3.7.