1952611 - Alt+C no longer toggles the “Match Case” checkbox, only focuses it

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Chris Morgan]

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

Steps to reproduce:

Ctrl+F (to open the find-in-page bar), Alt+C.

Actual results:

The “Match Case” checkbox was focused, but its state was not toggled.

Expected results:

Its state should have toggled, just as Alt+A focuses and toggles Highlight All, Alt+I focuses and toggles Match Diacritics, and Alt+W focuses and toggles Whole Words.

I’m pretty sure this is a regression in recent months.

Related: bug 369089, which at first sounded like it might be describing this, but I think is instead long obsolete.

Comment 1

[Francesco Lodolo [:flod]]

Could you try running mozregression to help to identify the issue?
https://mozilla.github.io/mozregression/quickstart.html

Comment 2

[Chris Morgan]

End of the mozregression logs:

2025-03-08T14:19:35.768000: INFO : Narrowed integration regression window from [2610a713, 44e48253] (3 builds) to [d7874269, 44e48253] (2 builds) (~1 steps left)
2025-03-08T14:19:35.777000: DEBUG : Starting merge handling...
2025-03-08T14:19:35.777000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=44e482539c57ba8486619c4f8f84f8e07401a5ef&full=1
2025-03-08T14:19:35.777000: DEBUG : redo: attempt 1/3
2025-03-08T14:19:35.777000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=44e482539c57ba8486619c4f8f84f8e07401a5ef&full=1',), kwargs: {}, attempt #1
2025-03-08T14:19:35.779000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-03-08T14:19:37.941000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=44e482539c57ba8486619c4f8f84f8e07401a5ef&full=1 HTTP/11" 200 None
2025-03-08T14:19:37.944000: DEBUG : Found commit message:
Bug 1942186 - Set automatic fluent support for accesskey in moz-button r=reusable-components-reviewers,tgiles

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

2025-03-08T14:19:37.944000: DEBUG : Did not find a branch, checking all integration branches
2025-03-08T14:19:37.945000: INFO : The bisection is done.
2025-03-08T14:19:37.945000: INFO : Stopped

Comment 3

[Alice0775 White]

I can reproduce the issue on Nightly138.0a1 Windows11.

Regression window:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d787426912914218d61d2eb2f03d4ebc6bbe30fb&tochange=44e482539c57ba8486619c4f8f84f8e07401a5ef

Comment 4

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

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

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

For more information, please visit BugBot documentation.

Comment 6

[akulyk]

This is a known issue with Alt+C shortcuts.
Please see Bug 1945032 - Alt+C shortcut is delayed for extension "Temporary Containers" for more details.

Comment 7

[Chris Morgan]

About “known issue”—there’s some difference between someone choosing Alt+C as a shortcut, and this, where the browser has declared that Alt+C is its shortcut, and it has been for many, many years.

I don’t understand the mechanism whereby bug 1942186 caused this regression, but I also don’t understand what its purpose is. Is backing it out, as a temporary measure, reasonable? (I’m also curious why it isn’t affecting more things. Is it literally only C that’s being affected at present?)

(This had been bothering me for a month before I finally got round to reporting it. I have learned that I use “match case” fairly frequently!)

Comment 8

[akulyk]

Copied this from Bug 1945032 - Alt+C shortcut is delayed for extension "Temporary Containers":

As my patch is set as a regressor for this bug, I did some research.
First of all, the issue with Alt+C shortcut is relevant not only for extension "Temporary Containers", for example Match Case checkbox in the findbar has the same accesskey and it has the same issue.
My patch did not create this issue, but it revealed the issue that we have with accesskeys at the moment.
Alt+C shortcut isn't working, because there's a button in the tabgroup menu panel with the same accesskey. When we check if the element is an accesskey target, we do visibility checks only for XUL elements. But have to do the same check for the chrome elements (like that button in the tabgroup menu panel).

Comment 9

[Chris Morgan]

My patch did not create this issue, but it revealed the issue that we have with accesskeys at the moment.

Well, from a user’s perspective, it did create the issue. Maybe there was something technically unsound there before, but Alt+C used to work, and now doesn’t.

So I repeat: is backing that patch out, as a temporary measure, reasonable? Did it improve something user-visible that we’d then lose again?

Comment 10

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

The severity field is not set for this bug.
:enndeakin, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Chris Morgan]

I want to poke this again, asking for a third time: can we back the patch that caused this regression out? I don’t see any user-visible improvements in it (maybe I missed some?), and here is an obvious user-visible regression. Sure, in the long run it might be better, but right now it’s breaking things.

Comment 12

[наб]

Also affects 139 (current Nightly 139.0a1 (2025-04-18) (64-bit)) which I don't see in the tags.

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Attachment: Bug 1952611 - revert setting automatic fluent support for accesskey for moz-button to fix bug 1942186. r=akulyk

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1d338f14132d
revert setting automatic fluent support for accesskey for moz-button to fix bug 1942186. r=akulyk,reusable-components-reviewers

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/87b081d8de00
revert setting automatic fluent support for accesskey for moz-button to fix bug 1942186. r=akulyk,reusable-components-reviewers

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/1d338f14132d

Comment 17

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

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

akulyk: Will you submit the uplift request for release?

Comment 20

[akulyk]

Comment on attachment 9480675 [details]
Bug 1952611 - revert setting automatic fluent support for accesskey for moz-button to fix bug 1942186. r=akulyk

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Alt+C shortcut no longer works
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: https://bugzilla.mozilla.org/show_bug.cgi?id=1952611#c0
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): the change is relatively small, it removes automated fluent support for the accesskey in moz-button reusable component. The accesskey can still be set with data-l10n-attrs.
• String changes made/needed:
• Is Android affected?: No

Comment 21

[Monica Chiorean]

I was able to reproduce the issue on Win11x64 using Firefox build 138.0a1(20250308211707).
Verified as fixed on Win11x64/Mac12.6/Ubuntu24.04 using Firefox build 139.0b1 and 140.0a1.

Comment 22

[Dianna Smith [:diannaS]]

Comment on attachment 9480675 [details]
Bug 1952611 - revert setting automatic fluent support for accesskey for moz-button to fix bug 1942186. r=akulyk

Approved for 138.0.3

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/0f5063bf747b

Comment 24

[Monica Chiorean]

Verified as fixed on Win11x64/Ubuntu24.04 using Firefox build 138.0.3.