The new behavior is normal / expected for text input.

hcarmona@ / dpapad@ / sgabriel@ - Can you think of any reason why we might not want this behavior here (and possibly elsewhere)? I think it makes the focused UI more obvious, and it's one less keystroke or double-click for the user to overwrite the default / placeholder name.

@stevenjb: Observing how a native <input> behaves I see the following (example at https://jsfiddle.net/c1u65tmr/1/):

1) Auto selects the text if the user focuses it via the Tab key.
2) Does not auto select if the user focuses by click.
3) Does not auto select if focus() is called programmatically.

Having similar behavior with cr-input seems reasonable. IIUC, the case here is that #3 behaves differently among native and cr-input?

3) Is actually a bit less straightforward. If you tab into the 1st input (selecting the text), or select any part of the text, then click 'focus 1st input problematically', then the text is selected.

I'll need to do some experimentation to see how cr-input behaves. Matching the <input> behavior exactly might be more of a PITA than it's worth.

sgabriel@, do you have an opinion about which behavior from the initial description is preferred, 'actual' or 'expected'?

+scottchen

>  If you tab into the 1st input (selecting the text), or select any part of the text, then click 'focus 1st input problematically', then the text is selected.

If the 1st input is focused, and the button is clicked, I see the selection being preserved. Is that what you are also describing?

Either way, I don't think this needs to be a P1 bug, and also maybe scottchen@ can comment on whether we need to do anything special about cr-input's focus. IIUC, it should delegate focus to the inner native <input>, and we should be getting most (if not all) of the same functionality for free.

re #3. In this specific case "actual" is better as it enables the user to quickly modify the name.

Can someone clarify if clicking any cr-input now automatically selects the text?

Native <input> prioritizes the "append text" case, and does not auto select the text. Chrome's omnibox on the other hand prioritizes the "replace text" case and auto selects the text.

Having all our cr-inputs priortizing the "replace text" case does not seem optimal to me (again this depends on the answer to my 1st question).

If this is only affecting the Person input, then I don't have strong preference one way or the other.

stevenjb@ I think having mouse-click focus select text is more "unexpected", than tab & shift-tab behaving differently, so maybe we should revert the cr-input change in https://chromium-review.googlesource.com/c/chromium/src/+/1217747.

Or, we could detect whether the focus comes from mouse or keyboard, and don't select text if focus comes from mouse.

I think the most tricky might be "do not select text when programatically called .focus()", because we're mimicking some keyboard-focus by actually programatically focusing in order to work around some weird tab-index-with-shadow-dom issue, but it might be okay if we let programmatic .focus() calls select text, as long as we fix it for the mouse-click case.

Let's step back, I think there is some confusion here.

*clicking* in <cr-input> field does not select anything in any case as far as I am aware. (i.e. it has the expected behavior of de-selecting anything and setting the cursor position, same as with <input>).

The *programatic* focus() behavior for <input> appears to have no affect on the selection, i.e. if the text was selected previously (e.g. with tab focus), then focus() will show the text as selected. If not, it will stay unselected. That is what I was trying to describe in comment #3. Note: It doesn't prioritize "append", if anything it prioritizes "prepend", which doesn't seem very useful to me.

The *programatic* focus() behavior for <cr-input> is unknown (setting up a test is not completely trivial), but I suspect that it currently behaves the same tab-focus, i.e. we always select the contents of the field.

This is unlikely to be common. It will only occur when the default focused (i.e. first) field of a page or dialog is an editable text field that is already populated with content (e.g. the 'add person' overlay).

Given that sgabriel@ prefers the current behavior in this case, I am going to mark this as WontFix, and if we encounter another instance where the behavior is undesirable, we can either fix that example or modify cr-input behavior.