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.