Bug 209486

Summary:

Drifting when scrolling an iframe that scrolls on both axes

Product:

WebKit

Reporter:

Dima Voytenko <dvoytenko>

Component:

Scrolling

Assignee:

Simon Fraser (smfr) <simon.fraser>

Status:

NEW

Severity:

Major

CC:

ap, cathiechen, fred.wang, jridgewell, simon.fraser, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

Safari 13

Hardware:

iPhone / iPad

OS:

iOS 13

Bug Depends on:

Bug Blocks:

209737

Attachments:

Description	Flags
Patch	ews-feeder: commit-queue-

Dima Voytenko

Reported 2020-03-24 12:14:46 PDT

Repro page: https://output.jsbin.com/wakuqok/quiet It's a simple page that overflows on x and y. When scrolled, it shows a very visible flicker. See screen recording: https://drive.google.com/file/d/1g7IQE25VOS2B5Bhg760_Qx7k0Bnrrqbp/view?usp=sharing

Attachments
Patch (6.01 KB, patch) 2021-03-17 06:54 PDT, cathiechen	ews-feeder: commit-queue-	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Alexey Proskuryakov

Comment 1 2020-03-24 22:35:59 PDT

I cannot reproduce this with iOS 13.4 (released today). But also, the page appears to look and behave very differently than on the video.

Justin Ridgewell

Comment 2 2020-03-25 10:45:53 PDT

> I cannot reproduce this with iOS 13.4 (released today). Flicker is better, but the scroll behavior still seems wrong. Normally, vertical scrolling will lock the horizontal position (unless you start the scroll by going diagonal, then both directions are unlocked). Iframe scrolling never scroll locks, so we get free movement in both directions. It feels unnatural. Here's a video recording with 13.4: https://drive.google.com/file/d/1SWnE8z_l2FPkBgBOip1vEz1nPo5ed6bH/view?usp=sharing > But also, the page appears to look and behave very differently than on the video. I had paint flashing enabled when recording, if you're referring to the red flashes.

Alexey Proskuryakov

Comment 3 2020-03-25 11:19:43 PDT

Thank you. There should probably be separate bug tracking these issues, I'll leave it to Simon to decide what works best.

Justin Ridgewell

Comment 4 2020-03-25 12:51:22 PDT

Actually, I don't believe 13.4 fixes the flicker. When using a more GPU intensive page, I get a very noticeable side-to-side flicker: https://drive.google.com/file/d/1cVn9KOU8Lzk4yVxYUxlssw280taYmdac/view?usp=sharing This is with a single vertical scroll, letting momentum continue downwards (I'm not touching the screen during the flicker).

Radar WebKit Bug Importer

Comment 5 2020-03-25 16:19:11 PDT

<rdar://problem/60894614>

Simon Fraser (smfr)

Comment 6 2020-03-25 16:30:20 PDT

My guess is that the New Yorker page is doing something to change layout during the scroll. What's the AMP url of that page?

Simon Fraser (smfr)

Comment 7 2020-03-25 16:31:12 PDT

The original bug here is is about us painting the fixed header when scrolling, which is possible. That might only happen in iframes.

Simon Fraser (smfr)

Comment 8 2020-03-25 16:33:40 PDT

So the issues I see in this bug, which need to all be separate: 1. Repaint in fixed header inside iframe 2. "drifting" when scrolling an iframe that scrolls on both axes 3. Bad behavior when scrolling AMP newyorker.com article

Dima Voytenko

Comment 9 2020-03-25 17:22:35 PDT

This is definitely not a New Yorker issue - just a good example. The minimal repro shows the problem here: https://output.jsbin.com/wakuqok/quiet

Dima Voytenko

Comment 10 2020-03-25 17:42:30 PDT

(In reply to Simon Fraser (smfr) from comment #8) To clarify, I think we can definitely focus on points 1 and 2.

Justin Ridgewell

Comment 11 2020-03-26 12:05:11 PDT

> 3. Bad behavior when scrolling AMP newyorker.com article We've tracked this down to a badly behaving scroll listener. Funnily, we added this listener as a fix to the "drifting" issue, and it turned out to make everything worse. As Dima said, I think we can focus on just the repaint and drifting, particularly the drifting issue. I think both are well demonstrated in the linked jsbin page.

Frédéric Wang (:fredw)

Comment 12 2020-03-30 06:58:16 PDT

I agree with Simon that we should separate issues. (2) == drifting seems more obvious than (1) == flashing to me and I expect we could Trying with 13.4, (2) seems better on the simulator than on a devide FWIW. I'll open a separate bug and rename this one.

Dima Voytenko

Comment 13 2020-04-15 09:27:32 PDT

A bit more info: I did some more testing with `touch-action: pan-y` in hopes that the scroll behavior would improve, but this doesn't seem to affect it.

cathiechen

Comment 14 2020-04-29 07:20:22 PDT

(In reply to Dima Voytenko from comment #13) > A bit more info: I did some more testing with `touch-action: pan-y` in hopes > that the scroll behavior would improve, but this doesn't seem to affect it. It seems touch-action is based on ENABLE(TOUCH_EVENTS). Only _handleTouchActionsForTouchEvent in WKContentViewInteraction.mm changes the touchActions values. But TOUCH_EVENTS seems can't be enabled by using the public SDK, see bug 179167 for details. https://output.jsbin.com/kezoqumeni The above test added `touch-action: pan-y;` to <html> of the iframe. The horizontal scrolling is locked if open the page on the original safari of iPhone(13.4.5) or iOS-simulator(13.3). Note, there's an issue about touch-action, it seems can't lock the horizontal scroll during momentum scrolling. The drifting issue seems related to UIScrollView, from the outside, maybe we can add a constraint to avoid unwanted horizontal/vertical scrolling as touch-action does in _scrollView and scrollViewWillEndDragging? But it seems still can't avoid it if it's during momentum scrolling.

Simon Fraser (smfr)

Comment 15 2020-04-29 07:49:22 PDT

Yeah I think this will require poking around in UIScrollView. Probably best done by someone at Apple.

Dima Voytenko

Comment 16 2021-01-07 09:56:32 PST

(In reply to Simon Fraser (smfr) from comment #15) > Yeah I think this will require poking around in UIScrollView. Probably best > done by someone at Apple. Simon, is there any update on this issue at all?

cathiechen

Comment 17 2021-03-17 06:54:13 PDT

Created attachment 423483 [details] Patch

cathiechen

Comment 18 2021-03-17 07:15:11 PDT

Hi, I uploaded a patch which filters the offset and velocity of the gesture. It seems to work well for the iframe drifting issue. Simon, do you think this change is reasonable? Any advices?

Simon Fraser (smfr)

Comment 19 2021-03-17 09:27:13 PDT

Sorry I haven't been able to get to see if UIScrollView will do this for us. I think, if it does, that will be a better solution.

cathiechen

Comment 20 2021-03-18 02:28:47 PDT

(In reply to Simon Fraser (smfr) from comment #19) > Sorry I haven't been able to get to see if UIScrollView will do this for us. > I think, if it does, that will be a better solution. Hi Simon, Yeah, I agree with you. It would be great that you can take a look at this inside UIScrollView.

cathiechen

Comment 21 2021-03-18 02:43:21 PDT

I also want to clarify the EWS failure and the touch-action workaround. About the EWS test failure, it seems LayoutTests/fast/scrolling/ios/scroll-iframe-003.html is against what we expect here. It expects both axes scroll for iframe. About the workaround (touch-action: pan-y) we talked above seems not work. Touch-action is not effective to iframe, according to https://github.com/w3c/pointerevents/issues/325

Note You need to log in before you can comment on or make changes to this bug.