Community
Participate
Working Groups
On Solaris 10 SPARC, the default location of the web browser is /usr/sfw/lib/mozilla As per bug 77217 comment 41. If a mozilla is indeed detected in that location, the corresponding Preference should be set automatically under General > Web Browser > External Web Browsers. Moreover, Solaris 10 is a GTK / Gnome based system, and does have the concept of a default web browser just like Linux-GTK. When I launch a newly downloaded Firefox and allow it to register as default web browser, the following happens: (1) $HOME/.gnome/application-info/user.applications receives an Entry with ID "Firefox" pointing to my browser's install dir (2) $HOME/.gnome/mime-info/user.keys receives entries for text/html and application/xhtml+xml pointing to default_application_id=Firefox I see that Eclipse on other other Platforms does automatically set this "Default system web browser" Preference, so I'd expect it to be set on Solaris as well. The benefit of this fix would be that Solaris users don't have to manually enter their browser location any more.
See also bug 286314 about the GTK / Gnome browser registry.
Paul, I'm not sure who owns the browser component. I'm marking this one as IDE, please correct if I'm wrong.
I just stumbled over this again. Not having an external browser configured by default on Solaris 10 really is an annoyance. Our product ships with "Help" configured into the external browser by default, so doing Help > Index just brings up the "No Browser Configured" Dialog. The minimum I would propose is that the "No Browser Configured" dialog should include a hyperlink to open the respective Preference page for configuring the Browser. Otherwise, new users are pretty stuck with this. I just filed bug 291885 for this separate requested usability enhancement. But of course it would be better to configure the Solaris 10 external browser properly automatically. There can only be one browser, and it is always in /usr/sfw/lib/mozilla . And this must be configured in code somewhere (I don't know where) since it is platform specific -- I cannot equip our product with a plugin_customization.ini to do this. I could try providing a patch myself, if you guys could give me some hint where to start looking for the right place to configure the default external browser?
I'm increasing severity of this issue since we are repeatedly seeing this problem from our testers. What happens to a typical user is this: - Help > Help Contents - See the dialog about missing external help browser - Many users do not know about the browser in /usr/sfw/lib/mozilla - So they download a recent firefox and try to integrate it... ... but the integration DOES NOT WORK! Interestingly, Sun has managed to set up their browser and sharedlibs such that integrating an externally downloaded Firefox FAILS due to the LD_LIBRARY_PATH and MOZILLA_FIVE_HOME settings that we do in SWT for the internal browser. See also the many comments on bug 77217 about external downloaded Firefox versions. We have lost lots of time debugging this already. Therefore, from a usability point of view I think it is MANDATORY that the Solaris 10 default browser is configured as external web browser, no that we also support it as internal browser. Rather than checking what GNOME tells us about the default browser, if /usr/sfw/lib/mozilla exists then it should be configured as the default external browser.
Created attachment 149453 [details] Trivial patch fixing the issue Attached trivial patch fixes the issue. It looks like ages ago, somebody disabled default browser support on Solaris due to bug 94497. With the newer Solaris GTK builds, this limitation seems no longer correct, although I did not read through all the gory details of bug 94497. I successfully tested this on Solaris 10 GTK. I did not test on Solaris 9. Patch is against Eclipse 3.5, and I would like to see this backported to 3.5.2
If this is no longer a problem I don't mind "un-disabling" the solaris GTK browser calls, if the failure case is simply an error they can reset a preference and work around. PW
Paul, are you going to release the patch into 3.6m3 for initial exposure to the wider community?
Hi Paul, we would like to have this fix in our product which is based on Eclipse 3.5.x -- and rather than patching a plugin ourselves, we would prefer picking up a pre-built plugin from an M-build. What would you think is needed to get this patch into the 3.5.2 Stream? Can you give some ETA time when it could be in the 3.5.2 Stream? Many thanks, Martin
(In reply to comment #8) > What would you think is needed to get this patch into the 3.5.2 Stream? > Can you give some ETA time when it could be in the 3.5.2 Stream? Did the fix released to 3.6 solve the problem? While the fix seems pretty low risk, would it not re-introduce the problem related to bug 94497 "Help on solaris silently failing" for some cases? Or is that ship long since sailed, and we should be using the system browser on Solaris now? I have no boxes to test it on. PW
(In reply to comment #9) > Did the fix released to 3.6 solve the problem? For me, yes. > While the fix seems pretty low risk, would it not re-introduce the problem > related to bug 94497 "Help on solaris silently failing" for some cases? The fix explicitly sets up the Browser on GTK only. I believe that the bug 94497 issue would only occur on older Solaris boxes on which GTK cannot be installed -- GTK requires Solaris 9 at least, and it is shaky there, so we are only interested in Solaris 10 now. > I have no boxes to test it on. While I have tested on my box, I would much appreciate another tester (Chris?) to review the patch, its relation to bug 94497, and try it on another machine.
I don't have a Solaris box to test on either. For Eclipse 3.6 I committed the patch because it only affects Solaris, fixes a serious usability problem on Solaris, comes from reliable source and after reading the thread of comments on this bug and on bug 94497 I'm pretty convinced that it is safe. For release into 3.5.2 the standard of proof for release of the patch is significantly higher. I would need to be 100% convinced that it could not cause a regression and I'm not there yet. Still I would be interested to hear from more users of Eclipse 3.6 on Solaris to see how the fix is working there.
Created attachment 150420 [details] Improved patch as per bug 292882 comment 5 Attached improved patch (against R3_5) is safer and better, as discussed in bug 292882 comment 5.
(In reply to comment #11) > For release into 3.5.2 the standard of proof for release of the patch is > significantly higher. I would need to be 100% convinced that it could not cause > a regression and I'm not there yet. Still I would be interested to hear from > more users of Eclipse 3.6 on Solaris to see how the fix is working there. Could we get some feedback from Solaris users on the 3.6 version? If this is good I'd like to get it into 3.5.2 sooner rather than later. PW
I tried last week's I-build on Solaris 10 SPARC, and it seems to work. Invoking Help->Help Contents opened in the external browser successfully, as did opening an HTML file with the System Editor.
FYI, I found out in the meantime that there is a workaround for Solaris 10-GTK users of Eclipse 3.5.1 : Doing export PATH=/usr/sfw/lib/mozilla:$PATH before launching Eclipse also makes the default browser show up in the Eclipse Preferences. For our commercial product on top of Eclipse, I put this into the startup shellscript so we are good to go without a backport. For the larger community, though, I think it would be good to backport the patch such that Eclipse finds the default browser even without changing the system PATH.
Chris, can we consider this for 3.5.2 now? PW
If you are unsure, you could only backport the change to plugin.xml: <location>usr/sfw/lib/mozilla/mozilla</location> that should be 100% safe but still provide the desired result (system default browser auto detected on Solaris 10 GTK).
I like the idea of only backporting the change to plugin.xml. Given the history of this problem and the way the first patch to Bug 292882 which we thought was safe but turned out not to be I was getting ready to add a note to this bug saying that the fix did not meet the very high degree of confidence that we expect from fixes to 3.5.2. I will attach a patch which changes only plugin.xml, request a review and get the change committed.
Created attachment 154511 [details] Patch for plugin.xml only plus bundle version change
Looks OK for 3.5.2 PW
Comment on attachment 154511 [details] Patch for plugin.xml only plus bundle version change iplog + for contribution from Martin Oberhuber (Wind River)
Patch applied to 3.5 maintenance stream. Fixed.
Hm... Chris, I'm afraid that if you "iplog+" the attachment that you uploaded, the system will not recognize me as the contributor. I think you need to "iplog+" my obsolete patch instead (which was uploaded by me), even if only parts of that patch were taken. On the other hand, given that I'm a Platform/Core committer, I'm not sure whether my contributions to another Eclipse Platform component even need to be iplog+'d (I think they don't need to). You should be able to check the outcome here: http://www.eclipse.org/projects/ip_log.php?projectid=eclipse.platform
Comment on attachment 150420 [details] Improved patch as per bug 292882 comment 5 Adding the iplog + to the obsolete patch
