Firefox steals the focus from other apps when clicking on a link

[mmertens]

Binary package hint: firefox-3.5

It is more a very uncomfortable situation. When you get via KMail a list with many links from Internet, you wish to click on the links you are intereste in continously and THEN go to Firefox and look the pages. On every click Firefox comes to the front and you have to select KMail again to click on the next and so on.

Further, Firefox works great!

Thank you in advance for your help.

Cordially,

Manfred

ProblemType: Bug
Architecture: amd64
Date: Thu Nov 12 16:25:35 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Kubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: firefox-3.5 3.5.5+nobinonly-0ubuntu0.9.10.1
ProcEnviron:
 LANGUAGE=es_ES:es:en_GB:en
 LANG=es_ES.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-14-generic x86_64
XsessionErrors: (polkit-gnome-authentication-agent-1:1804): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Nickolay Ponomarev (asqueella)]

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

[Syskin (syskin)]

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.

[Syskin (syskin)]

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

[Mmortal03 (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).

[Richard-corbin (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.

[Mmortal03 (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

[Dopefishjustin (dopefishjustin)]

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.

[Unknown W. Brackets (unknownbrackets)]

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]

[Mmortal03 (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.

[Syskin (syskin)]

The fix for opening tabs from external applications seems fo be very simple. It
was attachment 159442 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 . 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 :(

[Jcginn (jcginn)]

Created an attachment (id=160898)
fix

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

[Jcginn (jcginn)]

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.

[Unknown W. Brackets (unknownbrackets)]

(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]

[Kakadu+bugzilla (kakadu+bugzilla)]

(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.

[Jcginn (jcginn)]

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.

[Syskin (syskin)]

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")

[Jcginn (jcginn)]

(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.

[Danm-moz (danm-moz)]

(From update of attachment 160898)
*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.

[Jcginn (jcginn)]

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.

[Jcginn (jcginn)]

Created an attachment (id=160985)
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.

[Jcginn (jcginn)]

(From update of attachment 160985)
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.

[Mmortal03 (mmortal03)]

(In reply to comment #18)
> (From update of attachment 160898)
> *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.

[Kakadu+bugzilla (kakadu+bugzilla)]

(In reply to comment #22)
> (In reply to comment #18)
> > (From update of attachment 160898)
> > *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.

[Unknown W. Brackets (unknownbrackets)]

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]

[Danm-moz (danm-moz)]

(From update of attachment 160985)
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.

[Mmortal03 (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.

[Jcginn (jcginn)]

Created an attachment (id=161088)
short term fix v2

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.

[Danm-moz (danm-moz)]

(From update of attachment 161088)
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.

[Kakadu+bugzilla (kakadu+bugzilla)]

(In reply to comment #28)
> (From update of attachment 161088)
> 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.

[Chofmann (chofmann)]

ben?

[Bugs-bengoodger (bugs-bengoodger)]

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?

[Jcginn (jcginn)]

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.

[Jcginn (jcginn)]

Created an attachment (id=161279)
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?

[Bugs-bengoodger (bugs-bengoodger)]

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.

[Danm-moz (danm-moz)]

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.

[Unknown W. Brackets (unknownbrackets)]

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]

[Jcginn (jcginn)]

(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.

[Kakadu+bugzilla (kakadu+bugzilla)]

(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 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.

[Danm-moz (danm-moz)]

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.

[Bugs-bengoodger (bugs-bengoodger)]

(From update of attachment 161279)
<email address hidden>

[Bugs-bengoodger (bugs-bengoodger)]

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.

[Kakadu+bugzilla (kakadu+bugzilla)]

Attachment 161279 has approval-aviary+; has it been checked in yet?

[Peter-vanderwoude (peter-vanderwoude)]

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

WFM

[Kakadu+bugzilla (kakadu+bugzilla)]

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.

[Jcginn (jcginn)]

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

[Ehume-pshrink (ehume-pshrink)]

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.

[Worcester12345 (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.

[Mmortal03 (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.

[Danm-moz (danm-moz)]

An option to force Firefox to remain on the background would be nice, that way
you could just click all links (in a message, for example) and then switch to
Firefox instead of clicking a link, switching the focus back to the email client
after Firefox steals it, click another link etc.

(By Timo Tolonen in bug 172962 comment 89.)

I've attempted to set the Summary to catch as many duplicate bug filings as
possible, since this request has popped up repeatedly in bugs in which it does
not belong.

[Danm-moz (danm-moz)]

Note bug 159946, which essentially makes the exact opposite complaint.

[Danm-moz (danm-moz)]

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

[Worcester12345 (worcester12345)]

Coming here from https://bugzilla.mozilla.org/show_bug.cgi?id=262537 "Tabs
opened from left click and from external applications should always open in
foreground" bug.

It used to work this way from Thunderbird to Firebird. You'd get 3 email
messages (say, about mozillazine forum updates), click the link and delete each
one, then switch over to Firebird to read the three pages. To do this all in
tabs is great versus 3 separate windows, and I think that is working OK now. The
trouble is that now one has to click back and forth from program to program.

[Kakadu+bugzilla (kakadu+bugzilla)]

Which part of the core controls this? I used to be able to stop window focusing
in a <window onload="Startup();"/> from TBP's XUL overlay.

[Danm-moz (danm-moz)]

Oh, I don't know how much control we have over this. (We could probably have
more control with some effort, but I think whatever control we may have appeared
to have was mostly serendipity.) You may also be interested in bug 255123. See
especially bug 255123 comment 30.

[Kakadu+bugzilla (kakadu+bugzilla)]

Hmmmm.

I just read bug 255123, and this does seem like a thorny issue. But knowing
where most of the window focusing is being done would be useful.

[Kakadu+bugzilla (kakadu+bugzilla)]

Found it.

http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#2415

I know zilch about nsGlobalWindow.cpp but it seems that wrapping lines 2454 and
2461 with appropriate code to check for the existence of a pref just might do
the trick. Perhaps line 2438 could also be wrapped.

[Danm-moz (danm-moz)]

Oh my, no. You don't want to disable window.focus in all cases just because a
pref was set requesting control in one case. Additionally, it's more likely that
the system is activating the window elsewhere, and refusing to play along at
this point would at best confuse things.

[Kakadu+bugzilla (kakadu+bugzilla)]

Well I wasn't really suggesting that, just saying that I found the spot where
all the window.focus() calls end up, and also identified the spots where control
would be needed if the focus() function really needed to be disabled.

Now we just need to find the spots where this is called...

[Kakadu+bugzilla (kakadu+bugzilla)]

Could somebody point me in the right direction to discover where the
window.focus(), content.focus() and _content.focus() calls are passed to the
nsGlobalWindow.cpp Focus() member function? I'm thinking that controlling the
focus() calls there would satisfy folks who want unfocused windows, but also
prevent massive breakage by editing nsGlobalWindow.cpp's Focus() function.

[Worcester12345 (worcester12345)]

Should this get the regression keyword, since this used to work before recent
releases?

[Syskin (syskin)]

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 :)

[Dean-tessman (dean-tessman)]

Bradley: Maybe jst's patch (attachment 160278) in bug 124750 will point you in
the right direction. It handles focus() calls on specific form elements,
perhaps it's the same code path for window.focus().

[Danm-moz (danm-moz)]

With bug 255123 fixed, beginning in tomorrow's nightly Windows builds you can
achieve the requested effect by setting Firefox to open external URLs in tabs
and setting the (UI-less) pref browser.tabs.loadDivertedInBackground true.
Arguably we're doubling up that pref and could employ YET another as well, but
there's just the one at this time.

[Worcester12345 (worcester12345)]

Tried to change block request from 1.8b4 to 1.8b5, which is what I first
intended. I am pretty sure that is what I clicked. Isn't there a bug for the
wrong behavior on these bugzilla pages?

Anyhow, it wouldn't let me.

[Adam Guthrie (ispiked)]

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

[Worcester12345 (worcester12345)]

Is this the same as 56690? If so, should they both go into "core"?

[Dkw1777 (dkw1777)]

(In reply to comment #0)
> An option to force Firefox to remain on the background would be nice, that way
> you could just click all links (in a message, for example) and then switch to
> Firefox instead of clicking a link, switching the focus back to the email client
> after Firefox steals it, click another link etc.
>
> (By Timo Tolonen in bug 172962 comment 89.)
>
> I've attempted to set the Summary to catch as many duplicate bug filings as
> possible, since this request has popped up repeatedly in bugs in which it does
> not belong.
Using the Tabbrowser Preferences extension option "Load windows diverted tabs in the background" used to work on Firefox versions earlier than 1.0PR.

[Ehume-pshrink (ehume-pshrink)]

TBP again allows you to open new tabs in background. I do it all the time now with Firefox 1.5 beta2.

[Worcester12345 (worcester12345)]

(In reply to comment #16)
> (In reply to comment #0)
> > An option to force Firefox to remain on the background would be nice, that way
> > you could just click all links (in a message, for example) and then switch to
> > Firefox instead of clicking a link, switching the focus back to the email client
> > after Firefox steals it, click another link etc.
> >
> > (By Timo Tolonen in bug 172962 comment 89.)
> >
> > I've attempted to set the Summary to catch as many duplicate bug filings as
> > possible, since this request has popped up repeatedly in bugs in which it does
> > not belong.
> Using the Tabbrowser Preferences extension option "Load windows diverted tabs
> in the background" used to work on Firefox versions earlier than 1.0PR.
>
...and earlier than that, the program did it without the help of an extension...

[Mike Connor (mconnor)]

browser.tabs.loadDivertedInBackground can be set to true in about:config to achieve this. This is a pref that doesn't need UI, either, so I'm not sure what the point is, exactly. If you call focus() on window.content, that will focus the window (as it rightly should) and if you create and select a new tab, that's what we do. Short of adding even more complexity to tabbrowser, I don't see a way to open in foreground while delaying focus without a core-level fix that would allow us to call focusIfAndWhenWindowIsFocused() or something instead.

[Kakadu+bugzilla (kakadu+bugzilla)]

(In reply to comment #19)
> browser.tabs.loadDivertedInBackground can be set to true in about:config to
> achieve this. This is a pref that doesn't need UI, either, so I'm not sure
> what the point is, exactly.

The point is that it is there and it is useful - I like being able to load external URIs into the browser without stealing focus from my current tab. What I don't like is that the window itself is raised every time; Firefox never used to do this, and many people attributed the loss of this behaviour to changes to TBP.

> Short of adding even more complexity to tabbrowser, I don't
> see a way to open in foreground while delaying focus without a core-level fix
> that would allow us to call focusIfAndWhenWindowIsFocused() or something
> instead.

That's basically what the point of this bug is. How hard would it be to add the necessary core APIs to allow focus to be suppressed when tabbrowser creates new tabs?

[Mike Connor (mconnor)]

(In reply to comment #20)
> (In reply to comment #19)
> > browser.tabs.loadDivertedInBackground can be set to true in about:config to
> > achieve this. This is a pref that doesn't need UI, either, so I'm not sure
> > what the point is, exactly.
>
> The point is that it is there and it is useful - I like being able to load
> external URIs into the browser without stealing focus from my current tab. What
> I don't like is that the window itself is raised every time; Firefox never used
> to do this, and many people attributed the loss of this behaviour to changes to
> TBP.

Right, but if we have that option as a hidden pref, and we're not going to expose UI for it, what's remaining here? You want the option to not steal access from the current tab, which we have.

Selecting the current tab without bringing the window forward would require allowing focus to happen when the window was brought forward, not when the focus() call happens. Really a bug should be filed in core to explore supporting something like this, and we can revisit adding this behaviour to tabbrowser as an option. I don't see the utility of that particular config, in the general case.

[Worcester12345 (worcester12345)]

Changing that setting in about:config worked for me. Now, the thing is to get it into a preference so it is easy to turn on and off as necessary. This should go under Tools:Options:Tabs. Thanks.

[Kakadu+bugzilla (kakadu+bugzilla)]

(In reply to comment #21)
> Right, but if we have that option as a hidden pref, and we're not going to
> expose UI for it, what's remaining here? You want the option to not steal
> access from the current tab, which we have.

What I want is what you suggested in the paragraph below - the ability to focus() a tabbrowser tab _without_ sending a focus message to the OS to raise the entire Firefox window.

>
> Selecting the current tab without bringing the window forward would require
> allowing focus to happen when the window was brought forward, not when the
> focus() call happens. Really a bug should be filed in core to explore
> supporting something like this, and we can revisit adding this behaviour to
> tabbrowser as an option. I don't see the utility of that particular config,
> in the general case.

That makes sense to me - such an API would of course be for Firefox 3.0.

[Worcester12345 (worcester12345)]

(In reply to comment #23)
...
> > Selecting the current tab without bringing the window forward would require
> > allowing focus to happen when the window was brought forward, not when the
> > focus() call happens. Really a bug should be filed in core to explore
> > supporting something like this, and we can revisit adding this behaviour to
> > tabbrowser as an option. I don't see the utility of that particular config,
> > in the general case.
>
> That makes sense to me - such an API would of course be for Firefox 3.0.
...
Is there a bug for this?

[Kevin Brosnan (kbrosnan)]

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

[Kevin Brosnan (kbrosnan)]

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

[Kevin Brosnan (kbrosnan)]

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

[Kevin Brosnan (kbrosnan)]

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

[Vincent+moz (vincent+moz)]

Note that this bug also occurs when starting Firefox, reloading a session with many tabs: Firefox constantly grabs the focus until everything has been loaded. For this reason at least, this should be seen as a bug, not as an enhancement.

[Johnath (johnath)]

This will not block Firefox 3.6. In fact, if I'm understanding this correctly:

> Changing that setting in about:config worked for me. Now, the thing is to get
> it into a preference so it is easy to turn on and off as necessary. This should
> go under Tools:Options:Tabs. Thanks.

my inclination would be to WONTFIX.

[Ehume-pshrink (ehume-pshrink)]

Re- Comment#30. The initial description of this bug began "An option to . . . "

The point is to put that pref in the UI, as per comment #22, which you quoted. Why limit the solution to people who know how to manipulate about:config or user.js?

[mmertens (mmertens)]

Binary package hint: firefox-3.5

It is more a very uncomfortable situation. When you get via KMail a list with many links from Internet, you wish to click on the links you are intereste in continously and THEN go to Firefox and look the pages. On every click Firefox comes to the front and you have to select KMail again to click on the next and so on.

Further, Firefox works great!

Thank you in advance for your help.

Cordially,

Manfred

ProblemType: Bug
Architecture: amd64
Date: Thu Nov 12 16:25:35 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Kubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: firefox-3.5 3.5.5+nobinonly-0ubuntu0.9.10.1
ProcEnviron:
 LANGUAGE=es_ES:es:en_GB:en
 LANG=es_ES.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: firefox-3.5
Uname: Linux 2.6.31-14-generic x86_64
XsessionErrors: (polkit-gnome-authentication-agent-1:1804): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Jonathan Thomas (echidnaman)]

KMail just invokes the browser; it does nothing special with the focus.

[Micah Gersten (micahg)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track reply to upstream through Launchpad by clicking on the Reply To Mozilla Bugzilla link on an upstream comment after the upstream bug is imported.
I'm going to mark it as Triaged and wait for upstream to work on this. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

[Micah Gersten (micahg)]

Adding a tracking task to the firefox package as that's where future versions will be.

[mmertens (mmertens)]

I think the stealing of the focus by links is a VERY unpleasant bug from Firefox... but it seems to be difficult to solve, therefore y wait for further actualizations that come without this problem.

Regards,
Manfred

[greeny (greenlittlething)]

I was just browsing firefox related bugs and spotted a funny thing. There's a bug https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/546969 that is actually the exact opposite of this bug: "Focus does not change to firefox when a hyperlink is clicked in another application". I guess u guys need to figure out "who's right" and which behaviour is the one we should support because you can't have both.

[cameleon (el-cameleon-1)]

I think this is clear: there is only one person affected by this problem, but already 6 for the opposite bug. So please go back to the normal behavior, which is that when the user wants to browse a link, the link open and is viewable without any other actions.

[Gavin Sharp (gavin-sharp)]

This is not a suitable default behavior, and I don't think it's commonly desired enough to add as an option (on some platforms it may not even be doable).

[Vincent-moz (vincent-moz)]

Just a note to say that the problem mentioned in Comment #29 no longer occurs.

[Vincent-moz (vincent-moz)]

Bug 775400 should be resolved as a dup of this bug.

[roger21 (roger21)]

browser.tabs.loadDivertedInBackground;true doesn't works has it used to: now the focus is lost from the calling app, the page is still loaded in the background BUT the user has to click back on his app to continue using it.

This cancel the point of browser.tabs.loadDivertedInBackground;true and, especially when scrolling/clicking from a mail, it is infuriating since you have to move the mouse out of the link, do dummy click and only then you can continue scrolling, it's a bug, it needs a reop.

all windows versions