1615977 - Firefox 74 no longer reacts to emulated Alt + Home/ArrowUp/PageUp/ArrowLeft/ArrowRight/End/ArrowDown/PageDown/Insert on Numpad

Status: VERIFIED FIXED

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

Description

[juraj.masiar]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

1. using Firefox 74 (Developer Edition)
2. install StrokeIt application (for gestures)
3. in the StrokeIt, create command of type "Keys - Hotkey" with Hotkey: "ALT + HOME". Don't forget to define a gesture that will execute this command. Also make sure the gesture will be executed in Firefox, for example by defining it in "Global Actions".
4. perform gesture in Firefox

Actual results:

Hotkey no longer works.

Expected results:

Hotkey should open your homepage in active tab, just like it works with keyboard.

This is a regression. It worked in 73 and all other versions for past 10 years.

The issue seems to affect all hotkeys with "Alt" key. All other hotkeys works as expected.

Comment 1

[Negritas Sergiu, Desktop QA]

Hello I managed to reproduce the issue using Fx 75.0a1 (2020-20-20) following the STR provided in the description. I also managed to find the regression for this issue, here is the pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=31e91b3d071e6b7a1453b8a89e2e60e60a7a6760&tochange=388a4d04e91159527a69fa1e3d2a91e7155247aa .

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Well, this is reproducible without StrokeIt. It just generates Alt + Home/ArrowUp/PageUp/ArrowLeft/ArrowRight/End/ArrowDown/PageDown in numpad and Gecko fails to handle it.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1615977 - Don't modify key value while pressing a numpad key with `Alt` but the virtual keycode is a function key r=m_kato!

Inputting Unicode scalar value with Alt + numpad keys is available even
without NumLock state. However, Alt + function key on numpad should also
be worked because user may intent to perform it. Therefore, this patch
stops the hacking for bug 1606655 when given virtual keycode value is a
function key, but this means that users cannot type a Unicode scalar value
without NumLock key state if the value includes 7 (Home),
4 (ArrowLeft), 6 (ArrowRight) because Firefox UI handles they are
shortcut keys (for "Go home", "Go back" and "Go forward"). Unfortunately,
I have no idea how to solve this conflict (if it's second key or latter key
after pressing Alt key, we could do that with a boolean flag, but I don't
like to make it only for this kind of edge case unless a lot of users want
to do it).

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eb02d91fd3b8
Don't modify key value while pressing a numpad key with `Alt` but the virtual keycode is a function key r=m_kato

Comment 5

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/eb02d91fd3b8

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 9128364 [details]
Bug 1615977 - Don't modify key value while pressing a numpad key with Alt but the virtual keycode is a function key r=m_kato!

Beta/Release Uplift Approval Request

• User impact if declined: Windows user cannot use Alt + Home/ArrowUp/PageDown/ArrowLeft/ArrowRight/End/ArrowDown/PageDown/Insert with the keys on Numpad (when NumLock is unlocked). And this is new regression from 74.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Except Alt + Home:

1. Load https://w3c.github.io/uievents/tools/key-event-viewer.html in new tab.
2. Type each Numpad key (only 0 ~ 9 keys are affected) with/without Alt key when NumLock is both on and off.
3. Each key value should be the pressed key which respects NumLock state.
4. Each keyCode value should be same as when you type same key on control pad section and arrow pad section.

For Alt + Home:

1. Type it and check whether it opens home page in the tab or not.

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Unfortunately, this cannot be tested by automated tests. On the other hand, this patch stops the hack of bug 1606655 which caused this regression when NumLock is off. The bug was for supporting customized keyboard layout, so, even if this causes breaking the original fix, the users must be fewer than the users who meet this regression.
• String changes made/needed: none

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

But I know it may be too late. It depends on whether we should fix this on beta to consider how much important Alt + numpad key shortcuts. Perhaps, only Alt + Home (Go home), Alt + ArrowLeft (Go back) and Alt + ArrowRight (Go forward) are important.

Comment 8

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Masayuki, how about backing out bug 1606655 instead? It fixed what seems to me an very edgy case while this bug here fixes a case that can impact all users as it doesn't depend on a specific keyboard. Am I missing something?

Comment 9

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Comment on attachment 9128364 [details]
Bug 1615977 - Don't modify key value while pressing a numpad key with Alt but the virtual keycode is a function key r=m_kato!

I consulted with the webcompat team and they are not aware of other reported issues caused by this bug, so I am not going to take it for our last beta to minimize risk of creating worse regressions than this one. Thanks.

Comment 10

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Comment on attachment 9128364 [details]
Bug 1615977 - Don't modify key value while pressing a numpad key with Alt but the virtual keycode is a function key r=m_kato!

Putting back the flag, my comment was for your other patch in bug 1616539

Comment 11

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Comment on attachment 9128364 [details]
Bug 1615977 - Don't modify key value while pressing a numpad key with Alt but the virtual keycode is a function key r=m_kato!

Uplift approved for 74.0b9 as this is likely to affect a lot of keyboard users.

Comment 12

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/releases/mozilla-beta/rev/22b224c5fa6a

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Pascal Chevrel:pascalc from comment #8)

Masayuki, how about backing out bug 1606655 instead? It fixed what seems to me an very edgy case while this bug here fixes a case that can impact all users as it doesn't depend on a specific keyboard. Am I missing something?

Yeah, backing out bug 1606655 and bug 1612238 is also fine. If you guys like it better, feel free to do that.

(In reply to Andreea Pavel [:apavel] from comment #12)

https://hg.mozilla.org/releases/mozilla-beta/rev/22b224c5fa6a

Although, it's uplifted.

Comment 14

[Negritas Sergiu, Desktop QA]

Hello I can confirm that the issue is fixed on Fx 75.0a1(2020-02-27) and 74.0b9.