New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 690709 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Feb 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Key events are rather flaky in mash

Project Member Reported by sky@chromium.org, Feb 9 2017

Issue description

Two sequences I've noticed as problematic:

. when chrome comes up the omnibox has focus and typing some characters works. For example pressing 'a' generates an 'a', but backspace does nothing.
. closing a window with the keyboard leads to a state where key events are wedged.
 

Comment 1 by sky@chromium.org, Feb 9 2017

Labels: mustash-1
Cc: moshayedi@chromium.org mfomitchev@chromium.org
+moshayedi FYI

Comment 3 by sky@chromium.org, Feb 10 2017

I've mostly understand both these issues. Patches soon.
Project Member

Comment 4 by bugdroid1@chromium.org, Feb 10 2017

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

commit b52e3c3e96944729c7f6a02b42f5c1b6d01dee24
Author: sky <sky@chromium.org>
Date: Fri Feb 10 20:34:38 2017

Fixes bug in DesktopWindowTreeHostMus's activation handling

If Activate() is called before the window is visible, then the call
should fail. The way the code is now it assumed it would succeed so
that when Activate() was called again later on we wouldn't do the
right thing (because the activation client was already installed).

BUG= 690709 
TEST=covered by test
R=erg@chromium.org

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

[modify] https://crrev.com/b52e3c3e96944729c7f6a02b42f5c1b6d01dee24/ui/views/mus/desktop_window_tree_host_mus.cc
[modify] https://crrev.com/b52e3c3e96944729c7f6a02b42f5c1b6d01dee24/ui/views/mus/desktop_window_tree_host_mus_unittest.cc

Project Member

Comment 5 by bugdroid1@chromium.org, Feb 13 2017

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

commit 7a0d90d6351c104b896cb2ecef771dab00d68323
Author: sky <sky@chromium.org>
Date: Mon Feb 13 19:22:26 2017

Makes ~InputMethodMus ack any in flight events

It's entirely possible for InputMethodMus to be awaiting a response
from the ime server when deleted. If this happens the event ack to mus
for the key event is never acked and mus won't process the next event
until it times out. This patch makes ~InputMethodMus ack any in flight
events immediately with unhandled.

BUG= 690709 
TEST=covered by test
R=moshayedi@chromium.org
TBR=sadrul@chromium.org

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

[modify] https://crrev.com/7a0d90d6351c104b896cb2ecef771dab00d68323/ui/aura/BUILD.gn
[modify] https://crrev.com/7a0d90d6351c104b896cb2ecef771dab00d68323/ui/aura/mus/input_method_mus.cc
[modify] https://crrev.com/7a0d90d6351c104b896cb2ecef771dab00d68323/ui/aura/mus/input_method_mus.h
[add] https://crrev.com/7a0d90d6351c104b896cb2ecef771dab00d68323/ui/aura/mus/input_method_mus_unittest.cc
[modify] https://crrev.com/7a0d90d6351c104b896cb2ecef771dab00d68323/ui/aura/mus/os_exchange_data_provider_mus_unittest.cc

Comment 6 by sky@chromium.org, Feb 13 2017

Status: Fixed (was: Started)

Comment 7 by dchan@google.com, Apr 17 2017

Labels: VerifyIn-59

Comment 8 by dchan@google.com, May 30 2017

Labels: VerifyIn-60

Comment 9 by dchan@chromium.org, Aug 1 2017

Labels: VerifyIn-61

Comment 10 by dchan@chromium.org, Oct 14 2017

Status: Archived (was: Fixed)

Sign in to add a comment