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

Issue 162486 link

Starred by 7 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug-Regression



Sign in to add a comment

iframe scrolling broken

Project Member Reported by owale@chromium.org, Nov 23 2012

Issue description

Application Version (from "Chrome Settings > About Chrome"): 25.0.1332521
Android Build Number (from "Android Settings > About Phone/Tablet"): JOP40D
Device: Galaxy Nexus

Steps to reproduce: 
1. Launch Chrome 
2. Go to a page that contains an iframe
3. Attempt to scroll the contents of the iframe

Observed behavior: 
Scrolling only seems to work when initiating the scroll from the top edge of the iframe

Expected behavior: 
To be able to initiate the scroll from anywhere within the iframe

Additional comments: 
Works as expected in 18.0.1025469
 

Comment 1 by owale@chromium.org, Nov 23 2012

Logs & barebones example page @ http://go/chrome-androidlogs/162486
Labels: Area-WebKit WebKit-Compositing
Cc: -skyos...@chromium.org
Labels: Mstone-25
Owner: skyos...@chromium.org
Status: Assigned

Comment 4 by owale@chromium.org, Dec 11 2012

Labels: dev-channel-test
Cc: skyos...@chromium.org
Labels: ReleaseBlock-Beta
Owner: wangxianzhu@chromium.org
Besides iframes, this issue also occurs for all scrollable areas in a page. Seems the initial hit test is incorrect, not or mistakenly considering page scale.
Labels: WebKit-ID-104730
Project Member

Comment 8 by bugdroid1@chromium.org, Dec 12 2012

Labels: -WebKit-ID-104730 WebKit-ID-104730-NEW
https://bugs.webkit.org/show_bug.cgi?id=104730
Owner: trchen@chromium.org
Project Member

Comment 10 by bugdroid1@chromium.org, Dec 12 2012

Labels: -WebKit-ID-104730-NEW WebKit-ID-104730-ASSIGNED
https://bugs.webkit.org/show_bug.cgi?id=104730
I just added some debug output to the compositor scroll handling code.
I think the workaround in https://bugs.webkit.org/show_bug.cgi?id=104730 is not correct and isn't really necessary.

The real problem is with LayerImpl::tryScroll()
The computed hitTestPointInContentSpace and hitTestPointInLayerSpace is horribly wrong. (why does it have anything to do with contentsScale anyway???)

It is a bit late today and I'll come up with a fix tomorrow.
It might be worth documenting the coordinate spaces used for the various touch events at http://trac.webkit.org/wiki/ScalesAndZooms. It seems like there's an endless potential for confusion here.
Horizontal articles bar on www.nytimes.com is very difficult to scroll. Similar to this issue ?
> Horizontal articles bar on www.nytimes.com is very difficult to scroll. Similar to this issue ?

No, technically the horizontal bar doesn't "scroll". It is transformed by the touch event handlers on the page. yusufo@ is working on fast touch handling recently. He knows better than me on that matter.
For those TL;DR, the bug cause is that ScrollingCoordinator::computeNonFastScrollableRegion() ignores transform on sub-frames.

After days of investigating, I think the compositor side is probably okay.

The bounds of the main frame scrolling layer will be the size of non-composited contents. In clank's scaling mode, it will be the document size in CSS pixel multiplied by the page scale factor. Then there is still a contentBounds associated with the scrolling layer, that is the bounds multiplied by contentsScale. Somehow the contentsScale will be scale factor, so the contentBounds will be scaled twice. That's why hitTestPointInContentSpace looks to be a ridiculously big number. It is confusing but should unharmful.

The bug is in ScrollingCoordinator::computeNonFastScrollableRegion(), which uses ScrollableArea::scrollableAreaBoundingBox to compute absolute rects(in clank's scaling mode, they are pre-scaled by page scale factor, and in the new mode they will be in CSS pixel) that needs slow scroll. This part is correct too. However when it recurses into a sub-frame, it only translates the returned region with FrameView::frameRect, ignoring any transformation that needs to be done.
Sorry, I didn't realize iframe is not a part of the frame tree. The recursion has nothing to do with the bug (though there might be other bug with frames. I'll investigate later.)

Anyway, a correct fix is uploaded: https://bugs.webkit.org/show_bug.cgi?id=105075
Project Member

Comment 17 by bugdroid1@chromium.org, Dec 15 2012

Labels: -WebKit-ID-104730-ASSIGNED WebKit-ID-104730-RESOLVED
https://bugs.webkit.org/show_bug.cgi?id=104730
FYI, with the Chrome Beta candidate, 25.0.1364.4, we can't scroll neither iframe nor frameset. At this point, even scroll from the top doesn't work.
Cc: aelias@chromium.org
Cc: klo...@chromium.org
Issue 167907 has been merged into this issue.

Comment 21 by k...@google.com, Jan 8 2013

Labels: -ReleaseBlock-Beta ReleaseBlock-Stable
Another example of a site that can't scroll (in desktop mode) due to frames on Nexus 10:

http://agmp.co.uk/

Would be great to pick up this fix for the next Play store update.  This bug makes sites unusable.

Comment 23 by k...@google.com, Jan 10 2013

Labels: -Restrict-View-Google Restrict-AddIssueComment-Commit
Just merged the patches for fast-path scrolling of frames ( bug 165783 ). Things may go differently with them.

Comment 25 by k...@google.com, Jan 14 2013

Labels: -WebKit-ID-104730-RESOLVED WebKit-ID-105075

Comment 26 by k...@google.com, Jan 14 2013

Labels: -Restrict-AddIssueComment-Commit
Project Member

Comment 27 by bugdroid1@chromium.org, Jan 14 2013

Labels: -WebKit-ID-105075 WebKit-ID-105075-UNCONFIRMED WebKit-Rev-138991
https://bugs.webkit.org/show_bug.cgi?id=105075
http://trac.webkit.org/changeset/138991
Project Member

Comment 28 by bugdroid1@chromium.org, Jan 15 2013

Labels: -WebKit-ID-105075-UNCONFIRMED WebKit-ID-105075-RESOLVED WebKit-Rev-139686
https://bugs.webkit.org/show_bug.cgi?id=105075
http://trac.webkit.org/changeset/139686
Labels: Merge-Requested

Comment 30 by k...@google.com, Jan 15 2013

Labels: -Merge-Requested Merge-Approved
Labels: -Mstone-25 -Merge-Approved Mstone-26
Status: Fixed
165783  is sufficient for M25. 

Lets pick this up in the next one. 

Comment 32 by owale@chromium.org, Jan 16 2013

Issue 167907 has been merged into this issue.
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 9 2013

Labels: -Type-Regression -Area-WebKit -WebKit-Compositing -Mstone-26 Cr-Content Type-Bug-Regression Cr-Content-Compositing M-26
Project Member

Comment 34 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 35 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Compositing Cr-Blink-Compositing

Comment 36 by Deleted ...@, May 30 2013

Has there been a fix for this yet because Im currently running into the same thing
This issue has been fixed. Please open a new bug with reproduction steps if you're seeing problems with iframe scrolling.

Comment 38 by Deleted ...@, May 30 2013

Iframe scrolling has most definately not been fixed, the scrolling is stuck to the parent of the Iframe and ignores the inner scrolling.  I will create a new bug with the reproduction,  how is this the only mobile browser still struggling with this tho?
I'm also experiencing this problem. You can scroll what you want inside an iframe and also inside textboxes. It does not work, only the parent is scrolling. Even when mouse is 'on' the iframe / textarea.

Sign in to add a comment