зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1347351 - nsMenuBarListener::KeyPress() should wait reply event for handling F10 key r=smaug
Currently, nsMenuBarListener::KeyPress() handles F10 key before remote content handles it. However, if a remote process has focus, the keyboard event should be handled in the content first. Then, only when it's not consumed in the remote process, menubar should handle the F10 key press. MozReview-Commit-ID: GDf4POAPsTy --HG-- extra : rebase_source : a450755d89bc410d17fef55fad98533169e2eff5
This commit is contained in:
Родитель
2477a4b823
Коммит
6f633adbf8
|
@ -327,6 +327,17 @@ nsMenuBarListener::KeyPress(nsIDOMEvent* aKeyEvent)
|
|||
// Also need to handle F10 specially on Non-Mac platform.
|
||||
else if (nativeKeyEvent->mMessage == eKeyPress && keyCode == NS_VK_F10) {
|
||||
if ((GetModifiersForAccessKey(keyEvent) & ~MODIFIER_CONTROL) == 0) {
|
||||
// If the keyboard event should activate the menubar and will be
|
||||
// sent to a remote process, it should be executed with reply
|
||||
// event from the focused remote process. Note that if the menubar
|
||||
// is active, the event is already marked as "stop cross
|
||||
// process dispatching". So, in that case, this won't wait
|
||||
// reply from the remote content.
|
||||
if (nativeKeyEvent->WillBeSentToRemoteProcess()) {
|
||||
nativeKeyEvent->StopImmediatePropagation();
|
||||
nativeKeyEvent->MarkAsWaitingReplyFromRemoteProcess();
|
||||
return NS_OK;
|
||||
}
|
||||
// The F10 key just went down by itself or with ctrl pressed.
|
||||
// In Windows, both of these activate the menu bar.
|
||||
mMenuBarFrame->SetActiveByKeyboard();
|
||||
|
|
Загрузка…
Ссылка в новой задаче