Open Bug 1300483 Opened 8 years ago Updated 1 months ago

keyboard events for <select> not working

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Version:
48 Branch
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
e10s + ---
firefox48 --- wontfix
firefox49 --- affected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: frank.ebner, Unassigned)

References

Details

Attachments

(1 file)

reporter's testcase
102 bytes, text/html
Details
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
Attached file reporter's testcase —
inconsistency behavior between e10s and non-e10s. With e10s: only [Enter] key triggers keyup event Without e10s: any key triggers keyup event
Blocks: e10s
Status: UNCONFIRMED → NEW
status-firefox48: --- → wontfix
status-firefox49: --- → affected
status-firefox50: --- → affected
status-firefox51: --- → affected
tracking-e10s: --- → ?
Component: Untriaged → DOM: Events
Ever confirmed: true
Product: Firefox → Core
Component: DOM: Events → DOM: Core & HTML
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?
Flags: needinfo?(bugs)
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.
Priority: -- → P2
Hey Mike, I suppose we could close this as bug 1300784 is resolved, right?
Flags: needinfo?(mconley)
(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
Flags: needinfo?(mconley)
(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.
Flags: needinfo?(bugs)
given that non-e10s will be going away, following e10s/Chrome model sounds reasonable.
Flags: needinfo?(bugs)
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
Severity: normal → S3

Since bug 1331725(In reply to Mike Conley (:mconley) (:⚙️) from comment #8)

(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.

Bug 1331725 (and bug 1744009, which it was marked as a duplicate of) are resolved. Does that mean bug 1300483 is resolved, too?

Flags: needinfo?(mconley)

Coming back to this 8 years later! Wow!

So going back to the original test case, it looks like the key events are only firing once a key is pressed when the popup is closed.

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] 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.

I just tested Safari, and it's similar - no key events appear to be passed down to content when the popup is open.

This might be a WONTFIX, unless there's a clear directive in the spec that calls for key events to go through.

Flags: needinfo?(mconley)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: