Description of problem: /usr/bin/seamonkey script forces urls to be opened in new window instead of letting user preferences decide. Version-Release number of selected component (if applicable): seamonkey-1.1.16-1.fc11.i586.rpm How reproducible: every time Steps to Reproduce: 1. open seamonkey 2. in preferences for tabbed browsing select new url's open in new tabs in current window 3. /usr/bin/seamonkey http://cnn.com Actual results: a new seamonkey window opens Expected results: a new tab in the current seamonkey window opens. Additional info: Fix to /usr/bin/seamonkey is change the 3rd from last line of the script from exec $MOZ_CLIENT_PROGRAM "openurl($opt,new-window)" 2>/dev/null >/dev/null to exec $MOZ_CLIENT_PROGRAM "openurl($opt)" 2>/dev/null >/dev/null
This isn't a bug, but a feature request. I disagree to make this change. "Open in a new window" is a safe operation for everyone. With your proposed change, if some other application starts seamonkey, the user may lose the work in the current window. A better change might be to improve the seamonkey start script to accept another parameter.
If you produce a patch that adds such a new parameter, or if you disagree with my words, you may reopen this bug or file a new one (for the new feature). Thanks.
The current behavior of your /usr/bin/seamonkey script is different from the behavior you get by calling the /usr/local/seamonkey/seamonkey script that comes with the seamonkey stock package. I got the behavior I wanted (determined by my seamonkey preferences) when I used that script. It seems to me the whole point of your /usr/bin/seamonkey script is to provide a static location to provide this behavior because you put seamonkey in version specific directories. If a new URL is opened in a window you are already using the back button will get you back to your original URL, nothing is lost. Adding this behavior as another parameter to the script, instead of default behavior, would also break compatibility the stock script. I'm using this script from alpine to display links/attachments, etc, and it expects the stock behavior, as, I expect, would most apps that call this.