[Webkit-unassigned] [Bug 207425] REGRESSION (r256072): ScrollViewScrollabilityTests.ScrollableWithOverflowHiddenAndInputView fails

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=207425

--- Comment #2 from Wenson Hsieh <wenson_hsieh at apple.com> ---
The way this API test currently works is a little unexpected. I think it’s intended to test that after focusing an input field (and bringing up the keyboard), we scroll to reveal the focused element even when the body has `overflow: hidden`. The logic responsible for making this work is in -[WKWebView _updateScrollViewForTransaction:]...

    bool hasDockedInputView = !CGRectIsEmpty(_inputViewBounds);
    bool isZoomed = layerTreeTransaction.pageScaleFactor() > layerTreeTransaction.initialScaleFactor();

    …

    bool scrollingEnabled = _page->scrollingCoordinatorProxy()->hasScrollableMainFrame() || hasDockedInputView || isZoomed || scrollingNeededToRevealUI;
    [_scrollView _setScrollEnabledInternal:scrollingEnabled];

However, since this is an API test on iOS (and therefore does not run in the context of a UIApplication), UIKit never attempts to actually bring up an input view; as a result, _inputViewBounds is always empty, so hasDockedInputView will always be NO. Instead, this test currently passes due to how -[WKWebView _zoomToFocusRect:…:] zooms the input field when running on iPhone; by zooming, the `isZoomed` flag is set, and so we end up setting scrollEnabled to YES anyways.

I manually verified on device (by focusing the bottom half of https://whsieh.github.io/examples/multiple-contenteditable) that we do still scroll to reveal focused elements after my change in r256072, since _inputViewBounds is non-empty.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200208/68784961/attachment.htm>