2035771 - Wake/Focus bug in split monitor on MacOs

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect, P3)

Description

[Paul]

Attachment: bug_firefox_multitab.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:150.0) Gecko/20100101 Firefox/150.0

Steps to reproduce:

On MacOs (tested on sequoia and Tahoe, not tested on other OS), using an external monitor, the window doesn't focus when we "right click>new tab on the right", but it does when we "right click>new tab". Very frustrating

Actual results:

The window doesn't awake, the focus is kept on the other monitor

Expected results:

It should focus automatically the research area as it does when we "right click>new tab or when we simply left click on the "+" new tab

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Stephen A Pohl [:spohl]]

Attachment: Bug 2035771: Raise the chrome window when opening a new tab via the tab context menu or tab group menu. r=#tabbrowser-reviewers

gBrowser.addAdjacentNewTab (the handler for the tab context menu's "New
Tab to Right" / "New Tab Below" item) creates the new tab through
addTrustedTab directly and never raises the chrome window. On macOS,
the tab context menu can be invoked on a window without that window
becoming frontmost — most reproducibly in a multi-monitor setup where
the user right-clicks a tab in a Firefox window that wasn't the OS-level
frontmost window. The new tab is then created in the right window and
its focusUrlBar: true state is set, but OS keyboard focus stays on
whichever window was frontmost, so the address bar can't actually be
typed into.

The plain "New Tab" command goes through
URILoadingHelper.openLinkIn, which calls aWindow.focus() before
loading the URI for exactly this reason. Mirror that here so both paths
behave the same: focus the chrome window, then create the tab and let
the existing focusUrlBar state place keyboard focus on the address
bar.

Comment 3

[Stephen A Pohl [:spohl]]

Attachment: Bug 2035771: Raise the chrome window when opening a new tab via the tab context menu or tab group menu. r=#tabbrowser-reviewers

The tab context menu's "New Tab to Right" and the tab group menu's
"New tab in group" both create the new tab through
gBrowser.addAdjacentNewTab and ask it to focus the address bar. On
macOS, those menus can be invoked on a window that isn't the OS-level
frontmost window -- most reproducibly in a multi-monitor setup, where
the user right-clicks a tab in a Firefox window that wasn't the
frontmost OS window. The new tab is then created in the right window
and its focusUrlBar: true request is honored within that window, but
OS keyboard focus stays on whichever window was frontmost, so the
address bar can't actually be typed into.

URILoadingHelper.openLinkIn handles this for the plain "New Tab"
command by calling aWindow.focus() before loading the URI. Mirror
that at the menu call sites rather than inside addAdjacentNewTab
itself, so gBrowser stays agnostic about who's calling it. The
non-menu caller in SpecialMessageActions is left untouched.

Comment 4

[Stephen A Pohl [:spohl]]

N-i regarding the question on phabricator. Thanks!

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/70efc5cd907a
https://hg.mozilla.org/integration/autoland/rev/43316e8df252
Raise the chrome window when opening a new tab via the tab context menu or tab group menu. r=tabbrowser-reviewers,dao

Comment 6

[amarc]

https://hg.mozilla.org/mozilla-central/rev/43316e8df252