| Summary: | [Chromium] Overlay scrollbars leave glitches on web content | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Sailesh Agrawal <sail> | ||||||||
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | eric, jamesr, mihaip, thakis, webkit.review.bot | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | Mac | ||||||||||
| OS: | Unspecified | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Sailesh Agrawal
2011-06-09 10:22:48 PDT
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. |