GNOME Bugzilla – Bug 322795
Browser links do not issue remote commands to existing instances for netscape and mozilla
Last modified: 2008-02-01 23:18:22 UTC
Distribution/Version: CentOS 4 I have Netscape set as my preferred browser (under Preferred Applications). If I have Netscape already open and I click on a link from another application (e.g. from gaim, from the terminal, etc.) then gnome will attempt to launch another instance of Netscape rather than issuing a -remote command to utilize the existing version. This leads to Netscape complaining about my profile already in use, and will not open the link unless I select a different profile. This same problem occurs with Mozilla selected as the preferred browser. Firefox does not show this problem, however - it will open links without this error even when already running. This is most certainly an error with how gnome is handling calls to netscape and mozilla. For example, when using gaim's internal browser preferences, it will properly recognize when netscape is already running and issue a -remote command, so that profile conflicts are avoided. Steps to Reproduce: ------------------- 1) Select Netscape or Mozilla as the browser under the Preferred Applications preference box. 2) Launch Netscape or Mozilla (URL is irrelevant). 3) While Netscape/Mozilla is already running, click on a link from another application (e.g. a link in gaim, in terminal, etc.) At this point, you will get the ever-annoying "please select a profile" dialog, and Netscape/Mozilla will complain if you choose the profile that is already in use. This same thing happens if you use the "Launch Web Browser" keyboard shortcut instead of clicking a link. This is happening because gnome is indiscriminately issuing "$browser %s" as the command, without checking if the browser is already running. What SHOULD happen: ------------------- gnome should recognize when netscape/mozilla are already running, and if so, issue a "$browser -remote 'openURL(%s, new-window)'" command to utilize the existing browser session. If the browser is not running, gnome should issue the usual "$browser %s" command. The "new-window" option should also be a user-configurable preference (i.e. user can choose whether links are opened in an existing window or a new window). Workaround: ----------- The easiest workaround is to simply use firefox rather than netscape or mozilla, but this is not an acceptable option for many people. Currently, the only true workaround is to write a "netscape-helper" wrapper script that will perform the above actions (check for existing browser and act appropriately). A less robust workaround is to use the manual browser command of "$browser -remote 'openURL(%s,new-window)'" at all times, but this will fail if the browser is not already running. None of these are excellent options, and this bug should really be fixed in gnome specifically. gaim has browser-launching code that works the way that gnome's should: it allows the user to specify the browser or a manual command. For non-custom browsers, it will launch the browser or issue the appropriate -remote command if the browser is already running. Opening the link in a new or existing window is a user-configurable preference. gnome should operate in exactly this manner. (Note that newer versions of gaim will auto-detect if a recent version of gnome is running and will hide gaim's browser prefs, using the gconf values instead. To see gaim's browser prefs, run it under gnome 2.2.0 in RedHat 9, or when NOT using gnome.) Finally, a related issue: it appears that the gconf preference for default browser (/desktop/gnome/applications/browser/exec) is completely ignored. The "true" default browser is really the one under the url-handlers preference, as that is what the Preferred Applications dialog modifies and what every application seems to look at. Is the default-browser pref even used by anything these days? I've got mine set to firefox, but it never gets launched... everything goes through the url-handlers prefs (which is netscape, as described above).
I can confirm this bug on Fedora Core 5 test 3 plus updates (2006-03-16): Description of problem: If either: -Open link in new window -Open link in new tab the web browser will *not* actually open. Version-Release number of selected component (if applicable): rpm -qa|egrep 'control|mozilla|firefox'|sort control-center-2.14.0-1 firefox-1.5.0.1-9 firefox-debuginfo-1.5.0.1-9 libdc1394_control13-1.1.0-5.rhfc4.92.at mozilla-1.7.12-5 How reproducible: two machines Steps to Reproduce: 1. Preferred Applications 2. Internet|Web Browser 3. Choose Mozilla or Firefox 4. Choose either open in new link or new tab Actual results: Starting Web Browser dialog and "doing somtehing" mouse cursor for 10-15 seconds Expected results: Chosen web browser starts with either new window or new tab selected. More info: It appears the -remote command mentioned above is filled into the command box, but it doesn't start the browser at all: a profile dialog is not shown for the above two browsers. for mozilla (and firefox): if a window is already running then: mozilla & mozilla -remote "openURL(www.mozilla.org, new-tab)" or mozilla -remote "openURL(www.mozilla.org, new-window)" work OK, yet the preferred application setting does not work: Error: Failed to send command: 500 command not parseable Perhaps the command is getting screwed because it needs to be passed to the mozilla commandline within ""'s within another string. if mozilla not already running then you see: Error: No running window found.
*** Bug 370779 has been marked as a duplicate of this bug. ***
At least Iceweasel (Firefox) seems to use -new-window and -new-tab now.
Is this bug still valid?
Created attachment 103997 [details] [review] Add -new-tab and -new-window commands to iceweasel This was fixed for Firefox in bug 393204. I'm attaching a patch to also fix it for Iceweasel. It's also possible this needs to be changed for Seamonkey/Iceape too.
Seamonkey/Iceape doesn't in fact support -new-tab/-new-window.
2008-02-01 Jens Granseuer <jensgr@gmx.net> Patch by: Sven Arvidsson <sa@whiz.se> * gnome-default-applications.xml.in: support --new-tab/--new-window for Iceweasel (bug #322795)
Has this been fixed for Netscape and Mozilla, as well? Or are they no longer supported? With Mozilla and Netscape, attempting to send -new-window (or its equivalent) when the app is not already running will result in an error.
Is there a way do this for Mozilla and Netscape? There's nothing we can do if there isn't.
Well, there is a way, which is to issue a -remote command first, and if that fails (because no instance of the browser is currently running), to issue a "regular" command. I have currently implemented this via a wrapper shellscript called "netscape-helper," and have set my gnome browser prefs to call that script instead of calling the browser directly. However, you should be able to implement this directly within gnome... gaim/pidgin has that functionality built-in, for example. See the function pidgin_notify_uri() inside the file "gtknotify.c" within the pidgin source. (I can attach it if you'd like.) For reference, here's the netscape-helper shellscript I'm using as a workaround: #!/bin/sh netscape -remote "openURL(${1},new-window)" if [ $? -ne 0 ] ; then netscape ${1} fi The above should work identically for mozilla. Indeed, firefox *also* supports these -remote commands (but it will not fail if the browser isn't already running), so you could probably handle all mozilla-based browsers with the above (that's exactly what gaim/pidgin does, in fact).
The "preferred applications" capplet has a generic framework for launching other programs (browsers in this case). We certainly don't want to special-case certain browsers in the code unless we can help it (in this case, Mozilla and Netscape are pretty much niche browsers, so we *can* help it). The only way to properly support those two browsers seems to be by way of such a script as you are already using. However, using such a script by default would mean special-casing them again, so I don't think this is going to happen.
Jens, I understand, although I think you could actually handle all gecko-based browsers with the same code. Firefox supports -remote, and I think IceWeasel does as well. Therefore, you could handle all gecko browsers via the same method that gaim/pidgin uses, which is the same method as the shellscript... it requires essentially no special casing since Netscape, Mozilla, Firefox, and I think IceWeasel should all be able to handle the same -remote command. If it won't happen, it won't happen and I'll let it go, since I have a reasonable workaround. However, I do think you can implement this without special-casing, per above. Thanks. =)
(In reply to comment #12) > I do think you can implement this without > special-casing, per above. No, you can't. Special-casing all gecko browsers is still special-casing, and it doesn't really matter whether it's one or five browsers that make up the special case. The only way to do it without special cases is to use your script. What we *could* maybe do (I'd have to discuss this with the other maintainers) is to include a script like yours in the package and use the script as the Mozilla/Netscape command. That's not perfect, either, though: The script would always be present and as a result Mozilla/Netscape could be selected by the user even though they aren't really installed.
Jens, Ah, your explanation makes more sense now, thanks. I understand the desire to keep the code as clean and as universal as possible. I don't want to press you to violate the coding principles, as I do understand them. Seeing as I've contributed probably about as much as I can, I'll let this issue go now and leave the final decision in your capable hands. (If you do decide to implement the shell-script idea, you could code in an error message if mozilla/netscape are not installed; while it wouldn't stop the user from selecting that option, at least it would pop up a dialog letting the user know that the option won't work without one of the applicable browsers. To avoid special-casing in the gnome code, the error message could be coded into the shell-script.) Thanks again.