WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Patch and manual test
(9.00 KB, patch)
2014-06-25 15:21 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch and manual test
(7.30 KB, patch)
2014-06-25 16:54 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch and manual test
(6.35 KB, patch)
2014-06-26 08:58 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch and manual test
(6.31 KB, patch)
2014-06-26 13:22 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2014-06-25 15:05:00 PDT
<
rdar://problem/17427385
>
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.
Top of Page
Format For Printing
XML
Clone This Bug