Scrolling a page with overlay scrollbars leaves trailing artifacts on web content. This needs to be fixed before overlay scrollbars are enabled.
Created attachment 97201 [details] Patch
This doesn't fix the root cause, any suggestions appreciated.
Created attachment 97213 [details] Patch
Comment on attachment 97213 [details] Patch don't set r? on work-in-progress patches
Comment on attachment 97213 [details] Patch How does the PLATFORM(MAC) port handle this in the non-composited case? Whatever the answer is here it does not belong in ScrollView.cpp
(In reply to comment #5) > (From update of attachment 97213 [details]) > How does the PLATFORM(MAC) port handle this in the non-composited case? I think that on PLATFORM(MAC) this is handled by the native host scroll view. Our RenderWidget just blindly copies the scrollrect even for overlay scrollbars. > Whatever the answer is here it does not belong in ScrollView.cpp What do you think of fixing this in RenderWidget. This would be a little more complicated because I'd have to pipe more information about scrollbars to RenderWidget.
sail: What was the file where you removed the ?: earlier today? Did that help?
(In reply to comment #7) > sail: What was the file where you removed the ?: earlier today? Did that help? That was in ScrollView.cpp ScrollView::rectToCopyOnScroll(). Changing it didn't help.
The mac port doesn't use platform widgets for scrolling in WebKit2
(In reply to comment #9) > The mac port doesn't use platform widgets for scrolling in WebKit2 Hm... how can I tell if I'm running Safar in composited or non-composited mode? Maybe they have this bug too.
Created attachment 97369 [details] Patch
(In reply to comment #9) > The mac port doesn't use platform widgets for scrolling in WebKit2 K, I think I got it. WebChromeClient::scroll() intersects the scroll rect with the clip rect. This excludes the scrollbars when overlay scrollbars are enabled. I'm running try bots now.
Try bot results look good. http://build.chromium.org/p/tryserver.chromium/builders/linux/builds/32264 http://build.chromium.org/p/tryserver.chromium/builders/mac/builds/32445 http://build.chromium.org/p/tryserver.chromium/builders/win/builds/37228
What about the layout tests trybots? (mac_layout, win_layout, linux_layout and the same with _rel for release).
(In reply to comment #14) > What about the layout tests trybots? (mac_layout, win_layout, linux_layout and the same with _rel for release). Damn, forgot. Layout try bots pending.
Hm.. a couple of webkit_gpu_tests failed. Not sure if it's my fault. I'm sending out a new layout try bot test with an empty change to check. http://build.chromium.org/p/tryserver.chromium/builders/mac_layout/builds/667 http://build.chromium.org/p/tryserver.chromium/builders/mac_layout_rel/builds/205 http://build.chromium.org/p/tryserver.chromium/builders/win_layout/builds/948 http://build.chromium.org/p/tryserver.chromium/builders/win_layout_rel/builds/289 http://build.chromium.org/p/tryserver.chromium/builders/linux_layout/builds/794 http://build.chromium.org/p/tryserver.chromium/builders/linux_layout_rel/builds/270
Yay, an empty change has the same failures: http://build.chromium.org/p/tryserver.chromium/builders/mac_layout_rel/builds/207
Comment on attachment 97369 [details] Patch Rubber-stamping since James is out.
Comment on attachment 97369 [details] Patch Clearing flags on attachment: 97369 Committed r89065: <http://trac.webkit.org/changeset/89065>
All reviewed patches have been landed. Closing bug.