Open
Bug 1382146
Opened 7 years ago
Updated 2 years ago
It's odd to send keyboard events which may match content accesskeys to *all* remote processes
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement, P3)
Core
DOM: UI Events & Focus Handling
Tracking
()
NEW
People
(Reporter: masayuki, Unassigned)
References
Details
When any remote process doesn't have focus, i.e., the main process has focus, EventStateManager in the main process posts eKeyPress event which may match with content accesskeys to *all* remote children. However, this means that two or more remote processes may handle same content accesskey.
Olli Pettay [:smaug] Bug 1333459 Comment 26
> ::: dom/events/EventStateManager.cpp:1209
> (Diff revision 1)
>> - // A remote child process is focused. The key event should get sent to
>> - // the child process.
>> + // processes.
>> + else if (!aEvent->IsHandledInRemoteProcess()) {
>> - aEvent->mAccessKeyForwardedToChild = true;
>> - } else {
>> AccessKeyInfo accessKeyInfo(aEvent, aAccessCharCodes);
>> nsContentUtils::CallOnAllRemoteChildren(mDocument->GetWindow(),
>
> Why do we have this kind of code. Looks bizarre. Why we send event to all the tabs?
Masayuki Nakano [:masayuki] (JST, +0900) Bug 1333459 Comment 27
>> Why do we have this kind of code. Looks bizarre. Why we send event to all the tabs?
>
> See above comment. I think that this is actually working with only one remote process. (Anyway, this is out scope of this bug and if we need to discuss more, we should wait Enn to back.
Updated•7 years ago
|
Priority: -- → P2
Comment 1•6 years ago
|
||
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
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•