Opening links from other applications focuses wrong window




14 years ago
13 years ago


(Reporter: Nickolay_Ponomarev, Unassigned)



Firefox Tracking Flags

(Not tracked)




14 years ago
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

Comment 1

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

Comment 2

14 years ago
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).
Assignee: firefox → danm.moz
Ever confirmed: true

Comment 3

14 years ago
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

14 years ago
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

14 years ago
I agree, bug 172962 comment 89 point 3 is a different bug, let someone else file it.

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

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

Comment 7

14 years ago
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

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

14 years ago
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

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

14 years ago
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.


14 years ago
Blocks: 265238


14 years ago
Assignee: danm.moz → nobody

Comment 11

13 years ago
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 ***
No longer blocks: 265238
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.