+++ This bug was initially created as a follow-up of Bug #1640883 +++

Currently, we don't treat key events with some modifiers as user activation given that we think the user might intend to interact with the browser at that time. But we should be a better way to handle it instead of just ignoring all combinations.

https://phabricator.services.mozilla.com/D77046#2347175

But could we somehow utilize the lists in https://searchfox.org/mozilla-central/source/dom/events/ShortcutKeyDefinitionsForInputCommon.h and
https://searchfox.org/mozilla-central/rev/bc3600def806859c31b2c7ac06e3d69271052a89/dom/events/unix/ShortcutKeyDefinitions.cpp
and other similar files. Those should catch, I think, most common cases. (There can be still other cases where some JS code adds event listener.)

(In reply to Edgar Chen [:edgar] from comment #1)

But could we somehow utilize the lists in https://searchfox.org/mozilla-central/source/dom/events/ShortcutKeyDefinitionsForInputCommon.h and
https://searchfox.org/mozilla-central/rev/bc3600def806859c31b2c7ac06e3d69271052a89/dom/events/unix/ShortcutKeyDefinitions.cpp
and other similar files. Those should catch, I think, most common cases. (There can be still other cases where some JS code adds event listener.)

Masayuki, besides https://searchfox.org/mozilla-central/source/dom/events/ShortcutKeyDefinitionsForInputCommon.h and https://searchfox.org/mozilla-central/rev/bc3600def806859c31b2c7ac06e3d69271052a89/dom/events/unix/ShortcutKeyDefinitions.cpp, do you know if there is any other additional thing we could use to filter out the browser key shortcut? Thanks!

Can you provide some more detail? I'm unclear why the presence of a modifier changes user intent.

edgar, sorry, I'm not sure what are you asking me.

If you meant that "Are there some other shortcut key definitions?", yes there are. XUL all <key> elements are shortcut key definition and the files you pointed is created for each platform. Additonaly, as far as I know some other shortcut keys like F7 for caret browsing and Ctrl+Tab to switch tabs are handled by chrome's keyboard event listeners, so, the latter case, it's hard to look for.

If you meant that "Are there some other shortcut keys in the file which should be treated as user's intentional activation, I'll check it later.

(In reply to Mike Kaply [:mkaply] from comment #3)

Can you provide some more detail? I'm unclear why the presence of a modifier changes user intent.

We don't want to treat browser shortcut as user's intentional activation given that we think the user is trying to interact with browser instead of web page, so we just filter out key event when modifier is pressed, see https://searchfox.org/mozilla-central/rev/803b368879fa332e8e2c1840bf1ec164f7ed2c32/widget/TextEvents.h#308-329.

So what I would like to do in this bug is trying to find a way to filter out the browser shortcut, so we won't treat them as user's intentional activation given that we think that the user is trying to interact with the browser, not the web page.

I found those lists and thought that maybe we could utilize those lists, but wonder if there are any other things I should consider. And it seems we probably should also check the <key> element and the chrome keyboard event listener. Do you know if there is any way that we could know the keyboard event would be handle by the browser as a shortcut around https://searchfox.org/mozilla-central/rev/803b368879fa332e8e2c1840bf1ec164f7ed2c32/dom/events/EventStateManager.cpp#772 and then we would not try to notify user activation for it? Right now we just ignore keyboard events when a modifier is pressed with some exceptions. Thanks!

Ah, maybe, I got it what you mean "browser shortcuts" vs. "Ctrl-X" etc. So, you must want to hook all commands which interact with content only when user kick them with keyboard. Okay, let me think how to do it...

Well, if you'd like to check it in content process, it might be a big hint that the keyboard event is requested a reply for the main process.
https://searchfox.org/mozilla-central/rev/819be4899a92213abf121b449779ced662f2ce13/dom/ipc/BrowserChild.cpp#2033
Most shortcut keys should be cancelable. Therefore, chrome process marks keypress events which matched with a non-reserved shortcut key as "wants a reply" before sending the event to focused content process. Currently, this information is not included in localEvent which is dispatched in a remote process, but you can add new flag if it's required. Then, you can ignore such event with whitelist which matches "cmd_cut", etc.

Is this what you want to know?

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #8)

Is this what you want to know?

Yes, thanks for this information! I will try in this direction.