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 eclipse-platform-3.2.1-19.el5.centos.x86_64 libswt3-gtk2-3.2.1-19.el5.centos.x86_64 (In both only upstream branding has been removed) How reproducible: 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 java.library.path) org.eclipse.swt.SWTError: No more handles (java.lang.UnsatisfiedLinkError: no swt-mozilla-gtk-3235 in java.library.path) Actual results: Browser doesn't work. Expected results: Browser should work. Additional info: 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. Reference: https://bugs.eclipse.org/bugs/show_bug.cgi?id=235020 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 java -version readlink -f `which java` which javac 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 for 3.4. 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.