Bug 158325 – Fixed position interaction broken with WKWebView when scrollView.bounce is false

• Component: Layout and Rendering
• Status: NEW

[Darryl Pogue]

Created attachment 280380 [details]
iOS App demonstration case

In a page with a fixed position header that contains interactive elements like buttons or links when shown in a WKWebView with rubberbanding disabled, it is possible for the logical interaction position of the element to get out of sync with the visual position of the element.

This happens when you do a scroll action that would normally trigger the rubberbanding effect. It has the effect of moving the logical position of the element further down the page as if rubberbanding has occurred.
The visual position is correct.

I've attached a simple test case iOS project that can reproduce the issue. The code for the test case is also available on GitHub: https://github.com/dpogue/WKScrollTest

[Radar WebKit Bug Importer]

<rdar://problem/26652772>

[Simon Fraser (smfr)]

I can reproduce.

[Simon Fraser (smfr)]

This happens because we get no "stable" viewport rect updates when a bounce would otherwise happen.

[Simon Fraser (smfr)]

It's odd that in -scrollViewDidEndDragging:willDecelerate:, [scrollView isDragging] is still true.

[Bjorn Rombaut]

Any news about this?

[Sven Peeters]

+1

[Darryl Pogue]

I think this was just fixed by https://trac.webkit.org/changeset/211379 in #167484 ?

[Simon Fraser (smfr)]

I don't think so. Comment 3 still applies.

[Pato]

Hi Gents, has this come to any solution yet? I've been goong crazy for the past days trying to come up with a plausible solution... I am using Cordova with WkWebview...

[Bjorn Rombaut]

(In reply to comment #9)
> Hi Gents, has this come to any solution yet? I've been goong crazy for the
> past days trying to come up with a plausible solution... I am using Cordova
> with WkWebview...

Our current workaround is to scroll 1px after the user has stopped scrolling, but it's a really dirty workaround. We're still waiting for a proper solution.

[Wart Claes]

Any news about this issue?

[Darryl Pogue]

I was revisiting this today, and I don't seem to be able to reproduce it on iOS 11 or 12. However, there's nothing on this ticket or any references to the Radar ticket in any WebKit commits, so I can't confirm that it's actually fixed.

@smfr Is it possible that this was fixed in https://trac.webkit.org/changeset/211197 (https://bugs.webkit.org/show_bug.cgi?id=167440) when switching from UIWebScrollView to UIScrollView?

[Simon Fraser (smfr)]

It's possible that a UIKit change fixed it.