Fixed parts of page flickers when scroll to top of page
Reported by
mshipo...@gmail.com,
Apr 14 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36 Example URL: http://192.168.88.77:8085/section_by_employee Steps to reproduce the problem: There is some preparation steps to reach the right page: 1. Open the page at address http://91.194.53.45:8873. 2. Logon with login: admin and password: admin. 3. Click the "Reports" tab in the top left corner and then click "Timeline". 4. There is mode selection button appear, from the right side of time filter button (that is under top panel). In this mode selector select "By days". 5. In the time filter select interval from 1 April to 30 April. 6. Now we on right page Steps to reproduce: 1. Scroll to the bottom of page 2. Then by single move of wheel scroll to almost the top of page. One wheel move should rest before top reached. 3. Then scroll to top. What is the expected behavior? Nothing should flicker What went wrong? Fixed left navigation panel, top navigation panel and panel under top navigation panel are all flickers Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 49.0.2623.112 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0 When change filter to 1 April - 1 May problem dissapears When change the height of rows in table it dissapears also. Think it depends on content height. Each row in second column contains canvas element. When change those canvas display to none problem also dissappears. My screen resolution 1920x1200, windo size in browser - 1903x1099 but problem seen in fullscreen mode also
,
Apr 14 2016
sorry, url is http://91.194.253.45:8873/section_by_employee
,
Apr 15 2016
Was able to reproduce after scrolling up and down many times. (attached video) Looks like occasionally the entire page including position:fixed elements get scrolled, causing the entire page to be redrawn. Maybe the compositor is scrolling by mistake?
,
Apr 15 2016
Hey keishi@, I wasn't able to reproduce the issue on my corp-issued Linux workstation nor on Chromebook Pixel. I don't have a windows machine at hand. Will try after I got home. What's the configuration you used? The mouse cursor and scrollbar looked like a low-DPI Mac. Could you post your chrome://gpu ? It'd be great if you could upload a short Frame Viewer trace using chrome://tracing that would certainly help diagnosing the issue. Thanks!
,
Apr 18 2016
Unable to access the link "http://192.168.88.77:8085/section_by_employee" from my end. It displays error saying "You do not have access to the requested resource". Could anyone please provide the access for this link, It will be helpful to check this issue from QA end and to provide the bisect information. Thanks!
,
Apr 18 2016
My mistake, brajkumar@. Correct url is http://91.194.253.45:8873/section_by_employee
,
Apr 18 2016
Reporter corrects the url in Comment 2. The url is "http://91.194.253.45:8873/section_by_employee" repro steps: 1. Open the page at address http://91.194.253.45:8873/section_by_employee 2. login with login: admin and password: admin 3. scroll up/down vigorously using mouse wheel I reproduced on Mac Version 52.0.2710.0 canary (64-bit) low DPI (corp Mac pro) I'm attaching the frame viewer trace file, screen recording while taking the trace, and my chrome://gpu output.
,
Apr 19 2016
I made a minimal test case for this. See test1.html I uploaded. It can be reproduced on every low-DPI devices or high-DPI devices with --disable-prefer-compositing-to-lcd-text. The bug happens on the first or second frame right after a fixed position element loses its backing. I don't know exactly why. It feels to me there may be a short gap between the backing loss and updating main thread scrolling reason. Note: --enable-prefer-compositing-to-lcd-text makes fixed position elements to be always composited, thus the bug doesn't manifest.
,
Apr 26 2016
I'll shutdown the server http://91.194.253.45:8873/. Write me, if it will required later
,
May 10 2018
The bug no longer reproduces with the #c8 test case. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ashej...@chromium.org
, Apr 14 2016