Bug 97927

Summary: Some non-scrollable elements are added to non-fast-scrollable region
Product: WebKit Reporter: Sami Kyöstilä <skyostil>
Component: Layout and RenderingAssignee: Sami Kyöstilä <skyostil>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, jamesr, simon.fraser, tonikitoo, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
URL: http://subtlepatterns.com
Bug Depends on: 103999    
Bug Blocks:    
Attachments:
Description Flags
Patch none

Sami Kyöstilä
Reported 2012-09-28 12:04:06 PDT
For example, RenderBox::canBeScrolledAndHasScrollableArea() returns true if horizontal overflow is hidden, vertical overflow is auto, but the scrolling content only extends beyond the client box horizontally. In this case the RenderBox isn't actually scrollable (except by setting scrollLeft/Top from JavaScript) because overflow is hidden on the only free axis. An example site where this happens is http://subtlepatterns.com. The relevant bit of CSS is: @media only screen and (-webkit-min-device-pixel-ratio: 1.5), only screen and (-o-min-device-pixel-ratio: 3/2), only screen and (min--moz-device-pixel-ratio: 1.5), only screen and (min-device-pixel-ratio: 1.5) { html, body { width: 100%; overflow-x: hidden; } }
Attachments
Patch (5.21 KB, patch)
2012-10-01 10:28 PDT, Sami Kyöstilä 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Sami Kyöstilä
Comment 1 2012-10-01 08:03:02 PDT
Sorry, I wasn't very clear on what the actual problem is: we are sometimes adding non-scrollable things to the non-fast-scrollable region. For example the following page always falls back to slow scrolling: <!DOCTYPE html> <html> <head> <style> html, body { width: 100%; overflow-x: hidden; } </style> <head> <body> <p style="font-size: 500px">hello</p> </body> </html>
Sami Kyöstilä
Comment 2 2012-10-01 10:28:22 PDT
Created attachment 166500 [details] Patch
Sami Kyöstilä
Comment 3 2012-10-05 07:57:59 PDT
Seems like this is related to bug 17488. If we made overflow-x: hidden not imply overflow-y: auto then this issue would also be fixed. But is that a change we want to make?
James Robinson
Comment 4 2012-10-08 15:06:44 PDT
Comment on attachment 166500 [details] Patch R=me.
WebKit Review Bot
Comment 5 2012-10-08 15:15:40 PDT
Comment on attachment 166500 [details] Patch Clearing flags on attachment: 166500 Committed r130692: <http://trac.webkit.org/changeset/130692>
WebKit Review Bot
Comment 6 2012-10-08 15:15:43 PDT
All reviewed patches have been landed. Closing bug.
Antonio Gomes
Comment 7 2012-10-09 09:47:44 PDT
RenderLayer::allowsScrolling is always false for the blackberry port, since we disable scrollbars creation at FrameView creation time. Not sure it is a valid fix.
James Robinson
Comment 8 2012-10-09 10:07:16 PDT
I think this patch is perfectly valid. You should patch allowsScrolling() for your non-standard scrollbar behavior.
Antonio Gomes
Comment 9 2012-10-10 06:45:27 PDT
(In reply to comment #8) > I think this patch is perfectly valid. You should patch allowsScrolling() for your non-standard scrollbar behavior. "For example, RenderBox::canBeScrolledAndHasScrollableArea() returns true if horizontal overflow is hidden, vertical overflow is auto, but the scrolling content only extends beyond the client box horizontally. " Another possibility is fixing the above. I've fixed it for BlackBerry already long ago. Will give it a try in WebCore See http://trac.webkit.org/browser/trunk/Source/WebKit/blackberry/Api/WebPage.cpp?rev=120861#L4652
Note You need to log in before you can comment on or make changes to this bug.