Given the asynchronous scrolling model of WK2 on iOS, we can receive a request to scroll from JavaScript while the UI process is still animating to reveal the focused input element. This breaks the behavior of pages like www.amazon.co.jp on iOS. <rdar://problem/16468462>
Created attachment 231018 [details] Patch
Comment on attachment 231018 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=231018&action=review > Source/WebCore/dom/Element.cpp:1983 > - if (document().page()) > - document().page()->chrome().client().elementDidFocus(this); > - > RefPtr<FocusEvent> event = FocusEvent::create(eventNames().focusEvent, false, false, document().defaultView(), 0, oldFocusedElement); > EventDispatcher::dispatchEvent(this, event.release()); > + if (document().page()) > + document().page()->chrome().client().elementDidFocus(this); > } As discussed: let's move this on a separate patch, and handle the programmatic scroll. > Source/WebCore/platform/ScrollableArea.h:72 > + virtual bool inProgrammaticScroll() const { return false; } Please move this to ScrollView. You should also add override on FrameView's implementation. > Source/WebKit2/UIProcess/API/Cocoa/WKWebView.mm:118 > + BOOL _isAnimatingScrollOrZoom; Let's try to remove this and stop the animations systematically. We will need a more generic heuristic to solve conflicts between user gesture and animation origination from WebProcess's requests.
Committed revision 168447.