| Specifying Mozilla Version for SWT Browser [message #547005] |
Wed, 14 July 2010 18:50  |
Eclipse User |
|
|
|
I have an RCP app that includes a SWT Browser. A site that I need to view in the browser works with Firefox 3.x but not with earlier versions. I have FF 3.0.5 on my system (RedHat Linux 5), as well as xulrunner 1.9, and I can't find out how to point the SWT Browser to the former instead of the latter.
Whether I specify a value for org.eclipse.swt.browserXULRunnerPath or not, the Browser detects the xulrunner there and uses it. And judging by the way the page renders, the GRE provided in this way is not the proper version.
I set env variables MOZILLA_FIVE_HOME and LD_LIBRARY_PATH to point to the FF 3.0.5 installation, but the Browser still instantiates from xulrunner.
I don't have the option of updating xulrunner on this system, so I need to either somehow make xulrunner invoke FF 3.0.5 or point the SWT Browser to FF 3.0.5.
Any ideas?
|
|
|
| Re: Specifying Mozilla Version for SWT Browser [message #547103 is a reply to message #547005] |
Thu, 15 July 2010 10:10  |
| Eclipse User |
|
|
|
Hi,
The Gecko renderer in Firefox 3.0.x is 1.9.0.x, so pointing the Browser at
either of these should render approximately identically. It sounds like you
haven't been able to make the Browser use your Firefox 3.0.5, so are you
saying that a page showing in the Browser control looks different than the
same page in stand-alone Firefox 3.0.5? If so then perhaps it's a Browser
bug?
To verify that the Browser is attempting to use the native renderer that you
think it is see http://www.eclipse.org/swt/faq.php#printmozillapath . If
set, the "org.eclipse.swt.browser.XULRunnerPath" environment variable takes
precedence over any other means of specifying a renderer, so if you set this
property to point at your Firefox when running this snippet then you'll know
for sure that it's trying what you want. Note that if your Firefox is
statically-linked (which is often the case) then it cannot be embedded, and
this test snippet will fail when it attempts to use it.
Grant
"Mark Leone" <midnightjava@verizon.net> wrote in message
news:i1lf04$957$1@build.eclipse.org...
>I have an RCP app that includes a SWT Browser. A site that I need to view
>in the browser works with Firefox 3.x but not with earlier versions. I have
>FF 3.0.5 on my system (RedHat Linux 5), as well as xulrunner 1.9, and I
>can't find out how to point the SWT Browser to the former instead of the
>latter.
>
> Whether I specify a value for org.eclipse.swt.browserXULRunnerPath or not,
> the Browser detects the xulrunner there and uses it. And judging by the
> way the page renders, the GRE provided in this way is not the proper
> version.
>
> I set env variables MOZILLA_FIVE_HOME and LD_LIBRARY_PATH to point to the
> FF 3.0.5 installation, but the Browser still instantiates from xulrunner.
>
> I don't have the option of updating xulrunner on this system, so I need to
> either somehow make xulrunner invoke FF 3.0.5 or point the SWT Browser to
> FF 3.0.5.
>
> Any ideas?
|
|
|
| Re: Specifying Mozilla Version for SWT Browser [message #547144 is a reply to message #547103] |
Thu, 15 July 2010 12:52 |
| Eclipse User |
|
|
|
Thanks for your response, Grant.
I looked over the SWT FAQ previously, and tried the snippet for identifying the Mozilla instance. It shows me that the Browser is using the GRE at /usr/lib/xulrunner-1.9, whether I specify the XULRunnerPath property or not. I saw in the debugger that it comes up with it via a static call to XPCOMInit.
I also tried setting the value of XULRunnerPath to point to my firefox 3.0.5 installation. When I do that I get a SWTError with message: XPCOM error -2147467259. I assume this is because I don;t have firefox compiled with the linkable Gecko libraries? I saw a note somewhere that I would get the "No more handles" error message in that case. Either way, should I see libxpcom.so in my FF installation directory if it's dynamically linked? That's the library that is added to the MozillaPath when I point to xulrunner-1.9. I have a number of systms here I can try to work with, and it would be nice to be able to tell from looking at the FF installation which one is dynamically linked.
I'm going to see if the SA here can compile FF with the linkable Gecko libraries, but I don;t know if he'll be able to. I was wondering if there's a way to make xulrunner link back to the FF installation. I noticed that I can run xulrunner path/to/firefox/installation and it launches FF from there. But I don't know if there's a way to make it work that way when the SWT Browser invokes xulrunner.
As far as the different behavior between xulrunner and Firefox 3.0.5: here's what's happening. The browser is loading a page with a JavaScript client that connects to a map server (a customized version of WMS), where the user needs to select an area, after panning and zooming.
With FF 3.0.5, this works as expected. With the SWT Browser based on xulrunner-1.9, when the user selects an area, the selection does not persist when the mouse button is released, and an unintended zoom occurs as well. I saw similar behavior (except for the unintended zoom) previously when I tried to view the map with a FF 1.x browser. This is why i assumed there is a rendering issue with xulrunner as compared to FF 3.0.5. Does that make sense, from your knowledge of the rendering engines in each, or are you saying that FF 3.0.5 and xulrunner-1.9 use the exact same engine?
|
|
|
| Re: Specifying Mozilla Version for SWT Browser [message #547200 is a reply to message #547144] |
Thu, 15 July 2010 18:17 |
| Eclipse User |
|
|
|
I found an installation of FF 3.0.7 with linkable libraries, and was able to point the XULRunnerPath to it. However, it did not fix the rendering problem.
Playing around in the JavaScript a while, i found that the event listeners were not firing for some inexplicable reason. This led me to the realization that i was not using the SWT Browser properly. I had earlier discovered that window.open() was not working in the SWT Browser, and I had set the value of window.location to the desired URL as a workaround. While this effectively loaded the URL, it didn't enable the Browser to be properly initialized with a WindowOpenListener, as explained in this post
I still don't quite understand why failing to do this caused the rendering issues I was seeing, but it is working properly now that I'm initializing the Browser as illustrated in the WindowEvent API.
|
|
|
Powered by
FUDForum. Page generated in 0.03647 seconds
Home