Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020510 Middle-click & CTRL+click on URL in Mail/News should open a NEW TAB, if "Tabbed Browsing Preference" is set to do so. This is a spinoff of bug 101955 as requested in bug 101955 comment #73 That bug had a bazillion dupes, *virtually all* of which requested that it be possible to open Tabs from mail/news links. It would make sense to also add a "Open in new Tab" context menu item to URLs in mail/news as part of this bug, but I or someone can file a separate bug, if needed. If no browser window is open yet, then instead of a new tab a browser window would open and the link loaded there. Whatever pref in prefs / tabbed browsing / "Hide the tab bar if only one tab is open" should be respected. If multiple browser windows are open, then focus the most recently-used browser window - just like if you were to left-click a link from mail/news under the same conditions.

copying keywords from bug 101955: adt1.0.1, mozilla1.0.1, nsbeta1 Should someone move the dupes in bug 101955 to this bug? It seems they should be.

*** This bug has been marked as a duplicate of 104380 ***

oops reopening. The original is even older.. i'll try to find it

RE Comment #3: All bugs previously requesting this feature were marked dupes of bug 101955. Bug 101955 comment #73g *specifically* requested that a *new* bug be filed for this. Please don't dupe this bug against something that may not be up-to-date.

Peter, Please copy from the old bug, or re-phrase, what should happen when a) there are multiple windows open b) there is no window open

RE Comment #5: Didn't you read the bug's initial text (the last two paragraphs)?

The same backend is needed for this and 104380; adding dependency. beta1 is out, so removing keyword.

putting nsbeta1 back. It's being used for mach v's rtm as well. Removing adt1.0.1 since there needs to be a patch and reviews before there can be approval for checking in.

Nav triage team: nsbeta1-

*** Bug 149679 has been marked as a duplicate of this bug. ***

*** Bug 152164 has been marked as a duplicate of this bug. ***

would we have time for this in buffy? (it'd be useful to have...)

Nav triage team: nsbeta1+/adt3

*** Bug 163315 has been marked as a duplicate of this bug. ***

I frequently right click (or click on a link) in a mail message and it opens in the top most window, or the top most tab. I've got my prefs set to "open tabs instead of windows for middle click", and that works from browser, but not from mail. Would it be possible, on the browser side, to allow it so if we are loading on a link click, we open a new tab? This is less destructive (no dataloss), as I might have been using that top most browser (or tab) for bugzilla or some other form. Something to keep in mind, we wouldn't want the "Open Link in Tab" in mail, as mail might be stand alone, and you don't know if the browser supports tabs. So I'm putting the work on browser, to handle the open request. If it was pref controlled, I'd be fine with that too. It seems like we might make it on by default as it leads to tab discoverability, and no dataloss.

That sounds like a great idea. Especially if it would mean that all requests from the operatingsystem would result in a new tab with the URL. For example in Win32 when a program (or Start-Run) requests a URL to be opened and Mozilla is already started it would result in a new tab inside the already started mozilla.

If anyone feels like fixing this, jump right in.

Please see bottom pref settings in: http://www.mozilla.org/mailnews/specs/prefs/Preferences.html#Window This was planned for mail for future: Clicking a link in a message window should open the link in: A new browser window An existing browser window We could also have: A tab in an existing browser window (Note: this would have to be removed for a mail only app). OR Prefs: Tabbed Browsing "Middle click or Ctrl click of links (in a web page)" could apply to mail as well.

Is there anyone available to make this happen? I'd love to see this on the trunk before our next release! Seth, "open in new tab" seems like a useful thing. If I know that Netscape is the default browser or if I'm using a bundled version, then I'd like to see that choice in the context menu. I would only hesitate on that if there were a performance hit.

This is not the same as the equivalent click on a link in a browser window, since there may not be a browser window open, and the prefs may cause the page to load in a background window. It sounds useful, but there may be problems predicting where the page loads, or even finding it in some cases, so it will need to bake on the trunk. I think loading in an existing tab is no different from loading in an existing window, so we should instead consider adding only a 'load in new tab' choice, preferably via the second suggestion in comment #18. cc patricec for browser UE input.

I've been wishing for this for a while. Here's a patch. It adds a new context menu entry to the message pane context menu, allows middle-click and ctrl-left-click to follow the pref. It doesn't touch the prefs UI or the default left-click behavior, as it sounds like that's not entirely settled.

Comment on attachment 105800 [details] [diff] [review] mailnews support for tabs patch, v1 r=sspitzer The other half of this bug is about how if I'm running a tab enabled browser (like mozilla, phoenix) and do something in another application that causes a url to open, it would be great if our tab enabled browsers would open the url in a new tab. (this might be pref controlled.) Can you spin up a new bug about that?

I wrote: "Something to keep in mind, we wouldn't want the "Open Link in Tab" in mail, as mail might be stand alone, and you don't know if the browser supports tabs." I think we do want it, at least when browser and mail are together. It make tabs more discoverable. when we get to it, and when we have xulpp support on the trunk, we'd wrap the new context menu item with: #ifndef MOZ_MINOTAUR <menuitem id="context-openlinkintab" label="&openLinkCmdInTab.label;" accesskey="&openLinkCmdInTab.accesskey;" oncommand="gContextMenu.openLinkInTab();"/> #endif thanks for fixing this dmose.

as trudelle points out, we'll want UI approval for this. (and someone like jag or blake to r/sr). Also, does your patch bring the existing browser window to the front?

Comment on attachment 105800 [details] [diff] [review] mailnews support for tabs patch, v1 >Index: mailnews/base/resources/content/mailWindowOverlay.xul >=================================================================== >@@ -645,7 +645,11 @@ > <menuitem id="context-openlink" > label="&openLinkCmd.label;" > accesskey="&openLinkCmd.accesskey;" >- oncommand="gContextMenu.openLink();"/> >+ oncommand="gContextMenu.openLink();"/> Space at end of line added. Just remove that locally, sr=jag with that change undone.

Except I guess you would want to focus the window when opening in a new tab from mail/news. Is there a way you could factor this support code for mail/news out into a function that calls openLinkInTab?

jag: Why factor it out? other non-browser applications (eg calendar, etc) are likely to want this behavior too.

They too could call the wrapping function, right? I was thinking it might make the code a little easier to understand, but I'm fine with it as is (bar not bringing the browser window to the front).

I'm fine with the context menu and what it does.

What do you think Jen?

two questions: if the user has "open tab behind", do we respect it? any reason not to in this case? I'm *so* looking forward to this patch!

> Just remove that locally, sr=jag with that change undone. Done in my local tree. > The other half of this bug is about how if I'm running a tab enabled browser > (like mozilla, phoenix) and do something in another application that causes a > url to open, it would be great if our tab enabled browsers would open the url > in a new tab. (this might be pref controlled.) > > Can you spin up a new bug about that? That sounds like bug 105547. > Also, does your patch bring the existing browser window to the front? I just tried, and it does in fact do that. Presumably an artifact of the existing code. > if the user has "open tab behind", do we respect it? Yes. > any reason not to in this case? Hmmmm. I suppose one could argue that this is different situation than opening a new tab from the browser, where one is likely to already be reading the front tab. Any UI folks have thoughts on this?

Yeah, that's what I meant in comment #20. We can't really predict user reaction, but the implementation you've described sounds like it maps readily to the browser case, and the prefs allow for focusing or not, so users who care can control it.

> > Also, does your patch bring the existing browser window to the front? > I just tried, and it does in fact do that. Presumably an artifact of the > existing code. I spoke a bit too fast. If the "load tabs in the background" preference is set, it does NOT bring the window to the front. So the semantics correctly match the preference. > and the prefs allow for focusing or not, so users who care can > control it. Not independently. I'm starting to dislike this behavior. That is, in the browser I always want my tabs to open in the background, and in mail I almost never do. What's the right solution here? Add another pref? Always open mail tabs in the foreground? Something else?

> in the browser I always want my tabs to open in the background, > and in mail I almost never do. The same here. > What's the right solution here? Add another pref? Always open > mail tabs in the foreground? As far as I'm concerned, I would be satisfied with either solution. But if I had to choose, I'd add a checkbox like "When triggered from outside the browser, load links in the background" right below "Load links in the background". It's probably not the best possible wording (and perhaps too long), someone who actually can speak English would be a better person to formulate this. I specifically vote against making the formulation or placement MailNews-specific, because - I suppose - the same should apply to other not-in-browser links: Calendar has been mentioned, and all other Mozilla components are also candidates; and invocation by clicking a link on the desktop too.

talked to dmose. sounds like he was 95% of the bug fixed, where the remaining 5% is: "in the browser I always want my tabs to open in the background, and in mail I almost never do." I think he's going to land as-is, and move that to another bug.

Landed. Bug 180042 filed for remaining UI issue.

this is great --dmose, thanks so much for implementing this. vrfy'd fixed: tested with 2002.11.14.08 comm trunk bits (linux rh7.2 and win2k) and 2002.11.14.07 mozilla mach-o (trunk, on OS X 10.2.2).

Just one question then, how do I have tabbed browsing in my browser, and open a link from mailnews in a new window? I just alt-tabbed back to mailnews, single-left-clicked on a link, and lost this bugzilla window (Bugzilla was in a tab in one window, and was my most recent browser focus). I restored bugzilla into that tab, and tried middle-clicking. Now it opens a new tab in the most recent pane. But the link I clicked on has nothing to do with the few bugzilla tabs I had open in that pane. I like to each pane for a given topic, and open tabs within those panes for the current session. A mailnews link is almost never related to whatever pane I was last in, and I would normally want it to open in a new window. This used to be possible with a middle click. (Yes I agree that this didn't agree too well with "middle click opens in a new tab") I suppose I can right-click and "open in a new window" which works. Oh well, I guess that's at least more consistent. Forgive me for being a little perturbed by the change in behaviour.

See also bug 180042, "'open tab for middle-click' shouldn't apply to links in mail messages". I think there should be a separate pref, "Open tabs instead of windows for... desktop shortcuts and links in other applications", either in the tabbed browsing section of prefs or in the section that contains the "Reuse windows for links in other applications" pref (bug 75138).

For those who want to "fix" the tab issue temporarily, I've stumbled on a patch I found and had applied to 1.3b... unzip comm.jar and open to content/communicator/contentAreaClick.js Look for this line (it has a comment about opening in a tab) if (pref && pref.getBoolPref("browser.tabs.opentabfor.middleclick")) { replace it with this if (pref && pref.getBoolPref("browser.tabs.opentabfor.middleclick") && ("getBrowser" in window) && getBrowser().localName == "tabbrowser") { And you'll get the old behaviour