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)
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
Comment 2•20 years ago
|
||
Interested to see if this gets fixed with the bug fix in post above this one.
Reporter | ||
Comment 3•20 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•20 years ago
|
Flags: blocking-aviary1.1?
Updated•20 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Updated•19 years ago
|
Flags: blocking-aviary2.0?
Comment 4•19 years ago
|
||
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•19 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•19 years ago
|
Flags: blocking-firefox2-
Flags: blocking-aviary1.5-
Comment 6•8 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
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•