Bug 452113 - Eclipse internal browser doesn't work
Eclipse internal browser doesn't work
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: eclipse (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Andrew Overholt
eclipse-bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-19 09:53 EDT by Ralph Angenendt
Modified: 2008-10-06 20:51 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-23 11:29:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralph Angenendt 2008-06-19 09:53:39 EDT
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.
Comment 1 Andrew Overholt 2008-06-23 11:29:05 EDT
This is intentional.  It was impossible to back-port the 3.4 SWT-xulrunner to
the version of the SDK we're shipping.
Comment 2 Brandon Davidson 2008-07-03 04:49:14 EDT
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?
Comment 3 Andrew Overholt 2008-07-04 08:59:09 EDT
(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?
Comment 4 Peter Hearty 2008-07-08 13:22:36 EDT
(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.
Comment 5 Andrew Overholt 2008-07-15 17:13:47 EDT
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.
Comment 6 Tom 2008-10-06 20:51:47 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.