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.

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

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.

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.

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.

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.

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.

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.

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

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.

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

Bradley: Maybe jst's patch (attachment 160278 [details] [diff] [review]) 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().

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.

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.

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

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

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

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

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

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.

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

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

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.

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

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

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.

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.

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?

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

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

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

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