New issue
Advanced search Search tips

Issue 804460 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 731255



Sign in to add a comment

mus: Mouse/touch event location issues in unified mode

Project Member Reported by msw@chromium.org, Jan 22 2018

Issue description

mus: Mouse/touch event location issues in unified mode

(1) Run ToT chrome on device per go/simplechrome (eg. cros 10328.0.0 / chrome 66.0.3329.0 ToT @ #530902 on cyan, similar on link)
(2) Add --mus and --ash-enable-unified-desktop flags to /etc/chrome_dev.conf per go/mustash-intro (or enable corresponding about:flags)
(3) Connect an external display to use the device in unified mode

Specific defects (they seem to occur frequently, but not always):
(A) Mouse warp doesn't always work (moving cursor external<->internal)
(B) Mouse/touch event locations seem incorrect (offset from visible cursor)
(C) A second cursor is shown (sometimes offset, sometimes a different size)
(D) Touch window-dragging event locations are offset (windows slide around)

These defects seem to start occurring after moving or resizing windows, particularly when the cursor moves between displays.

I tried fixing some event location issues in cros linux-desktop unified during capture in this CL:
  https://chromium-review.googlesource.com/c/chromium/src/+/842467
That seemed to fix a lot of problems I was seeing, but it may not be entirely correct.
 

Comment 1 by msw@chromium.org, Jan 22 2018

We definitely handle display scaling incorrectly when moving between unified mirror displays with different dpis.
Dragging a chrome window from the 400x400 display at y=100 to the 800x800 display warps the mouse to y=200:

out/Default/chrome --ash-enable-unified-desktop --ash-host-window-bounds=400x400,410+0-800x800 --mus
[92703:92703:0122/154640.905726:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 294,21 399,100
[92703:92703:0122/154640.905761:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 399,100 399,100
[92703:92703:0122/154640.906284:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 305,121 410,200
[92703:92703:0122/154640.906319:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 410,200 410,200

This is possibly distinct from the defects (A-D) listed above.

Comment 2 by sky@chromium.org, Jan 23 2018

If the second display is 2x then isn't 200 the expected location? I'm assuming you're looking at pixels. If that isn't the case, then I agree 200 isn't right.

I did notice some weirdness on the screen edge that we seem to get a spurious event with the wrong x-coordinate. This happens on classic though and it seems to be generated from ozone.

Comment 3 by sky@chromium.org, Jan 23 2018

At least when run on the desktop I think we are offsetting the drawing of the second display vertically (in the negative direction). This is pretty easy to reproduce if you change WorkspaceWindowResizer::kScreenEdgeInset to 0, create a window that spans monitor and drag slowly to the top. Notice with classic the window touches the top of both monitors. With --mus on the second display the window is going offscreen slightly. My guess is we are off by about 4 pixels.

Comment 4 by msw@chromium.org, Jan 23 2018

#2: Actually, when I'm hovering without dragging a window, MusUnifiedEventTargeter::FindTargetForEvent reports that 100 on the first display corresponds to 50 on the second display (ditto on cash), so those are probably dips, not px? I don't know why dragging would 

Just hovering (I also see a spurious event with a wrong x-coord here):
chrome --ash-enable-unified-desktop --ash-host-window-bounds=400x400,410+0-800x800*2 --mus
[253647:253647:0123/101815.898770:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 399,100 399,100
[253647:253647:0123/101815.898812:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 399,100 399,100
[253647:253647:0123/101817.232882:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 0,50 400,50
[253647:253647:0123/101817.232931:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 400,50 400,50
[253647:253647:0123/101817.233685:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 200,25 400,50
[253647:253647:0123/101817.233715:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 400,50 400,50

Dragging a browser window across displays:
chrome --ash-enable-unified-desktop --ash-host-window-bounds=400x400,410+0-800x800*2 --mus
[256049:256049:0123/102419.948173:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 95,6 399,100
[256049:256049:0123/102419.948201:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 399,100 399,100
[256049:256049:0123/102419.948486:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 106,106 410,200
[256049:256049:0123/102419.948503:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 410,200 410,200
[256049:256049:0123/102419.957842:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 84,-94 400,100
[256049:256049:0123/102419.957870:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 400,100 400,100
[256049:256049:0123/102419.958642:ERROR:ash_window_tree_host_mus_unified.cc(44)] MSW FindTargetForEvent A 104,106 410,200
[256049:256049:0123/102419.958660:ERROR:ash_window_tree_host_mus_unified.cc(46)] MSW FindTargetForEvent B 410,200 410,200

Weirdly, I'm now seeing reasonable behavior dragging across displays on --mus, but *not* in cash...
Mus's window's translation stays smooth during the drag, it doesn't jump around when crossing displays.
The only mus defect I notice is that the cursor on the second display is just the 1x system cursor, not a 2x virtual cursor.
Cash's window dragging jumps back to the left end of the display when dragging right to the second display.
I wonder if something is different between local linux-desktop chrome os usage and my current usage over chrome remote desktop.

Here's the corresponding logging I get when hovering and dragging across displays in cash unified:

Just hovering (I also see a spurious event with a wrong x-coord here):
chrome --ash-enable-unified-desktop --ash-host-window-bounds=400x400,410+0-800x800*2
[256762:256762:0123/102939.574376:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 399,100 399,100
[256762:256762:0123/102939.574401:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 399,100 399,100
[256762:256762:0123/102939.574669:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 400,100 400,100
[256762:256762:0123/102939.574692:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 400,100 400,100
[256762:256762:0123/102939.575147:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 0,100 0,100
[256762:256762:0123/102939.575170:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 0,100 0,100
[256762:256762:0123/102939.575343:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 400,100 400,100
[256762:256762:0123/102939.575362:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 400,100 400,100
[256762:256762:0123/102939.575695:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 400,100 400,100
[256762:256762:0123/102939.575717:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 400,100 400,100
[256762:256762:0123/102939.605149:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 799,100 799,100
[256762:256762:0123/102939.605191:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 799,100 799,100
[256762:256762:0123/102945.707738:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 400,50 400,50
[256762:256762:0123/102945.707783:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 400,50 400,50

Dragging a browser window across displays:
chrome --ash-enable-unified-desktop --ash-host-window-bounds=400x400,410+0-800x800*2
[256762:256762:0123/103308.175965:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 399,100 399,100
[256762:256762:0123/103308.175984:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 399,100 399,100
[256762:256762:0123/103308.176271:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 0,100 0,100
[256762:256762:0123/103308.176288:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 0,100 0,100
[256762:256762:0123/103308.210344:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 400,100 400,100
[256762:256762:0123/103308.210386:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 400,100 400,100
...
[256762:256762:0123/103312.277175:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 408,100 408,100
[256762:256762:0123/103312.277210:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 408,100 408,100
[256762:256762:0123/103312.332749:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 0,50 0,50
[256762:256762:0123/103312.332787:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 0,50 0,50
...
[256762:256762:0123/103314.430955:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 1,50 1,50
[256762:256762:0123/103314.430982:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 1,50 1,50
[256762:256762:0123/103314.431242:ERROR:ash_window_tree_host_unified.cc(38)] MSW FindTargetForEvent A 401,50 401,50
[256762:256762:0123/103314.431265:ERROR:ash_window_tree_host_unified.cc(41)] MSW FindTargetForEvent B 401,50 401,50

Maybe I'll look into the cursor appearance for now.

Comment 5 by msw@chromium.org, Jan 23 2018

Scott, I can't actually see the defect you're describing in comment #3.
I modified WorkspaceWindowResizer::kScreenEdgeInset to 0 and rebuilt.
Both sides of the window appear to touch the top edge correctly.

Comment 6 by osh...@chromium.org, Jan 23 2018

Cc: afakhry@chromium.org
just fyi: the drag behavior on desktop may not be same as one on the device due to the passive grab implementation bug. crbug.com/773348. 

Comment 7 by msw@chromium.org, Jan 24 2018

Components: UI>Shell>MultipleMonitor

Comment 8 by msw@chromium.org, Jan 24 2018

Cc: msw@chromium.org
Owner: sky@chromium.org
Scott has a fix in flight! https://chromium-review.googlesource.com/c/chromium/src/+/884569
I split out the other remaining defects from my original report:
-mus: Touch event locations incorrect for unified display mode  crbug.com/805714  
-mus: Software and hardware cursor overlap in unified mode  crbug.com/805719  
Project Member

Comment 9 by bugdroid1@chromium.org, Jan 25 2018

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

commit 84b41dc990a9810ae67a3f6583faadf72422fdb0
Author: Scott Violet <sky@chromium.org>
Date: Thu Jan 25 06:24:57 2018

window-service: don't do a grab when in unified mode

Classic ash doesn't do grabs when in unified mode. For compatibility
this patch makes the window-service not execute a grab when in unified
mode. To execute a grab leads to ash doing the wrong event conversion.

BUG= 804460 ,773348
TEST=covered by test

Change-Id: I6d402ec4eb5d68946f98757cc4a56e850bd1e8b0
Reviewed-on: https://chromium-review.googlesource.com/884569
Commit-Queue: Scott Violet <sky@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531828}
[modify] https://crrev.com/84b41dc990a9810ae67a3f6583faadf72422fdb0/services/ui/ws/display_manager.cc
[modify] https://crrev.com/84b41dc990a9810ae67a3f6583faadf72422fdb0/services/ui/ws/display_manager.h
[modify] https://crrev.com/84b41dc990a9810ae67a3f6583faadf72422fdb0/services/ui/ws/test_utils.cc
[modify] https://crrev.com/84b41dc990a9810ae67a3f6583faadf72422fdb0/services/ui/ws/test_utils.h
[modify] https://crrev.com/84b41dc990a9810ae67a3f6583faadf72422fdb0/services/ui/ws/window_manager_state.cc
[modify] https://crrev.com/84b41dc990a9810ae67a3f6583faadf72422fdb0/services/ui/ws/window_manager_state_unittest.cc

Comment 10 by msw@chromium.org, Jan 25 2018

Status: Fixed (was: Started)
Marking this fixed with your patch, thanks!
Components: -Internals>MUS Internals>Services>WindowService
Components: -MUS

Sign in to add a comment