1805375 - Multiple command events fired on XUL <key> with alt and shift modifiers

Status: NEW

(Core :: XUL, defect)

Description

[Geoff Lankow (:darktrojan)]

For a <key> with the shortcut alt + shift + any letter, and with a visible chrome <browser> containing a remote <browser> (visible or not), the command event fires twice. If more <browser>s are visible (remote or not) more command events are fired.

If the chrome <browser> is hidden, one event fires as expected.
If the remote <browser> isn't present, one event fires as expected.
If different modifiers are used, one event fires as expected.
This appears to be cross-platform, although I didn't try Mac OS.

This particularly unusual combination of things is present in Thunderbird with the new 3-pane UI. That's not easy to debug right now but I can have a look myself if somebody can point me in the right direction.

Comment 1

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

It's probably fired from nsContentUtils by KeyEventHandler::DispatchXULKeyCommand. It's called by GlobalKeyListener::WalkHandlersAndExecute and it may be called multiple times. However, if once KeyEventHandler::DispatchXULKeyCommand returns NS_OK, GlobalKeyListener::WalkHandlersAndExecute returns true and GlobalKeyListener::WalkHandlersAndExecute stops the for loop. So, I have no idea how it's dispatched multiple times (keydown vs. keyup?).

Comment 2

[Geoff Lankow (:darktrojan)]

Thanks. I walked back up the call stack to GlobalKeyListener::HandleEvent, which I realised is being called (multiple times, once for each command event) with a mozaccesskeynotfound event. That would explain why it's only happening with these modifiers.

I guess the event crosses the process boundary and bubbles up the document tree to the top-level, causing a command event at every level. But the number of events doesn't match the number of levels, and that doesn't explain why the event is firing when the remote browser isn't active or even visible.

Comment 3

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

(In reply to Geoff Lankow (:darktrojan) from comment #2)

Thanks. I walked back up the call stack to GlobalKeyListener::HandleEvent, which I realised is being called (multiple times, once for each command event) with a mozaccesskeynotfound event. That would explain why it's only happening with these modifiers.

Ah, mozaccesskeynotfound... It's a reply from remote process(es) of checking access key matches with content's one. In other words, the shortcut key may be conflict with access key in HTML mails which is visible.

I guess the event crosses the process boundary and bubbles up the document tree to the top-level, causing a command event at every level. But the number of events doesn't match the number of levels, and that doesn't explain why the event is firing when the remote browser isn't active or even visible.

Yeah, if mozaccesskeynotfound may be fired later, keydown (keypress?) should not cause dispatching command event before sending the event to remote process.

Comment 4

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

Enn, do you have any ideas?

Comment 5

[Geoff Lankow (:darktrojan)]

Ping! Can we get some movement on this please?