Created attachment 325580 [details] Screen capture video showing the buggy behavior Reproduction steps: 1. Load a page that uses -webkit-scrollbar, e.g. http://w3c-test.org/visual-viewport/viewport-dimensions-custom-scrollbars-manual.html Notice that the custom vertical and horizontal scrollbars touch at the corner 2. Press Ctrl/+ several times. Notice a gap appearing between the corners of the vertical and horizontal scrollbars 3. Press Ctrl/- once. Notice that the scrollbars are not touching at the corner, but a gap appears between each scrollbar and the respective page edge. 4. Press Ctrl/- a few more times. Notice that the edge gaps persist. 5. Press Ctrl/+ once. Notice that the edge gaps disappear, but the corner gap reappears.
Does this affect real sites?
<rdar://problem/35296527>
The impact on real websites is probably not too large. I spent 30 minutes digging through URLs from HTTPArchive that use -webkit-scrollbar, and only found one website where the problem is somewhat visible: http://www.toixemphim.net/p/lich-phim.html Even in this case, I'd have to zoom in to see the buggy behavior. Movie attached. HTTPArchive data reports ~3% CSS files out there in the wild uses this prefix. But it's hard to tell whether that translate into user visible impact. From the small sample size of ~100 URLs I looked at, it seems that either the style is not applied to the main element, so this bug is not manifesting, or the scrollbar is so small the effect of the bug is minimal. I wish we have better tools to know when custom scrollbar is actually rendered. Just a wild question: would you consider deprecating support for webkit-scrollbar? Most mainstream sites don't seem to use it anyways...
Created attachment 325912 [details] Buggy behavior on a real website
If you can get gmail off of it, sure :) It's also used on neatorama.com.
Some sites also use it to hide the scrollbar (esp. with -webkit-overflow-scrolling: touch) so we'd need new CSS to do that.