Issue metadata
Sign in to add a comment
|
Scroll event fired when no scrolling was done under certain RTL circumstances. Works OK in 64 and under. Introduced in 65. Full tests inside.
Reported by
jonathan...@gmail.com,
Dec 16
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Steps to reproduce the problem: 1. Open latest Chrome (71) 2. Open DevTools, change docking to floating window 3. Change Chrome window size to 449 width, 655 height (During my research I noticed this is size related and this test size just kind of stuck with the process. Can probably be reproduced regardless of size). 4. Go to this link showing the problem with RTL turned on: https://output.jsbin.com/kopigacixu/1 5. Wait 4 seconds for timeout, this will show the first blue DIV that appears on the right because of RTL 6. Console shows "scroll event???" indicating there was a scroll event on the red DIV. 7. Try again with LTR sample (RTL direction is commented out in the first lines): https://output.jsbin.com/higikowoya/1 8. Scroll event is not fired when the wrapper is LTR. 9. Retry steps 1-8 with Chromium 64.0.3282.0 (r520834) and Chromium 65.0.3325.0 (r530358) and see that the problem was introduced in Chromium 65. 10. I retried all the steps on a Mac, too. Same result. What is the expected behavior? Scroll event should not fire on the second (red) DIV What went wrong? Scroll event was fired on the second (red) DIV Did this work before? Yes 64.0.3282.0 (r520834) Does this work in other browsers? Yes Chrome version: Chrome/71.0.3578.98 Channel: stable OS Version: 10.0 Flash Version: Hi, Source files are also available here: https://jsbin.com/kopigacixu/edit (RTL - event bug) https://jsbin.com/higikowoya/edit (LTR - no bug) During a search for an existing bug I reached to the following link which may be related, I'm not sure: https://bugs.chromium.org/p/chromium/issues/detail?id=910914&q=rtl%20scroll&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified This reduced test case is a result of research done on a Sencha project. I went deep inside Sencha code to isolate the issue, which was not easy... so I'm posting this here to wrap up my research and help any other devs out there who are facing a similar issue. The new scroll event caused a chain reaction in the application which ended in an application freeze, affecting users in production environments. I instructed the users of the app to reset their Android to factory settings (back to Chrome/WebView 61) and to disable their automatic updates until I can provide them with a fix. The new behavior in Chromium 65 may work as intended due to fixes or additions to 65, but it's definitely different from version 64, which I think shouldn't happen without a deprecation warning. I hope this is indeed something that needs fixing in Chromium, because I'm really not enthusiastic about changing Sencha's code... It's Sencha Touch, no longer supported. Thanks for reading, let me know if you need more info. Jonathan
,
Dec 16
jsbin.com appears to have a limit on these files. Just use the attached HTML file to reproduce. Comment out direction:rtl in .wrappedDir class to switch to non-buggy LTR
,
Dec 16
Bisect info: 523656 (good) - 523659 (bad) https://chromium.googlesource.com/chromium/src/+log/982457e6..9631babb?pretty=fuller Suspecting r523659 = 9631babbfaf4563f9b8385b13827476b175d76cb = https://crrev.com/c/811889 by szager@chromium.org "Fix rounding of overflow rect location when setting scroll origin" Landed in 65.0.3294.0 Simplified repro: 1. open the attached test.html 2. click the button inside - it'll open a new small window Expected: "GOOD" is shown Observed: "BAD" is shown
,
Dec 16
,
Dec 17
jonathan.carse@ Thanks for the issue. Able to reproduce this issue on Windows 10, Ubuntu 17.10 on the latest Stable 71.0.3578.98 and latest Canary 73.0.3642.0 as per comment #4. On Mac OS , unable to reproduce the issue as on clicking the button inside the html, Good/Bad window is not shown. The same Button window is popping up. Attached is the screen shot for reference. Bisect Information: ==================== Good Build: 65.0.3293.0 Bad Build : 65.0.3294.0 As per comment #4, suspecting the below Change. Reviewed-on: https://chromium-review.googlesource.com/811889 szager@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Thanks...
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1d101abd42d9d4fca49bc7328d0c934ddc392a9a commit 1d101abd42d9d4fca49bc7328d0c934ddc392a9a Author: Stefan Zager <szager@chromium.org> Date: Thu Dec 20 18:29:59 2018 Snap scroll origin towards beginning of content With the existing snapping code, it's possible that an RTL block with non-pixel-aligned size will have a MaximumScrollOffset which is -1 instead of zero. The resulting geometry is entirely self-consistent and not web visible, but it can cause a spurious scroll event to be fired when clamping the scroll offset in response to a style/layout change. BUG= 915503 Change-Id: Ib760cecb3e14cc9b675ee0769139bb65c3ecb30f Reviewed-on: https://chromium-review.googlesource.com/c/1382867 Reviewed-by: Steve Kobes <skobes@chromium.org> Commit-Queue: Stefan Zager <szager@chromium.org> Cr-Commit-Position: refs/heads/master@{#618277} [modify] https://crrev.com/1d101abd42d9d4fca49bc7328d0c934ddc392a9a/third_party/blink/renderer/core/paint/paint_layer_scrollable_area.cc [modify] https://crrev.com/1d101abd42d9d4fca49bc7328d0c934ddc392a9a/third_party/blink/renderer/core/paint/paint_layer_scrollable_area_test.cc [modify] https://crrev.com/1d101abd42d9d4fca49bc7328d0c934ddc392a9a/third_party/blink/web_tests/external/wpt/2dcontext/scroll/2d.scrollPathIntoView.verticalRL-expected.txt [modify] https://crrev.com/1d101abd42d9d4fca49bc7328d0c934ddc392a9a/third_party/blink/web_tests/platform/mac/fast/dom/rtl-scroll-to-leftmost-and-resize-expected.png
,
Dec 20
This should be fixed, but it probably won't appear in a dev channel release until early January.
,
Dec 21
Much appreciated Stefan. I will probably instruct clients to install a future beta version that contains your fix. Have a happy new year. Jonathan |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jonathan...@gmail.com
, Dec 16