Open Bug 1300483 Opened 4 years ago Updated 2 years ago
keyboard events for <select> not working
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160823121617 Steps to reproduce: <html> <select onkeyup="alert(0);"> <option>a</option> <option>b</option> </select> </html> open in browser click on the combo-box -> the drop-down appears hit a key on the keyboard Actual results: nothing. the keyup event is not triggered. Expected results: the key event should trigger like it did in firefox 47 and earlier
inconsistency behavior between e10s and non-e10s. With e10s: only [Enter] key triggers keyup event Without e10s: any key triggers keyup event
We stop the propagation of these KeyboardEvents cross processes here: https://dxr.mozilla.org/mozilla-central/source/layout/xul/nsXULPopupManager.cpp#2640 smaug, do you remember why we do this in this particular case?
bug 1119074 explains the case. But would removing aKeyEvent->AsEvent()->StopCrossProcessForwarding(); help here? I'm not too familiar with key event handling of <select> in e10s.
Flags: needinfo?(bugs) → needinfo?(mconley)
> But would removing aKeyEvent->AsEvent()->StopCrossProcessForwarding(); help > here? No. This is not enough. But at least the keyEvent is received by the child process. I haven't debugged it fully.
FWIW, Chrome doesn't seem to pass key events to child process either. Don't have access to Safari or Edge right now. But yes, inconsistency between e10s and non-e10s is bad.
Hey Mike, I suppose we could close this as bug 1300784 is resolved, right?
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7) > Hey Mike, I suppose we could close this as bug 1300784 is resolved, right? I'm afraid not. :( The patch landed, but it's disabled by default. Bug 1331725 is for enabling it by default. I've marked my comment 6 as obsolete.
Depends on: 1331725
(In reply to Olli Pettay [:smaug] from comment #5) > FWIW, Chrome doesn't seem to pass key events to child process either. Don't > have access to Safari or Edge right now. > But yes, inconsistency between e10s and non-e10s is bad. Do you think it makes more sense to follow Chrome or non-e10s Firefox? Should we survey the other browsers first? It should be easier to start addressing the test failures in bug 1331725 if we decide on what exactly the behavior should be.
given that non-e10s will be going away, following e10s/Chrome model sounds reasonable.
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.