New issue
Advanced search Search tips

Issue 604069 link

Starred by 1 user
Status: Fixed
Owner:
jamescook@chromium.org
Closed: Apr 2016
Cc:
mustash-bugs@google.com
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

mus: Input events are always acked as handled, regardless of actual handled state

Project Member Reported by jamescook@chromium.org, Apr 15 2016 
Dispatching an input event to an app may spawn a nested message loop (e.g. for a context menu), which will prevent the app from acking the event before the window server times out.

As a workaround, https://codereview.chromium.org/1571953003 changed the input event handler to immediately ack the event, before dispatch. This means it can't know if the event was handled or not.

A better solution would be to process events normally and return their actual handled state, and only early-ack if we detect a nested message loop starting.
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 28 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/aacdfd0e17cb1597dd22745f73b172a0e2797359

commit aacdfd0e17cb1597dd22745f73b172a0e2797359
Author: jamescook <jamescook@chromium.org>
Date: Thu Apr 28 00:50:03 2016

mus: Fix handled status in UI event ack, add MessageLoop::NestingObserver

mus applications receive their events from the window server, which runs
in another process.

Currently all input events to a mus application are immediately acked as
handled, because it's possible the event will start a nested message loop
(e.g. by spawning a context menu) and we don't want the event delivery
message to time out.

With this CL we observe for a message loop starting and if we see one we
immediately ack the event to avoid a timeout. Otherwise we process the
event normally and return a correct handled status.

BUG= 604069 
TEST=added to base_unittests and views_mus_unittests

Review-Url: https://codereview.chromium.org/1891233006
Cr-Commit-Position: refs/heads/master@{#390259}

[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/base/message_loop/message_loop.cc
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/base/message_loop/message_loop.h
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/base/message_loop/message_loop_test.cc
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/base/message_loop/message_loop_test.h
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/base/run_loop.cc
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/ui/views/mus/BUILD.gn
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/ui/views/mus/native_widget_mus.h
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/ui/views/mus/platform_window_mus.cc
[modify] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/ui/views/mus/platform_window_mus.h
[add] https://crrev.com/aacdfd0e17cb1597dd22745f73b172a0e2797359/ui/views/mus/platform_window_mus_unittest.cc

Comment 2 by jamescook@chromium.org, Apr 28 2016

Status: Fixed (was: Started)

Comment 3 by lafo...@chromium.org, Feb 26 2018

Components: -MUS Internals>Services>WindowService
►

Sign in to add a comment