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
Created attachment 413223 [details]
Created attachment 413351 [details]
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]
Created attachment 413442 [details]
Comment on attachment 413442 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=413442&action=review
> + 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)
> + PlaceCursorAtStart,
Also, this should be (selection) Caret, not (mouse) Cursor :P
> + 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]
Committed r269587: <https://trac.webkit.org/changeset/269587>
All reviewed patches have been landed. Closing bug and clearing flags on attachment 413483 [details].