Open Bug 1300483 Opened 8 years ago Updated 2 years 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
(deleted), 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 (deleted) — 
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: