262537 - Tabs opened from left click and from external applications should always open in foreground

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Radek 'sysKin' Czyz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041001 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041001 Firefox/0.10

If links that open new windows are set to open new tabs instead, and new tabs
are set to open in background, left-clicking links might open them in background.

Although the settings' wording explains that perfectly, I believe left click
should NEVER open things in background. This is very confusing - especially if
you don't expect that. It looks like your click is being ignored. If someone
left-clicked, he wants to follow the link right now. If he wanted to open it in
the background, he would middle click.

Reproducible: Always
Steps to Reproduce:
1. Set a perfectly reasonable configuration: tabs open in background, new tabs
open for _blank tagrets
2. Find a link with tagret="_blank". Click to follow.

Actual Results:  
You don't follow the link. Something happens (we know what) but you aren't
following the link.

Expected Results:  
The link should open before your eyes, just like for the other two options (same
tab, new window) and just like in other browsers.

Sometimes, a person who never used FF before sits before my computer. Until now,
he never saw a difference (wasn't using it too much) - browsing was just like
before.
Right now, I expect these persons to get stuck at first _blank link they
encounter (and no, I'm not changing my favorite configuration for them...)

Comment 1

[Nickolay_Ponomarev]

Same here. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041001 Firefox/0.10

This is also a problem when opening links from external applications. The
browser window is brought to front, but the tab is opened in background, makes
absolutely no sense to me.

In my opinion either the "Select new tabs opened from links" option should
affect middle(CTRL)-clicked links only, or there should be another option that
applies to new tabs opened by code from bug 172962, default should be 

Comment 2

[Radek 'sysKin' Czyz]

There was some discussion here. Some people say that this should be an
enhancement request for a new option. That would indeed work, but my personal
opinion is that the way it is now is pretty useless. No need for another option,
IMHO.

There's also a problem with localization freeze. The best solution I see is to
automaticaly "select" (brrr, focus. focus! /off topic) tabs opened with left
click, and change the options string from:
 - "a new tab in most recent window"
 + "a new foreground tab (/selected tab) in most recent window"

But there's the obvious problem of strings being frozen.

I still think new tabs opened this way should be "selected" even if strings,
when taken literally, say something slightly different.

Comment 3

[Radek 'sysKin' Czyz]

Changing summary (again) as explained in Comment #2. I'm open for discussions
about it, of course.

Comment 4

[mmortal03]

Say you already have Firefox open and minimized, and you have it set to open all
links in a new tab (one of the new tab behavior options recently added). I
personally don't want more than one Firefox window running on my system unless I
SPECIFICALLY open another one WITHIN Firefox. So, If I doubleclick on my desktop
shortcut to Firefox, or click on the Quick Launch toolbar link, my prefered
behavior would be to have the minimized Firefox window popup into focus, and
have a new tab opened within it, also in focus, and not have a new Firefox
window opened. My current partial solution is to replace all my Firefox
shortcuts with .url files linked to my homepage.  Using this, I can at least get
everything always opened in the same window as tabs. Doing it this way, the
minimized Firefox window WILL pop up into focus, but the new tab still WON'T,
because I don't use the option to "Select tabs opened from links" (because in
any other case, I WOULDN'T want a new tab to steal focus.)  By fixing this bug,
it would solve my problem, because the "Select tabs opened from links" option
only applies to me when I use my middle click, as well.

I would actually like to add a more complete alternate solution to the external
link problem that would allow for more configurability.  We should make another
"Select tabs" case called "Select tabs opened by external programs", and place
it only in about:config, and on by default.  I know you are thinking that there
is no situation where an external program or .url link is clicked on that one
WOULDN'T want focus to shift to this new tab, but take the situation where
someone is using their external program (say a text editor with url support)
RIGHT NEXT to their Firefox window to edit their webpage frames.  They may not
want the current page to change by the other clicked links stealing focus in new
tabs, because they are refering back to and from the top page frameset.  By
deselecting this option for a session this would save them some time and effort.
 It would later be even more handy if the often talked about "Always on top" and
"Never on top" options are ever added to the Firefox View menu, because then a
user could open external program links in  background tabs, while refering the
entire time to the current tab, while never losing focus of the program they are
working in.

Btw, is there an enhancement request for having "Always on top" and a "Never on
top" options in the View menu?

Here is some more external link bugy behavior: When Firefox is minimized,
clicked on .htm files DON'T bring Firefox into focus, but clicked on .url files
DO. Unless they give us options to control Firefox focus situations, case by
case, program by program, filetype by filetype, then ALL external links (.url,
.htm, and other programs) should be handled the same way (which is what this bug
report requests, to by default always bring Firefox into focus, AND bring the
clicked on content into focus when opening external links).

Comment 5

[Richard Corbin]

Under "Tools > Options > Advanced > Tabbed Browsing", there is an option that
could be changed (rather than adding a new option) that would help solve this
(if the back-end code was added also):

*Select new tabs opened from bookmarks or history* ... could become ...
*Select new tabs opened from bookmarks, history or external applications*

Just an idea and this may need a little tweaking to get right / easy to
understand for the user.

Comment 6

[mmortal03]

(In reply to comment #5)
> Under "Tools > Options > Advanced > Tabbed Browsing", there is an option that
> could be changed (rather than adding a new option) that would help solve this
> (if the back-end code was added also):
> 
> *Select new tabs opened from bookmarks or history* ... could become ...
> *Select new tabs opened from bookmarks, history or external applications*
> 
> Just an idea and this may need a little tweaking to get right / easy to
> understand for the user.

That makes total sense.  I think that everyone wants their bookmarks, history,
AND external applications to by default open with focus.  If they needed to use
an external app temporarily, they could disable that option.  Let me add to your
idea.

To completely fix the issue, we should just have two sets of options.  Any more
simplification and it just gets too complicated.

Left Click:
*Select new tabs opened from bookmarks, history or external applications*
Default True
*Select new tabs from links* Default True

Open in new tab (Middle Click):
*Select new tabs opened from bookmarks or history* Default False
*Select new tabs from links* Default False

Comment 7

[Justin Kerk]

I think using a wording like "Open new tabs from bookmarks, history or external
applications in the foreground" would be better since "select" (or even "focus")
isn't terribly clear if you don't already know what the options do. You might
even use "in the background" and reverse what the option does.

Comment 8

[Unknown W. Brackets]

Unless I'm mistaken, changing any text means this cannot happen for 1.0....
there was a localization freeze, no?

Personally, I don't mind a small number of new windows - sometimes they annoy
me, but not always.  However, opening things from other applications... I would
prefer in a tab.

If this tab were not focused by default, I would be very confused.  It seems
everyone agrees on this point - tabs opened from programs should be focused by
default, but there should be an option to change this (because there are those
who would want it otherwise.)

I think the suggestion to use the bookmarks pref made much in the way of sense,
since by default new tabs from bookmarks are selected.  However, without
changing this text... it might be a bit confusing.  That means that other
locales will be confused, whether the text is changed for English or not, and so
it may not really work.

However, I'd like to say that I would very much like to see this changed for 1.0
final.  As I've now said a few times, this probably means no text changes.  In
that case, why not a new pref?  Or perhaps, no pref for 1.0?

Just think of it this way.  My grandma doesn't really know how to use tabs....
so if this feature accidentally got turned on for her, she might get quite
confused.  So, let's say she clicked some link, which said "click here and my
site will open in a new window".... and nothing happened.

Well, my grandma would probably call me, and tell me her browser was broken.  No
new window.  She'd not notice the tabs at all, and just get confused.

Now, let's say the default was the other way.  She'd click it, and it would
open.  When she was done, she'd hit x, and get a message about more than one tab
open.  Being that my grandma isn't stupid, she'd probably get an inkling about
what tabs are at this point.  Thus, it would promote discoverability, without
much (or possibly any) confusion.

Please, change this - for grandma.

-[Unknown]

Comment 9

[mmortal03]

Exactly.  Even if we don't get the options to configure alternatives in 1.0, at
least the backend code setting the defaults should be fixed for 1.0.

Comment 10

[Radek 'sysKin' Czyz]

The fix for opening tabs from external applications seems fo be very simple. It
was attachment 159442 [details] [diff] [review] that added the code. This diff says:
+        if (!gPrefService.getBoolPref("browser.tabs.loadInBackground"))
+          gBrowser.selectedTab = newTab;
ie it checks for the preference. No reason to do this (in fact, it's a bug),
just remove the 1st line.
Can someone make a diff for that?

The code for left click was added as attachment 159443 [details] [diff] [review] . This time, I don't see
this code checking for the preference. I sure hope it won't be difficult to
change...

I'm CCing the author of both patches: Dan M, I hope you don't mind, but it's an
annoying bug :(

Comment 11

[Jim Ginn]

Attachment: fix

I agree that this is the correct approach. We can add additional options for
power users later.

Comment 12

[Jim Ginn]

Another solution is to land this patch and remove the “select” options. I hate
to say this, but I tend to like this option, as it will not result in a string
change. Most users probably won’t miss the fact that tabs can load in the
background (majority are coming from window based browsing where you can’t
really load windows in the background) and right now the wording is confusing.
Of course this will anger some users (please note: I too like the prefs), but
this would be a perfect time for an extension to step up and fill the void.
Remember, it will still be a settable pref in about:config and we can easily add
it back after Firefox 1.0.

I also want to point out that it’s trivial to add a pref to regulate whether
links loaded from left click/external applications load in the background.

Comment 13

[Unknown W. Brackets]

(In reply to comment #12)
> Another solution is to land this patch and remove the “select” options. I hate
> to say this, but I tend to like this option, as it will not result in a string
> change. Most users probably won’t miss the fact that tabs can load in the
> background (majority are coming from window based browsing where you can’t
> really load windows in the background) and right now the wording is confusing.
> Of course this will anger some users (please note: I too like the prefs), but
> this would be a perfect time for an extension to step up and fill the void.
> Remember, it will still be a settable pref in about:config and we can easily add
> it back after Firefox 1.0.

I disagree.  I've used Firefox for a while, and I have liked that the middle
mouse button popped up links without focusing/selecting/switching to them since
day one.  I never ever wanted to change that.

But some do.  In fact, a lot do - including my brother.  When I told him there
was an option to change it, he said "wow, that's great" and asked me where...
since then, he's stopped using Internet Explorer and actually started using
tabs. (before, he had still sometimes used IE, and never used tabs.)

To me, middle click is logically a "open this and keep doing stuff here" type
button.  It makes sense to me that way, because it doesn't quite feel like an
action button.

One of the biggest things about Firefox is tabbed browsing, and saying that it
should not have this option just because most people don't come from using
tabbed browsing.... does not float the boat for me :P.  Some countries aren't
democracies, does that mean America should do away with voting?  Immigrants
won't notice the difference.

Yes, you're saying "keep the pref, just remove the option"... but I'm saying
that's not even enough.  If you remove the option... you're essentially making
it so it's not a feature of Firefox.  My grandma definitely doesn't know how to
use about:config, but she might like the tabs opening out-of-focus if she
learned to use the middle mouse button.

And I certainly hope you don't mean to remove the option and make the default
open in focus - then, this new feature that *caused* this bug would be in
vain... left clicking would be the same as middle clicking... what a waste of a
good button.

-[Unknown]

Comment 14

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #12)
> Most users probably won’t miss the fact that tabs can load in the
> background (majority are coming from window based browsing where you can’t
> really load windows in the background)

And a minority come from other OSes where such functionality may be possible.

I use Linux and TBP, and I always set it up to load internal and external tabs
unfocused. Anything covering up what I'm reading is anathaema.

> Of course this will anger some users (please note: I too like the prefs), but
> this would be a perfect time for an extension to step up and fill the void.
> Remember, it will still be a settable pref in about:config and we can easily add
> it back after Firefox 1.0.

I also happen to be the maintainer of TBP and this is something I've offered for
some time ;-)

> I also want to point out that it’s trivial to add a pref to regulate whether
> links loaded from left click/external applications load in the background.

Why add another pref? Just keep the existing one for left-click links, and add
new meanings to browser.link.external (IIRC). The way I did it with the
equivalent TBP pref, extensions.tabprefs.externalLinkTarget, was:

0 - New window.
1 - New tab in current (recent) window, focused.
2 - Current tab in current (recent) window.
3 - New tab in current (recent) window, unfocused.

Obviously, something like this would need a string thaw after 1.0, but it an be
easily done.

Comment 15

[Jim Ginn]

Ok guys, I have always wanted the prefs to stay in the options window. With that
said, IF this patch lands (or something similar), than the current wording of
the options clearly become even more problematic. When a user can’t even figure
out what the options mean in the first place, then there is no point for the
options to be there.  If the devs approve new strings, than I am more than happy
to withdraw my suggestion. Otherwise, I don’t think leaving in the strings as
they are is a good idea -> they are too confusing. When the localization freeze
ends, the strings can be corrected and the options added back.

(In reply to comment #14)
> Why add another pref? Just keep the existing one for left-click links, and add
> new meanings to browser.link.external (IIRC). The way I did it with the
> equivalent TBP pref, extensions.tabprefs.externalLinkTarget, was:
> 
> 0 - New window.
> 1 - New tab in current (recent) window, focused.
> 2 - Current tab in current (recent) window.
> 3 - New tab in current (recent) window, unfocused.

Easily done. If browser.link.open_newwindow and browser.link.open_external = 3
open tab in focus = 4 open tab in background. Also, I was thinking of TBP when I
asked for an extension to step up.

Comment 16

[Radek 'sysKin' Czyz]

Actually the patch that we have now only affects links opened from external
applications. It's pretty clear that a setting called "select tabs opened from
links" just doesn't apply at all. This setting is just irrelevant in this situation.

The bigger problem is with the left click, since it really is a "tab opened from
link". I, however, strongly suggest to fix this bug and ignore the minor wording
inconstancy. I don't believe that anyone ever wanted the current behaviour, and
extra wording inconstancy is a small price to pay.

As for the "select" being totally confusing, I couldn't agree more. Whenever I
read this I'm sure the browser wants me to select something (as in "select this
option")

Comment 17

[Jim Ginn]

(In reply to comment #16)
> Actually the patch that we have now only affects links opened from external
> applications. It's pretty clear that a setting called "select tabs opened from
> links" just doesn't apply at all. This setting is just irrelevant in this
situation.

The attached patch does affect left clicks, not just external links. To have
only external links take focus all the time we want:

if (!gPrefService.getBoolPref("browser.tabs.loadInBackground") && aContext !=
nsCI.nsIBrowserDOMWindow.OPEN_EXTERNAL)
  gBrowser.selectedTab = newTab;

We should probably take this debate to mozillazine instead of spamming bugzilla.
Once a dev weighs in, I/or someone else can post a patch and get this fixed.

Comment 18

[Dan M]

Comment on attachment 160898 [details] [diff] [review]
fix

*Always* in the foreground? Despite opinions to the contrary using strong words
like "broken" and "useless," Bradley and I don't want tabs to *always* load in
the foreground. And we get to win. As long as he agrees with me :). I'm r-ing
this patch.

I'm unswayed by Grandmother Arguments about the undiscoverability of tabs
loading in the background, because the user has to explicitly set them up to
load in the background. The default is for new tabs to gain focus.

However I agree with Richard (comment 5) the pref that should control the
current situation is more akin to the one controlling whether bookmarks/history
tabs automatically gain focus. It's questionable whether we'll want to add yet
another pref to the dialog. Certainly not during the current localization
freeze.

But it's not so simple. This is generic back-end code with few clues about how
it's being used. Beginning with tomorrow's nightly builds (and hopefully from
then on) this code also affects the treatment of tabs opened when
javascript:window.open is diverted into a tab. I think we can all agree that
popup windows opened on a timer (from an allowed popup site, presumably) would
behave under the sway of the generic "load in background" pref, as the code
currently stands.

The best practical solution, still imperfect, would seem to be to use the pref
controlling bookmarks/history tabs for the two present usages, and use the pref
controlling generic windows for javascript:window.open. The distinction could
be made by using in the window.open case an as-yet undefined third Context
const in the third parameter to openURI.

Comment 19

[Jim Ginn]

Danm,
I want to thank you for your work in getting better tab settings in Firefox. You
did an awesome job. I really never thought that the patch should go in as is,
just posted because of a request.

(In reply to comment #18)
> I'm unswayed by Grandmother Arguments about the undiscoverability of tabs
> loading in the background, because the user has to explicitly set them up to
> load in the background. The default is for new tabs to gain focus. 

Actually, to the best of my knowledge, new tabs load in the background by
default (from firefox.js). This can be confusing behavior especially if the user
is not aware of  how tabs exactly work.

Now that I have had time to think about it, I think there should really be 2-4
prefs here:

1) Whether to focus tabs from links explicitly chosen to open in tabs (this
would be middle clicking, "open in tab", and alt enter). 
2) Whether to focus tabs from links explicitly chosen to open in tabs from
bookmarks and history. This could be rolled into 1 as both actions require a
middle click.
3) Whether to focus tabs opened by direct user action that results in a new tab
(this would be from left click or opened from external application).
4) Whether to focus tabs opened without user interaction (ie. timer based
pop-ups). This pref could be rolled up into 2, for now, as the user has to allow
the pop-up in the first place and I assume most users don't allow a lot of
pop-ups from timers.

For the short term, we could allow the generic open tab option to cover cases
3+4 and the bookmarks/history option to regulate case 2. Case 1 would be
available through about:config or extensions, as Unknown argued that most users
 will use middle click to open links they want to look at later, otherwise, they
can just use left click and the back button to transition between the two sites.
This isn't perfect, either, but it allows for users to have all links open
unfocused (as Bradley argued for) and I think it makes the most logical sense.
Personally, this makes me happy since I want 1+2 in the background, 3 in the
foreground, and 4 doesn't impact me. Furthermore, this matches the current
wording better since the new tab options and the old options use the terms
"opened from links" and "open links”. This also is in agreement with the
shortcut section of the Firefox Help files.

Comment 20

[Jim Ginn]

Attachment: short term fix

Implement what I just stated. This is a very simple three line fix, does not
effect localization, and does not change the meaning of any prefs.

This is only a short-term fix, after Firefox 1.0 we can go back and fix this
properly.

Comment 21

[Jim Ginn]

Comment on attachment 160985 [details] [diff] [review]
short term fix

DanM, does this meet with your approval? I think most users will want to change
whether diverted links open in the background, rather than tabs resulting from
middle clicks. Also, you can still use the options window to have all your tabs
open in the background, which you requested. I wanted to ask for your review,
but I am not sure what address you use.

Comment 22

[mmortal03]

(In reply to comment #18)
> (From update of attachment 160898 [details] [diff] [review])
> *Always* in the foreground? Despite opinions to the contrary using strong words
> like "broken" and "useless," Bradley and I don't want tabs to *always* load in
> the foreground. And we get to win. As long as he agrees with me :). I'm r-ing
> this patch.

This bug should be renamed to "New windows that are forced to opened in tabs by
"Single Window Mode" should have their own focus rules".  The current wording is
scaring away DanM. :)

What we are saying to do here for 1.0 is when using the new "Single Window
Mode", make the situations where links that would normally open in a new window
but are now forced to open via tabs NOT be controlled by the "Select tabs opened
from links" option.  

You are right, the Grandmother argument doesn't fly, because the Grandmother
wouldn't even be turning on the new "Single Window Mode", and even if she just
touched that, these windows would STILL open in focus.  But that isn't the bug
here, actually.

The bug here is when we turn on the recently added Single Window Mode option AND
turn off the "Select tabs opened from links" option.  This new mode was
inadvertantly coded to have it's *special case* of forcing normally NEW WINDOWS
to open as NEW TABS, but STILL have them controlled by the same options as
normal tabs.  This shouldn't be, because these new tabs fall into a special
case.  The key here is to think of these tabs as new windows that would normally
pop up into focus.  Now they are being forced to become tabs, but they should
still act in every other way as if they were new windows popping up.  

The whole point from the beginning of the "Select tabs opened from links" was so
that we could middle click on links and have them open behind what we were
reading.  This option is not meant to have any affect on the new "Single Window
 Mode", and it is actually detracting from it.  We should not have to have one
option selected to have another option work properly, and it even just goes
against logic to have this special case fall under the control of an option not
meant for them.  

Later on we can add settings to control this special case of tabs taking focus
or not.  But at the moment, HARDCORE users aren't able to use the new Single
Window Mode AND have their middle clicked links open in the background, and that
is annoying.

Comment 23

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #22)
> (In reply to comment #18)
> > (From update of attachment 160898 [details] [diff] [review])
> > *Always* in the foreground? Despite opinions to the contrary using strong words
> > like "broken" and "useless," Bradley and I don't want tabs to *always* load in
> > the foreground. And we get to win. As long as he agrees with me :). I'm r-ing
> > this patch.

I still agree with you danm, but this comment is worth considering.

> 
> This bug should be renamed to "New windows that are forced to opened in tabs by
> "Single Window Mode" should have their own focus rules".  The current wording is
> scaring away DanM. :)

<snip long and interesting justification for bug renaming>

Agreed. New windows forced into tabs are special-cased and shouldn't be
controlled using the same controls.

The problem now is how to adequately address this, using either patches to Fx
after aviary-1.0 or using TBP.

Comment 24

[Unknown W. Brackets]

Because, from the above comments, I assumed I was going nuts... I downloaded the
latest nightly and created a completely clean profile.

Select tabs opened from links is, by default, unchecked.  This means they will
load in the background, without focus, as I suggested.

As I thought, aftering turning just this one option (Force links that open new
windows to open in -> a new tab) they loaded in the background.  Indeed, the
same thing happened when I turned on "Open links from other applications in" ->
"a new tab of the most recent window".  This is what I'm arguing against.  I
would very much prefer the default be kept as unfocused for middle-clicking, but
if this is not an option I would prefer that the default for "Select tabs opened
from links" be changed to on.

So I'm not crazy.  The default really is what I thought, and said, it is.

So my Grandmother argument... I've known grandmas who touched settings like
"single window mode", and didn't change other options (they didn't understand
what meant) like the highly confusing "Select tabs opened from links".

-[Unknown]

Comment 25

[Dan M]

Comment on attachment 160985 [details] [diff] [review]
short term fix

Ugh yes, Firefox does load middle-click tabs in the background by default. I
forgot that Firefox and Sunbird for some reason override the default
application setting. So the Grandmother Argument is back.

Nevertheless, this patch won't fly, either. It removes from the UI the ability
to control middle-click tab focus. We can't change functionality at this point.
Agreed, we need to reconsider the UI after the UI freeze. And that my example
of timer window.open was extreme.

This morning I think the solution is to leave the control of left-click tab
focus in the hands of the loadInBackground pref as it currently stands, but
allow Jim's new loadDivertedInBackground pref to override that setting if it
exists. That seems to me to afford the least surprise to a mid-level user
reading the text of the Options dialog, while giving a power user the ability
to fine-tune, and extensions a hook for a more complete UI.

Comment 26

[mmortal03]

(In reply to comment #24)
> Because, from the above comments, I assumed I was going nuts... I downloaded the
> latest nightly and created a completely clean profile.
> 
> Select tabs opened from links is, by default, unchecked.  This means they will
> load in the background, without focus, as I suggested.

Yes, sorry about this, I just noticed today that you were right about the
default setting of this option being off as well.  So both your grandmother
argument, and my argument fly.  Double the pleasure, double the fun.

To fix this bug in the short term, can't we just alter the new "Single Window
Mode" coding to act on its own focus settings?  Later we can add options to
allow user configurability of the special case tabs. Or is this not possible?

Is that what you are saying here in the following?
 
> This morning I think the solution is to leave the control of left-click tab
> focus in the hands of the loadInBackground pref as it currently stands, but
> allow Jim's new loadDivertedInBackground pref to override that setting if it
> exists. That seems to me to afford the least surprise to a mid-level user
> reading the text of the Options dialog, while giving a power user the ability
> to fine-tune, and extensions a hook for a more complete UI.

Comment 27

[Jim Ginn]

Attachment: new hidden pref for left-click tabs

I can live with that.

By default, the browser.tabs.loadInBackground pref regulates middle clicked
links and diverted windows. Creating the pref
browser.tabs.loadDivertedInBackground allows the user to fine tune whether
diverted windows open in focus - independent of the middle click link pref.
Extensions and power users can easily set this pref.

As for the discoverability problem, I think, for now with this solution, we can
leave browser.tabs.loadInBackground set to true by default. If a user is
willing to go into the options menu (the Advanced section) and change the new
tab options, that user is probably going to notice when a tab is loaded in the
background (its pretty obvious considering we hide the tab bar by default).
This also keeps functionality the same from 1.0PR to 1.0.

Comment 28

[Dan M]

Comment on attachment 161088 [details] [diff] [review]
new hidden pref for left-click tabs

I think it's good. Ben? Whaddayasay? I've asked for sr= but really I intend a
directed a=?.

Abridged version, or this entire bug in five sentences: This establishes yet
another pref for tuning what kind of tab gets focus when opened, or doesn't.
The argument is that tabs opened on left-click, such as the ones coming out of
bug 172962, would fain be focused when opened, while those tabs opened on
middle-click, such as the ones we've had for a long time now, would not.
Currently we use the extant middle-click pref and UI for both middle- and
left-click tabs. This patch uses a new left-click pref if it exists and falls
back to the middle-click pref, the one with a UI, if not. Yet another checkbox
in a future version of the Tabbed Browsing dialog is implied.

If we decide this is a good path to take, we should also consider renaming the
prefs before 1.0 to fit their true usage. The generically named
loadInBackground pref really applies only to middle-click tabs, which are fast
becoming only a subset of the tabbed world.

Comment 29

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #28)
> (From update of attachment 161088 [details] [diff] [review])
> I think it's good. 

I think it's good too. And providing a fallback to the old pref also allows 
for seamless behavioural transitions later on.

Comment 30

[chris hofmann]

ben?

Comment 31

[Ben Goodger (use ben at mozilla dot org for email)]

I agree with the original report... you might like a hidden pref for this but I
think focusing the new tab should be the default. Ditto for links coming in from
other applications... i.e. if I set "new tab" for either the "from links
targeting _blank" or "from other applications" prefs, then I think the behavior
should be to show the new tab by *default* not load it in the background... 

why?  because I've had the pref set this way for the past few days and it's
really annoying to click a link in mail or IRC and have it load in the
background only to have to click it to the front. 

What does this patch do, exactly? Can it be made to make focus-tab the *default*
behavior?

Comment 32

[Jim Ginn]

Yes, Ben it can - with slight modification. Look at the patch above it, "short
term fix." If you ignore the changes to the options window (I assume you
wouldn't want this in the UI), the patch will make all diverted links
(window.open, external, and target _blank) load in the foreground, by default,
and creates a pref called browser.tabs.loadDivertedInBackground that can
regulate the focus of diverted links.

Comment 33

[Jim Ginn]

Attachment: default to focus

This patch will cause diverted links to load in the foreground by default. To
change this, set browser.tabs.loadDivertedInBackground to true. This is the
previous patch without the fallback. Although this patch is fine as is, I
strongly suggest, if we go this route, we update the tab options to something
like:

[X] Select new tabs opened from links
[X] Select new tabs opened from external applications or forced links
[X] Select new tabs opened from bookmarks or history

This change keeps the behavior consistent with the previous releases, but does
have a l10 impact. Ben, what do you think?

Comment 34

[Ben Goodger (use ben at mozilla dot org for email)]

The load in background from external applications option is somewhat useless I
imagine to most people... I'm not approving adding any more UI to what we have
now when we're probably going to try and compress what we have in the future.
about:config is suitable as a editing tool for now. 

Comment 35

[Dan M]

Alright Ben it seems an important shift in tab functionality has blindsided us.
Given that we can't add more UI now even if we wanted to, in fact we can't even
change wording, the question on my mind is what should a user expect from a
prefs dialog that asks the question

[ ] Select new tabs opened from links

Is our user expecting this setting to affect these tabs mentioned just 1 cm up
in the same dialog

[ ] Force links that open new windows to open in:
    ( ) a new tab

or is our user expecting this pref to affect tabs opened by middle-clicking; a
hidden pref in Firefox? Hmmmm.

It seems to me that we should shift the generically named
browser.tabs.loadInBackground pref over to left-click and external-URL duty and
invent a new hidden pref for dealing with the (now) less visible middle-click
tabs. All you gotta do then to make the external-URL default the way you want it
is remove the Firefox override.

>The load in background from external applications option is somewhat useless I
>imagine to most people.

Not so, though I have no good idea of what "most" is. The linux crowd especially
seems to resent focus theft. See for example bug 172962 comment 89 point 3 and
bug 262978. Personally I agree with the former and the latter, though to my eye
appears to argue just the opposite, is actually asking that the window remain in
the background (see bug 262978 comment 3).

This is complicated by the fact that the external URL and diverted left-click
tabs aren't quite the same thing, but we've never considered giving them
separate focus prefs.

--

As an aside perhaps it's time to mention I've already heard one user complain:
"I set links to open in new tabs but it's inconsistent. Sometimes I get a new
tab, sometimes it opens in the same window." So there's a third link expectation
group out there. In order from oldest to newest:

1) Do whatever the webpage says. Open a new window, replace my current
   page, knock yourself out.
2) Generally replace my current page but whatever you do, don't give me
   another window, even if that's what the website wants.
3) Leave my current page alone.

#3 seems impractical for long-term use. But unable to see the page source and
not wanting to either, how is a common user supposed to know what to expect when
clicking a link? I can understand the claim of inconsistency.

Comment 36

[Unknown W. Brackets]

Dan M., in my opinion you are mistaken is assuming that everyone will turn this
"single-window mode" on.

If I have it off, which I plan to except perhaps for external links, the middle
click action will remain the only way to get a link into a tab (besides dragging
it into the tab bar) so it seems to me that middle-clicking will still be in
use, and that some people may want to use it to have tabs open with or without
focus.

I would argue that since, previous to this, you could not have new windows open
without focus... it's better to take a small step and annoy those who wanted you
to step farther, than to take such a big step you annoy those who didn't expect
you to move.  My meaning is that it's better to stay closer to the original
functionality, again in my opinion, and that is having new windows (whether they
are "diverted" into tabs or not) always have focus (except with a pref.)

Forgive me if I'm too forward.

Now, I use middle-clicking a lot.  And it may surprise you to know that at one
point, for several months, I did not know the function of middle-clicking.  But
I still opened tabs.  It is easy to forget that you can right click a link and
choose "Open Link in New Tab" - something I did often before I found out you
could middle-click.

People will still right click.  That is the discoverability.  Seeing that option
was my first introduction into how to open tabs and even tabbed browsing.  I
didn't know about ANY options before then.  I would argue that people WILL know
about tabs, in many cases, when they set the options in the preferences dialog.

Of course, I would also say the name for the pref that controls focus of new
tabs (and everyone agrees on this, largely, it's just nearly impossible to fix)
is horribly confusing.  You say that having it not affect "diverted" links will
confuse people... I say, we don't even need it to do anything with diverted
links to confuse people.  I hardly think it will help or hurt people whether
diverted links are focused either way or not - that option's label means nothing
to me... and I'm a programmer!  It won't mean anything to most people, imho.

And... if mostly Linux people will want to change the pref... so be it.  My
grandmother does not use Linux, nor will she be using about:config.  Linux
users, however, are several flights more likely to use about:config.

Lastly, I think the "option #3" you mentioned a bit strange.  You can go to
Properties... on links and find what they will open in.  It is the website
designer's job to make the site usable, even use a css style like a[target] or
something to color them different if neccessary... but it's not the browser's. 
If someone really wants that option, I can't imagine why an extension couldn't
solve their need... anything otherwise would be bloat, imho.

-[Unknown]

Comment 37

[Jim Ginn]

(In reply to comment #35)
> Is our user expecting this setting to affect these tabs mentioned just 1 cm up
> in the same dialog or is our user expecting this pref to affect tabs opened by
> middle-clicking; a hidden pref in Firefox? Hmmmm.

I saw the same potential confusion and my solution is the second attached patch.
The problem, of course, is that this is inconsistent with previous builds, as we
have now changed the meaning of the option.

> It seems to me that we should shift the generically named
> browser.tabs.loadInBackground pref over to left-click and external-URL duty and
> invent a new hidden pref for dealing with the (now) less visible middle-click
> tabs. All you gotta do then to make the external-URL default the way you want it
> is remove the Firefox override.

I disagree, I think the prefs should stay the same and we use the new
browser.tabs.loadDivertedInBackground (or something) to regulate diverted links.
The reason for this is the loadInBackground pref doesn’t just regulate middle
click links, but links opened by the right click command “Open in new Tab” – the
most obvious/logical means to open links in tabs to the user (especially new
users). Furthermore, it is inconsistent with previous builds and will be
confusing for returning users.

> This is complicated by the fact that the external URL and diverted left-click
> tabs aren't quite the same thing, but we've never considered giving them
> separate focus prefs.

Agreed. Bradley proposed the best option for doing this in comment 14. The
problem is, this solution breaks the current tab option UI.

Comment 38

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(In reply to comment #36)
> Dan M., in my opinion you are mistaken is assuming that everyone will turn this
> "single-window mode" on.

Perhaps not everyone, but a considerable number.

> And... if mostly Linux people will want to change the pref... so be it.  My
> grandmother does not use Linux, nor will she be using about:config.  Linux
> users, however, are several flights more likely to use about:config.

Fascinating - I would think that there are just as many Windows and OSX users
who mess with about:config as well!

> 
> Lastly, I think the "option #3" you mentioned a bit strange.  You can go to
> Properties... on links and find what they will open in.  It is the website
> designer's job to make the site usable, even use a css style like a[target] or
> something to color them different if neccessary... but it's not the browser's. 
> If someone really wants that option, I can't imagine why an extension couldn't
> solve their need... anything otherwise would be bloat, imho.

Which is precisely why I will now take either attachment 161088 [details] [diff] [review] or 161279 - if
you'll check my latest build of TBP, 0.9.90, you'll see that in the Tab Focus
section of the Tabbed Browsing panel of the Preferences dialog has the following
checkbox (the panel is created by TBP, which suppresses the original UI):

"Load windows diverted into tabs in the background"

Everybody wins - the default UI is OK, the strings don't need munging, and if I
create the pref on install with a default of 'false', then the original meaning
of browser.tabs.loadInBackground is preserved.

If I may say so, Mr. Goodger, take your pick.

Comment 39

[Dan M]

Landru! Guide us!

PS:
>Dan M., in my opinion you are mistaken is assuming that everyone will turn this
>"single-window mode" on.
Frequency of use has nothing to do with my argument.

Comment 40

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 161279 [details] [diff] [review]
default to focus

r+a=[e-mail]

Comment 41

[Ben Goodger (use ben at mozilla dot org for email)]

I'm not sure we've addressed all the issues discussed here, so I'm not marking
this fixed, however the last patch rubs me the right way so I've checked it in
and am minusing this bug for 1.0. 

The reason to diverge from the 'load in background' preference here goes to user
intent. 

When middle/ctrl+clicking on links on a web page, the general case is that the
user is not done with that page yet, he is queuing up a set of pages to look at
when he's done. 

When loading a link from another application such as an IRC client or mail, the
argument is that he's looking to view that link *now* (since he presumably
left-clicked on the link in that application)

When loading a link in the browser targeted at _blank by left clicking again we
can reasonably assume the intent of the user is to see that content *now* not
later, so again focusing it seems a good default. 

So there seem to be two "load in background" cases - one controlling whether or
not to select the tab when the user was performing an
open-with-force-in-new-medium-modifier and one controlling whether or not to
select the tab when the user was performing a standard "just let me see this
darned link" left-click. In the latter case, I'd rather not have the user need
to think about what they were doing, and just have what they were probably
expecting - see the page content appear - happen. 

Comment 42

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Attachment 161279 [details] [diff] has approval-aviary+; has it been checked in yet?

Comment 43

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041008
Firefox/0.10 - Sweetlou

WFM

Comment 44

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Great!

JFEI, this preference will be configurable using any 0.9.X prerelease build of
TBP. Look for "Load windows diverted into tabs in the background".

I'll need to change my patch for bug 262575.

Comment 45

[Jim Ginn]

Should we open a new bug so that we can fix properly for the trunk/post 1.0? Or
just continue on this bug?

Comment 46

[Ed Hume]

The current behavior is really annoying, and there is no pref to stop the annoyance.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041008
Firefox/0.10

I prefer to go through my email messages, clicking on the various links, then
read the links at my leisure. With builds up through a few months ago, I could
do this. I could do this even more recently by opening a non-registered (second)
installation of Firefox by hand. Messages would then open from Outlook in
background without Firefox disturbing my reading.

Now, from Ben's comment 41, I take it that my preferred method is not preferred.
I can accept the current method as a default, but I would like a settable pref
so that I don't have to keep clicking back from Firefox intruding on my reading.
I'd even accept a pref I can put in user.js. But the current method is quite rude.

Comment 47

[Worcester12345]

(In reply to comment #46)
> The current behavior is really annoying, and there is no pref to stop the
annoyance.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041008
> Firefox/0.10
> 
> I prefer to go through my email messages, clicking on the various links, then
> read the links at my leisure. With builds up through a few months ago, I could
> do this. I could do this even more recently by opening a non-registered (second)
> installation of Firefox by hand. Messages would then open from Outlook in
> background without Firefox disturbing my reading.
> 

And here all along I thought it was just my imagination or a bad setting
somewhere. ME TOO! I can't believe I just let it go, and now there is finally a
bug on it.


> Now, from Ben's comment 41, I take it that my preferred method is not preferred.

WRONG!



> I can accept the current method as a default, but I would like a settable pref
> so that I don't have to keep clicking back from Firefox intruding on my reading.

This is especially good with messages in Thunderbird from Mozillazine pointing
to threads, for example. I want to click click click on three, then delete the
emails, THEN switch over to Firefox to read the threads.

Comment 48

[mmortal03]

I knew this was coming...as soon as I logged into Hotmail today with the new
Aviary with this patch checked in, I knew someone was going to say that they
like clicking all their email links first, and then going through them after
they close out their external email program (Hotmail made me consider this, in
this case, only because it ALSO uses diverted links (by way of Javascript) to
popup the URLs inside your emails into new windows, and the fix of this bug
controls the action of BOTH external programs AND these javascript popups).  For
Hotmail's case, you can't middle click on the links because Bug 55696 (and Bug
125668) hasn't been fixed.  In the case of external email programs, obviously,
you can't apply the middle click functionality to links within them AT ALL.  

So, if you ARE still talking about a TAB focus problem, which this bug fixes,
but which I doubt is your problem, then read up, and you will see that
browser.tabs.loadDivertedInBackground is the setting that you need to fool with.
  
More likely, you are not talking about the TAB focus problem that this bug
fixed, but instead referring to a WINDOW focus bug, where the entire Firefox
WINDOW gains focus for each link clicked in an external program.  Well, that is
a whole 'nother problem.  This bug did not change that behavior one way or the
other.  If you clicked on an external program link before this bug was fixed,
the Firefox WINDOW WOULD still gain focus; the whole problem here was that the
TAB associated with the link wouldn't.  

A way to fix YOUR problem, which seems to be next on the list of focus bugs, is
to have a new option added to the Firefox View menu called "Never on top" that
you could select before you read your mail, and/or have an option added to
Firefox that controls whether or not the entire window steals focus when
external links are clicked.  I don't think there is an enhancement request for
either of these.  In your special case of using Thunderbird though, I assume you
CAN middle click on links within emails and have them open in Firefox tabs?  In
this case, Thunderbird should still be treated as an external program, and so
the way of doing things before was buggy behavior, though you sure thought it
was a feature :)

To sum this all up, most likely, this is not the bug you are looking for, though
the title makes it sound like it is.  Instead, you have to understand that your
previous convenience was actually just a coincidence and buggy behavior, and the
correct way of implementing what YOU are wanting still needs to be come up with.

Comment 49

[Dan M]

Quite right mmortal03. Sasquatch, all, bug 263553 is the correct place for
visions of unactivated windows.

Comment 50

[Radek 'sysKin' Czyz]

OK I'm setting this to FIXED because the browser's tabs work exactly as I
explained when I reported this bug.

I see there is more discussion about whether *window* should be brought back
from minimized/unfocused state for external links - I hope you don't mind when I
say that this is a separate bug / request.

Thanks everyone for solving this :)