[webkit-changes] [WebKit/WebKit] d66021: stagent.dev: Clicking email field on sign up form ...

[Aditya Keerthi]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: d66021f088795fd0954d82d1098e0ad587d23537
      https://github.com/WebKit/WebKit/commit/d66021f088795fd0954d82d1098e0ad587d23537
  Author: Aditya Keerthi <akeerthi at apple.com>
  Date:   2022-11-11 (Fri, 11 Nov 2022)

  Changed paths:
    A LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field-expected.txt
    A LayoutTests/fast/forms/auto-fill-button/show-auto-fill-button-while-selection-inside-field.html
    M Source/WebCore/html/HTMLTextFormControlElement.h
    M Source/WebCore/html/TextFieldInputType.cpp
    M Source/WebCore/html/TextFieldInputType.h

  Log Message:
  -----------
  stagent.dev: Clicking email field on sign up form does not allow input until you click a second time
https://bugs.webkit.org/show_bug.cgi?id=245976
rdar://98341809

Reviewed by Wenson Hsieh.

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.

Note that an attempt to fix this issue was made earlier in 255229 at main. However,
that fix was reverted due to crashes observed as a result of synchronous event
dispatch when restoring the selection.

* 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::createShadowSubtree):
(WebCore::TextFieldInputType::createContainer):

Restore the selection after an input decoration is added. Restoration is only
performed when a decoration is added to an already created input, and is
performed asynchronously to avoid running script while adding a decoration.

* Source/WebCore/html/TextFieldInputType.h:

Canonical link: https://commits.webkit.org/256581@main