[text field] Fix inconsistent input caret position on focus

[shalini-saloni]

This PR fixes a bug where clicking on the InputBase wrapper (outside the actual element) causes the caret to jump to the beginning of the input value.

Problem

When clicking inside the InputBase container but not directly on the native input, MUI programmatically forwards focus to the input:

inputRef.current.focus();

Some browsers reset the caret position to 0 when focus is forwarded this way, resulting in unexpected cursor behavior.

Solution

This change:

Saves the current caret position before forwarding focus

Restores the caret position on the next animation frame

Adds a safe type guard to ensure setSelectionRange is called only on valid inputs

Removes unnecessary console logging and try/catch blocks

This ensures the caret remains at the correct position when clicking anywhere inside the input container.

Related Issue

Fixes #47336

[mui-bot]

Netlify deploy preview

https://deploy-preview-47340--material-ui.netlify.app/

Bundle size report

Bundle	Parsed size	Gzip size
@mui/material	🔺+299B(+0.06%)	🔺+91B(+0.06%)
@mui/lab	0B(0.00%)	0B(0.00%)
@mui/system	0B(0.00%)	0B(0.00%)
@mui/utils	0B(0.00%)	0B(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against b2362ce

[mj12albert]

Should not use instanceof as it's inconsistent across window contexts

[shalini-saloni]

Thanks for the feedback!
I’ve removed the instanceof check and replaced it with a safer, window-agnostic guard (checking for .setSelectionRange and .focus).

The updated approach no longer depends on instanceof and works correctly across window contexts.

[mj12albert]

FYI tests would be needed

[shalini-saloni]

FYI tests would be needed

I’ve added a unit test to cover caret-position preservation when clicking the wrapper.
The test verifies that the caret stays at its previous position and that clicking the wrapper doesn’t reset it.
Please let me know if you'd like additional scenarios covered!