New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stagent.dev: Clicking email field on sign up form does not allow input until you click a second time #4950
Conversation
EWS run on previous version of this PR (hash 6160508) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me
Thanks for the review! Updated the test to work on iOS. |
EWS run on previous version of this PR (hash 4786e36) |
EWS run on current version of this PR (hash c221a57) |
β¦t until you click a second time https://bugs.webkit.org/show_bug.cgi?id=245976 rdar://98341809 Reviewed by Ryosuke Niwa. Safari's AutoFill heuristic recently began (correctly) detecting email fields on stagent.dev as autofillable. Consequently, Safari now adds an autofill button to their email field when it is clicked. WebKit has a longstanding bug where the selection is lost when an input decoration is added while the selection is inside the input. Adding a decoration, such as the autofill button, changes the structure of the shadow subtree. Specifically, the contenteditable element is removed from the shadow root and added to a separate container. The removal of the contenteditable element wipes out the selection. To work around this issue, Safari has logic to restore the selection after adding an autofill button. However, Safari's workaround is not robust, as the HTML spec limits which input types support the input selection APIs, such as `setSelectionStart` and `setSelectionEnd`. Email inputs do not support the selection API, hence Safari's workaround fails to apply to email fields where an autofill button is added. To fix, restore the selection in WebKit, following the addition of an input decoration, such as the autofill button. Note that this change still results in two "selectionchange" events getting dispatched when focusing an autofillable field for the first time. However, this matches behavior in shipping Safari. An alternate solution considered was to avoid moving the contenteditable element when adding a decoration. However, this change would have a much larger surface area, and is too risky in the short term. * LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field-expected.txt: Added. * LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field.html: Added. * Source/WebCore/html/HTMLTextFormControlElement.h: Expose a method returning the enumerated value of the selection direction so that the variant of `setSelectionRange` that does not dispatch "select" events can be used. * Source/WebCore/html/TextFieldInputType.cpp: (WebCore::TextFieldInputType::createContainer): Restore the selection after an input decoration is added. Canonical link: https://commits.webkit.org/255229@main
c221a57
to
f3b946f
Compare
Committed 255229@main (f3b946f): https://commits.webkit.org/255229@main Reviewed commits have been landed. Closing PR #4950 and removing active labels. |
f3b946f
c221a57