From f332c6813ce16fce76d314ee583eb9d1a05765e3 Mon Sep 17 00:00:00 2001 From: Henri Sivonen Date: Thu, 7 Mar 2019 08:14:45 +0000 Subject: [PATCH] Bug 1524240 - In EventStateManager::PostHandleKeyboardEvent look up TabParent by LayersId. r=masayuki Differential Revision: https://phabricator.services.mozilla.com/D20654 --HG-- extra : moz-landing-system : lando --- dom/events/EventStateManager.cpp | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/dom/events/EventStateManager.cpp b/dom/events/EventStateManager.cpp index 7d3d135c14b3..24699b728fa1 100644 --- a/dom/events/EventStateManager.cpp +++ b/dom/events/EventStateManager.cpp @@ -2870,6 +2870,21 @@ void EventStateManager::PostHandleKeyboardEvent( RefPtr remote = aTargetFrame ? TabParent::GetFrom(aTargetFrame->GetContent()) : nullptr; + if (remote && aKeyboardEvent->mLayersId.IsValid()) { + // remote is null-checked above in order to let pre-existing event + // targeting code's chrome vs. content decision override APZ if they + // disagree in order not to disrupt non-Fission e10s mode in case + // there are still bugs in the Fission-mode code. That is, if remote + // is nullptr, the pre-existing event targeting code has deemed this + // event to belong to chrome rather than content. + TabParent* preciseRemote = + TabParent::GetTabParentFromLayersId(aKeyboardEvent->mLayersId); + if (preciseRemote) { + remote = preciseRemote; + } + // else there was a race between APZ and the chrome-process LayersId + // to TabParent mapping. + } if (remote && !remote->IsReadyToHandleInputEvents()) { // We need to dispatch the event to the browser element again if we were // waiting for the key reply but the event wasn't sent to the content