1936294 - Document focus lost when tab changes from non-remote to remote

Status: VERIFIED FIXED

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

Description

[zlice]

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

Steps to reproduce:

Updated nightly this morning (Dec 10 2024)

Actual results:

Windows seem to randomly be losing focus.

Some times I'll go to a page and vimium-plugins hotkeys won't work, but also arrow keys won't work.

Another page I couldn't even use Ctrl+W to close it.

Expected results:

Works as expected.

Rebuilt my profile the other day and everything was working fine for the past few days.

Comment 1

[zlice]

Fluxbox WM

Comment 2

[zlice]

Attachment: browser-console1.png

uploading 2 browser-console screenshots

• 1 is random google search where hotkeys quit working
• 2 is mozilla bugzilla google search where hotkeys quit working

Comment 3

[zlice]

Attachment: browser-console2.png

Comment 4

[Martin Stránský [:stransky] (ni? me)]

Can you use mozregression to find the broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 5

[zlice]

2024-12-11T08:54:17.875000: INFO : Narrowed integration regression window from [aa3c500f, 842468e4] (4 builds) to [ce16236a, 842468e4] (2 builds) (~1 steps left)
2024-12-11T08:54:17.878000: DEBUG : Starting merge handling...
2024-12-11T08:54:17.878000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=842468e46637da9a69dd59c5ccf610fcbb04de0f&full=1
2024-12-11T08:54:17.879000: DEBUG : redo: attempt 1/3
2024-12-11T08:54:17.879000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=842468e46637da9a69dd59c5ccf610fcbb04de0f&full=1',), kwargs: {}, attempt #1
2024-12-11T08:54:17.881000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2024-12-11T08:54:18.956000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=842468e46637da9a69dd59c5ccf610fcbb04de0f&full=1 HTTP/11" 200 None
2024-12-11T08:54:19.031000: DEBUG : Found commit message:
Bug 1933769 - Remove no-op focus() calls. r=tabbrowser-reviewers,dao

Since bug 1823984, this focus() call has been a no-op on remote frames.

The previous patch also fixes the non-remote frame focus switch.

Differential Revision: https://phabricator.services.mozilla.com/D230098

2024-12-11T08:54:19.031000: DEBUG : Did not find a branch, checking all integration branches
2024-12-11T08:54:19.032000: INFO : The bisection is done.
2024-12-11T08:54:19.032000: INFO : Stopped

Comment 6

[zlice]

fwiw, had to use my profile (copied to /tmp)

attaching about-support if that helps

Comment 7

[zlice]

Attachment: about-support.txt

Comment 8

[Martin Stránský [:stransky] (ni? me)]

So looks like Bug 1933769 is the culprit here.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 1933769, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

The patch removed some .focus() calls from the front-end so it's probably just uncovering a pre-existing issue.

(In reply to zlice from comment #6)

fwiw, had to use my profile (copied to /tmp)

So this doesn't happen on a clean profile?

"desktopEnvironment": "shynebox",

Huh, that's one I had never seen. Do you know how can I set it up to reproduce this? Also, since you mentioned fluxbox, does setting widget.gtk.ignore-bogus-leave-notify=1 in about:config help? That's a workaround that we had to add for fluxbox.

Comment 11

[zlice]

i can try again but i don't think it did

ya basically had to fork fluxbox because they were never going to address other focus event issues. i think you and stransky worked on those.

i'll try the gtk-ignore-leave later, that sounds like it may help. thanks

Comment 12

[zlice]

confirmed a blank profile does not seem to have the issue. tried opening a default homepage of about:blank because that's what i have but it doesn't change anything. goes through a few commits then gives some commit from dec 10 (assume that's the commit from the date range i put in of 09-10th)

still see behavior on nightly with my profile if i use a different search engine when i : new window > search > keys don't work

the gkt ignore bogus events does not change anything (i only put in about:config then opened new window, if i have to restart for that to take effect i can try)

Comment 13

[Emilio Cobos Álvarez (:emilio)]

It'd be good to find what in your profile causes it (maybe check modified prefs?).

Otherwise investigating this is going to be a pain.

Comment 14

[zlice]

ya ill have to take a look. hopefully it's custom startup about:config stuff

can you provide that same 'ff.cfg' to mozregression?

Comment 15

[zlice]

Attachment: ff.cfg

Comment 16

[zlice]

Attachment: nogo.png

trying to do even a simple ini from the example https://mozilla.github.io/mozregression/documentation/usage.html

does not seem to work =/ probably a mozregression bug. can not find the python files it's talking about anywhere

Comment 17

[zlice]

tested in openbox and the same thing happens

Comment 18

[zlice]

appears that a private browser is fine. not sure what may be disabled, disabling all my plugins (even vimium which i allow in private) does not seem to change anything.

Comment 19

[zlice]

this is indeed fine without homepage being about:blank

ff.cfg about:config bootstrap

pref("browser.startup.homepage", "about:blank");

i'm not sure why the commit has a different affect depending on the homepage...i assume because it's blank there is something that isn't ran, because there's "nothing to update"

Comment 20

[zlice]

steps to cause issue

• new profile with homepage being about:blank (i do it through the startup cfg file, not sure if that matters)
• ctrl+n for new page
• type something in address bar
• arrow down doesn't scroll down page

Comment 21

[James Teh [:Jamie]]

I just discovered this problem and found this bug report via mozregression. This occurs whenever we switch from a local (chrome) document to a remote (content process) document; i.e. the opposite of bug 1933119. STR:

1. Open about:support.
2. In the same tab, open:
   data:text/html,hi
   • Expected: The document should have focus.
   • Actual: It doesn't.
3. Open the parent process browser console.
4. Enter: document.activeElement
   • Expected: <browser ...>
   • Actual: <html:body xmlns="http://www.mozilla.org/k…keeper/there.is.only.xul">

The <browser> element seems to be losing focus and never regaining it.

Comment 22

[James Teh [:Jamie]]

Not sure if this belongs here or in tabbed browser, but this is definitely not widget specific.

Comment 23

[James Teh [:Jamie]]

Attachment: Bug 1936294: Add a11y test for focus when changing a tab from non-remote to remote.

Comment 24

[James Teh [:Jamie]]

The attached test demonstrates the failure. It should pass once it is fixed.

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Ok that is a lot more actionable

Comment 26

[zlice]

hey all. sry to bump, any update on this?

Comment 27

[Emilio Cobos Álvarez (:emilio)]

Hey, no, just got back to work today. But, looking.

Comment 28

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1936294 - Fix-up mFocusedWindow / mFocusedElement when replacing frameloaders. r=#dom-core

The issue is that when replacing frame loaders for a non-remote browser,
mFocusedElement is not that <browser> element. It instead points to the
(potentially null) focused element in mFocusedWindow.

If mFocusedWindow is about to be destroyed (or put into the bfcache), clear it
and point mFocusedElement to the <browser> instead, so that we can focus the
new frame loader if needed later.

If we don't do this, the focused window gets cleared when the window is nuked
in nsFocusManager::WasNuked (but by that point it's too late to do any fix up,
as we've lost the context that we're swapping, and of our frameloader owner,
and everything else).

Test in D232437.

Comment 29

[James Teh [:Jamie]]

Emilio, please feel free to land D232437 when you land your patch. I'll be heading out on PTO for a couple of weeks soon.

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d3f21fe8379a
Fix-up mFocusedWindow / mFocusedElement when replacing frameloaders. r=dom-core,sefeng
https://hg.mozilla.org/integration/autoland/rev/a913ebae3ac0
Add a11y test for focus when changing a tab from non-remote to remote. r=nlapre

Comment 31

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/d3f21fe8379a
https://hg.mozilla.org/mozilla-central/rev/a913ebae3ac0

Comment 32

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Comment 33

[zlice]

looks like it's working. thanks all!

Comment 34

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9446169 [details]
Bug 1936294 - Fix-up mFocusedWindow / mFocusedElement when replacing frameloaders. r=#dom-core

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Relatively low risk regression fix.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Very isolated patch to the "focused while switching remoteness".
• String changes made/needed: none
• Is Android affected?: Yes

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9446169 [details]
Bug 1936294 - Fix-up mFocusedWindow / mFocusedElement when replacing frameloaders. r=#dom-core

Approved for 135.0b4.

Comment 36

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/03bbb26ab7dd
https://hg.mozilla.org/releases/mozilla-beta/rev/3d2449a6bc2c

Comment 37

[Alexandru Trif, Desktop Test Engineering [:atrif]]

I could reproduce this issue with Firefox 135.0b3 on Windows 10x64 only by enabling NVDA and then following the steps from comment 21. After step 2, NVDA does not read the hi document, and after step 4, the active element is not browser ....
The issue is verified fixed using the same steps with Firefox 136.0a1 (202501112212231) and 135.0b4 (2025011020645) on Windows 10x64, macOS 12 and Ubuntu 24. The screen reader successfully reads the hi string and the active element is browser ... as suggested in comment 21.