Bug 158325

Summary: Fixed position interaction broken with WKWebView when scrollView.bounce is false
Product: WebKit Reporter: Darryl Pogue <dvpdiner2>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: bjorn.rombaut1991, enrica, jonlee, patogalan82, simon.fraser, sven, wart.claes, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 9   
Hardware: iPhone / iPad   
OS: iOS 9.3   
Attachments:
Description Flags
iOS App demonstration case none

Description Darryl Pogue 2016-06-02 16:04:09 PDT
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
Comment 1 Radar WebKit Bug Importer 2016-06-06 10:49:44 PDT
<rdar://problem/26652772>
Comment 2 Simon Fraser (smfr) 2016-06-06 16:47:58 PDT
I can reproduce.
Comment 3 Simon Fraser (smfr) 2016-06-06 17:18:53 PDT
This happens because we get no "stable" viewport rect updates when a bounce would otherwise happen.
Comment 4 Simon Fraser (smfr) 2016-06-06 17:29:04 PDT
It's odd that in -scrollViewDidEndDragging:willDecelerate:, [scrollView isDragging] is still true.
Comment 5 Bjorn Rombaut 2016-07-07 07:27:28 PDT
Any news about this?
Comment 6 Sven Peeters 2016-10-13 05:01:36 PDT
+1
Comment 7 Darryl Pogue 2017-01-30 12:29:47 PST
I think this was just fixed by https://trac.webkit.org/changeset/211379 in #167484 ?
Comment 8 Simon Fraser (smfr) 2017-01-30 12:42:13 PST
I don't think so. Comment 3 still applies.
Comment 9 Pato 2017-03-08 04:58:36 PST
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...
Comment 10 Bjorn Rombaut 2017-03-08 05:03:29 PST
(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.
Comment 11 Wart Claes 2017-03-30 00:33:24 PDT
Any news about this issue?
Comment 12 Darryl Pogue 2018-06-11 11:39:13 PDT
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?
Comment 13 Simon Fraser (smfr) 2018-06-11 13:01:37 PDT
It's possible that a UIKit change fixed it.