Bug 158325

Summary:

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

Product:

WebKit

Reporter:

Darryl Pogue <dvpdiner2>

Component:

Layout and Rendering

Assignee:

Nobody <webkit-unassigned>

Status:

NEW ---

Severity:

Normal

CC:

bjorn.rombaut1991, enrica, jonlee, patogalan82, simon.fraser, sven, wart.claes, webkit-bug-importer

Priority:

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.