Closed Bug 56690 Opened 24 years ago Closed 14 years ago

Allow opening link in a new background window (behind current window)

Categories

(SeaMonkey :: UI Design, enhancement, P4)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: mpt, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [p-opera] [p-icab] [p-omniweb] [p-ie/mac] [p-safari]) 

Mozilla should offer a modifier key to open a link in a new window which opens 
immediately behind the current window. That way, multiple links on the same page 
can be opened into new windows without the user having to return focus to the 
original window each time.

If Control+click/Command+click is going to be used to open a link in a new 
frontmost window (bug 12056), then I suggest Ctrl+Shift+click/Command+Shift+click 
be used for opening in a non-frontmost window; it is a variation on the behavior 
requested in bug 12056, and Shifted shortcut keys are often used for variations 
on the commands performed by their respective unShifted shortcuts.
taking.

Dan, can you point me towards how this might be implemented in JS?
Assignee: don → blakeross
Blocks: 42557
Adding Bug 42557 as dependent on this one, because this bug (56690) asks (at
least in part): how to send a window to back (and then hooking up the shortcut
isn't hard I'm sure). 42557 asks this question too, as well as "How do you tell
the window to then stay put in back of all other Mozilla windows?" 42557 would
be a button, but it could be a keyboard shortcut, too. I thought someone might
have a revelation while working on this one on how to fix that one, too, is all.

Bug 42557 asks about putting an existing window behind *all* other windows: this 
bug asks for opening a new window behind *just* the frontmost window (but in 
front of all the other windows). I don't think the dependency is valid.
No longer blocks: 42557
  Blake: you asked for implementation notes. The short answer is, the C++ code 
currently doesn't have support enough or hooks enough to be able to do this in 
JS. But it's probably not very far from it.
  As Matthew noted there are notes in bug 12056 about capturing the keyboard 
modifier state. I haven't gone through the whole thing, but I gather it's not 
working yet since the bug hasn't been closed.
  To adapt that to service bug 42557 and this one, you'll have to somehow capture 
the mouse info and turn it into some sort of flag that window.open understands. 
Our little window manager does understand something of window layering: we've 
implemented the alwaysRaised and alwaysLowered features flags from Navigator 4. 
That's not quite what you want, though: you want a browser window which *could* 
be brought to the front.
  We're already playing pretty loose with the window.open "standards"; it's 
possible we could implement a features flag that opens a window in a temporarily 
lower layer and then promotes it to the normal browser layer so it remains behind 
but is otherwise a normal browser window (note this would make it open behind all 
other browser windows; not just behind the current active browser window. I 
suppose that too would be possible, but would take more hacking in the layer 
"manager.")
  A caveat: the window layering code currently really only works on Windows, and 
has probably bit-rotted even there. It nearly worked on the Mac at one time, and 
has never worked on Linux, where the problem of multiple window managers with 
nonstandard APIs strikes again.
  So my not terribly helpful advice is to work with bug 12056 and adapt what you 
find there to capture the mouse state, turn it into some new, nonstandard 
window.open features flag (maybe "lowered" -- we already have "alwaysLowered," 
after all) and modify the appropriate window.open call. (And try to ignore the 
sight of my wildly waving hands.) We'll have to tweak the layering code to 
support the new flag. (Of course you'll have to be running in trusted JS to be 
able to open a lowered window.)
  I'd say you can go to Debug -> XPToolkit -> Dialog in a debug build to see the 
effect of opening alwaysLowered windows, except that I see someone has broken 
that again. Damnit.
  Was this any help? I'm obviously glossing over a lot of detail, some of which I 
haven't thought through very well and some of which I just don't know.

Dan, thanks a lot for the info. Now that 12056 has been fixed, I can look at 
this.  Thanks again!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Priority: P3 → P4
*** Bug 64673 has been marked as a duplicate of this bug. ***
Whiteboard: [parity-opera]
Blocks: 67571
I think we agree that opening the new window behind all other windows (like in 
Opera 5.10) isn't desirable, because that would make the new windows get "lost" 
behind other windows.  But if each new window loads just behind the current 
window (like in Opera 5.02), then after the user minimizes or closes the window 
with the links, the window in front will be the last link clicked.  This leads 
to two minor problems:

- The order that the user gets to see the content of the new windows is 
reversed from the order the links were clicked.

- If the link targets load slowly, the user has to wait for the last one to 
load before looking at it (or manually switch focus to a window that has 
already loaded).

How about instead loading ctrl+shift+clicked links behind the current window, 
and behind other links opened from the current window?  That would solve the 
two problems above without making the new windows likely to be lost behind 
other windows that happened to be open.

(Cross-posting to news://news.opera.no/opera.beta and opera.general under Chris 
Eaton's thread.)
What's quite simple is to load a link into another existing window. I wrote that
for an RFE but I added a focus() because I wanted to activate the other window.
OmniWeb has a pref for choosing the behavior of command-click.
Pro:
* Users who always want to open links with new windows on the background only
need to hold down one modifier key.
Con:
* One more pref.
Why not just make an option in Prefs that says:

"Open in New Window" puts the new window:
 ( ) In front of all the others
 ( ) Just behind the current one
 (*) Behind all the others

And Jesse, could you elaborate on what you meant when you said "I think we agree
that opening the new window behind all other windows (like in Opera 5.10) isn't
desirable, because that would make the new windows get 'lost' behind other
windows."? 
> And Jesse, could you elaborate on what you meant when you said "I think we 
> agree that opening the new window behind all other windows (like in Opera 
> 5.10) isn't desirable, because that would make the new windows get 'lost' 
> behind other windows."? 

If ctrl+shift+clicking a link opens the link behind all other windows, then 
when you close the window you opened the link from, the windows you opened are 
not immediately available.  My guess is that Opera 5.10 acts this way because 
the makers of Opera wanted you to be able to open multiple links from one 
window and then read them in first-to-last order, but didn't realize the 
problems that would be caused by opening a new window behind everything else 
you have open.
I see your point. Opening the new window behind all windows would be fine with 
me -- i wouldn't get lost, but i can see that some people would get confused 
and your solution would please everyone.

I can't wait till this feature gets added. I'm so sick of going "see 
interesting link, open in new window, minimize it so i can read my old window 
while the new one loads, repeat many times, close original window, maximize all 
the other windows in reverse order so i can read them in forward order"
> Why not just make an option in Prefs that says:

No, because that would only help those who wanted new windows to open behind 
the current one either always or never; it would be useless for those who 
wanted the behavior sometimes. And I suspect the latter group would make up the 
majority of those who wanted links to open in new windows at all.
iCab uses command+shift+click, according to http://www.icab.de/info.html.
Whiteboard: [parity-opera] → [parity-opera] [parity-icab]
*** Bug 92836 has been marked as a duplicate of this bug. ***
*** Bug 98398 has been marked as a duplicate of this bug. ***
What's wrong with opening it as a normal new window (middle click, shift+click,
or whatever mac/windows use), and hitting alt-tab. WFM, been doing it since
Netscape 3. Having the app hide windows itself is nonstandard (no normal apps on
windows, mac, or unix do this) and will just be confusing. alt+tab is no more
work that holding an extra key during the click (even easier, if you ask me).

The real issue here is window opening speed freaking blows. Target that for 1.0
and this bloat isn't needed. How would we even advertise this feature so users
could use it (as opposed to alt-tab, which users already know). It certainly
isn't going in the context menus as bug 67571 asks for.
Jeremy: 

> alt+tab is no more work that holding an extra key during the click (even 
> easier, if you ask me).

Middle-clicking a link opens it in a new window. You don't have to hold down an 
extra key.

> What's wrong with opening it as a normal new window and hitting alt-tab.

It requires two hands, for starters. And it really slows things down. A lot of 
people have a breadth-first method of surfing, where you go to a site like 
Slashdot and are presented with a whole bunch of links you want to follow. So 
you open them all in new windows. This lets you keep your focus on the main 
page until you've exhausted all the links and it's fantastic for those of us 
who are forced to surf by modem. Read one page while the others download. 

Having to press alt-tab (or use the mouse to click the main window over and 
over and over again) really slows things down.

> Having the app hide windows itself is nonstandard (no normal apps on
> windows, mac, or unix do this) and will just be confusing. 

No other apps do this because the breadth-first surfing technique doesn't 
really have an equal in any other application. It only really makes sense for 
viewing hyperlinked documents. And since this would be a non-default pref, 
nobody would be be confused because they wouldn't see the behavior unless they 
explicitly selected "Open new browser windows behind current one"

> The real issue here is window opening speed freaking blows.

Even if the windows opened instantaneously, the lack of this feature would 
still severely slow me down because of my connection speed and the amount of 
time it takes to click / hit alt-tab.
I have to add to spam... but
>(no normal apps on windows, mac, or unix do this)

well this isn't true at all... under Mac OS X we have a nifty little web browser
(that looks nice but is very slow at times) called OmniWeb lets users open a new
window behind the current one. Infact this is very useful if you have a slow
internet connection... you can might want to read a few articals so you just
open them in the background and continue on with what your doing.

As for bloat why can we copy the email address or the email address link? One
just removes mailto: in most case... in most case what people are asking for on
this is just to open a window behind another (not hide it).


See also bug 102120, the tabbed-browser version of this bug.
Target=1.0, Isn't this relatively easy to implement?
I would think that 0.9.5 would be more appropriate (including the tabbed 
version of this "bug")...
Whiteboard: [parity-opera] [parity-icab] → [Aufbau-P2] [parity-opera] [parity-icab]
The tabbed version, bug 102120, seems to be fixed now (2001102708),
(although one user is still claiming that the pref is getting 
ignored on his system).  Anyway, it (102120) should definitely be 
fixed in 0.9.6.  Note that it was resolved with a preference, so
there is still only one context-menu item.  Also note what the
tabbed browser is now doing with pref-controlled behavior for
the modifier keys.  

You could have a combined preferences panel, thus:
Edit->Preferences->Navigator->Windows And Tabs
(currently this is called Tabbed Browser)

   Tab Display
         [*]  Hide the Tab Bar when only one Tab is open
         [ ]  Load links in background tabs

   Window Display
         [*]  Hide Window menu when only one Window is open
         [ ]  Open new Windows in background

   Open Tabs Instead of Windows for:
         [ ]  Middle-click or control-click of links in a web page
         [ ]  Windows opened by the web page
         [ ]  Middle-click or control-click of bookmarks in the
              personal toolbar items
         [ ]  Enter in the URL bar
         [ ]  Control+Enter in the URL bar
Whiteboard: [Aufbau-P2] [parity-opera] [parity-icab] → [parity-opera] [parity-icab]
Jonadab: Please don't use Ctrl-Enter in the URL bar for this. IE has a great
little feature where pressing Ctrl-Enter in the URL bar appends "www." and
".com" to whatever you typed and then loading that URL. I'm sure it'll
eventually be added to Moz, but in order to do that, Ctrl-Enter in the URL bar
will have to be reserved for this purpose.

How about using Shift-Enter to open the link you type in a new tab? Or
number-pad enter?
jonadab@bright.net: i'd ignore bugzilla@schiraldi.org :-)
bugzilla@schiraldi.org: ctrl-enter is quite likely never going to do www.%a.com,
there's a bug about that and the general assertion is that www.%a.com is an
american centric thing which doesn't internationalize well and falls apart when
you have lots of tld's.

*** Bug 107887 has been marked as a duplicate of this bug. ***
Timeless: please give bug numbers instead of just saying "there's a bug about 
that".  The bug you're talking about is bug 37867, which took me 15 seconds to 
find.
Target Milestone: mozilla1.0 → mozilla1.2
*** Bug 109621 has been marked as a duplicate of this bug. ***
Opera does this with a pref:
    Command-click to open new window
          ( ) behind the current window
          ( ) in front of the current window

They then provide both options in the contenxual menu
    open link ("anchored text here") in new window
    open link behind this window

The fact that the first option opens a window in front of the current window is
relatively clear given the context provided by the contrasting option
immediately below.

I *always* surf with command-click opens behind current window because pages
take non-zero load/render time and I'd rather continue reading while that
happens. For example, scroll down the slashdot front page, command-click
anything interesting, and then close the window. Now you've got half a dozen
windows all loaded and ready to read without waiting.

Now I've got to figure out what to dump so I can vote for this....

-matt

whoops... I meant omniweb, not opera.

...and I'd love to see simliar functionality for tabs.

background tabs are just as handy a place to put loading pages as background
windows (maybe even more handy)

-matt


"...and I'd love to see simliar functionality for tabs. 
background tabs are just as handy a place to put loading pages as background
windows (maybe even more handy)"

Loading pages in the background via tabs is already there. Check the prefs for
tabbing to see if it does what you want. Personally, I think that now that the
tabbing is there, there isn't as much of a need to open new pages in new windows.



ditto that. I suggest closing this bug, since it's now possible to get the
effect you wanted with tabs.
I disagree.  I see no reason why the presence of tabbed-browsing affects those
who prefer to browse with many browser windows.  Doing away with the proposed
functionality of being able to open new windows below the current window because
you can do something similar with tabs is essentially expressing a subjective
preference for tabs.  I like tabs, too.  I like MDI over SDI.  But many people
apparently like SDI.  Those people would rather have many Mozilla windows--one
for each web page they view--and those people should not be denied the utility
of being able to open said windows below the current.
closing it would be fine with me... I hadn't played with the tabs prefs enough
to realized that I could already be surfing more optimally. Thanks for the tip.

it also sounds like it meets the needs of the blocked bug 67571


this isn't relevant to me personally, but I'm wondering if there are any
accesibility-type reasons to keep this feature open.

Are tabs just as accessible as windows? Users can switch windows via the "tasks"
menu, and menus may be accessible. There's also the command-1 (one, not el)
keyboard shortcut to switch windows. Are tabs just as accesible?

From a note in bug 79450, I'm guessing that tabs can't be switched via the
keyboard, and from just looking, it doesn't seem that they can be switched from
the menus either.

So, closing this bug sounds like it might imply that either the feature isn't
important, or it isn't important to disabled users, or the fix is to improve tab
accesibility.

-matt
see also bug 105028 - tabs not in tasks menu
> From a note in bug 79450, I'm guessing that tabs can't be switched via the
> keyboard, and from just looking, it doesn't seem that they can be switched
> from the menus either.

Accelerator + Page Up and Accelerator + Page Down.

Not that I don't agree with you otherwise.
This bug is still valid. Not everyone wants to use tabs some of us can and want
to work with windows (with lower case 'w' :-). I guess Windows users who run
everything maximized prefer tabs but I assume that numerous Mac users to prefer
real windows.
I am also a user that doesn't use tabs at all (Windows and Linux). This bug is
about windows, not tabs.
Target Milestone: mozilla1.2 → Future
Since the release of MSIE 5.1 for Mac, Mozilla is now the only serious Mac 
browser which does not have this feature.
Whiteboard: [parity-opera] [parity-icab] → [p-opera] [p-icab] [p-omniweb] [p-ie/mac]
Blocks: 105977
For the clueless (me) just how do you go about getting this on IE Mac 5.1?  I can't find a pref or get a menu to come up for this.  This is still the main reason I use OnmiWeb over other browsers.
With I.E. 5.1.3 on OS X , holding the shift+cmd key while clicking on the 
link will open the new window behind the current one.
>ditto that. I suggest closing this bug, since it's now possible to get the
>effect you wanted with tabs.

tabs are something completely different from windows, which is why some people
(I for example) hate them. And in any case this is a valid RFE.
*** Bug 141379 has been marked as a duplicate of this bug. ***
IMO a good idea to implement this would be a customizable midle button
behaviour, or  midle button opens window in foreground and clicking both left
and right buttons opens in the background, but not all people have a 3 button
mouse so.... -----stop idea here-------
In the same way there is a option to load tabs in the background, there should
be a option like that for windows. WINDOWS ARE NOT TABS. Tabs are very cool, but
try to open 31+ tabs in the same window, when that happen here, the scroll bar
gets out  the visible area in the screen. 
The default setting would be "open in foreground", so users used to normal
behaviour, don't get "confused". This option would add more configurabilty to
the browser. Let the users decide. Please implement this RFE.
 
*** Bug 150328 has been marked as a duplicate of this bug. ***
Wow.  Lots of "me too" comments on this bug....  the last technical comment is
comment 4.  And as it says, doing this on Linux would be well-nigh impossible. 
On Windows/Mac a possible solution is to open a new window then .focus() the
previous one.  When working with a windowmanager in which the focus and raise
operations re independent, however, this is not an option....

So are there any reasonable suggestions for doing this on Linux?
Hm. I tried to do a very similar feature for bug 97123, however I couldn't get a
code similar to this to work on Linux:

var foo = window.open(bar);
foo.blur();

or in variation:
var foo = window.open(bar);
window.focus();

So... as not even this works, I'm not sure if this is possible on Linux. Dan
seems to say the same in comment 4.
(I cannot say how I hate XFree and this window manager stuff there. That also
makes Fullscreen mode very difficult.)
This isn't a keyboard navigation issue.  The issue is implementing code on each
platform to handle this feature (adding a key binding for it once its
implemented is trivial).  Changing Component to get it off the keynav radar.
Component: Keyboard Navigation → XP Apps: GUI Features
Keywords: helpwanted
Keywords: mozilla1.2
*** Bug 158897 has been marked as a duplicate of this bug. ***
The "open behind" bookmarklet on
http://www.squarefree.com/bookmarklets/pagelinks.html makes left-clicking a link
open it behind the current window.  It simply opens a new window and calls
focus() when you click on a link.

I'm surprised at how well it works in Mozilla on WinXP: the new window doesn't
flash in front for half a second or steal any clicks.  Does it work that well on
platforms other than Windows?  If so, adding this feature to Mozilla could be a
several-line patch.
Opening links BEHIND my current view of a page is a good portion of why I've
been using tabbed browsing in Mozilla so much.  Without having to alt+tab back
to the other window (yay, Icewm!), I save a lot of redundant finger wear :)  I'd
love to see this option apply to "bare" middle click -> new window functionality.

Plus my logical focus is kept on the page I'm currently interacting with when
such behaviour is on :)
> Does it work that well on platforms other than Windows?

No.  It doesn't even work so well on Windows.  In particular it breaks in any
focus model in which a window can have focus without being the topmost window
(and that includes Win32 with TweakUI installed).
In response to comment 50:

Why do I want pop-under window and no tabs:
1) Tabs cosume screen space, which I care of; windows consume Taskbar space I
don't care of (takbar is set to "auto roll-down").
2) More importantly, Ctrl-Tab (see bug 136915) and Alt-Tab are both left-handed
chords, while Ctrl-PgUp/PgDn are right-handed chords. Difference? For me,
Ctrl-Tab = 0.3 sec (left hand always on the keyboard, with thumb lurking around
Ctr-Alt-Shift triangle), Ctrl-PgUp = 2.4 sec (Move the hand off the mouse, find
Ctrl-PgUp, press, return to mouse, re-establish mental mapping between hand
position and pointer position).

2.1 sec difference is QUITE a burden. I'd better be Alt-tabbing.


P.S. I keep swearing at ABBYY Software, who mapped "prev/next page" to
Ctrl-NumpadPlus and Ctrl-NumpadMinus. Try THIS chord with your right hand,
and you'll see what I mean...

In responce to the confused sounding comment 52:

Tabbed browsing is an option.  Don't turn it on if you don't want it.
Having new windows open in the background would be another option that shouldn't
be on by default.  Don't turn it on if you don't want it.

It's not like I'm forcing you to turn on these options, nor am I advocating that
they are the default.  I just think that open links in backround as a generic
option which works for TABS or NEW WINDOW middle clicks would be nice.

I'd also like it if I could somehow assign the mousewheel to go back and forth
in the tab list, much like I can set it to zoom, scroll, or go through my
browser history.

Jesse, your open behind bookmarklet is cool, but to fix this bug I believe we 
need more sophisticated open behind behavior. You seem to have thought the same 
thing: in comment 7 you say "How about instead loading ctrl+shift+clicked links 
behind the current window, and behind other links opened from the current 
window?" I've found Tab browsing with open links in background to be quite 
nice, despite the other usability problems with tabs. The best part is that 
with the change to the tab close direction, you can easily read the links in 
the order you clicked them. It'd be nice if you could do the same with new 
windows. I would want to make new windows always open in the background, but I 
don't think that should be default behavior for most users.

I tweaked Jesse's bookmarklet to open the window behind the current and 
previously opened windows. The extra logic causes more window flashing as it 
switches the order, but it's not too bad. You can get it here:
http://www.worldtimzone.com/bookmarklets/openbehind.php
Obviously this isn't a perfect fix, but works reasonably well if you want to 
get a feel for the behavior.
Dylan: I've created bug 159376 for your RFE ("Allow mouse wheel to scroll
through tabs")
In response to comment 53:

1) I'm sorry I didn't mention it, as I joined the discussion from a duped one,
but I actually was requesting some click-modifier, like current Ctrl-click.
Like, ctrl-click = open in new window and focus on it, Alt-click = open in new
window but DO NOT focus on it.
2) Addressing problem with making window sink: maybe we can just start new
window minimized instead? No need to sink it below the current one, then.

And sure, making everything optional ([x] switch feature off) is always a great
idea.
Alt-click is a commonly used windowmanager key shortcut; we should not be using
it because many Unix users will be unable to access it, imo.

Does annyone actually have a workable suggestion for how to achieve this window
sinking in real life?  
1. Would Ctrl-Shift-click do then?
2. Isn't "open this link in new window, minimized" workable?
> 1. Would Ctrl-Shift-click do then?

Should work...

As for minimizing, that might work, yes.  It's not what the report asked for,
but it may be a reasonable substitute if it can be done.  Note that at least on
MacOS Classic minimized windows can be focused (while being minimized) and a
focused window can be minimized without losing focus.
From talking to bz:

1. window.focus() does the same thing on each platform: it raises and focuses
the window.  This is a good thing.

2. The problem with calling window.focus() is that it brings the original window
above other windows that it might not have been above before.  This is only an
issue on setups where clicking a window (without modifiers) does not focus and
raise the window.  bz says this type of setup was very common on Linux two years
ago but might not be common now.  I think anyone with such a setup is a power
user and would be able to deal with the "open link behind" feature not working
as advertised.

3. We (bz and I) don't know how hard it would be to cause a window to open
behind other windows without using window.focus().  I think it would require a
lot of platform-specific and maybe window-manager-specific code.

4. Many linux window managers use Alt+click.  They use it for various things:
raise, lower, move.  (Maybe this feature could have two shortcuts,
Ctrl+Shift+click and Alt+click.  Both would work on Windows and only
Ctrl+Shift+click would work on Linux.)
Blocks: 161466
This is not anymore a problem for me with the use of tabs and "don't change
focus to new tabs".

Thank you all.
On Mac, Ctrl+Click brings up the context-sensitive menu (ala right-hand-mouse
button on other systems). Further, most Macs only have the one button, so
expecting there to be a middle click or even a right click isn't going to help
Mac users.

The only reason I use OmniWeb instead of Mozilla for most of my browsing is that
it has the ability to use background-clicks, using Command+Click.

I suggest that the keybindings for the Mac version uses Command+Click, and other
platforms use the Ctrl+Click; however, using the Ctrl+Click for the Mac isn't
going to give the Mac people what they need.

Alternatively, some kind of user-specific keybinding could be defined in the
preferences, rather than just expecting it to be Ctrl. Then users could define
any combination of modifiers (e.g. Meta/Ctrl/Click) that does the job as it
suits them. I don't think you'll find a combo that will work the same on
Linux/Mac/Windows, so why not have a different or user selectable one?
>I suggest that the keybindings for the Mac version uses Command+Click

of course. I'm pretty sure that that is what the current code does.
The keyboard shortcut for this function in every other Mac browser is Shift+
Command+click. It is not configurable in any of them, and nor does it need to be. If 
you want it to be configurable, go vote for bug 85169.
*** Bug 209341 has been marked as a duplicate of this bug. ***
*** Bug 265943 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Summary: Allow opening link in a new window behind current window → Allow opening link in a new background window (behind current window)
Whiteboard: [p-opera] [p-icab] [p-omniweb] [p-ie/mac] → [p-opera] [p-icab] [p-omniweb] [p-ie/mac] [p-safari]
This one is still broken in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b5) Gecko/20050927 Firefox/1.4
Flags: blocking1.7.13?
Blocks: 271588
Is this the same as 263553? If so, should they both go into "core"?
No, this is not the same as bug 263553. This is about support for opening background windows using a modifier key or keys. Background tabs are somewhat similar, but not a replacement for this feature. Due to the UI impact I don't think this can be exclusively in "core", although the the ability to properly layer windows without messing with window focus should certainly be.
not appropriate for a security release, not blocking.
Flags: blocking1.7.13? → blocking1.7.13-
This is probably the one reason I don't use Firefox. :) I really like windows over tabs. On a Mac, cmd-` cycles thru windows; it's much faster than any shortcut to cycle thru tabs.  I wish there could be a preference to set what control/command-clicking does. 
I would just like to add my support for this.
Can Firefox prefs support opening a link in a new background window?

Thanks
Assignee: bross2 → guifeatures
Status: ASSIGNED → NEW
QA Contact: bugzilla
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
With all the world moving to tabs, and not seeing window stacking to be really fixed, I guess we just should admit we won't be able to fix this.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Oh, that's a pity, bug 271588 depending on this one cannot be avoided using tabs...
What about the Thunderbrowse extension coming in to play here somehow?
(In reply to comment #76)
> What about the Thunderbrowse extension coming in to play here somehow?

Thunderbrowse does not apply to SeaMonkey, while this is a WONTFIXed SeaMonkey bug.
My error. I've been updating a lot of my Thunderbird/mail bugs lately.
Were there recent changes to this? My Thunderbird just started sending me immediately to the browser instead of staying in Thunderbird. This happened in the last 2 weeks.

(In reply to Worcester12345 from comment #80)

Were there recent changes to this? My Thunderbird just started sending me
immediately to the browser instead of staying in Thunderbird. This happened
in the last 2 weeks.

Still doing this, by the way. OR just restarted. VERY annoying when going through bug mails, and it opens the browser each time. Sometimes you can fool it by clicking really quick twice.

You need to log in before you can comment on or make changes to this bug.