Community
Participate
Working Groups
Build ID: I20080523-0100 Steps To Reproduce: 1. Have the Javadoc view open (this usually aborts Eclipse) 2. Try to restart 3. Eclipse comes up, loads it's plugins and then hangs with an empty dialog box (the splash is gone). More information: There appears to be something wrong with the xulrunner. You can "fix" the problem by setting -Dorg.eclipse.swt.browser.XULRunnerPath=/dev/null in eclipse.ini. I run Hardy x86 (32 bit).
Same here, 3.4RC3, when initially starting up a fresh install with a new workspace. Ubuntu Hardy 32bit, Firefox 3.0b5.
This is going to be logged ~a million times in the coming week, so I'll explain what's happening in more detail here: mozilla changed its 1.9-stream nsIDocShell interface in early May (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=213194#c14) which Browser.setText() depends on for setting its text content. swt adapted to use this new interface as of 3.4RC3. This means that the following combinations should work: - swt 3.4M5-3.4RC2 with xulrunner 1.9/firefox 3.0 betas from before May - swt 3.4RC3 and newer with xulrunner 1.9/firefox 3.0 betas newer than early May Other combinations of swt with xulrunner 1.9/firefox 3.0 betas will not work. swt is now where it should be because the 1.9-stream mozilla interfaces it uses when it releases in June will match the interfaces in the xulrunner 1.9/firefox 3.0 releases (coincidentally also in June). However there's currently the potential for a mis-match since some linux distros are making xulrunner 1.9/firefox 3.0 betas available via auto-update at various schedules. The empty error dialog should be showing an error resulting from the mis-matched interface, but for some reason is failing. This is logged as bug 234910, so marking report as a duplicate. *** This bug has been marked as a duplicate of bug 234910 ***
*** Bug 235541 has been marked as a duplicate of this bug. ***
*** Bug 248617 has been marked as a duplicate of this bug. ***
