Description of problem:
(Filing this with eclipse, as there is no libswt3-gtk target in bugzilla)
The internal browser in eclipse - Window->Show View->Other->General->Internal
Web Browser - does not work.
Version-Release number of selected component (if applicable):
[angenenr@shutdown backup]$rpm -q eclipse-platform libswt3-gtk2
(In both only upstream branding has been removed)
Try to open the internal web browser in eclipse. This will error out with:
No more handles (java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3235 in
org.eclipse.swt.SWTError: No more handles (java.lang.UnsatisfiedLinkError: no
swt-mozilla-gtk-3235 in java.library.path)
Browser doesn't work.
Browser should work.
This seems to be a problem with changing from firefox-1.5 to firefox-3.o and the
accompanied change from libgtkmozembed to xulrunner.
libswt3-gtk2 lost the mozilla component and there isn't a xulrunner replacement
available - at least libswt3-gtk2 doesn't offer one and eclipse is still
searching for the old lib which was available in 5.1.
This is intentional. It was impossible to back-port the 3.4 SWT-xulrunner to
the version of the SDK we're shipping.
Besides making the internal web browser non-functional, this issue also causes
Eclipse to crash if the JavaDoc view is opened, and will prevent it from being
restarted until XULRunner is completely disabled in eclipse.ini.
This is a major showstopper for both me and my users; I find the NOTABUG label
wholly inappropriate. Is there a recommended workaround, or planned update
release that will fix this?
(In reply to comment #2)
> Besides making the internal web browser non-functional, this issue also causes
> Eclipse to crash if the JavaDoc view is opened
I can't reproduce this. Can you paste here the output of:
rpm -qa | egrep "eclipse|swt"
for f in `rpm -aq | egrep "eclipse|swt"`; do rpm -qV $f; done
readlink -f `which java`
readlink -f `which javac`
> I find the NOTABUG label wholly inappropriate.
The NOTABUG resolution was for the initial report of the internal browser not
working. Since that was intentional due to the Firefox upgrade, I thought
saying it wasn't actually a bug was correct.
I would suggest putting -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null
in eclipse.ini but does Eclipse 3.2.1 even have that code path?
(In reply to comment #3)
> I would suggest putting -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null
> in eclipse.ini but does Eclipse 3.2.1 even have that code path?
I found that simply downloading the latest xulrunner and setting
-Dorg.eclipse.swt.browser.XULRunnerPath seemed to get the internal browser
running again. This whole thing caused me terrible problems with the zend
debugger for PHP until I found this bug report.
A recent blog entry has implied that this situation is simple to fix on Red
Hat's part and that Red Hat is unwilling to do so. This is far from the truth.
The problem is that Firefox was updated in RHEL 5 and this caused an
incompatibility issue with the SWT shipped in RHEL 5. The problem is solved in
the latest release of Eclipse -- 3.4 -- but we cannot back-port that code into
Eclipse 3.2 and we can't upgrade to latest Eclipse because of RHEL 5
dependencies. So, our only choice was to disable the internal web browser.
When used with our RPMs, everything still works as the help system et al fall
back to using the external web browser. If anyone is experiencing problems with
the SDK we ship, please provide the requested information as mentioned in
comment #3 and describe how we can reproduce the errors you are seeing.
The XULRunnerPath variable support was added post-3.2.1 which is what we are
shipping in RHEL 5. According to the CVS logs, it was only added on 2008-03-12
We obviously can't support random third party plugins, but if there are serious
issues using them with our packages, one could always run them on top of an
upstream download of Eclipse (which we also can't support). Since it appears
many of those CC'd here are doing this, are any of you still experiencing
issues? I thought there was something that got fixed between Firefox 3.0b5 and
3.0 final to make eclipse.org 3.4 downloads work.
(In reply to comment #4)
> (In reply to comment #3)
> > I would suggest putting -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null
> > in eclipse.ini but does Eclipse 3.2.1 even have that code path?
> I found that simply downloading the latest xulrunner and setting
> -Dorg.eclipse.swt.browser.XULRunnerPath seemed to get the internal browser
> running again. This whole thing caused me terrible problems with the zend
> debugger for PHP until I found this bug report.
Peter, in light of #5, how did you manage to get this working? I tried downloading the latest version of xulrunner (which seems to be the same one included in the centos 5.2 package) and pointing to it as you suggest, but no luck. Any details you could provide would be very helpful. Thanks.