this appears to be longstanding behavior of WebKit (`HTMLInputElement::updateFocusAppearance` calls `select` or something with an equivalent effect), but I'm not really sure why both Chrome and Firefox do not have this behavior
<rdar://problem/60130704>
Created attachment 413223 [details] Patch
Created attachment 413351 [details] Patch my initial attempt had more behavior change "ripples" than i'd anticipated, so here's another approach that's (hopefully) far more targeted in behavior change putting this up before writing tests to see if EWS still has issues with this approach
Created attachment 413371 [details] Patch
Created attachment 413442 [details] Patch
Comment on attachment 413442 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=413442&action=review > Source/WebCore/dom/Document.h:292 > + Restore, // If there is no previous selection, this behaves like SelectAll. Nit - it's a little more verbose, but maybe `RestoreOrSelectAll`? (and remove the comment) > Source/WebCore/dom/Document.h:293 > + PlaceCursorAtStart, Also, this should be (selection) Caret, not (mouse) Cursor :P > LayoutTests/fast/forms/input-text-autofocus.html:27 > + shouldBe("input.selectionStart", UIHelper.isIOSFamily() ? "3" : "0"); > + shouldBe("input.selectionEnd", UIHelper.isIOSFamily() ? "3" : "0"); We generally try to avoid platform-specific logic like this in tests, if possible. Can we just override the editing behavior instead, and make all platforms yield the same results?
Created attachment 413483 [details] Patch
Committed r269587: <https://trac.webkit.org/changeset/269587> All reviewed patches have been landed. Closing bug and clearing flags on attachment 413483 [details].