Issue metadata
Sign in to add a comment
|
table rows paint backgrounds incorrectly with scroll after window resize (codepen included)
Reported by
scott.so...@gmail.com,
Apr 18 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: 1. https://codepen.io/darkmarmot/pen/vmNdrr 2. resize window to reduce size of table 3. scroll and see paint defects What is the expected behavior? row backgrounds paint normally What went wrong? see link: https://codepen.io/darkmarmot/pen/vmNdrr Did this work before? N/A Does this work in other browsers? Yes Chrome version: 57.0.2987.133 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 25.0 r0 in my full build, the bug is worsened by javascript it seems, and the row backgrounds can scroll INDEPENDENTLY of their content -- which looks crazy.
,
Apr 19 2017
Unable to reproduce the issue on Mac 10.12.4 & Ubuntu 14.04 using chrome reported version-57.0.2987.133 & latest Canary-60.0.3074.0 as per the steps mentioned in comment#0. Observed no row backgrounds can scroll INDEPENDENTLY of their content after resize. Please find the attached screencast for reference. If possible could you please provide us the screencast of the issue for further investigation. Thanks in advance...!!
,
Apr 19 2017
I've attached a brief screencast -- when the codepen loads and you scroll -- the backgrounds do not appear on rows until you mouse over them. Small rendering issues occur in the row colors from that point forward. The independent scrolling occurs only in my full app with Javascript added to the mix -- the codepen is intentionally simple and without JS. I upgraded to OSX 10.12 to see if that changed the behavior, but it's still the same. Thanks, Scott
,
Apr 19 2017
Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 19 2017
I've also verified this behavior now on multiple OSX computers (so not just my laptop).
,
Apr 19 2017
What are the system scrollbar preferences on the machines you are testing on? In my testing they definitely make a difference. With scrollbars always on things mostly look OK. With scrollbars when scrolling, the scrollbar appearance changes, and there is a sometimes an under-painted area where the scrollbar should be. I only see the effect in comment #5 with Chrome M-58. We have apparently fixed it for M-60. I don't think we will attempt to merge any changes back, even if we knew what was causing this. Could you please download Chrome Canary and verify that the problem is not occuring there?
,
Apr 19 2017
I had scrollbars on 'always' during those demos. But -- Canary looks to fix almost everything! It has one issue which might actually be fixing a different issue -- see attached photo. I was using linear-gradients on my table row backgrounds. This only worked with the css style 'background-attachment: fixed' applied. It looks like this now screws up the display, but removing that hack makes things work exactly as expected! Thanks so much -- you guys are fast! :) Take care, Scott S.
,
Apr 19 2017
Thank you for providing more feedback. Adding requester "schenney@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 20 2017
As per the comment#8, closing this issue. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by scott.so...@gmail.com
, Apr 18 2017