New issue
Advanced search Search tips

Issue 901540 link

Starred by 1 user

Issue metadata

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

Blocking:
issue 890071



Sign in to add a comment

TabDragController sees 1-frame older touch location when dragging with touch

Project Member Reported by mukai@chromium.org, Nov 2

Issue description

TabDragging/DetachToBrowserTabDragControllerTest.DragToSeparateWindow/1 is still failing with SingleProcessMash.
 
Summary: TabDragController sees 1-frame older touch location when dragging with touch (was: TabDragging/DetachToBrowserTabDragControllerTest.DragToSeparateWindow/1 is failing with SingleProcessMash)
Basically this is because of the timing of the touch event location.

When the window moves with tab-dragging;
- window move happens within Ash, input events are not sent to the browser
- the move causes OnBoundsChanged(), which is delivered to the browser. TabDragController watches the bounds change and updates its dragging state.
- TabDragController also registers the update of the touch location through EventObserver (ws::mojom::ObserveEventTypes)

However, looking into the details, the bounds change happens *before* the observed event is sent to the browser. This means, when TabDragController wants to handle updates of dragging state upon OnBoundsChanged, it does not see the actually latest location of the touch. It will see 1-frame old location.

This is typically not a huge problem and maybe not user-noticeable since touch location moves continuously. But some tests like DragToSeparateWindow jumps the location, so referring old location actually causes an unexpected behavior.
Labels: Pri-2
Project Member

Comment 3 by bugdroid1@chromium.org, Nov 7

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

commit bfc78a0a51d3bb81ca3b5464899c14c8be38e5e1
Author: Jun Mukai <mukai@chromium.org>
Date: Wed Nov 07 01:38:52 2018

Fix the last touch point in Mus

Currently GestureRecognizerImplMus recceives the last touch point
location through ui::EventObserver (which is supplied through
ObserveEventTypes() mojo call). However, during window move, this
can be late since the OnObservedInputEvent will be called after
processing other event handlings in the window server.

As is written in the bug, if the client observes through
OnBoundsChanged(), this bounds change happens in the client before
OnObservedInputEvent. This results with GetLastTouchPointForTarget
returning 1-frame older location. This isn't quite observable
on normal user operation but has significant differences on test
scenario.

Instead of observing the input, it can simply remember the offset
of the touch location when the window move starts.

BUG= 901540 
TEST=see the filter update

Change-Id: I84bf19d9b705ec582b5359383a914b19c506adf9
Reviewed-on: https://chromium-review.googlesource.com/c/1321257
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Jun Mukai <mukai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605921}
[modify] https://crrev.com/bfc78a0a51d3bb81ca3b5464899c14c8be38e5e1/testing/buildbot/filters/chromeos.single_process_mash.interactive_ui_tests.filter
[modify] https://crrev.com/bfc78a0a51d3bb81ca3b5464899c14c8be38e5e1/ui/aura/mus/gesture_recognizer_impl_mus.cc
[modify] https://crrev.com/bfc78a0a51d3bb81ca3b5464899c14c8be38e5e1/ui/aura/mus/gesture_recognizer_impl_mus.h

Status: Fixed (was: Started)

Sign in to add a comment