Opening links from other applications sometimes brings wrong window to the front. Steps to Reproduce: 1. Start a new profile (default pref for external links is to open in most recent tab/window) 2. Start Firefox, open Javascript Console window. 3. Switch to other application 4. Open a simple file, associated with Firefox (note: some pages with focus() statements don't exhibit this bug due to another bug) Actual results: Page opened in browser window, but Javascript Console is focused. The browser window may very well be not visible. Expected results: Bring browser, not JS console, window to the front. Obviously, this didn't happen before check-in for bug 172962. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

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

More details: Open links from other applications in: a new window - opens a new window in front of all others a new tab - leaves browser unfocused (however the browser window is focused if the new tab is preffed to gain focus i.e. "Select new tabs opened from links") the most recent tab/window - leaves browser unfocused Yes we should probably focus the browser window when an external app opens a new URL into it. However not everyone would agree. In fact I expect this is more a Windows-user's desire. See bug 172962 comment 89 point 3 and bug 262537 comment 14. The correct behaviour is probably to leave it as is, but focus the window also if the external link is loaded into the most recent tab/window and "select new tabs opened from links" is true (or the newer browser.tabs.openDivertedInBackground pref is false, see bug 262537 comment 28).

You didn't understand. I'd prefer the windows NOT to be focused, imo there should be another pref for that, like in TBP (if there is not one already, I'm a little bit lost already ;-) This bug is about different issue: your code *always* brings Mozilla on top of others (well, at least for me on default setup, with 20041001 build), but sometimes it brings the **wrong** window on top.

Ah. Yet another pref controlling whether the app is activated at all, as brought up in bug 172962 comment 89 point 3. As mentioned in bug 172962 comment 93 yes, that would be useful though perhaps problematic to implement. Nickolay, you may want to open another bug specifically for that since even after re-reading this bug with your latest comment in mind I still interpret comment 0 the way I did in comment 2.

I agree, bug 172962 comment 89 point 3 is a different bug, let someone else file it. However. My 20041001 build doesn't behave as described in comment 2. * new tab - focuses the most recent Mozilla window (_sometimes_not_browser_window_) although "Select new tabs opened from links"=false. * the most recent tab/window - ditto. (The problem I tried to describe in comment 0 is underlined above.) I suppose that behaviour has changed since then and shut up until I get newer nightly. Apologies.

Related to bug 255123? This sounds like a newer regression.

Comment 5: I think your 20041001 build should have the most current behaviour. It could be my build which is off, since it does have a few extra modifications from pending bugs like bug 262537. However I'm beginning to suspect that there's some window activation/focus issue that makes it behave differently for different people. Maybe we should let this bug lie until this area stops being a moving target. In the meantime Nickolay, do you have any extensions installed? I'm curious where the differing activation behaviour comes from, if it really exists. Comment 6: These two bugs may be related. I've commented in that one. NB: I don't know how fair it is to call this bug a regression. The ability to open an URL from an external app into a new tab is brand new. And it's been impossible to open the URL into the same tab of an extant window on a branch build since the semi-single-profile code was checked in last May.

comment 6: I don't think they are related, I opened *.html files and http:// links from Thunderbird. comment 7: (muffled) I have a few extensions, but I reproduced this bug on completely clean profile before filing it.

Thanks for the CC danm ;-) Anyway, the way I did this in TBP was rather problematic - I went and wrapped all the calls made to window.focus() so that they could be bypassed if desired. I was able to eliminate a considerable number of window focusing doing this, but not all - the tabbrowser automagically focuses its window when a tab is selected programatically. Having this around would be a Nice-to-Have feature. Where in the source do most of the focus() calls to various widgets go?

FWIW, it still doesn't work for me with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041008 Firefox/0.10 installer build. I installed to a new directory, created a new profile, and with default prefs, I see the bug as described in comment 0 and comment 5.

Fixed on trunk (deerpark) and per bug 255123 will be released in version 1.1. (removed blocking bug 265238) *** This bug has been marked as a duplicate of 255123 ***