xremote 'new-tab' doesn't honour browser.tabs.loadInBackground

RESOLVED INCOMPLETE

Status

()

Core
X-remote
--
enhancement
RESOLVED INCOMPLETE
15 years ago
2 years ago

People

(Reporter: bbaetz, Assigned: blizzard)

Tracking

1.4 Branch
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
If you open a url in a new tab via xremote (eg from xchat), then it always goes
to the front. Instead, it should load in the background if
browser.tabs.load-in-background is set.

The usual use case is to see a URL on IRC/etc that looks interesting, and then
load it up to look at later afer I've finished doing whatever I'm in the middle
of. I can see an argument that the externally loaded case is different to the
'loaded from a browser' case, but I'm not sure that I'm convinced by it.

Comment 1

14 years ago
NB: there is no pref named browser.tabs.load-in-background. But lest you
implement something that uses the actual pref with nearly that name, know that
other bugs have already been written relying on a different pref. This bug is
basically the Linux version of (nominally cross-platform but so far patched only
on Windows) bug 255123.
Depends on: 255123

Comment 2

14 years ago
Interested to see if this gets fixed with the bug fix in post above this one.
(Reporter)

Comment 3

14 years ago
OK, so I misspelt it. Its the pref that controls whether
rightclick->open_link_in_new_tab pops the new tab to the foreground or not.

See http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#2593

Its on by default; no idea whether thats changed since I filed this.

Its not the same issue - the other bug is a windows thing, not a tab thing; I
don't care (for the purposes of this bug) whether the window comes to the
foreground or now.
Summary: xremote 'new-tab' doesn't honour browser.tabs.load-in-background → xremote 'new-tab' doesn't honour browser.tabs.loadInBackground

Updated

14 years ago
Flags: blocking-aviary1.1?

Updated

13 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1-

Updated

13 years ago
Flags: blocking-aviary2.0?
Really, this as reported is invalid, at least for Firefox, since it uses browser.tabs.loadDivertedInBackground to control external link locations (separate from content-links you manually open in a tab, since those are different use cases, and indeed have different defaults.
Flags: blocking-aviary2? → blocking-aviary2-

Comment 5

13 years ago
(In reply to comment #0)

> The usual use case is to see a URL on IRC/etc that looks interesting, and then
> load it up to look at later afer I've finished doing whatever I'm in the middle
> of. I can see an argument that the externally loaded case is different to the
> 'loaded from a browser' case, but I'm not sure that I'm convinced by it.

Is this what happens when looking at, for example, a bunch of forum (or bug) links in Thunderbird email. I want to click, delete, click, delete, click, delete on three messages in a row and have it open three (or twenty!) tabs with info; then close Thunderbird and look at the open tabs one at a time. Older versions of Firefox USED TO do this. I think it changed around .8 or .9.

Updated

13 years ago
Flags: blocking-firefox2-
Flags: blocking-aviary1.5-

Comment 6

2 years ago
Mass resolving a bunch of old bugs in the x-remote component in preparation for archiving it. If this bug is still valid and useful, please move it to the "Toolkit: Startup and Profile System" component and reopen it.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.