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

Darryl Pogue
Reported 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
Attachments
iOS App demonstration case (10.88 KB, application/zip)
2016-06-02 16:04 PDT, Darryl Pogue 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2016-06-06 10:49:44 PDT
<rdar://problem/26652772>
Simon Fraser (smfr)
Comment 2 2016-06-06 16:47:58 PDT
I can reproduce.
Simon Fraser (smfr)
Comment 3 2016-06-06 17:18:53 PDT
This happens because we get no "stable" viewport rect updates when a bounce would otherwise happen.
Simon Fraser (smfr)
Comment 4 2016-06-06 17:29:04 PDT
It's odd that in -scrollViewDidEndDragging:willDecelerate:, [scrollView isDragging] is still true.
Bjorn Rombaut
Comment 5 2016-07-07 07:27:28 PDT
Any news about this?
Sven Peeters
Comment 6 2016-10-13 05:01:36 PDT
+1
Darryl Pogue
Comment 7 2017-01-30 12:29:47 PST
I think this was just fixed by https://trac.webkit.org/changeset/211379 in #167484 ?
Simon Fraser (smfr)
Comment 8 2017-01-30 12:42:13 PST
I don't think so. Comment 3 still applies.
Pato
Comment 9 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...
Bjorn Rombaut
Comment 10 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.
Wart Claes
Comment 11 2017-03-30 00:33:24 PDT
Any news about this issue?
Darryl Pogue
Comment 12 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?
Simon Fraser (smfr)
Comment 13 2018-06-11 13:01:37 PDT
It's possible that a UIKit change fixed it.
Note You need to log in before you can comment on or make changes to this bug.