1974148 - Media's key event is always dispatched to AudioManager

Status: RESOLVED FIXED

(GeckoView :: IME, defect)

Description

[Makoto Kato [:m_kato]]

When Key event is dispatched to web content, if it isn't consumed (or content doesn't call preventDefault), we call AudioManager.dispatchMediaKeyEvent. But this doesn't work on e10s (GeckoView). When we don't have a focus to editable control, we will dispatch key event from chrome process. So we cannot recognize whether event is consumed.

So we need a way to how to recognize whether key event from chrome process is consumed, like GlobalKeyListener.

Comment 1

[Makoto Kato [:m_kato]]

Attachment: Bug 1974148 - Media keys on GeckoView aren't e10s-aware. r=masayuki!,#geckoview-reviewers!

Originally, media keys were dispatched to AudioManager if web content
consumes it by bug 730192. But after GeckoView (moving to e10s),
we always call GeckoEditable.onDefaultKeyEvent() if focused element
isn't editable even if web content consumes it.

DispatchKeyboardEvent is asynchronous and it doesn't wait for
whether the event is consumed or not. Also, even if we set the flag for
"waiting reply from remote process", its flag will reset in
DispatchKeyboardEventInternal.

So I would like to inhibit this. Then if media key, we set the flag if
on parent process.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/43a750107bd0
https://hg.mozilla.org/integration/autoland/rev/49fbc2814452
Media keys on GeckoView aren't e10s-aware. r=masayuki,geckoview-reviewers,ohall

Comment 3

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/49fbc2814452