User Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1 Build ID: 20120713134347 Steps to reproduce: - open msg in tbird 14.0 - click on link in msg Actual results: - link opened in firefox - firefox stole focus Expected results: focus should have remained on tbird.

howdy y'all, os = win7x32 ff ua = Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0.1 tb ua = Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 just updated to ff1401 and now i am again seeing focus stealing when a link is sent to firefox. for instance, when i click on a link in tbird the focus now switches to firefox. that is not how it was before the update. when the last update to flash came out, this also happened. with help from the forum folks at mozillazine, i was able to track it down to flash and simply disabled flash to fix the problem. flash is _still_ disabled, but now that ff has updated to the problem has returned. the problem also occurs in mozilla safe mode. mozillazine forum thread ... - since update to ff1401, links sent to ff steal focus • mozillaZine Forums http://forums.mozillazine.org/viewtopic.php?f=38&t=2504105&p=12145367#p12145367 take care, lee

I can confirm that this is still happening with Firefox Nightly builds and Thunderbird Daily. (It also happens with opening links in Skype, so I don't think it's a Thunderbird-exclusive.) I'm on Windows 8. And, actually, it doesn't look like Firefox takes the focus when I click the links in another application. Firefox's window does not take the "focused" appearance, and it stays in the background, while the application I clicked the link from stays in front. It's just that the application I click the link from loses focus (to the desktop, maybe?)

(In reply to Wes Kocher (:KWierso) from comment #2) > (to the desktop, maybe?) Hrm, if the desktop is focused, the arrow keys can move around between icons on the desktop, but when I click a link, the arrow keys don't target those icons...

howdy KWierso, blast! [*frown*] you are correct, firefox is NOT stealing the focus. i can't find out where the focus is going. it doesn't seem to be going to anything on the desktop or the system menus, tho. if i set chrome as the system default browser, IT gets the focus. but when i switch the system default browser back to firefox, i get the same "focus goes somewhere non-obvious" effect. this is looking more an more like the way things behaved when flash was the problem. flash IS installed, but it very definitely is disabled. take care, lee

So, just as an extra datapoint, if I set browser.tabs.loadDivertedInBackground back to the default 'false', when I click a link in another application, it opens a tab in Firefox, that tab becomes focused, and Firefox gets application focus. When I have that pref set to 'true' and I click a link in another application, it opens in a tab in Firefox, whatever tab was previously focused in Firefox stays focused, and neither Firefox nor the other application has actual focus on the system.

Issue still present in v15

Issue still present in FireFox 16.0.1

I'd seen this a couple times in the last several months, i.e. rarely. But not seen in the past month. In all cases, using firefox and thunderbird nightly builds.

Taking a stab at getting this to the proper component.

howdy y'all, this post ... http://forums.mozillazine.org/viewtopic.php?p=12396635#p12396635 " What you describe happens with me if I set browser.tabs.loadDivertedInBackground to true. " ua = Mozilla/5.0 (Windows NT 6.2; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ... seems to indicate the problem still exists in ff19. take care, lee

howdy y'all, this bug ... - 541923 – focus problem invoking firefox with createprocess https://bugzilla.mozilla.org/show_bug.cgi?id=541923 ... seems to be somewhat related. i _think_ it has a different cause since the problem here didn't show up until ff14. would someone who better understands the ins-n-outs of this please decide if this bug otta be duped to that one? take care, lee

http://hg.mozilla.org/releases/mozilla-aurora/rev/895e866ddec3 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20121109042012 This problem happens since Firefox14. This problem happens regardless of Version# of Thundervird. Steps to reproduce: 1. Make sure Firefox is "System Default Browser" (Tools > options > Advanced > General ) 2. Set browser.tabs.loadDivertedInBackground = true in about:config 3. Restart browser 4. Open Thunderbird (or any other apprication) 5. Click a link in Thunderbird Actual results: Thunderbird becomes inactive state. And the focus goes to desktop. (Though Firefox is still in inactive state as expected) Expected results: Thunderbird should be stay active state. Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/147c0d893cdb Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120327 Firefox/14.0a1 ID:20120327150849 Bad: http://hg.mozilla.org/mozilla-central/rev/244991519f53 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120327 Firefox/14.0a1 ID:20120327153449 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=147c0d893cdb&tochange=244991519f53 Suspected : 09362c5dceafRobert Strong — Bug 491947 - Disable DDE shell integration. r=jmathies

This in an issue that's been in the build for several cycles, not a release blocker at this point so no need to track.

first report and confirmation NEW is in Jul-2012... be negligent in developer's duties...

Still present in the newly released 17.0

Present in FF 17 on ubuntu 12.04.1 LTS.

(In reply to soltysh from comment #17) > Present in FF 17 on ubuntu 12.04.1 LTS. This bug is for a windows specific regression (e.g. not a Linux bug).

Version 18.0 of FF still has this bug.

Still present in version 19.0

19.0.2 still shows the issue

Version 20.0.1 does not show a change in behavior

Version 21 got installed yesterday, and the problem is still present. Tracking flags seem to hint that the problem will atleast be present until version 23.

Just updated to FF25 - Bug is still present.

howdy y'all, bug 541923 just mentioned what seems to be the exact same problem with a few other details. see the following comment ... - https://bugzilla.mozilla.org/show_bug.cgi?id=541923#c13 take care, lee

Dup of bug 263553.

howdy Vincent Lefevre, this bug does not seem to be a dupe of bug 263553. that one is about "keep browser in background (unfocused, unactivated) as new tabs are opened into it" which is what the pref "browser.tabs.loadDivertedInBackground = true" seems designed to do. _this_ bug is about the failure to leave the focus in the source app [tbird in particular, but any other app that sends a link to ff]. the two items are not the same. [*grin*] take care, lee

True. In my case I use Outlook as an e-mail client, and prior to version 16 atleast it worked as expected. Clicking a link in a mail left focus on Outlook, while Firefox opened a tab and connected to the website. So I could just click, hit delete to remove the mail, and be presented with the next mail for clicking. As it is since atleast version 16 is that I click a link, have to move the mouse a bit up, click again, and then can hit delete to remove the mail. Then move the mouse down, and click on the next link (yeah, I'm talking forum notification e-mails here ;)).

(In reply to Lee_Dailey from comment #27) > this bug does not seem to be a dupe of bug 263553. that one is about "keep > browser in background (unfocused, unactivated) as new tabs are opened into > it" which is what the pref "browser.tabs.loadDivertedInBackground = true" > seems designed to do. No, read the bug report: |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. This is exactly the same bug. The comment about browser.tabs.loadDivertedInBackground is just bogus (I don't know what this option is supposed to do, I couldn't find any difference). > _this_ bug is about the failure to leave the focus in the source app [tbird > in particular, but any other app that sends a link to ff]. Just like bug 263553.

howdy Vincent Lefevre, please see bug 263553 – keep browser in background (unfocused, unactivated) as new tabs are opened into it - Comment 21 - https://bugzilla.mozilla.org/show_bug.cgi?id=263553#c21 three points ... [1] that bug is CLOSED as WONTFIX. [2] it covers adding a UI to the "browser.tabs.loadDivertedInBackground" pref. [3] it was opened on 2004-10-08, was last active in 2009, and therefore covers a VERY different version of firefox. THIS bug is about the failure to honor that pref. instead, firefox sends the focus to "some mystery location" in windows. i don't know where it goes in other operating systems. THIS bug covers a regression that appeared in ff 14.0.1 and still exists in ff 25.0. it's really quite different ... take care, lee

(In reply to Lee_Dailey from comment #30) > please see bug 263553 Read again the bug report: |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. This is *exactly* the same bug: an external link sent to Firefox makes Firefox steal the focus. > – keep browser in background (unfocused, unactivated) as new tabs are opened > into it > - Comment 21 - https://bugzilla.mozilla.org/show_bug.cgi?id=263553#c21 Again, this comment is bogus. > three points ... > [1] that bug is CLOSED as WONTFIX. So what? > [2] it covers adding a UI to the "browser.tabs.loadDivertedInBackground" pref. No, it doesn't. Please RTFM. browser.tabs.loadDivertedInBackground is a different thing, that doesn't solve the problem. > [3] it was opened on 2004-10-08, Several bugs are even older. > was last active in 2009, No, 2013. If you mean that people should spam bug reports to make them active, that's very stupid. > and therefore covers a VERY different version of firefox. You're wrong. Firefox has worked consistently for many years. > THIS bug is about the failure to honor that pref. instead, firefox sends the > focus to "some mystery location" in windows. i don't know where it goes in > other operating systems. That's not what you described in comment 0. Note that according to bug 263553 comment 32, the focus should be given to Firefox, not remain in Thunderbird.

howdy Vincent Lefevre, we obviously are reading different things into the other bug. i'm not going to argue about it, tho, since there is a good chance i am misunderstanding the point of that other bug. [*grin*] please see Comment 13 of this bug for a more concise _and_ more accurate description of the point of this bug. in that comment Alice0775 White properly describes the problem. this bug is a _regression_. the other bug is NOT a regression. the behavior of firefox _changed_ in v-14 and has not reacted correctly since. the problem has _nothing_ to do with the bug you keep referring to. there is nothing in that other bug about a regression in ff14. please, if you seriously cannot see the difference between the two bugs, then state your perception of the situation and LET IT GO. i'm going to let it go now. take care, lee

OK, Comment 13 now makes that's a different bug. But the title of this bug is then incorrect and should be corrected. Comment 13 says "the focus goes to desktop" while the title says "... cause firefox to steal focus" (meaning Firefox has the focus). The fact that browser.tabs.loadDivertedInBackground must be true could also be mentioned in the title since that's not the default. But note that according to http://kb.mozillazine.org/About:config_entries, the focus should be given to Firefox when a new tab is opened from an external application, even when browser.tabs.loadDivertedInBackground is set to true: "Note: Setting this preference to True will still bring the browser to the front when opening links from outside the browser."

I'm going with this bug under the assumption it's FF that steals the focus. I click a link in Outlook, FF accepts that link, and steals the focus from Outlook to itself, and proceeds to load the link. At that point FF is the active program. Prior to version 14 it would leave the system focus on Outlook. So clicking on a link would push it to FF, let FF load, but Outlook would remain the active program.

howdy Vincent Lefevre, [1] new title for this bug if you can come up with one that fits better i'll be happy to change it. [*grin*] i haven't had any luck at that myself. [2] browser.tabs.loadDivertedInBackground thanks for pointing out the mozillazine KB notes on that. [*grin*] however, that is NOT how it worked in firefox previous to 14.0.1, nor is it how it works now. before 14.0.1 firefox left the focus in the link-source app. now it goes "somewhere" that Alice0775 White believes to be the desktop. i personally have never been able to find out _where_ the focus goes. it seems to simply disappear. take care, lee

I tried to figure out, when this bug was really introduced into firefox. I was able to reproduced it with ftp://ftp.mozilla.org/pub/firefox/nightly/2012/03/2012-03-28-03-12-11-mozilla-central/firefox-14.0a1.en-US.win32.txt This version of firefox stilled worked: ftp://ftp.mozilla.org/pub/firefox/nightly/2012/03/2012-03-27-10-05-41-mozilla-central/firefox-14.0a1.en-US.win64-x86_64.txt This is the changelog of the patches added to firefox between these to versions: diff browse244991519f53 2012-03-28 00:33 +0200Tim Taubert - merge m-c to fx-team diff browsefb41b10cd782 2012-03-27 15:08 +0200Tim Taubert - Backed out changeset 26051ffdbc34 (bug 739171) diff browse50483ab04fd6 2012-03-27 14:14 +0200Tim Taubert - Bug 738774 - [Page Thumbnails] Channel leaks intermittently; r=dietrich diff browse26051ffdbc34 2012-03-27 12:59 +0200Tim Taubert - Bug 739171 - Don't save tabItem data while updating tabItems; r=dietrich diff browse5b1154a3289c 2012-03-27 12:02 +0200Tim Taubert - Bug 734280 - [New Tab Page] clean up newtab test suite; r=dietrich diff browse09362c5dceaf 2012-03-26 12:45 -0700Robert Strong - Bug 491947 - Disable DDE shell integration. r=jmathies diff browse1db916a98bd4 2012-03-20 12:28 -0700Philipp von Weitershausen - Bug 728886 - Part 2: Support ril.h v6 parcels. r=qDot DONTBUILD because NPOTB diff browse87aa00676c4b 2012-03-19 15:49 -0700Philipp von Weitershausen - Bug 728886 - Part 1: Introduce constants from ril.h version 6. r=qDot diff browse53001c577ab9 2012-03-20 16:18 -0700Philipp von Weitershausen - Bug 728886 - Part 0: Use constants when initializing RIL state. r=qDot diff browse147c0d893cdb 2012-03-27 17:16 -0400Armen Zambrano Gasparnian - Bug 739768. We fixed the talos.zip issue with a symlink but let's be cut and clear to which talos.zip is the good one. r=jhammel diff browse03fbc2e18d7e 2012-03-27 10:11 -0400Armen Zambrano Gasparnian - Bug 739345 - update new talos.zip with fixed permissions for minidump_stackwalk. r=jmaher diff browse273173a592dc 2012-03-27 22:13 +0200Serge Gautherie - Bug 483992. (Av1) dom-level*-*/DOMTestCase.js: Remove sayrer's override of SimpleTest._logResult(). r=rcampbell. diff browse7290c4f0a150 2012-03-27 12:04 -0700Blake Kaplan - Bug 739234 - Deal with the odd case on a desktop computer where the backend error'd out. r=vingtetun diff browseaa0f1e5fcf00 2012-03-27 12:04 -0700Vivien Nicolas - Bug 739680 - onsettingchange is not called when the setting is changed inside another window r=fabrice

(In reply to Joachim Herb from comment #36) > This version of firefox stilled worked: > ftp://ftp.mozilla.org/pub/firefox/nightly/2012/03/2012-03-27-10-05-41- > mozilla-central/firefox-14.0a1.en-US.win64-x86_64.txt > Wrong OS zip file but correct hg version: http://hg.mozilla.org/mozilla-central/rev/0ff816e5e992

I had already found the offending change set, see comment #13. No need doing same thing.

(In reply to Lee_Dailey from comment #35) > [1] new title for this bug > if you can come up with one that fits better i'll be happy to change it. > [*grin*] i haven't had any luck at that myself. I suggest: external links sent to firefox cause loss of focus when browser.tabs.loadDivertedInBackground is true > [2] browser.tabs.loadDivertedInBackground > thanks for pointing out the mozillazine KB notes on that. [*grin*] > however, that is NOT how it worked in firefox previous to 14.0.1, nor is it > how it works now. This means that Firefox previous to 14.0.1 was also "buggy" (as not behaving as documented), but in a different way. Bug 263553 was an attempt to change this documented behavior.

howdy Vincent Lefevre, bug title changed! thank you for the nifty and concise description. [*grin*] ***** i'm still not certain that the pre-ff14.0.1 behavior was a bug. while the mozillazine KB is usually correct, it aint canonical. i have not [yet] been able to find the info in the MDN. i'll post back here if/when i do. for the developers - in any case, i DO NOT want what the mozillazine KB describes to be the way ff works. it is far too useful to be able to send a series of links to ff while working my way thru my email and THEN go look at things in ff. take care, lee

This patch it thought as starting point for a fix for this bug. It backs out the patch for Bug 491947 (commit: http://hg.mozilla.org/mozilla-central/rev/09362c5dceaf) form the current default branch (actually based on commit 153218:d8fd5706493e). And it fixes the problem. So could someone from mozilla staff please indicate how to proceed with this bug. I do not understand what bug 491947 was really for or why that patch is needed. Also I do not know which part of that patch has really been causing the problem. So please help.

DDE will not be re-enabled. There are a multitude of reasons to disable DDE and they can be found in existing bug reports as noted in bug 491947 comment #1. Creating a patch to make Firefox do what you want would be a "good thing" though the behavior would be different than what is expected on Windows (e.g. the initiated application takes focus) so what ever solution is created should not be the default behavior and should be available via a preference (likely hidden).

(In reply to Robert Strong [:rstrong] (do not email) from comment #42) > DDE will not be re-enabled. There are a multitude of reasons to disable DDE > and they can be found in existing bug reports as noted in bug 491947 comment > #1. That comment isn't really helpful: > One example of a MS DDE bug > http://support.microsoft.com/kb/892850 The link points to a hotfix of Microsoft. So what are the bugs? > Creating a patch to make Firefox do what you want would be a "good > thing" though the behavior would be different than what is expected on > Windows (e.g. the initiated application takes focus) so what ever solution > is created should not be the default behavior and should be available via a > preference (likely hidden). I was assuming this is what this bug is all about. And especially the already (at least since changeset #1 of the hg repository) existing preference is intended to do exactly this: browser.tabs.loadDivertedInBackground Looking in the source code, especially: https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#4356 it seems clear that if this preference is true firefox should not take the focus. I even found this prehistoric documentation: http://mxr.mozilla.org/firefox/source/camino/docs/Release%20Notes%201-6a1.rtf#89 > \f1 hidden preference to load tabs created by links that would open new windows in the background.\ > 91 \'95 When an alert causes tab focus to change, closing the alert will return focus to the original tab.\ > 92 \'95 When a page is loading, a progress spinner displays in place of the site icon on the tab.\ http://mxr.mozilla.org/firefox/source/camino/src/browser/BrowserWrapper.mm#1281 > // If browser.tabs.loadDivertedInBackground isn't set, we decide whether or > // not to open the new tab in the background based on whether we're the fg > // tab. If we are, we assume the user wants to see the new tab because it's > // contextually relevant. If this tab is in the bg, the user doesn't want to > // be bothered with a bg tab throwing things up in their face. We know > // we're in the bg if our delegate is nil. But back to this bug: Is DDE needed to avoid the current behavior and get back the pre-14.0 behavior? Or or there other ways to get the intended (as described in this bug) behavior?

(In reply to Joachim Herb from comment #43) > (In reply to Robert Strong [:rstrong] (do not email) from comment #42) > > DDE will not be re-enabled. There are a multitude of reasons to disable DDE > > and they can be found in existing bug reports as noted in bug 491947 comment > > #1. > That comment isn't really helpful: > > One example of a MS DDE bug > > http://support.microsoft.com/kb/892850 > The link points to a hotfix of Microsoft. So what are the bugs? > > > Creating a patch to make Firefox do what you want would be a "good > > thing" though the behavior would be different than what is expected on > > Windows (e.g. the initiated application takes focus) so what ever solution > > is created should not be the default behavior and should be available via a > > preference (likely hidden). > I was assuming this is what this bug is all about. And especially the > already (at least since changeset #1 of the hg repository) existing > preference is intended to do exactly this: > browser.tabs.loadDivertedInBackground Yes, it was added a long time ago. > Looking in the source code, especially: > https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser. > js#4356 it seems clear that if this preference is true firefox should not > take the focus. > > I even found this prehistoric documentation: > http://mxr.mozilla.org/firefox/source/camino/docs/Release%20Notes%201-6a1. > rtf#89 > > \f1 hidden preference to load tabs created by links that would open new windows in the background.\ > > 91 \'95 When an alert causes tab focus to change, closing the alert will return focus to the original tab.\ > > 92 \'95 When a page is loading, a progress spinner displays in place of the site icon on the tab.\ > > http://mxr.mozilla.org/firefox/source/camino/src/browser/BrowserWrapper. > mm#1281 > > // If browser.tabs.loadDivertedInBackground isn't set, we decide whether or > > // not to open the new tab in the background based on whether we're the fg > > // tab. If we are, we assume the user wants to see the new tab because it's > > // contextually relevant. If this tab is in the bg, the user doesn't want to > > // be bothered with a bg tab throwing things up in their face. We know > > // we're in the bg if our delegate is nil. My understanding of the browser.tabs.loadDivertedInBackground preference is for it to load tabs from within Firefox in the background and not from outside of Firefox. For example, from "we decide whether or not to open the new tab in the background based on whether we're the fg tab" it is clear it is referring to opening tabs from another tab and not from external apps. It was most likely an unintended side affect. > But back to this bug: Is DDE needed to avoid the current behavior and get > back the pre-14.0 behavior? Or or there other ways to get the intended (as > described in this bug) behavior? DDE should definitely not be needed to add this functionality.

Despite the discussion in bug 263553 this behavior was (re?)-implemented Bug 392038: > Don't focus new tabs opened by left-click or external URL. Allowing the user the choose to override default behavior. There is also the preference: browser. tabs. loadInBackground http://kb.mozillazine.org/About:config_entries Focus behavior for new tabs from links True (default): Do not focus new tabs opened from links (load in background) False: Opposite of above Shouldn't this preference apply to all internally opened new tabs? What causes the hidden window mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=541923#c13 to get the focus? By the way: I think that a fix to this bug would also fix bug 541923.

By default, opening an url from another app should focus Firefox. Solving this would require knowing that Firefox was opened via the OS's use of ShellExecute and then reading the pref for the non-default behavior. Bug 541923 is about using CreateProcess to launch Firefox.

Testing in latest nightly (31.0a1 (2014-03-24)) : STR: 1) set nightly as the default browser 2) set browser.tabs.loadDivertedInBackground to true 3) open some other application with links (mail apps work well) 4) click on a link result: nightly does not take desktop focus, mail app keeps foreground status. Nightly loads page in new background tab as well. I'm I missing something here? This seems to be WFM.

Version 28 of FireFox just installed. Get a notice from a forum through an e-mail in Outlook 2013. Click the link, new tab opens in Firefox, no focus on the tab (i.e. browser.tabs.loadDivertedInBackground = true) However, if I go a hit the delete button at that moment to delete the mail, the focus turns out to have been stolen from Outlook, and focused on Firefox. I have the click the mail again (just above the link or something) to refocus on Outlook, before I can use the delete button to delee the mail. And prior to version 14 focus remained with Outlook, so it was just click-delete-click-delete. Sped up mail processing pretty well.

Ok I see this now. STR: 1) set nightly as the default browser 2) set browser.tabs.loadDivertedInBackground to true 3) open some other application with links (mail apps work well) 4) click on a link result: nightly does not take desktop focus however the mail app loses input focus while staying in the foreground. Interesting bug. Might be useful to go back and find a regression range. Firefox 14 was on mc from 2012-03-13 - 2012-04-24.

(In reply to Jim Mathies [:jimm] (away 4/1-4/21) from comment #50) >... > Interesting bug. Might be useful to go back and find a regression range. This is due to the removal of dde (see comment #36 and onward)

Same behavior in FF 29.0.1 I can also confirm loss of keyboard focus and window focus in some situations. For example when I'm playing a steam game in full-screen mode, whenever there's a new firefox tab loaded, the game alt-tabs out to the desktop. I can set the game in "windowed" mode in the same resolution to prevent this, but keyboard focus will always be lost until I click somewhere in-game. loadDivertedInBackground is a decent option but like others have said here, it really lacks correct focusing. If a new tab is opened, even the "current" firefox tab loses keyboard focus until clicked. There's got to be a way to tell Windows to never allow firefox as an application to have focus or to steal keyboard/window focus from other applications (if some component of firefox in fact gets focus; I don't believe focus goes to the desktop.) I tried experimenting with other applications' "always on top" window option -- same result, that application window turns "inactive" and keyboard is lost.

Build 38.0.5 (or might have been lower) -- finally fixed? Focus for me is finally not lost on the working window.

No, I cannot confirm that it is working: Tested with Thunderbird 38.0 (beta channel, build 20150522020825) and Firefox 39.0 (beta channel, build 20150618135210) using Windows 7 and the problem still exists

Well I'm on the release version (of firefox) and playing steam games in full-screen mode no longer alt-tabs out to the desktop when a new tab gets loaded in the background in firefox. Keyboard and window focus also isn't lost when I'm working in an unrelated text editor. It could also be a new windows update. MS has pushed out a lot of "optional" ones that may have fixed this issue, at least for me. KB3048761 stands out to me (pushed out in late April 2015) as that one had a lot to do with "parent windows" and memory leaks in DWM.exe. I haven't been on top of this for some amount of months and didn't notice that focus wasn't being lost until today so for me, the fix might have already been months old and I didn't even know.

Ok, through a series of unknown steps, focus is now being lost again. I had thought this was resolved but there was a period there were focus wasn't being stolen and I have no idea to reproduce it.

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160315153207 I have tested your issue on latest FF release (45.0.1), latest Nightly build (20160403030243) and managed to reproduce it. I've enabled browser.tabs.loadDivertedInBackground in about:config and if I opened a link from Skype or Thunderbird, that application loses focus while Firefox opens a new tab with the clicked link(not switching to it). I've also performed a regression on this issue and here are my results: Last good revision: 0ff816e5e992 (2012-03-27) First bad revision: c3fd0768d46a (2012-03-28) Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0ff816e5e992&tochange=c3fd0768d46a

Any info on any progress made on this problem?

From the looks of things, version 57 has (finally) seem to have corrected this problem. Not that I'm too charmed my add-ons now all seem to have completely died on me, due to the whole new standard set forth tho. But that's another issue. If anyone can confirm it also works on their end, guess we can finally put this one to bed?

I might have spoken a bit too soon... It doesn't seem like FF steals the focus upon clicking a link in the e-mail, but the focus does move away from the e-mail program it seems :(