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

Status: NEW

(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?