WKWebView contentOffset/contentInset bugs |
||||||
Issue descriptionThis bug tracks 2 radars/webkit bugs regarding contentOffset/contentInset in WKWebView. Once one of these is fixed, workaround code (marked by a TODO) can be removed. 1. Back in iOS 9.2 and before, setting the content inset on a web view's scroll view would push the content down for normal web pages and PDF pages immediately when page is loaded. In 9.3.x and later, content inset no longer pushes content down for PDFs when page load completes. It does, however, still allow user to scroll up to see the space created by the inset. 2. When the following steps occur, the content offset is reset: a. Set content offset to negative value. b. Make frame height bigger. c. Then, content offset is set to 0. This behavior existed in at least iOS 9.0, and occurs for both normal web pages and PDFs. It may be WAI.
,
Sep 12 2016
Filed content inset bug: rdar://28267125 , https://bugs.webkit.org/show_bug.cgi?id=161875 , http://b/31437789 Clarification on content inset bug: Setting content inset alone never worked when setting from didFinishLoad. It did, however, worked pre iOS 9.3.x when the frame size was increased just before assigning the content inset. Then, this workaround broke in 9.3.x.
,
Sep 12 2016
For content offset bug: rdar://28268621 Also submitted as webkit bug: https://bugs.webkit.org/show_bug.cgi?id=161880 http://b/31439571
,
Apr 7 2017
,
Sep 14 2017
,
Oct 5
The 3 external bugs mentioned in #3 are untouched. eugenebut@, can you check if this is still an issue?
,
Oct 5
I believe this is still an issue.
,
Oct 19
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by gch...@chromium.org
, Sep 12 2016