WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
210697
[iOS] -_didFinishTextInteractionInTextInputContext should only zoom to reveal focused element if it changed
https://bugs.webkit.org/show_bug.cgi?id=210697
Summary
[iOS] -_didFinishTextInteractionInTextInputContext should only zoom to reveal...
Daniel Bates
Reported
2020-04-18 14:04:29 PDT
-_didFinishTextInteractionInTextInputContext should only zoom to reveal the focused element if it changed via a call to -_focusTextInputContext.
Attachments
Patch and tests
(35.86 KB, patch)
2020-04-18 15:29 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Patch and tests
(35.08 KB, patch)
2020-04-18 16:23 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
To Land
(46.87 KB, patch)
2020-04-21 13:19 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
To Land
(46.70 KB, patch)
2020-04-21 13:21 PDT
,
Daniel Bates
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Bates
Comment 1
2020-04-18 14:04:44 PDT
<
rdar://problem/60997530
>
Daniel Bates
Comment 2
2020-04-18 14:11:51 PDT
The effect of this bug can be seen on a google.com using the following steps: 1. Visit google.com and search for "Disneyland" and scroll the page until the search field becomes fixed to the top of the page. 2. Use -_requestTextInputContextsInRect to get the context for the search field at the top of the page. 3. Call -_willBeginTextInteractionInTextInputContext with this context. 4. Call -_focusTextInputContext with this context. 5. Call -_didFinishTextInteractionInTextInputContext with this context. Then the page will scroll to the top because -_didFinishTextInteractionInTextInputContext marks the view as needing to reveal the focused element.
Daniel Bates
Comment 3
2020-04-18 14:13:58 PDT
(In reply to Daniel Bates from
comment #2
)
> The effect of this bug can be seen on a google.com using the following steps: > > 1. Visit google.com and search for "Disneyland" and scroll the page until > the search field becomes fixed to the top of the page.
1.5. Tap on the search field
> 2. Use -_requestTextInputContextsInRect to get the context for the search > field at the top of the page. > 3. Call -_willBeginTextInteractionInTextInputContext with this context. > 4. Call -_focusTextInputContext with this context. > 5. Call -_didFinishTextInteractionInTextInputContext with this context. > > Then the page will scroll to the top because > -_didFinishTextInteractionInTextInputContext marks the view as needing to > reveal the focused element.
Daniel Bates
Comment 4
2020-04-18 15:29:21 PDT
Created
attachment 396866
[details]
Patch and tests
Daniel Bates
Comment 5
2020-04-18 16:00:57 PDT
This patch depends on the patch for
bug #210624
due to placement of the added tests in the file.
Daniel Bates
Comment 6
2020-04-18 16:23:15 PDT
Created
attachment 396872
[details]
Patch and tests
Daniel Bates
Comment 7
2020-04-18 21:58:25 PDT
Comment on
attachment 396872
[details]
Patch and tests View in context:
https://bugs.webkit.org/attachment.cgi?id=396872&action=review
> Source/WebKit/ChangeLog:26 > + making this a FIXME, but this function is otherwise capable of handling multiple innocations
innocations => invocations
> Source/WebKit/ChangeLog:31 > + do everything we do now except for marking the page as needing reveal the focused element
Needing reveal => needing to reveal
> Source/WebKit/ChangeLog:39 > + element. Passing true to visiblePositionInFocusedNodeForPoint() asserts this to be true.
asserts => will ultimately assert
Wenson Hsieh
Comment 8
2020-04-20 10:02:47 PDT
Comment on
attachment 396872
[details]
Patch and tests View in context:
https://bugs.webkit.org/attachment.cgi?id=396872&action=review
> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:5104 > + _textInteractionDidChangeFocusedElement |= NO;
Was this intended to be `_textInteractionDidChangeFocusedElement = NO;`? If not, can we just remove this line?
> Tools/TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm:583 > + // Zoom scale of scroll view should change to reveal the focused element.
I don’t believe this is true for iPad. Maybe we can only do the scale check if we’re on iPhone?
> Tools/TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm:605 > + // Zoom scale of scroll view should change to reveal the focused element.
Ditto.
Daniel Bates
Comment 9
2020-04-20 11:00:11 PDT
Comment on
attachment 396872
[details]
Patch and tests View in context:
https://bugs.webkit.org/attachment.cgi?id=396872&action=review
Thanks for the review, Wenson.
>> Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:5104 >> + _textInteractionDidChangeFocusedElement |= NO; > > Was this intended to be `_textInteractionDidChangeFocusedElement = NO;`? If not, can we just remove this line?
OK I'll remove this line.
>> Tools/TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm:583 >> + // Zoom scale of scroll view should change to reveal the focused element. > > I don’t believe this is true for iPad. Maybe we can only do the scale check if we’re on iPhone?
I'll check on iPad.
Daniel Bates
Comment 10
2020-04-21 13:19:25 PDT
Created
attachment 397109
[details]
To Land
Daniel Bates
Comment 11
2020-04-21 13:21:19 PDT
Created
attachment 397110
[details]
To Land
Daniel Bates
Comment 12
2020-04-21 13:22:15 PDT
Comment on
attachment 397110
[details]
To Land Clearing flags on attachment: 397110 Committed
r260449
: <
https://trac.webkit.org/changeset/260449
>
Daniel Bates
Comment 13
2020-04-21 13:22:17 PDT
All reviewed patches have been landed. Closing bug.
Ryan Haddad
Comment 14
2020-04-21 15:46:09 PDT
(In reply to Daniel Bates from
comment #12
)
> Comment on
attachment 397110
[details]
> To Land > > Clearing flags on attachment: 397110 > > Committed
r260449
: <
https://trac.webkit.org/changeset/260449
>
This change broke the iOS build: /Volumes/Data/slave/ios-13-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/RequestTextInputContext.mm:550:5: error: unknown type name 'IPhoneUserInterfaceSwizzler'; did you mean 'TestWebKitAPI::IPhoneUserInterfaceSwizzler'?
https://build.webkit.org/builders/Apple%20iOS%2013%20Release%20%28Build%29/builds/6599/steps/compile-webkit/logs/stdio
Daniel Bates
Comment 15
2020-04-21 15:54:01 PDT
(In reply to Ryan Haddad from
comment #14
)
> (In reply to Daniel Bates from
comment #12
) > > Comment on
attachment 397110
[details]
> > To Land > > > > Clearing flags on attachment: 397110 > > > > Committed
r260449
: <
https://trac.webkit.org/changeset/260449
> > This change broke the iOS build: > /Volumes/Data/slave/ios-13-release/build/Tools/TestWebKitAPI/Tests/ > WebKitCocoa/RequestTextInputContext.mm:550:5: error: unknown type name > 'IPhoneUserInterfaceSwizzler'; did you mean > 'TestWebKitAPI::IPhoneUserInterfaceSwizzler'? > >
https://build.webkit.org/builders/Apple%20iOS%2013%20Release%20%28Build%29/
> builds/6599/steps/compile-webkit/logs/stdio
Fixed in <
https://trac.webkit.org/changeset/260469
>
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