New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

A page having overflow:hidden on its body can be scrolled with touch and touchpad when the events are handled on the fast path

Project Member Reported by, Feb 11 2013

Issue description

It should not be possible to scroll the attached page with either touch or touchpad because its body has overflow-y:hidden. But this has regressed since M23:

23.0.1271.110: touch and touchpad scrolling do NOT scroll the page
25.0.1364.58: touch and touchpad do scroll the page
26.0.1410.0 ToT: touch and touchpad do scroll the page

For this simple page, the scroll and mousewheel events are handled on the fast path (i.e., not in WebCore/page/EventHandler.cpp).

I am investigating similar incorrect scrolling behavior for events on the slow path in .
249 bytes View Download

Comment 1 by, Feb 11 2013

Labels: -Restrict-View-Google MStone-27
Since this changed in M25 and we haven't heard any complaints yet, I doubt it's a huge deal.  

I checked Chrome 25 on Mac and Safari 6.0.2 on Mac, and both also support scrolling this case.  There is a bunch of discussion about inconsistency between browsers.

I took a quick look at the relevent specs, and it's not clear to me (from a quick glance) what the specified behavior is.  Eg, see:  <body> is not a block element, so I think technically overflow doesn't apply to it.  Terry, do you see a similar problem applying overflow to <html>?  Do you have any concrete examples of sites doing this (for either fast or slow path)?


Comment 3 by, Feb 26 2013


Comment 4 by, Feb 26 2013

If you want to change back this behavior, the easiest way is probably to set a nonFastScrollableRegion encompassing the whole document when you see an "overflow: hidden" on the body.  Then all scroll gestures will go on the slow path, which it sounds like you've already fixed to behave as you want.
A nonFastScrollableRegion on the whole page may be a little overkill since it would prevent fast scrolling of other overflow elements. It seems like the problem is that we're setting the scrollable bit on the root scroll layer even though it isn't actually scrollable. The compositor then infers the page can be scrolled because that bit is set and the root contents layer is bigger than the viewport.

Probably we need to tell ScrollingCoordinator{Chromium} about overflow: hidden on the html element. Note that overflow hidden things can still be programmatically scrolled and we shouldn't break that.

Comment 6 by, Feb 26 2013

Sami's right, supporting fast scrolling of subframes is important in this use case.  Forget what I said about nonFastScrollableRegion, we should do it a more explicit way.

Comment 7 by, Feb 27 2013

Labels: -Pri-2 Pri-1 Feature-Ash-Gestures
Status: Assigned
This now affects the GSG (as it's scrolling has been improved to now happen on the fast path - see 174255).  Regardless of what the specs say the behavior should be, I think it's critical that (in priority order):

1) We behave identically on the slow and fast paths
2) We're consistent with previous behavior and behavior in other browsers

Given #1 and  issue 174255 , I think we should fix this not to scroll.  But it's worth digging a little to understand the extent of #2.  Eg. how did mousewheel scrolling behave for this scenario in M23?  

Comment 8 by, Feb 27 2013

Labels: Iteration-76
Labels: Iteration-77
Status: Started
Investigating if/when this regressed and how mousewheels behaved in previous versions.
Status: Assigned
Testing with the attached non-scrollable-body.html shows a regression from behavior in M23, even when overflow-y:hidden is replaced by overflow:hidden:

23.0.1271.110 - touch and mousewheels do NOT scroll the page
25.0.1364.58 - touch and mousewheels both scroll the page
27.0.1430.0 ToT - touch and mousewheels both scroll the page

In M27, pages having overflow:hidden on their body will not scroll if the gesture/mousewheel events are handled on the slow path due to landing. This patch will also be DIed to 26 shortly (see

@aelias, since this is a bug for fast-path event handling, I am handing it over to you.

@aelias and @rbyers, should this be marked as a 26 stable-blocker? If the fix for this does not make it into 26 then we will have inconsistent scrolling behavior between the slow and fast paths in 26.
I hate any difference between fast and slow paths (since web developers generally can't be expected to reason about which path they're on).  But I think this is a bit of a corner case, and without a concrete site having problems I can't justify a merge request (especially since 25 is shipping this way regardless).

Thanks for the investigation Terry.
I don't have the spare cycles to work on this, sorry.
Status: Started
Project Member

Comment 15 by, Mar 9 2013

Labels: -Type-Regression -Area-WebKit -MStone-27 -Feature-Ash-Gestures Cr-Content Type-Bug-Regression Cr-UI-Shell-Gestures M-27
Status: Assigned
The reason this bug might pose a real problem for M27 is that some pages (like ChromeOS's getting started guide) are now getting fast-path scrolling and so can be broken by this bug when they worked fine in M26.

Talking with wjmaclean, rjkroege and tdanderson it sounds like there are a number of options but they're probably all ones that will get push back in review.  Since we'll be branching for M27 soon, I think someone on the compositor team needs to take the lead on determining the correct approach here if it's going to get fixed for M27.  I'm happy to have Terry (on my touch team) work on the implementation if desired, but the 'design through code review' process seems like a recipe for missing the branch deadline in this case.

James, sound reasonable to you?  Feel free to assign back to us (tdanderson or wjmaclean) with a concrete design for how you'd like to see this fixed, or otherwise reassign as you see fit.
Pasting what I wrote in email for reference:

"I tend to agree we should be able to pinch zoom on them, otherwise such pages would be totally unusable on a phone.  I'm thinking the solution would be to, instead of disabling scrolling entirely in the compositor, override the scrollable bounds to be the initial containing block.  Then, when pinch zoomed out, the page would not be scrollable, but when pinch zoomed in, we could scroll around the original viewport.

To implement this behavior, here's what I would propose.  Currently, in LayerTreeImpl::ScrollableSize(), the scrollable area is root_scroll_layer_->children()[0]->bounds() (which is the content layer size).  But jamesr@ was anyway planning to change it to root_scroll_layer_->bounds() (root scroll layer size).  We can set the size of the root scroll layer to whatever we want from WebKit because it wouldn't be used for anything other than scrollable bounds.  So we could normally set it to the same size as the content layer, but in your special case, set it to the size of the initial containing block."
This looks like a nice solution that is both simple and principled. +1
The original bug title is about being able to scroll, but the most recent comments are about pinch zoom.  Is this just about scrolling when pinch zoomed or something else?
The title and original description in #1 still define this bug.  I believe the comments wrt. pinch are as a result of discussions about the implications that various solutions to this problem may have on pinch (we don't want fixing this bug to also prevent panning when zoomed on such a page).
Labels: Iteration-78
This is another user interactivity scrolling vs programmatic scrolling difference.  With overflow-y: hidden the page is programmatically scrollable in the Y direction (i.e. scrollBy(...) works), but not user scrollable in that direction.  Just messing with bounds might work, but you'll have to take some care to figure out which axis you want to restrict scrolling on (X or Y).  For instance, on this test:

the user should be able to scroll horizontally with user gestures but not vertically.

I think what we really need to do is plumb through a couple of bits indicating whether a layer can be user-gesture scrolled in the X and Y directions, separately from the scroll bounds (which are the limits of programmatic scrollability).

I suppose you could also argue that since the compositor is just about user interactions adjusting the scrollable bounds it sees to be the bounds of user interactivity scrolling is right, but that feels fiddly.

We could possibly key off of the scrollbars existing or not, but this would need some experimentation to see if it's right.

rbyers@ - sending back to you to find an owner.
The code that I believe handles this for wheel is here:

which zeros out the deltaX/Y if there is no scrollbar in that direction (which overflow-x/y: hidden controls)

For keyboard scrolls, there's different logic here:

that calls:

to see if a keyboard event can scroll in the given direction.  That works by calling through ScrollableArea which null-checks the scrollbar in the given direction (here: )

So it looks not not allowing user scrolling in a direction that doesn't have a scrollbar may be the easiest and most consistent fix.
Labels: -Pri-1 -M-27 Pri-2 M-28
I'm not seeing any problems in the GSG on M27 as a result of this, and given the lack of spec clarity and inconsistencies with other browsers, I no longer thing it's urgent that we fix this.  Still fast and slow path should behave the same, so we should still fix this at some point.

wjmaclean, since this is really a compositor issue, can you find someone on your team to take a look at some point?
and +davidyu to confirm this bug isn't causing a problem for the GSG.
Does this only affect pages with overflow-y:hidden and not overflow:hidden? I remembered that we made a workaround to change from overflow-y to overflow in GSG.
Re #26 - yes, I believe this is only an issue when overflow in a specific axis is restricted by overflow-(x|y).
Re #26 and #27 - Actually, the difference was only present due to a (now fixed) bug when the events were handled on the slow path. I just verified that pages with either overflow-{x,y}:hidden or overflow:hidden on their body will incorrectly scroll with touch when the events are handled on the fast path.
Hi Rick -

I don't really know who to give this too. I haven't looked at it myself
because I've been grinding on the scrollbar rescaling issue.

What's the timeline on this? Can it be back-merged?
wjmaclean see c#24 - no longer urgent from my perspective so M28 Pri-2.  Hopefully we can find someone on the compositor team to take a look sometime in M28.  Of course if a site materializes that is broken by this then it may become urgent, but since it would already be broken on other browsers I suspect that's unlikely.

If it's not too time critical, then I'll do it in a couple of weeks. :-)
Labels: -Cr-UI-Shell-Gestures Cr-UI-Input-Touch-Screen CR-UI-Shell
Project Member

Comment 33 by, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Blockedon: chromium:233853
Blocking this on  based on the discussion of how to properly support pinch zoom (see my comment at #17).
Blocking: chromium:236639
The layer tree change for pinch zoom will affect this issue as well ( ).  I'm thinking we can mark the outer viewport scroll layer nonscrollable when "overflow: hidden", whereas in the inner viewport scroll layer can be always scrollable.
Re: #37
I think viewport should always in fast path, then the new method can also fix  bug 181315 .
Project Member

Comment 39 by, May 8 2013

Labels: -M-28 MovedFrom-28 M-29
Moving all non essential bugs to the next Milestone.
Labels: -M-29 M-30
Blocking: chromium:252907
 Issue 241189  has been merged into this issue.
A real world example of a site whose behavior has changed because of this (from  issue 241189 ):
Labels: Cr-UI-Input-Touch-Pad

Comment 46 by, Jul 31 2013

M30 branches today, moving to M31
Labels: -M-30 M-31
Labels: -Pri-2 Pri-1
This has come up in a number of contexts - bumping to Pri-1
Labels: -M-31 M-32
But too late for M31
Load balancing to sadrul
Status: Started
Project Member

Comment 53 by, Oct 22 2013

r230032 | | 2013-10-22T03:36:43.172859Z

Changed paths:

cc: Do not allow gesture-scrolling 'overflow[-{x|y}]:hidden' layers.

BUG= 175502

Review URL:
Status: Fixed
Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
Labels: -Cr-UI-Input-Touch-Pad Cr-Internals-Input-Touch-Pad
Status: Verified

Google Chrome	32.0.1680.1 (Official Build 230628) dev
Platform	4867.0.0 (Official Build) dev-channel link
Blink	537.36 (@160414)
 Issue 302878  has been merged into this issue.
Labels: -M-32 M-34 Cr-Internals-Compositing
Status: Assigned
The fix for this was reverted in  issue 322223 .  Sadrul, did you have a plan for the "right" way to fix this?
Note that this is part of the problem with things scrolling in fullscreen when they shouldn't (eg.  issue 303920 ).  Blink's fullscreen implementation adds the following rule which gets applied to <html>:

:root:-webkit-full-screen-document:not(:-webkit-full-screen), :root:-webkit-full-screen-ancestor {
overflow: hidden;
The right fix for this will be possible once we switch to using pinch-virtual-viewport by default (so that we can still pan around a zoomed overscroll:hidden body).
Blockedon: chromium:148816
Ok, thanks.  I guess this is blocked on  issue 148816  then.
Issue 173276 has been merged into this issue.

Comment 65 by, Feb 11 2014

Re #62: Pinch-virtual-viewport will get us half way there, but I don't think it's a full solution. I'm having running up against this issue right now in . The problem is the page won't pan horizontally when pinched in with overflow-x: hidden. The pinch-virtual-viewport would fix the issue on the fast path, but in this case - on Windows - the page has a non-fast-scrolling region so the scroll gestures are forwarded to the main thread where there is no concept of inner/outer viewport and the scrolls are dropped because of overflow-x: hidden.

It seems to me the only way to fix this definitively  would be to either a) somehow send the scroll back to the Impl thread (feels dubious) or b) teach WebCore about the virtual viewport.

Comment 66 by, Feb 11 2014

Blocking: chromium:339601
Re #65: Sounds like the bug that is blocking you is 'Unable to pan zoomed content in slow path when overflow: hidden is set'? That sounds more like an issue with pinch-to-zoom, than this bug (which is explicitly about the fast path). Once panning works in the fast path, we can reland the change reverted in r239675 (with the necessary changes to work with the inner/outer viewport layers), and this bug should be fixed, but it wouldn't help with panning in slow path.
It's possible that we could avoid telling WebCore about the two viewports, by just allowing a non-zero MaxScrollOffset when page_scale_factor > 1. WebCore doesn't need to know where it came from, i.e. that there are two viewports. Since this value is already plumbed up from the compositor this seems already in line with existing machinery..

If this bug is concerned solely with the fast-path, then I would say leave the slow-path as a separate issue, but my suggestion here should help with that.
"fast path" and "slow path" scrolling behavior should never be different from each other.  If they are, that's a serious bug.
Labels: -M-34 M-36
Agreed.  Hopefully we're finally close to being able to fix this long-standing issue (see blocking bugs).
 Issue 366146  has been merged into this issue.

Comment 72 by, May 5 2014

Labels: Hotlist-Input-Dev
Labels: -OS-Chrome -Iteration-76 -Iteration-77 -Iteration-78 -CR-UI-Shell -Cr-Blink -MovedFrom-28 -M-36 OS-All Cr-Blink-Input M-38
The main thing this needs is the virtual viewport work - reassigning to bokan.  This has been a serious longstanding issue - I hope we can land the fix soon!
 Issue 393703  has been merged into this issue.
Any work going on here lately?

Comment 76 by, Aug 28 2014

Yes, this is blocked on  issue 148816  since fixing this today would mean that a zoomed in page can't pan around on pages with overflow: hidden. Launching "virtual viewport" pinch to zoom is targeted for M39 so hopefully this can be fixed in the following release.

Comment 77 by, Sep 10 2014

Labels: -M-38
Labels: M-40
 Issue 412957  has been merged into this issue.
Project Member

Comment 80 by, Oct 14 2014

The following revision refers to this bug:

commit af915a887e3ec61eb029822ac7577a9198628935
Author: aelias <>
Date: Tue Oct 14 04:12:04 2014

Respect user_scrollable disabling in pinch-virtual-viewport mode.

user_scrollable_x/y are used to suppress impl-side scrolling when the
page specifies overflow: hidden.  This has been disabled for a while
because of poor interaction with pinch zoom.  In the new pinch-virtual
model, this works better (outer viewport doesn't scroll so that the user
can't see parts of the page not intended to be seen, but pinch zooming
and moving around still works), so re-enable it when that setting is

Note that I'm also planning to start using this for disabling scrolling
for fullscreen elements.

BUG= 322223 , 175502 , 411072 

Review URL:

Cr-Commit-Position: refs/heads/master@{#299428}


Comment 81 by, Oct 16 2014

 Issue 425460  has been merged into this issue.

Comment 83 by, Oct 21 2014

Blockedon: -chromium:233853
Status: Started
Note that this is now fixed wherever virtual viewport is enabled ( issue 148816 ), eg. currently working in M40 on Android. 
Simple test page:

I verified this is fixed in M40 on Android, but not fixed in M39 with the pinch-virtual-viewport flag enabled.
Simple test page:

I verified this is fixed in M40 on Android, but not fixed in M39 with the pinch-virtual-viewport flag enabled.

The issue reproduces in Safari iOS 8.0

Note that the CSS spec is now clear on this point:
UAs must apply the 'overflow' property set on the root element to the viewport. When the root element is an HTML "HTML" element or an XHTML "html" element, and that element has an HTML "BODY" element or an XHTML "body" element as a child, user agents must instead apply the 'overflow' property from the first such child element to the viewport, if the value on the root element is 'visible'. The 'visible' value when used for the viewport must be interpreted as 'auto'. The element from which the value is propagated must have a used value for 'overflow' of 'visible'.
My jsbin ( looks fixed too!
Note that  tracks Yahoo image search not scrolling due to this fix.  It has overflow-y: hidden on the body.  I believe the reason it has this is because it used to disable rubberbanding (while still allowing scrolling) on older versions of Safari.  It no longer has this effect: it's now a complete no-op on recent versions of Safari on both iOS and desktop.  Anyway, I think it's possible we may need to back the behavior change out and provide more time for outreach if that CSS ended up on a lot of random websites.
It's not completely fixed, but it's mostly fixed. Testing with Chrome Canary v40 on my computer, I can't scroll on using my mouse wheel, the space bar, or my touch screen (that's good), but, when I "click" with the scroll button, then move the mouse around, I can still scroll. So it seems like whatever's been done is more of a patch that stops touch scrolling than a solution that completely stops scrolling
Screencast of scrolling using center button on
That's pan scrolling, it might need a separate fix.

Comment 92 by, Nov 10 2014

Re #89: The fix for this is behind the --enable-pinch-virtual-viewport flag only. This flag is  being turned on in M-40 on Android but M-41 on the remaining platforms so I expect it'll still broken on desktop builds for one more milestone. Did you try this with the flag on? If so, it's possible we'll need to do some additional work for pan scrolling, as esprehn@ mentioned.

Comment 93 by, Nov 20 2014

 Issue 429604  has been merged into this issue.
Labels: -Pri-1 Pri-2
Issue has been around for a while, lowering pri to 2.
Labels: -Pri-2 Pri-1
Status: Fixed
Nope, this is still Pri-1!  But it's fixed on all platforms that have virtual viewport pinch zoom (including Android - see  issue 148816 ), so we should call it fixed.  Enabling virtual viewport pinch-zoom by default on Windows is tracked in  issue 438064 .
See  issue 444581  for discussion of sites broken by this fix.

Sign in to add a comment