RESOLVED FIXED 134309
[iOS][WK2] Distant focusable element may not be scrolled into view when focused using keyboard
https://bugs.webkit.org/show_bug.cgi?id=134309
Summary [iOS][WK2] Distant focusable element may not be scrolled into view when focus...
Daniel Bates
Reported 2014-06-25 15:04:45 PDT
Created attachment 233839 [details] Example Focusing a distant focusable element using the keyboard accessory may not scroll the newly focused element into view, 1. Open the attached test case, example.html, in Safari for iOS. 2. Follow the instructions in the test case.
Attachments
Example (901 bytes, text/html)
2014-06-25 15:04 PDT, Daniel Bates
no flags
Patch and manual test (9.00 KB, patch)
2014-06-25 15:21 PDT, Daniel Bates
no flags
Patch and manual test (7.30 KB, patch)
2014-06-25 16:54 PDT, Daniel Bates
no flags
Patch and manual test (6.35 KB, patch)
2014-06-26 08:58 PDT, Daniel Bates
no flags
Patch and manual test (6.31 KB, patch)
2014-06-26 13:22 PDT, Daniel Bates
no flags
Daniel Bates
Comment 1 2014-06-25 15:05:00 PDT
Daniel Bates
Comment 2 2014-06-25 15:21:35 PDT
Created attachment 233841 [details] Patch and manual test I'm unclear how to write a DRT test for this change. Maybe we can write a TestWebKitAPI test? I'm open to suggestions. For now, I included a manual test that is similar to example attached to this bug (attachment #233839 [details]).
Daniel Bates
Comment 3 2014-06-25 15:23:45 PDT
The approach taken in this patch was inspired by an in-person discussion yesterday (06/24) with Enrica Casucci.
Enrica Casucci
Comment 4 2014-06-25 15:40:00 PDT
Comment on attachment 233841 [details] Patch and manual test I don't think you need to do it in the WebProcess. You know in the UIProcess if the < > buttons have been pressed and you can replace the selection rect with an empty rect before calling zoomToFocusNode.
Daniel Bates
Comment 5 2014-06-25 16:54:42 PDT
Created attachment 233851 [details] Patch and manual test Updated patch based on Enrica Casucci's feedback.
Benjamin Poulain
Comment 6 2014-06-26 00:39:49 PDT
Comment on attachment 233851 [details] Patch and manual test View in context: https://bugs.webkit.org/attachment.cgi?id=233851&action=review > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.h:139 > + BOOL _didAccessoryTabInitiateFocus; Don't forget to clear this in the crash handler.
Daniel Bates
Comment 7 2014-06-26 08:58:34 PDT
Created attachment 233903 [details] Patch and manual test Upated patch based on Benjamin Poulain's feedback; clear _didAccessoryTabInitiateFocus in -[WKContentView cleanupInteraction]
Daniel Bates
Comment 8 2014-06-26 13:22:30 PDT
Created attachment 233929 [details] Patch and manual test Rebased patch
WebKit Commit Bot
Comment 9 2014-06-26 13:24:02 PDT
Attachment 233929 [details] did not pass style-queue: ERROR: Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:628: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] Total errors found: 1 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Daniel Bates
Comment 10 2014-06-26 21:31:50 PDT
Comment on attachment 233929 [details] Patch and manual test Clearing flags on attachment: 233929 Committed r170518: <http://trac.webkit.org/changeset/170518>
Daniel Bates
Comment 11 2014-06-26 21:31:57 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.