1947723 - Cmd-L doesn't give keyboard focus to address bar in new windows with blank tab

Status: RESOLVED FIXED

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

Description

[flack]

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

Steps to reproduce:

• open a new window with Cmd-N
• enter some URL
• once the website loads, press Cmd-L

Actual results:

The list with addressbar sugestions opens, but the address itself doesn't have keyboard focus, i.e. you can't type or use arrow keys

Expected results:

the address bar should have keyboard focus.

This used to work fine prior to the last update. It still works fine the second time you press Cmd-L. Only the first time you press Cmd-L in a newly opened window, the problem happens. In newly-opened tabs (with Cmd-T) it also works without problems

Comment 1

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

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

Comment 2

[Marco Bonardo [:mak]]

if this was working fine before, it would be extremely useful if you could try to use mozregression to help us finding which change caused the issue: https://mozilla.github.io/mozregression/
It will download builds and ask you to reproduce the bug and mark builds as good/bad, until it can generate a link that you can post to this bug report.

Comment 3

[flack]

I tried mozregression, the problem didn't occur there. I also downloaded 135 again and ran it from the DMG without installing it, also couldn't reproduce there.

I restarted my installed Firefox in safe mode, and can reproduce the problem there.

Comment 4

[flack]

I also tried logging into mac's guest account, and also couldn't reproduce there

Comment 5

[Marco Bonardo [:mak]]

Hm so it looks like the behavior may be related to your profile, since mozregression will use a new profile.
If it can reproduce in safe mode, we can probably exclude add-ons and hardware acceleration.
Would you mind getting a text log from about:support and attach it to this report? That may provide some hints about profile settings.

Comment 6

[flack]

Attachment: about:config txt

here you go:

Comment 7

[flack]

one more thing I just noticed: The focus problem even happens when I click the address bar with the mouse, i.e. I click, the dropdown with the suggestions opens, but the keyboard focus is still in the webpage (e.g. if I'm on a login page, click the address bar and start typing, the text goes into the username field of the login form)

Comment 8

[Marco Bonardo [:mak]]

Could you please check if using the default newtab page solves the problem? We're wondering if alternative new tab pages are actually causing this issue.

Comment 9

[flack]

yes, that did the trick!

I had set blank page for new windows, when I change it back to Firefox default, the problem disappears.

(BTW: It only affects new windows, new tabs work fine with either setting)

Comment 10

[flack]

I've managed to bisect this now. mozregressions says

2025-02-17T21:13:12.686000: DEBUG : Found commit message:
Bug 1936294: Add a11y test for focus when changing a tab from non-remote to remote. r=nlapre

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

2025-02-17T21:13:12.691000: DEBUG : Did not find a branch, checking all integration branches
2025-02-17T21:13:12.692000: INFO : The bisection is done.
2025-02-17T21:13:12.693000: INFO : Stopped

Comment 11

[Marco Bonardo [:mak]]

That phab diff is unlikely, but the bug containing it is more likely

Comment 13

[flack]

Yes, actually, there were one or two warnings that mozregression couldn't get builds for some commits, so it might be off by one or two or so

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Is this somehow macOS specific? STR seem to work for me on Linux.

Comment 15

[flack]

Attachment: Bildschirmaufnahme 2025-02-17 um 23.32.04.mov

this is what it looks like with a freshly downloaded FF 135.

And yes, on my Linux machine it also doesn't happen.

Comment 16

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

Set release status flags based on info from the regressing bug 1936294

Comment 17

[Marco Bonardo [:mak]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)

Is this somehow macOS specific? STR seem to work for me on Linux.

the other report in bug 1946955 was on Windows.

Comment 18

[[e-mail]]

It also exists in Windows Firefox 135.0.1 received earlier today. In Windows there was no problem in v.134.x.x.

Comment 19

[flack]

Small update: I can now also reproduce this on Linux (it turns out I was still on 134 the last time I tried, only got 135.0.1 Snap today)

Comment 20

[Julien Wajsberg [:julienw]]

(helping out the release management team for v136)

Hey James, is this really a S2? It sounds like a S3 or S4 to me.
Also do you have a plan to fix this already? I doubt this would be for v136 because it will be out tomorrow, but it would be good to have a path for v137.

Thanks!

Comment 21

[flack]

Found another way to reproduce:

• open a webage, e.g. https://bugzilla.mozilla.org
• in the same tab, open some internal FF view, e.g. about:cache
• in the same tab, open a webpage again, e.g. https://bugzilla.mozilla.org
• press Cmd-L (or click the address bar)

=> the address menu opens, but keyboard focus is still in the content window (you can check by pressing the Arrow keys, they will scroll the page, not go through address suggestions)

Comment 22

[flack]

(In reply to flack from comment #21)

Actually, the first step is unnecessary. Like it says in the linked bug, as soon as you switch from non-remote (about:cache) to remote (https://bugzilla.mozilla.org), you lose keyboard focus in the address bar after. It doesn't even have to be in a new window or anything.

Comment 23

[Marco Bonardo [:mak]]

(In reply to Julien Wajsberg [:julienw] from comment #20)

Hey James, is this really a S2? It sounds like a S3 or S4 to me.

Breaking the most used UI widget in a way it's not usable in that tab is definitely S2, in this case at least it's limited to switching remoteness, but still particularly annoying when opening a new window or loading a site and the urlbar is broken.
We're aware a fix is unlikely to make 136 at this point.

Regarding a plan, we don't have expertise about bug 1936294 that caused this regression, so I defer to Emilio to please let us know if the urlbar is misusing focus or why it's affected by that change to the focus manager.

Comment 24

[Julien Wajsberg [:julienw]]

(In reply to flack from comment #21)

Found another way to reproduce:

• open a webage, e.g. https://bugzilla.mozilla.org
• in the same tab, open some internal FF view, e.g. about:cache
• in the same tab, open a webpage again, e.g. https://bugzilla.mozilla.org
• press Cmd-L (or click the address bar)

=> the address menu opens, but keyboard focus is still in the content window (you can check by pressing the Arrow keys, they will scroll the page, not go through address suggestions)

Thanks for the updated STR.
I don't reproduce on my linux at least.

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Attachment: Screencast of emilio trying to repro on macOS

I also can't repro this on either Linux or macOS, on latest Nightly at least. I've also tried a clean profile right now, where I can't repro either... :(

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Ok, I think I got to repro this (on macOS at least) by:

• Open about:newtab (remote)
• Open about:cache on the same tab.
• Click somewhere inside about:cache (just to make sure it gets focus).
• Press the back button (so that we go to about:newtab again).
• Cmd+L: The urlbar view opens, but focus is still on the tab.
• Cmd+L again: The urlbar view gets focus.

Comment 27

[Emilio Cobos Álvarez (:emilio)]

Seems to repro as well on Linux using comment 26 fwiw. I'll try to dig.

Comment 28

[Julien Wajsberg [:julienw]]

I reproduce with your str in comment 26 as well.
It's still not S2 for me, especially if a second cmd+l would make it focused. But it's annoying for sure.

Comment 29

[flack]

what is problematic about it is that it can cause you to type where you didn't intend to type if you're not paying attention. Imagine you have your workplace's group chat open in a tab, and then press Cmd-L to google for "new hemorrhoid cream" or something equally embarrassing. Pressing Enter will send that as a message to all your work colleagues (because keyboard focus was in the content tab all the time, even though the address menu opened).

Comment 30

[Julien Wajsberg [:julienw]]

Yes, I'm not saying it's unimportant.
See the definition of severities here: https://wiki.mozilla.org/BMO/UserGuide/BugFields#bug_severity

But there's no point in being pedantic about it. If Mak thinks it's a S2 I'm fine with it :-)

Comment 31

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1947723 - Set correct focused window when swapping frameloaders. r=smaug

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7487a194dc49
Set correct focused window when swapping frameloaders. r=smaug

Comment 33

[Marco Bonardo [:mak]]

Thanks for prompt reaction Emilio and Olly.

Comment 34

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7487a194dc49

Comment 35

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7487a194dc49

Comment 36

[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-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 37

[Donal Meehan [:dmeehan]]

To add to Comment 36, Fx136 is now in release, so a release uplift request will be needed.
We could take it a dot release ride-along depending on the risk.

Comment 38

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9468669 [details]
Bug 1947723 - Set correct focused window when swapping frameloaders. r=smaug

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: comment 0
• 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 26 have the steps that worked for me.
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): One liner for very special code-path already.
• String changes made/needed: none
• Is Android affected?: No

Comment 39

[flack]

downloaded the current FF nightly and can't reproduce with that anymore, so it seems fixed. Thanks, everyone!

Comment 40

[Monica Chiorean]

I was able to reproduce the issue on Mac 12.6 using Firefox build 135.0 and steps from comment #26.
Verified as fixed on Mac 12.6 / Win11 using Firefox Nightly build 137.0a1. Waiting for Beta 137.0