[iOS] Focusing a large editable element always scrolls to the top of the element
authorwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 18 Dec 2018 04:04:44 +0000 (04:04 +0000)
committerwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 18 Dec 2018 04:04:44 +0000 (04:04 +0000)
commit0eb43d49e78be07658633e549948c2dd954476d2
treeaeb28be30f8767dcd919368806ee23ebce6b264d
parentd3728efdb49064d2de633c7fa887cdca7cdd22e9
[iOS] Focusing a large editable element always scrolls to the top of the element
https://bugs.webkit.org/show_bug.cgi?id=192745
<rdar://problem/46758445>

Reviewed by Tim Horton.

Source/WebKit:

Currently, when focusing form controls or editable elements, we try to scroll such that the focused element rect
is centered within the visible area. In the case of very large focusable elements whose dimensions exceed the
width or height of the visible area, we instead scroll such that the top left point of the element is at the top
left corner of the visible area.

However, this results in unnecessary scrolling if the top of the element is already near the top of the visible
area. For WebKit2-based rich text editors that have an editable body element with a top content inset that
contains additional content, this means we will always scroll the additional content away when focusing the
editable body.

To avoid this behavior, adjust focused element zooming logic for editable elements that are too large to be
centered in the visible area, such that we only scroll the top left position of the focused element to the top
half or top right of the visible area, respectively. This reduces the amount of scrolling when focusing large
editable elements, while still making it clear which element is being focused.

* Platform/spi/ios/UIKitSPI.h:
* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView _zoomToFocusRect:selectionRect:insideFixed:fontSize:minimumScale:maximumScale:allowScaling:forceScroll:]):

Make some small adjustments to improve the readability of this method by using `clampTo` instead of clamping
values by comparing and setting values.

Also, fix an existing bug wherein focusable elements that are meant to be centered within the visible area are
currently offset by half the difference between the bottom inset amount and the top inset amount, in the case
where the `_obscuredInsets` SPI is used to specify content insets for the web view (i.e., MobileSafari).

* UIProcess/API/Cocoa/WKWebViewInternal.h:

Make a couple of arguments `const FloatRect&` instead of just `FloatRect`.

LayoutTests:

Add a new layout test to verify that we don't scroll unnecessarily when focusing a tall editable element, whose
top offset is already near the top of the viewport.

* editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt: Added.
* editing/selection/ios/no-scrolling-when-focusing-large-editable-area.html: Added.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@239314 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests/ChangeLog
LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area-expected.txt [new file with mode: 0644]
LayoutTests/editing/selection/ios/no-scrolling-when-focusing-large-editable-area.html [new file with mode: 0644]
Source/WebKit/ChangeLog
Source/WebKit/Platform/spi/ios/UIKitSPI.h
Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm
Source/WebKit/UIProcess/API/Cocoa/WKWebViewInternal.h