See: http://blogs.testbit.eu/timj/2006/11/24/24112006-how-to-start-a-web-browser/ (page moved)
Last week i got a bug report where activating “Help/Quick Start”, “Help/FAQ” and any other web browser related menu item in Beast would do nothing.
That of course completely defeats the purpose of writing help documents and offering help via the menu.
Luckily, we were able to get browser launching debugging print outs in that scenario, and what happened was:
* Beast started up gnome-open
with the help URL.
* Since gnome-open
was present on the system and could be started, browser launching was considered successful and no error dialog had to be displayed.
* gnome-open
in turn would error out (for unknown reasons):
Error showing URL: There was an error launching the default action command associated with this location.
The problem here is clearly that Beast wrongly assumed launching a browser or script successfully would be enough. I’ve since reworked the logic so that:
* Browser launch scripts/programs are now always started in the foreground to verify their respective exit codes.
* A correctly functioning browser launcher now has to reliably start the browser in the background and has to provide a correct exit code.
* Graphical browser programs are started in the background, because browsers can reasonably be expected to show a URL once started successfully. Besides that, the exit code depends on other events during a browsing session anyway and it also is only provided at the end of a browsing session.
* If no browser launching script with 0 exit code could be started and no browser program could be started successfully in the background, a descriptive error dialog is shown, including the target URL.
I had to test out a bunch of browser launchers to get this to work reliably, and some of the launchers that fell short to be usable really came at a surprise:
* gnome-open
(GNOME) – the browser is opened in the background, and if no browser could successfully be launched a non-0 exit code is provided.
* exo-open
(XFCE) – browser is opened in the background, provides correct exit code.
* kfmclient
(KDE) – browser is opened in the background, provides correct exit code.
* gnome-moz-remote
(old GNOME) – browser is opened in the background, provides correct exit code.
* browser-config
(Gentoo) – this script goes through some lengths to make sure all browsers are opened in the background, but then it always quits with an exit code of 0, even if no browser was configured and launched.
* xdg-open
(Portland) – provides correct exit code, but the browsers are unpredictably launched in the foreground or background (usually depending on whether a running browser instance already exists or not).
* sensible-browser
(Debian) – provides correct exit code, but unpredictably opens in foreground or background.
* htmlview
(Red Hat) – provides correct exit code, but unpredictably opens in foreground or background.
In the end, the Linux distribution launchers that i was really hoping for to get user configuration right (honor $BROWSER
) and work reliably across desktops failed short to do so (browser-config
, xdg-open
, sensible-browser
and htmlview
), while all the desktop project launchers fullfiled the required needs (gnome-open
, exo-open
and kfmclient
). For everyone interested, the current browser launching code used in Beast now can be found here:
http://svn.gnome.org/viewsvn/beast/trunk/birnet/birnetutils.cc?view=markup – scroll to “url_test_show
“.