Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cursor misbehaviour in Safari's <input> controls #3449

Closed
lahickey opened this issue Aug 22, 2019 · 4 comments · Fixed by #4179
Closed

Cursor misbehaviour in Safari's <input> controls #3449

lahickey opened this issue Aug 22, 2019 · 4 comments · Fixed by #4179
Labels

Comments

@lahickey
Copy link

Describe the bug
In Safari (12.1.2), when adding an <input> control with manual two-way binding - by using an 'on:input' handler for instance - changing the contents of the <input> control at any point other than the end of the word causes the cursor to jump to the end of the control.

This does not happen in Chrome (76.0.3809.100) or Firefox (68.0.2). I have not been able to test Edge yet.

To Reproduce
Check out this minimal REPL - https://svelte.dev/repl/db64dcebc4da4ab89100870a9fe7522b?version=3.9.1

In Safari (12.1.2), select the input control in the middle and make any sort of edit. Notice how the cursor jumps to the end of the input control.

Expected behavior
Consistent behaviour across all modern browsers

Severity
Annoying, however I suspect it'll catch more people out as it's such a simple thing to try. I've worked around it by having the variable updated by on:input be different from the one that is used as the initial {value} of the control. I cannot use two-way binding in this case because I'm using the on:input to handle validation.

@Conduitry Conduitry added the bug label Aug 28, 2019
@Vages
Copy link
Contributor

Vages commented Sep 10, 2019

I've been looking into this for about an hour. No results so far, but there seemed to be a similar problem in Elm for a while: elm/html#174

@Conduitry
Copy link
Member

Fixed in 3.17.0.

@dak0rn
Copy link

dak0rn commented Jan 28, 2020

I can still reproduce that issue on 3.18.1 in Safari (macOS and iOS) by moving the assignment into its own component.

https://svelte.dev/repl/0c54225119274537823c4d1077629550?version=3.18.1

@dak0rn
Copy link

dak0rn commented Jan 28, 2020

The problem here seems to be {...$$props}, used to have something similar to Vue's Non-prop attributes/attribute inheritance. Works when it is omitted:

Demonstration:
https://svelte.dev/repl/af09fae984e4408c8b302a27981cf1c2?version=3.18.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants