Bug 176243 - requestAnimationFrame causes bad location of position:fixed inside overflow:auto and iframe
Summary: requestAnimationFrame causes bad location of position:fixed inside overflow:a...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: WebKit Nightly Build
Hardware: iPhone / iPad All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks: 154399
  Show dependency treegraph
 
Reported: 2017-09-01 13:04 PDT by Frédéric Wang (:fredw)
Modified: 2017-11-14 11:12 PST (History)
3 users (show)

See Also:


Attachments
Testcase (840 bytes, text/html)
2017-09-01 13:04 PDT, Frédéric Wang (:fredw)
no flags Details
Alternative testcase (868 bytes, text/html)
2017-11-13 08:28 PST, Frédéric Wang (:fredw)
no flags Details
Experimental patch (4.84 KB, patch)
2017-11-14 08:33 PST, Frédéric Wang (:fredw)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frédéric Wang (:fredw) 2017-09-01 13:04:04 PDT
Created attachment 319637 [details]
Testcase

The attached testcase is essentially attachment 316551 [details] + some regular calls to requestAnimationFrame(). After r220261, the flickering is gone, but we still see some "big jumps" when scrolling the frame.

This issue disappears if we remove these requestAnimationFrame() calls or reduce their frequency. It looks like these requestAnimationFrame might cause some out-of-sync scroll coordinates between the web and UI process.
Comment 1 Radar WebKit Bug Importer 2017-09-01 13:47:53 PDT
<rdar://problem/34214708>
Comment 2 Frédéric Wang (:fredw) 2017-11-13 08:28:19 PST
Created attachment 326761 [details]
Alternative testcase

This testcase relies on a more standard use of requestAnimationFrame.
Comment 3 Frédéric Wang (:fredw) 2017-11-13 10:15:48 PST
I did a quick debugging of this and the trace for requestAnimationFrame is something like:

RemoteLayerTreeDrawingArea::flushLayers
 |
(Timer)
 |
RemoteLayerTreeDrawingArea::scheduleCompositingLayerFlush
ScriptedAnimationController::scheduleAnimation
ScriptedAnimationController::registerCallback
Document::requestAnimationFrame
DOMWindow::requestAnimationFrame

where RemoteLayerTreeDrawingArea::flushLayers commit the scrolling state and is actually also called when we perform async scrolling on iOS. So I don't see anything abnormal. Maybe requestAnimationFrame should not commit the scrolling state and let that work be done by the async scrolling code to avoid conflicts?
Comment 4 Frédéric Wang (:fredw) 2017-11-14 08:33:11 PST
Created attachment 326879 [details]
Experimental patch

This patch is a quick dirty hack to force a delayed flush when RemoteLayerTreeDrawingArea::scheduleCompositingLayerFlush is caused by a requestAnimationFrame call. As you can see, it avoids big jumps of the fixed element in the testcase. I wonder whether we should do something like that when user scrolling is happening... @Simon: WDYT?
Comment 5 Simon Fraser (smfr) 2017-11-14 11:12:51 PST
I don't get why that's the right approach to fix this bug. Would need to analyze further.