Regression: PDF viewer interface does not hide when cursor moved outside window
Reported by
anowlcal...@gmail.com,
Apr 21 2018
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36 Steps to reproduce the problem: 1. Open a PDF in Chrome 2. Leave the cursor still in the middle of the window for a few seconds; observe that the UI (file name, page number, zoom buttons, etc.) gets hidden, and comes back if the cursor is moved near the edge of the window 3. Move the cursor out of the window via the top edge; observe that the UI does not hide itself any more What is the expected behavior? When the PDF UI is not being interacted with, it should go away. What went wrong? If the cursor isn't in within the page boundaries, the PDF UI won't ever hide itself. Did this work before? Yes probably M65, but M64 for sure Chrome version: 66.0.3359.117 Channel: stable OS Version: Ubuntu 16.04.4 Flash Version:
,
Apr 23 2018
Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 14.04 using chrome reported version #66.0.3359.117 and latest canary #68.0.3404.0. Bisect Information: ===================== Good build: 65.0.3303.0 Bad Build : 65.0.3304.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/d37a9f10c7e32ff40e864a2ff30478fc8a0a1169..8e8ae37d2e02943cadb4d658777866e8e4a12f60 From the above change log suspecting below change hange-Id: I55a75f9d69136731af96b2bf292c0f361fa729c4 Reviewed-on: https://chromium-review.googlesource.com/838626 sadrul@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks...!!
,
Apr 30 2018
Since this is a recent regression and also have a clear suspect. Please have a fix during M68 time frame.
,
Apr 30 2018
I suspect this is fixed. But not sure. --> kenrb@ and wjmaclean@
,
May 4 2018
,
May 7 2018
*** Bulk Edit *** M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.
,
May 7 2018
This doesn't appear to be fixed on version 68.0.3424.0 from https://download-chromium.appspot.com.
,
May 7 2018
Re #7 ... I had noticed that. I'll try and dig into this a bit since I'm familiar with the codepaths for this.
,
May 8 2018
So this seems to be happening because the handler for mouseMove is firing after the handler for mouseOut. In pdf/toolbar_manager.js, the mouseOut event is used to reset two flags, isMouseNearTopToolbar and isMouseNearSideToolbar, to be false. Then a timer is set, and when it times out it invokes the hiding mechanism. But the hiding mechanism checks these state vars again, and only hides if they're true. Since the mouseMove happens after the mouseOut, if you drag the mouse out through the top of the window then isMouseNearTopToolbar has been set to true, and this causes the hiding timout to early out without hiding. It seems that mouseMove often doesn't set isMouseNearSideToolbar if you exit via the right side, but if you move the mouse slowly, you can create the same situation where the toolbars don't hide by exiting the window via the right side. I don't know if the ordering of mouseMove/mouseOut has somehow changed or not.
,
May 8 2018
,
May 8 2018
I'm trying to track this down, but reproducing it is somewhat inconsistent.
,
May 8 2018
I have a fix running on the trybots
,
May 9 2018
Since this is regressed in M65 & M66, considering not a blocker for M67.
,
May 9 2018
Sure thing. But, that being said, there is now a fix, and it looks mergeable, if you think it's worth it. But it's not a high priority issue.
,
May 9 2018
Thank you wjmaclean@. Lets wait until M68. Thank you.
,
May 10 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e commit 4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e Author: W. James MacLean <wjmaclean@chromium.org> Date: Thu May 10 15:57:52 2018 Fix MouseLeave for BP-based guests. The MouseEnter/Leave logic in RenderWidgetHostInputEventRouter expects child frames to return a non-null GetParentView(), but children that are RenderWidgetHostViewGuests currently return null, causing the logic to fail. This CL fixes that. Bug: 835566 Change-Id: I0792772872e10134f4c79b8f929bc4271543f00e Reviewed-on: https://chromium-review.googlesource.com/1050613 Reviewed-by: Ken Buchanan <kenrb@chromium.org> Reviewed-by: Charlie Reis <creis@chromium.org> Reviewed-by: dsinclair <dsinclair@chromium.org> Commit-Queue: James MacLean <wjmaclean@chromium.org> Cr-Commit-Position: refs/heads/master@{#557538} [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/chrome/browser/pdf/pdf_extension_test.cc [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/content/browser/frame_host/render_widget_host_view_guest.cc [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/content/browser/frame_host/render_widget_host_view_guest.h [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/content/browser/renderer_host/render_widget_host_view_child_frame.h [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/content/public/test/browser_test_utils.cc [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/content/public/test/browser_test_utils.h [modify] https://crrev.com/4263cfccd50ca0fe62d61caa5a67fb71c6e3a61e/testing/buildbot/filters/viz.browser_tests.filter
,
May 10 2018
This should be fixed now on ToT. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by susan.boorgula@chromium.org
, Apr 22 2018Labels: Needs-Bisect Needs-Triage-M66