Community
Participate
Working Groups
For situations where the existing, platform-browser-based Browser control is not sufficient, we should support embedding of Mozilla on all platforms. This would allow developers to implement code that worked against a common back end, so that they could access a common DOM, or surface the browser's HTML editing support. [SWT]
An enthusiastic +1 here.
is the plan to embed XUL runner in a bundle and re-use the Mozilla packaged xpcom eclipse plugin? Would that be similar to the Web tools ATF approach? Is there an explicit provision in "everywhere" to at least support win, linux and mac? Has the work started? How can we help?
>>> is the plan to embed XUL runner in a bundle and re-use the Mozilla packaged xpcom eclipse plugin? I don't think that eclipse or swt would include xulrunner, the user would have to download and install it (or just have it by default if they're on a new linux distro). It will be a separate widget that can contain a xulrunner-created browser, which a developer could communicate with via JavaXPCOM. > Would that be similar to the Web tools ATF approach? Yes, probably with a reduced API set. > Is there an explicit provision in "everywhere" to at least support win, linux and mac? Yes > Has the work started? The ATF work is the start on this. An initial investigation of this has been done, but this item is currently in queue behind 64-bit XP for serious implementation effort. > How can we help? OSX looks like it will be the most difficult part of this, and ATF does not provide any implementation here. There's currently an incomplete patch in bug 78048. Maybe someone can complete it? ;-)
(In reply to comment #3) Thanks Grant! > > Would that be similar to the Web tools ATF approach? > Yes, probably with a reduced API set. Why would you reduce the API? Where? What would be the rationale? > > Has the work started? > The ATF work is the start on this. An initial investigation of this has been > done, but this item is currently in queue behind 64-bit XP for serious > implementation effort. Ok the way it is done in ATF (at least in CVS) would benefit from a fragment split for each platform, as opposed to use one swt fragment for wll platform using the same ID /version regardless of the platforms. I'll be submitted a patch there. > > How can we help? > OSX looks like it will be the most difficult part of this, and ATF does not > provide any implementation here. There's currently an incomplete patch in bug > 78048. Maybe someone can complete it? ;-) I will definitely get a look into it.
>Why would you reduce the API? Where? What would be the rationale? In ATF there are some convenience methods that just make a JavaXPCOM call or two which a client could have made, for example AbstractMozillaBrowser.getDocument(). Methods like these will likely not be kept. (In reviewing the public methods in AbstractMozillaBrowser I now realize that many of them are answering JavaXPCOM callbacks, so are not intended solely as client API as I had previously thought). Be assured that there will be no loss of functionality as a result of trimming the apis.
Like to see it is supported some day.
Is there a 3.3 Milestone target for this yet? I noticed the 3.3 development plan on the website is WAY out of date. Thanks
Setting target to 3.3M5.
anyone here that's not also on bug 79213 should see https://bugs.eclipse.org/bugs/show_bug.cgi?id=79213#c46
Time to mark this as fixed?
too bad... we still need manually install the XULRunner and we cannot just install FireFox... Anyway to solve this ?
only if https://bugzilla.mozilla.org/show_bug.cgi?id=262453 gets addressed, which I don't think it will
In a perfect world, adding a 'org.mozilla.xulrunner' plugin into the eclipse install or in a RCP application whould enable the use of mozilla-based SWT Browser widget. Is it possible right now to create such a plugin ?
Important initial disclaimer: I don't know if there are legal issues associated with shipping xulrunner in any form with your app, so you should investigate this first. These plug-ins exist (though I have not tried them) from mozilla.org: http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse/ If you want to point the Browser at a specific XULRunner location, rather than having it find a registered one at runtime, you can set system property org.eclipse.swt.browser.XULRunnerPath to point at it BEFORE the first Browser instance has been created. Presumably there's some eclipse API that can be used to determine where the xulrunner plugin's content gets auto-extracted to by the platform.
This is completed in 3.3, marking as FIXED.
These XULRunner plugins on Mozilla.org work in ATF since they use an ATF extension point to register XulRunner. The extension code is very simple, As part of using the SWT Mozilla browser. the ATF code checks to see if the extension is defined, and sets the property "org.eclipse.swt.browser.XULRunnerPath" to location of XULRunner in the plugin. I have opened IPZilla CQ: 1528(http://dev.eclipse.org/ipzilla/show_bug.cgi?id=1528) to start the legal reviews to ship XULRunner 1.8.1.3. I have also opened IPZilla CQ: 1509 (http://dev.eclipse.org/ipzilla/show_bug.cgi?id=1509) for shipping JavaXPCOM Version: 1.8.1.3
I tried both of this line and both crash the VM. I'm using 1.4.2 It run fine if I register the XULRunner with -register-xxxxx Any ideas ? -Dorg.eclipse.swt.browser.XULRunnerPath=C:\Progra~1\xulrunner and System.setProperty("org.eclipse.swt.browser.XULRunnerPath", "C:\\Progra~1\\xulrunner"); Exception :- java.lang.NullPointerException Message box shown :- Microsoft Visual C++ Runtime Library Runtime Error! Program: C:\Program Files\jre142\bin\javaw.exe R6025 -pure virtual function call
oppss!!!!!!!! my mistake!!!! sorry guys!!! I'm so sorry!!! Is my code cause the syetem crash! I used wrong test code. sorry
Pinging on the bug because it changed while Bugzilla e-mail notifications were turned off. Please look at this bug (click on "View Bug Activity" under "Related actions") to see what the change was.
(In reply to comment #19) > Pinging on the bug because it changed while Bugzilla e-mail notifications were > turned off. Please look at this bug (click on "View Bug Activity" under > "Related actions") to see what the change was. Only the "CC list" changed (one person was added).
