[TextField] Cursor position on Chrome after server-side rendering

[zachbradshaw]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

When clicking the label of an input that has a value, the input's cursor will appear at the beginning of the value. A second click/action is required to move the cursor to the end of the value to edit it.

Expected Behavior 🤔

When the label of a field is clicked, the input's cursor should default to the end of the value, if one exists.

Steps to Reproduce 🕹

Steps:

1. Go to the TextField demo page
2. Click on the label of a non-disabled, editable input that has a value.
3. Notice that the cursor defaults to the beginning of the value, instead of the end.

Context 🔦

We're using Material UI inputs for all of our forms, and are looking to make editing behavior as consistent as possible.

Your Environment 🌎

Tech	Version
Material-UI	v4.11.0
React	16.13.1
Browser	Chrome 86.0.4240.80
TypeScript	4.0.3

[eps1lon]

Thanks for the report 👍

When the label of a field is clicked, the input's cursor should default to the end of the value, if one exists.

This is indeed the behavior for native inputs on pristine inputs. But once the select range changes, clicking the label restores the range.

Restoring is already working with Material-UI inputs. It's just that the range is different for pristine inputs. Though it might be caused by something different (e.g. controlled vs uncontrolled?).

Either way, we need to identify what is responsible for changing the selection range. The actual label-click behavior is working correctly.

[eps1lon]

Not sure, on Chrome 86 after a hard refresh:

The point is not to force a particular behavior but try to avoid changing the selection range on pristine text fields. We could never reproduce nor we should we override native behavior.

[oliviertassinari]

It looks like an issue with our documentation, not the component itself. The behaviors are identical on https://codesandbox.io/s/angry-tdd-fh4qq?file=/src/App.js.

[eps1lon]

It looks like an issue with our documentation, not the component itself. The behaviors are identical on codesandbox.io/s/angry-tdd-fh4qq?file=/src/App.js.

Interesting. The demo cloned in codesandbox works correct as well. I also tried https://material-ui.com/components/text-fields/#form-props in an incognito window and had the same issue (suspecting it was auto-fill related).

[oliviertassinari]

It has something to do with the server-side rendering. NoSsr changes the outcome.

[oliviertassinari]

Reproduction https://codesandbox.io/s/determined-noyce-vc2tq?file=/pages/NoSsr.js

[oliviertassinari]

I think that we can close, it looks like the native behavior: same on https://getbootstrap.com/docs/4.5/components/forms/#server-side.

[eps1lon]

It has something to do with the server-side rendering.

Yes! There's a difference between <input value="foo" /> in plain HTML and a client-side rendered <input defaultValue="foo" />: https://codesandbox.io/s/serverless-field-jokfq?file=/src/index.js

Related react issues: facebook/react#18404, facebook/react#14904, facebook/react#12762

This is best raised against the React repo. The correct behavior would be to not modify the selection and keep the cursor at the start for mounted inputs. So the opposite of what you would expect.

[zachbradshaw]

@eps1lon @oliviertassinari Thanks for taking the time to check this out and for the info about SSR.