1544072 - "firefox -new-window <url>" steals focus starting in 61.0

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Description

[gak]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Hi,

On Debian testing, running 60.0 vs 61.0, i.e.

http://archive.mozilla.org/pub/firefox/releases/60.0/linux-x86_64/en-US/firefox-60.0.tar.bz2
http://archive.mozilla.org/pub/firefox/releases/61.0/linux-x86_64/en-US/firefox-61.0.tar.bz2

using an X11 window manager set to focus-follows-mouse[*]

from shell window:

% firefox -new-window www.google.com

The newly created window steals focus in 61.0, but does not in 60.0. This is true both for the first invocation (firefox not already running) as well as subsequently (firefox running, and opens a new window from running instance via remote protocol).

Expected result: if the new window does not overlap the mouse pointer location, the new firefox window should not take focus, and focus should remain on the shell window below the mouse.

The problem also exists in subsequent releases 62.0, 63.0, 64.0, 65.0, and 66.0.1.

[*] focus follows mouse:
https://en.wikipedia.org/wiki/Focus_(computing)#Focus_follows_pointer

I'm using fvwm 2.6.3 though any version should be fine (development has slowed or stopped). See my previous focus-stealing related bug here at comment 6 and below:
https://bugzilla.mozilla.org/show_bug.cgi?id=1090416#c6
for additional discussion of focus follows mouse, and how to configure fvwm or Unity (at least 3 years ago) for this mode. Or google it for whatever window manager you use.

Actual results:

the new firefox window takes focus when it is NOT beneath the mouse pointer location.

Expected results:

the shell window from which the command was run, and over which the mouse pointer was and remains pointing, should have kept the focus.

Comment 1

[gak]

Some additional details:

1. Both of these:

% firefox -new-window
% firefox

i.e. with no URL to open, and with both "Homepage and new windows" and "New tabs" set to "Blank page"

behave correctly for 59.0 through 66.0.1, and do not steal focus either upon first or subsequent invocations.

2. This variant:

% firefox www.google.com

correctly does NOT steal focus upon first invocation (firefox not already running).

however, it incorrectly steals focus on subsequent invocations (firefox running, and opens a new window from running instance via remote protocol).

This is a also a bug, but exists in all versions I have tested so far (59.0 through 66.0.1). I will see how far back I can track it, and report back.

Comment 2

[gak]

the related bug in comment #2, that

% firefox www.google.com

steals focus when firefox is already running, and just opening a new window, was introduced between 18.0 and 19.0.

If you would prefer I move this case to a separate bug, just let me know.

Comment 3

[gak]

https://bugzilla.mozilla.org/show_bug.cgi?id=1090416, related to focus stealing when center-clicking a link to open in a new window, was also introduced between 18.0 and 19.0.

Comment 4

[Adrian Florinescu [:aflorinescu]]

I've tried to reproduce this issue (comment0):
68.0a1 20190417214729
67.0b11 20190415085659
60.0.2 20180605171542

• Ubuntu 16.04 x64, gnome-tweak-tool;
• terminal case :~$ ./firefx -new-window www.google.com

With session restore off, the reported behavior(comment0) a.k.a. Firefox stealing FX is reproducing with all 3 tested versions 60,67,68. This was tested with both with "sloppy" and "mouse" focus mode.

For the latest versions (67, 68), I've noticed is that for both focus modes (sloppy and mouse), if the session restore is true, Fx will get the focus is the last action was inside the browser. Fx will release the focus after restore if the last action before close was not inside the browser.

I'm inclining to believe that depending on the window manager, the focus behavior might vary, so I'd guess the first step would be to validate what the expected behavior should be for the start-up focus of Firefox. In this sense, moving this to a component to shed some light into the expected behavior here.

Comment 5

[gak]

Hi Adrian, thank you for looking into this! If you are seeing the same behavior with 60.0 as with the newer versions, I suspect you have not reproduced the issue. Can you provide more detail about what window manager/desktop environment you are using, and what settings you changed for sloppy/mouse focus? I wonder if your WM has a rule to always focus to newly created windows? What happens if you run

% xterm&

from a shell window, such that the new xterm window is randomly placed somewhere where it is not beneath the mouse pointer location? Does the new xterm get the focus, or does focus stay with the original shell/xterm window?

I'll try to use xtrace or another X event trace utility to definitively demonstrate the difference.

Comment 6

[Henri Sivonen (:hsivonen)]

Considering that this doesn't affect the default configuration of Mutter, it's unlikely that we can devote time to tracking this down. However, this might be actionable if we knew the exact regressing change. It could be found with https://mozilla.github.io/mozregression/install.html

Comment 7

[gak]

Thank you Henri.. I will look into mozregression.

Is mozregression likely to be able to do the bisection for the other bug I linked to above, which occurred way back between 18 and 19?

This problem really does make firefox quite intolerable with focus follows mouse policy, which I realize is not the default, but is a supported option in most window managers.

Comment 8

[Henri Sivonen (:hsivonen)]

(In reply to gak from comment #7)

Is mozregression likely to be able to do the bisection for the other bug I linked to above, which occurred way back between 18 and 19?

Possibly, but I'm not sure. My understanding is that it goes pretty far back.

Comment 9

[firefox]

Can confirm this is still an issue, and is present on MacOS as well.

Launching a new window from the command line, either by invoking Applications/Firefox.app/Contents/MacOS/firefox (with or without -new-window) or by using MacOS's open -a Firefox (with or without -g, -n or both), causes the previously-focused Firefox window to steal focus before the new window is launched.

This is extremely in-ergonomic. In a hypothetical situation, the user has multiple MacOS spaces, and a Firefox window on space 1. They have navigated to space 2, or to another screen, and are trying to open a new Firefox window on that space/screen, via a keybinding from an app such as Karabiner or skhd. Instead, the space switches out from under them, and the window launches on the wrong screen. Now they have to perform multiple interactions (such as access mission control -> move window -> navigate space -> rearrange windows again) to get back to where they were. This is honestly frustrating enough on its own to stop using Firefox on this platform.

Importantly, on MacOS, focus stealing cannot be prevented, unlike on most Linux window managers, so there's no workaround to this usability defect.

Chromium-based browsers do not currently suffer from this.