From bug 148974: > > 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?

I'd agree that from non-browser sources (a link in mail, address book, etc,.) users would most likely want focus for the link they just opened. If non-browser sources are obeying the prefs in Navigator: Tabbed browsing (which they should), we should be consistent and obey the "load links in background" as well. So, we'd need an additional control for this. It could be enabled by default. Wording is tough those. Cc'ing jatin for help with the wording. Maybe something like: []Load new tab contents in the background []Except when requested from outside the browser

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

Bug 180042 says it all. This has really broken my way of working in mail :-( The previous behaviour, that middle-clicking of links in mail always opens a new browser window, was _perfect_. Because I am so used to middle-clicking links in browser, it was a natural thing to do in mail, and the behaviour described above, while perhaps inconsistent from an implementation point of view, perfectly matched my expectations. Gerv

For anyone using Patch Maker (http://www.gerv.net/software/patch-maker/), here is a patch you can apply to your installed copy of Mozilla to restore the old behaviour. No CVS tree required. Gerv

I (humbly) think that Gerv meant to refer to bug 184730. :) To reiterate what I said in that bug, and to agree with Gerv, middle-clicking a link in mailnews should open a new window by default. I'm all for new prefs, but I really think the default behavior should open a new window. It's also the way it's worked from the start, and I suggest that people are used to it. (Note that the current pref for middle-click reads "links in a Web page" and technically mail/news messages aren't web pages.) For new prefs, I think Mozilla needs two new exceptions to cover all the options that've come up: Tab Display []Load links in the background []Except for links in mail or news messages Open tabs instead of windows for []Middle-click or control-click of links []Except for links in mail or news messages (ps. Thanks for the patch!)

Middle-clicking a link in mail should open a new window, not a new tab in a random browser window, when "Open tabs instead of windows for... middle-click" is checked. Instead, this behavior should depend on the pref "Open tabs instead of windows for... desktop shortcuts and links in other applications" and the reuse-windows pref from bug 75138. See also bug 167245, "Tabs opened from external application should ignore 'load in background' pref".

Jesse: bug 75138 is Futured, and bug 167245 is untargetted. I think that we should restore the old behaviour while we decide what to do in the long term. As you can see from my attachment, this is a one-line change. I am sure that if we release a major milestone with this behaviour, we'll get a lot of complaints. Gerv

We need to work out how to get the correct behaviour for as many people as possible, with the minimum of prefs. CCing some more of the players in bug 148974 for views. The current set of preferences seems to work very well for all situations involving just the browser. We just need to work out whether we should be applying them to other Mozilla components, or other applications. Here are some unsupported assertions: - People use tabs to group related windows or tasks - URLs opened from e.g. calendar, an external application, or mail (collectively "other places") are, more often than not, not related to an existing window. - URLs opened from other places are usually opened so the user can look at them immediately. This contrasts with the browsing method of opening tabs in the background to look at later. This leads to the following conclusions: - "Load links in the background" should only ever apply to URLs opened in the browser (bug 167245) - You should be able to control new tab vs. new window independently for "browser" and "other places" (bug 184730, sort of, and bug 75138, sort of.) The mistake made in bug 148974 was to reuse the same middle-click pref for mailnews as for browser. So, one way of resolving this problem would be: - Make "load links in the background" apply to browser links only, and document it as such in the prefs - Add an extra pref: Open tabs instead of windows for: ... [] Links requested from outside the browser Comments? Gerv

I agree with and second everything Gerv said.

No, no, no! I *love* the current behaviour! When I browse through new mail, I often open the links in the background (in tabs) with the middle mouse button, and look at the pages once I'm finished with mail. It may not be everyone's favorite way, but it is mine. Except for this, Gerv's proposal is fine. So, how about: +- Tab display --------------- | [ ] Hide the tab bar... | [ ] Load links in the background | [ ] Load links requested from outside the browser in the background +----------------------------- +- Open tabs instead of windows for --------- | [ ] Middle-click, Control+click or Control+Enter | [ ] Control+Enter in the Location Bar | [ ] Links requested from outside the browser +-------------------------------------------- The prefs will probably have to be reworked at some point, though, because both of the "load links in the background" prefs will hopefully apply to new windows, too, not only tabs. There's another problem: what exactly is "outside the browser"? When you click on a URL icon on the Windows desktop, that is certainly outside. But is Mozilla Mail "outside the browser"? Some people might say it isn't. And some people might say that these are, in fact, separate categories, so that we should have something like: [ ] Load links in the background [ ] Load links requested from other Mozilla application in the background [ ] Load links requested from outside Mozilla in the background

In the IRC window, clicking the middle button on a link does absolutely nothing - the link doesn't open anywhere. I have all 4 boxes ticked in the 'tabbed browsing' screen in 1.3b.

> When I browse through new mail, I often open the links in the background (in > tabs) with the middle mouse button, and look at the pages once I'm finished with > mail. It may not be everyone's favorite way, but it is mine. And you don't mind hunting through all your windows for the relevant tab? And you don't mind trying to remember which mail each page related to? Mozilla mail is definitely "outside the browser". We are not having a separate pref for mail to everything else. :-) Gerv

> And you don't mind hunting through all your windows for the relevant tab? All my tabs are in one window. I don't want a new browser window to be created. > And you don't mind trying to remember which mail each page related to? If I care, I'll look at the new tab immediately, but usually I don't care. > Mozilla mail is definitely "outside the browser". We are not having a separate > pref for mail to everything else. :-) Not just for mail, but for chatzilla too. And what about the 'Bookmarks' tab in the sidebar? Is that "inside the browser"? The items there don't currently act like links in the browser (no middle button click activation, etc).

I continue to assert that opening multiple links from mail in the background is far from the norm, and allowing this to be turned on would just confuse most users who did so. However, I modify my proposal to add a hidden pref for "Open links in the background when requested from outside the browser", defaulting to false, given that it shouldn't be too complicated to do. But I do not believe that this pref needs UI. A line must be drawn :-) Gerv

Well, the formulation "Load links requested from outside the browser in the background" is probably not the best possible, but I don't see what's confusing on that, in principle? There are already two of us only in this bug who like the current behaviour (I agree totally with comment 13), so perhaps it's not so rare. I don't see why we have to draw any lines. :-)

I'll give a third comment in favor of the current behavior. If it must be changed, I see having a new window for the first tab middle clicked in mailnews (honoring some sort of open in background pref). This window would in some manner (in title bar and behavior) identify itself as browser_target="from_mailnews", giving us a specific window which would be the target for all mailnews links (rather than guessing which of 2 or more windows the link went to). But then again I like to dream, not design UI.

> I don't see why we have to draw any lines. :-) Because if we had enough prefs to make every behaviour possible, it would be impossible to configure the behaviour you actually wanted. Mozilla already has too many prefs, and I only proposed adding a new one after much thought about whether it could be done without. The question is not "how many Mozilla hackers can we get in a bug who want behaviour X, vs. how many who want behaviour Y". The question is: "what minimal set of prefs and defaults can we provide that do the right thing as much of the time as possible, and can be configured to do the right thing for the most people with the least hassle?" If you think the design should be changed, bearing in mind my comments above, refute the assertions or logic in comment 8. Gerv

> > I don't see why we have to draw any lines. :-) > Because if we had enough prefs to make every behaviour possible, it would be > impossible to configure the behaviour you actually wanted. Mozilla already > has too many prefs, and I only proposed adding a new one after much thought > about whether it could be done without. OK, I was only half-serious about not drwaing lines. But seriously, I don't think that customizability is such a bad thing, provided that the defaults are reasonable. The hard part is thinking of words that will make the prefs understandable. > The question is not "how many Mozilla hackers can we get in a bug who want > behaviour X, vs. how many who want behaviour Y". The question is: "what > minimal set of prefs and defaults can we provide that do the right thing as > much of the time as possible, and can be configured to do the right thing for > the most people with the least hassle?" Right, of course. The problem is, how do you determine what is "the right thing" much of the time, and what is the right thing for most people. I do admit that those who comment in the bug are probably not a representative sample of users. Perhaps there could be a voting system right on the front page of mozilla.org to solve such issues? > If you think the design should be changed, bearing in mind my comments above, > refute the assertions or logic in comment 8. It's hard to refute "unsupported assertions" (you said it yourself) involving general terms like "people tend to" etc. But I'll try: > People use tabs to group related windows or task Some people, yes. Some of us just like to have exactly one browser window. > URLs opened from [...] "other places" are, more often than not, not related > to an existing window Probably right. > URLs opened from other places are usually opened so the user can look at them > immediately. Why do you think so? Do you have statistics? Why is it any different? The situation is virtually the same: I want to continue whatever I am doing (usually reading a page/email) while having the page load in the background so that 1) I will be reminded later that I wanted to see it, and 2) I make use of bandwidth that is idle while I'm only reading. Of course, other people may have other opinions or habits, but who are we to judge which of those are the "right ones"?

> OK, I was only half-serious about not drwaing lines. But seriously, I don't > think that customizability is such a bad thing, provided that the defaults are > reasonable. The hard part is thinking of words that will make the prefs > understandable. Mozilla's prefs UI is notoriously bloated, and it is hard to use as a result. The hard part is reducing the number of prefs and making Mozilla do a sensible thing by default in more cases. > It's hard to refute "unsupported assertions" (you said it yourself) involving > general terms like "people tend to" etc. But I'll try: > >> People use tabs to group related windows or task > > Some people, yes. Some of us just like to have exactly one browser window. Fine - so your task group is "browsing the web". >> URLs opened from [...] "other places" are, more often than not, not related >> to an existing window > > Probably right. > >> URLs opened from other places are usually opened so the user can look at them >> immediately. > > Why do you think so? Do you have statistics? Why is it any different? The question is not "why are other URLs any different?", but "why is the browser different?". In general, if you ask your computer to do something (which doesn't take a long time), you want to see the results of it, because it's your foreground task and what you are doing. In a web page context, where the action is to open a link for reading into a new window or tab, then this general rule has an exception. In the case of new tabs, at any rate, the user knows the result of his action - because he can see the new tab appear, and so gets feedback that his operation succeeded (when it changed from "Loading" to the page title.) However, when a URL is invoked from e.g. Evolution, or the command-line, I assert that the viewing of the URL is part of the user's current workflow, like any other command that they may run. Gerv

I just want to add my 2 cents here... I believe the current behavior is broken when you have background loading set. When I "middle click" a link in mail it opens a new tab in a browser window. The problem is: that window might be anywhere, including in a minimized window. This basically makes in invisible, which is not good UI. I admit to there being issues with adding extra preferences; most users will not figure out what any new preference is really for. Take this as a vote to restore the old behavior, or if that doesn't get done, to at least bring the targeted browser window to the front when the new pane is created...

> However, when a URL is invoked from e.g. Evolution, or the command-line, I > assert that the viewing of the URL is part of the user's current workflow, > like any other command that they may run. This is the crux of the issue. Like I said in bug 184730, I often have several browser windows opened on different desktops. With the current open-as-tab behaviour, I have no idea _where_ the new tab appears. I have to go rooting about through all my open browser windows on all my desktops to find the background-tab containing the URL. This sucks. Even if I wanted to just view the page(s) later, after I finished with my mail, it would still suck. It's obvious that different people work differently, but I'm really not seeing what the current argument is about. How does what Gerv proposed in comment 8 fail to give everyone what they want? Is it about background-vs-foreground tabs? If you're reading mail and like to open links in tabs, does it really matter if the tab is in the browser window's foreground of background? I think Gerv's comment 8 proposal is fine, and covers what everyone here needs. I think getting foreground tabs (if you want tabs at all) on URLs invoked from outside the browser is a reasonable compromise (but then, I don't want tabs so maybe it's a major issue for tab lovers). I don't think there's any need for a foreground/background pref, hidden or otherwise. The whole foreground/background tab issue comes from bug 167245. Maybe we should leave that discussion there, and concentrate here on the window-vs-tab issue. I think the extra pref Gerv described in comment 8 is all we need.

Marc: The proposal in comment 8 obviously does _not_ cover what everyone wants, as explained - perhaps not clearly enough - in comment 10 and comment 13. In particular, the _only_ thing that I don't like about comment 8 is: 'Make "load links in the background" apply to browser links only'. (It may cover what everyone _needs_, though (as you said) - after all, we don't really _need_ tabs, or loading in the background, or more than one open page at a time...) There's a distinction between Mozilla's built-in applications and the rest of the user's desktop: in Mozilla Mail, you can left-click a link or middle-click (or ctrl+click etc.) it, while you generally don't have that distinction in other applications. I agree that if you left-click, you generally want the link to open in the foreground. However, with a middle-click, I'm explicitly asking for a different action than the normal left-click. I'm too tired now and feel like giving up the argument, I just wanted to mention that distinction because I think it hasn't been raised here yet.

Vaclav: Don't give up! :) I really think the discussion here has expanded beyond the original issue, and I'd like to see more appropriate focus. There are currently two issues being discussed. One is the tab-vs-window issue, where a recent checkin changed what happens when you middle-click a link in mailnews. The other issue is the foreground/background tab issue. I believe that bug 167245 is intended to focus on the forground/background issue. If we can agree that this is the case, then I suggest that the focus here be solely on the tab-vs-window issue. Further, WRT the tab-vs-window issue only, I think everyone can agree with the second half of Gerv's proposal in comment 8: - Add an extra pref: Open tabs instead of windows for: ... [] Links requested from outside the browser To sum up, I suggest: 1. Move the foreground/background tab discussion to bug 167245, which is where it belongs. 2. Resolve this bug by adding the new pref described above. Can we at least agree to move the foreground/background tab discussion to bug 167245?

Before 1.3 I could middle-click in MailNews and it would open new windows. Now, it opens new tabs in a random (I'm told it's the "last used") window. If your browser window is not visible (because it's on another virtual desktop or minimized or whatever) you have to hunt for your links. Why was 148974 checked in even though it broke the existing behaviour? 95% of a fix is not enough. There isn't even a way to restore the previous (IMHO correct) behaviour in current builds. I fully agree with adding the pref in comment 23. That should have been part of 148974 and needs to be in Mozilla before I will use a recent version of MailNews. I didn't notice this in 1.3b. I guess I'll go back to that.

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

I for one am chagrined to find that the middle-click-in-mail behavior is, IMHO broken in 1.7.5. In 1.7.3, I could sift through a number of emails, middle-click a link in each email, and have those links appear in background tabs without doing anything stupid like changing the focus. As I recall, if I set tabs to NOT load in the background, the browser window with the new tab would come to the front. This behavior made perfect sense, and now with my preferred "Load tabs in background" setting middle-click in mail is completely broken. Now I have to right-click and select "Open link in new tab". I see the patch dated 2002, but it's not clear to me whether this will restore the quite sensible behavior that I observed in 1.7-1.7.3. I will probably downgrade to 1.7.3 unless there is a patch to bring back the behavior that didn't suck. If the plan is to leave it broken like this, please respond so I can take the appropriate action.

Addendum; just for giggles I tried the patch and it doesn't help.

> Addendum; just for giggles I tried the patch and it doesn't help. Yes, the patch actually seems to break things in 1.7.5. I've been meaning to poke at it before posting something here, but it's low on my todo list so I figured I might as well sympathize with your pain!

I don't know or particularily care about foreground background but as per 1.7.3 I really liked being able to middle click a link in mail and have a new tab open in my active (or last active) browser window! I get a large number of e-bot notifications from several art sites/discussion groups and that feature was wonderful.

(In reply to comment #26) > I for one am chagrined to find that the middle-click-in-mail behavior is, IMHO > broken in 1.7.5. In 1.7.3, I could sift through a number of emails, > middle-click > a link in each email, and have those links appear in background tabs without > doing anything stupid like changing the focus. I can only second that! Since I upgraded to 1.7.5 I am really annoyed about this each and every day! The 1.7.3 behaviour was perfectly fine for me! > As I recall, if I set tabs to NOT > load in the background, the browser window with the new tab would come to the > front. This behavior made perfect sense, and now with my preferred "Load tabs > in > background" setting middle-click in mail is completely broken. It is just broken regardless of the 'Load tabs in background' setting as far as my (brief) tests show. What was the reason for the latest change? I don't see any recent recent announcements of changes here in this call... PLEASE, please, bring the old behaviour back, regardless whether it involves adding a new switch in the preferences screen or (only) changing the prefs file! And if I may post my preferences here: 1) I was completely happy with opening new tabs in the last used browser window. This was (once I found out about it) logical and easy to remember. If I wanted a certain link to come up in a specific window I just shortly activated it and alas, there it went. 2) If the above is no option I'd prefer opening a new browser window for the first middle-click from mail and adding any new tabs being requested the same way there. See as well comment 16 on this. 3) I certainly would not like to have a new window open for each and every middle-click in mailnews... Thanks, Michael

OK, I thought it was just me, but it wasn't. _Please_ bring back the previous middle-click functionality! -JW

...and v1.7.6 has restored the previous middle-click function. THANK YOU! -JW

Yes, *Thank You!*

Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.