Issue metadata
Sign in to add a comment
|
Scrolling left with touchpad in zoomed in pdf triggers going back in history
Reported by
mkumail....@gmail.com,
Feb 21 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Open a pdf (e.g. https://arxiv.org/pdf/1611.02167.pdf) with something in the current tab's history 2. Zoom in so that there is horizontal overflow 3. Try scrolling to the left with the touchpad What is the expected behavior? The browser should scroll the document to the left until there is no more room on the left. Only then should it go back in history. What went wrong? Instead, the browser goes back in history Did this work before? Yes Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.11.5 Flash Version:
,
Feb 22 2017
Unable to reproduce the issue on Mac 10.12.3 using chrome version 56.0.2924.87 with the below steps 1.Opened the PDF https://arxiv.org/pdf/1611.02167.pdf 2.Zoomed in to 250% to get horizontal overflow 3.Try scrolling 4.Able to scroll without any issues. Please find the attached screen cast and confirm if anything missed here in triaging the issue. Thanks,
,
Feb 23 2017
I can reproduce this. It looks like if we hit the horizontal extent we go straight into a gesture nav, rather than rubber banding until a new gesture activates the navigation. I'm suspecting something out-of-process related here. James loves PDF scrolling issues, mind taking a look? :)
,
Mar 1 2017
Right now rubber-banding is broken on Mac for WebView: https://bugs.chromium.org/p/chromium/issues/detail?id=628742 I'm going to guess that's related to this bug, but I won't mark them as dups just yet.
,
Mar 6 2017
,
Mar 7 2017
I can also reproduce this on chrome os with both the touchscreen and trackpad.
,
Apr 13 2017
,
May 15 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bf5beebbd5dea348bda215061cea04289d86e9f1 commit bf5beebbd5dea348bda215061cea04289d86e9f1 Author: mcnee <mcnee@chromium.org> Date: Mon May 15 16:47:20 2017 Don't drop mouse wheel events with phase ending information in RWHVCF. Currently, RenderWidgetHostViewChildFrame::ProcessMouseWheelEvent drops mouse wheel events that have deltas of 0. However, we may see mouse wheel events carrying phase ending information that have deltas of 0. When these are dropped, MouseWheelEventQueue is not informed that the user's gesture has ended. So when it sees subsequent wheel events, it considers them all part of the same gesture. By allowing events with phase ending information through, MouseWheelEventQueue is able to properly start and end gesture scrolls. BUG= 694393 , 628742 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2866523002 Cr-Commit-Position: refs/heads/master@{#471797} [modify] https://crrev.com/bf5beebbd5dea348bda215061cea04289d86e9f1/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/bf5beebbd5dea348bda215061cea04289d86e9f1/content/browser/site_per_process_mac_browsertest.mm
,
May 23 2017
OverscrollController does not do gesture-nav if the scroll-begin event is consumed, right? And events that go to the plugin are marked as consumed, as far as I remember. So can you explain why we get the gesture-nav in the reported cases? (i.e. the stream of events that OverscrollController sees that triggers the gesture-nav?)
,
May 23 2017
Gesture/touch events go directly to the guest, and not to the plugin in the embedder.
,
May 23 2017
OverscrollController is looking for consumed GestureScrollUpdates to prevent the gesture-nav: https://cs.chromium.org/chromium/src/content/browser/renderer_host/overscroll_controller.cc?l=157 Consumed GestureScrollUpdates in the guest are not resent to the embedder, so OverscrollController doesn't see them. Once the guest stops consuming GestureScrollUpdates, it will start resending the unconsumed GestureScrollUpdates, which the OverscrollController will see.
,
Jun 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb commit 19fd249f2bd7f2a7ebf6f26a365119ac71e694cb Author: mcnee <mcnee@chromium.org> Date: Thu Jun 01 14:42:43 2017 Notify OverscrollController of gesture events in plugins. RenderWidgetHostViewGuest resends unconsumed GestureScrollUpdates to its embedder (via BrowserPluginGuest::ResendEventToEmbedder) which are then individually wrapped by RenderWidgetHostImpl with GestureScrollBegins and GestureScrollEnds. Hence OverscrollController (a) sees a GestureScrollEnd immediately following every GestureScrollUpdate and ends the overscroll gesture, and (b) does not see GestureScrollUpdates consumed by the plugin, so OverscrollController starts an overscroll gesture even though the content of the plugin was scrolled. Also, OverscrollController does not have a chance to filter the plugin's gesture events, so even if an overscroll gesture has started, the plugin can start consuming scroll updates again. We now notify OverscrollController (as well as the Mac history swiper) of the ACKed gesture events from the plugin, so that it can update its state correctly and allow it to filter the gesture events of the plugin. They also ignore the wrapper GestureScrollBegins and GestureScrollEnds as they do not indicate the beginning/end of the user's gesture. Note that OOPIF-based guests do not use this resending logic. They instead rely on RenderWidgetHostViewChildFrame's scroll bubbling logic. Ensuring this is correct w.r.t. overscroll is being tracked in crbug.com/713368 . BUG= 694393 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation Review-Url: https://codereview.chromium.org/2815823003 Cr-Commit-Position: refs/heads/master@{#476282} [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/chrome/browser/apps/guest_view/web_view_browsertest.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/chrome/browser/renderer_host/chrome_render_widget_host_view_mac_history_swiper.mm [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/frame_host/render_widget_host_view_child_frame.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/frame_host/render_widget_host_view_child_frame.h [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/frame_host/render_widget_host_view_guest.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/frame_host/render_widget_host_view_guest.h [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/renderer_host/overscroll_controller.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/renderer_host/overscroll_controller.h [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/renderer_host/render_widget_host_view_aura.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/renderer_host/render_widget_host_view_aura.h [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/renderer_host/render_widget_host_view_base.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/browser/renderer_host/render_widget_host_view_base.h [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/public/test/browser_test_utils.cc [modify] https://crrev.com/19fd249f2bd7f2a7ebf6f26a365119ac71e694cb/content/public/test/browser_test_utils.h
,
Jun 5 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by lgrey@chromium.org
, Feb 21 2017