262978 - Opening links from other applications focuses wrong window

Status: RESOLVED DUPLICATE of bug 255123

(Firefox :: General, defect)

Description

[Nickolay_Ponomarev]

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

Comment 1

[Dan M]

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

Comment 2

[Dan M]

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

Comment 3

[Nickolay_Ponomarev]

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.

Comment 4

[Dan M]

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.

Comment 5

[Nickolay_Ponomarev]

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.

Comment 6

[Jesse Ruderman]

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

Comment 7

[Dan M]

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 8

[Nickolay_Ponomarev]

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.

Comment 9

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

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?

Comment 10

[Nickolay_Ponomarev]

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.

Comment 11

[Wayne Mery (:wsmwk)]

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