Closed Bug 276808 Opened 18 years ago Closed 15 years ago
URL($xuri,new-tab)" now opens new window instead of tab
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050101 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20050101 mozilla-xremote-client "openURL($xuri,new-tab)" (as invoked from EXMH when I click an URL in a msg) worked reliably as recently as mozilla1.8a6.20041129 but now that I't the mozilla1.8a6.20050101 build it ALWAYS opens a new window instead of just using a tab in an existing window. Reproducible: Always Steps to Reproduce: 1. from Linux command line (with Mozilla already running) just say mozilla-xremote-client "openURL(http://www.mozilla.org/,new-tab)" ...and a new window will be opened instead of a tab. Actual Results: A new window is opened instead of a tab Expected Results: A new tab in an existing window should have been created.
Confirming. This is a major loss of functionality. Requesting blocking status.
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's actually worse than that. mozilla -remote 'openURL(http://mozilla.org)' also opens in a new window, even without the new-tab. There seems to be no way to call mozilla -remote now without opening a new window. Eek!
There's a new pref, browser.link.open_external, which according to a terse comment on http://www.mozilla.org/unix/customizing.html#prefs should affect this behavior somehow. But I've tried setting it to 1, 2, and 3 via about:config (user.js seems to be no longer working in 1.8a6!) and with all three settings mozilla -remote 'openURL(http://mozilla.org)' opened a new window. The comment on the customizing page notes: "(May not work quite right in 1.8a Suite builds on Windows)" but the pref seems to be completely ignored on Linux, so that comment may not go far enough.
DanM, is this behavior related to the other tabbed browsing prefs we were discussing in bug 278429?
I'm changing this bug's product to Suite. Sure it's more a core problem but in this case there really is an app distinction. This works in Firefox, though bug 267435 maintains that it's partially broken there. I'm prepared to believe that it's completely broken in the Suite. See bug 278867.
Component: Tabbed Browser → General
Depends on: 278867
Product: Core → Mozilla Application Suite
*** Bug 278437 has been marked as a duplicate of this bug. ***
In Japanese bugzilla one reported that make with 'cvs co -r1.44 mozilla/xpfe/components/xremote/src/XRemoteService.cpp' is not reproduced. relate bug 172962, 263689?
Too late for 1.8b, but it should block 1.8b2.
isn't this fixed? I can't reproduce this since two or three weeks now. But will check again.
Bug 231984 helped but I would have thought it wasn't enough. Still if you find that everything is working, may as well close the bug.
WFM now with 20050223 build.
Marking worksforme based on comments.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Not fixed: reopening. In 1.8b1, opening as new-tab works; but attempting to open in the same tab/window (see comment 2) opens in a new tab as well.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Mozilla/5.0 (X11; U; Linux i686; rv:1.9pre) Gecko/2008040301 SeaMonkey/2.0a1pre Working as expected. Reopen if your test differs.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.