| Summary: | Evernote device management web view sometimes displays at the wrong scale | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Tim Horton <thorton> | ||||
| Component: | New Bugs | Assignee: | Tim Horton <thorton> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | bdakin, mitz, simon.fraser, wenson_hsieh | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Tim Horton
2018-02-07 17:11:35 PST
Created attachment 333342 [details]
Patch
Comment on attachment 333342 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=333342&action=review > Source/WebKit/ChangeLog:25 > + Evernote implements the WKWebView's scroll view's delegate method > + viewForZoomingInScrollView: and returns null. This results in > + WKScrollView's zoomScale always returning 1, no matter what the > + WKContentView's actual scale is. This will result in us never updating > + the WKContentView's scale to 1. When loading a page that has a few > + scale changes during load but ends up at scale 1, we get stuck at whatever > + intermediate scale immediately preceded settling on 1. > + > + Fix this by not forwarding viewForZoomingInScrollView: to the external > + WKScrollView delegate; we are in charge of the contents of the scroll > + view (including which view scrollView's zoomScale should track), and > + overriding viewForZoomingInScrollView: is only ever going to lead to > + a broken WebKit. Put all this above the function names. Also null -> nil says mitz. > Tools/TestWebKitAPI/Tests/ios/WKScrollViewDelegate.mm:2 > + * Copyright (C) 2016 Apple Inc. All rights reserved. 2016-2018 i guess. |