Bug 193997 – After the fix for bug 192529, fast/scrolling/ios/hit-testing-iframe.html fails

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Scrolling

[Simon Fraser (smfr)]

fast/scrolling/ios/hit-testing-iframe.html is doing frame scrolling in the UI process. Sometime during the interaction with the last frame ("clickElementInsideFrameAfterUserScroll"), we get a full scrolling tree update from the web process which clobbers the scroll position back to 0,0, causing the last hit test to fail.

This suggests that iOS frame scrolls aren't getting back to the web process. It also suggests that maybe we need to be more incremental about reconnecting subframe scrolling tree nodes to avoid churn.

I'll mark the test as failing for now.

[Frédéric Wang (:fredw)]

(In reply to Simon Fraser (smfr) from comment #0)
> fast/scrolling/ios/hit-testing-iframe.html is doing frame scrolling in the
> UI process. Sometime during the interaction with the last frame
> ("clickElementInsideFrameAfterUserScroll"), we get a full scrolling tree
> update from the web process which clobbers the scroll position back to 0,0,
> causing the last hit test to fail.
> 
> This suggests that iOS frame scrolls aren't getting back to the web process.
> It also suggests that maybe we need to be more incremental about
> reconnecting subframe scrolling tree nodes to avoid churn.
> 
> I'll mark the test as failing for now.

Yes, the sync from web to UI process was supposed to be implemented in bug 182868 but the patch is no longer working with the new approach. All test cases involving programmatic scrolling are known to fail right now.

[Radar WebKit Bug Importer]

<rdar://problem/47671657>

[Simon Fraser (smfr)]

Fixed via bug 195099.

*** This bug has been marked as a duplicate of bug 195099 ***