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
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.
> 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.
Thank you. There should probably be separate bug tracking these issues, I'll leave it to Simon to decide what works best.
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).
<rdar://problem/60894614>
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?
The original bug here is is about us painting the fixed header when scrolling, which is possible. That might only happen in iframes.
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
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
(In reply to Simon Fraser (smfr) from comment #8) To clarify, I think we can definitely focus on points 1 and 2.
> 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.
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.
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.
(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.
Yeah I think this will require poking around in UIScrollView. Probably best done by someone at Apple.
(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?
Created attachment 423483 [details] Patch
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?
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.
(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.
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