Bug 158325 - Fixed position interaction broken with WKWebView when scrollView.bounce is false
Summary: Fixed position interaction broken with WKWebView when scrollView.bounce is false
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: Safari 9
Hardware: iPhone / iPad iOS 9.3
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-06-02 16:04 PDT by Darryl Pogue
Modified: 2018-06-11 13:01 PDT (History)
8 users (show)

See Also:

Attachments
iOS App demonstration case (10.88 KB, application/zip)
2016-06-02 16:04 PDT, Darryl Pogue 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.