Closed Bug 226826 Opened 21 years ago Closed 8 years ago

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

Categories

(Core Graveyard :: X-remote, enhancement)

1.4 Branch
x86
Linux
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: bbaetz, Assigned: blizzard)

References

Details

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.
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
Interested to see if this gets fixed with the bug fix in post above this one.
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
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
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-
(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.
Flags: blocking-firefox2-
Flags: blocking-aviary1.5-
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
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.