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

Date input types weirdly when date boundaries are set with spread attributes in Chrome #6751

Closed
Wojmis3 opened this issue Sep 21, 2021 · 4 comments
Labels
bug compiler Changes relating to the compiler

Comments

@Wojmis3
Copy link

Wojmis3 commented Sep 21, 2021

Describe the bug

When date input has directly set minimal date (min={mindatestring}) it behaves nicely. When typing "21" it types 02 then 21.

When it is set with {...attributes} where attributes={min:mindatestring} it behaves unexpectedly: typing 21 gives 02 then 01, to type 21 you need to type 221 (so second two doesn't trigger the on:input event, I think).

I would expect these two to give the same result.

This occurs in the current version 3.42.6, the earliest I found it occur is 3.24.0 and is probably associated with the fix of #4418

Reproduction

This code has some extra comments in the script tag, but they are basically repeating the description.
https://svelte.dev/repl/cf4fdde9695049ad807dd8412c346a6e?version=3.24.0

Logs

No response

System Info

Chrome 93, works as expected in Firefox 92.0

Severity

annoyance

@dummdidumm dummdidumm added bug compiler Changes relating to the compiler labels Sep 21, 2021
@Conduitry
Copy link
Member

Similarly to #6752, I bet this is a difference in how Chrome handles the min attribute and the min property (which gets set when using a spread). If that's what it is, I'm not sure what would be a good way to handle this, either.

@TylerRick
Copy link

I ran into this bug as well.

I hadn't noticed the problem with entering the day before. For me, what I noticed was I couldn't enter the year. Just entering the first 2 digits, "20", caused the entire value to get reset to ''. Very annoying. (But now I know the workaround, thanks!)

Here's my REPL: https://svelte.dev/repl/eb22a3694b834c22b1594662eea1bd23?version=3.46.6

@TylerRick
Copy link

TylerRick commented Apr 8, 2022

Unfortunately, the workaround doesn't work if you're using SMUI Textfield component, because it internally relies on a spread:

      <Input
        bind:this={input}
        {type}
        {disabled}
        {required}
        bind:value
        ...
        {...prefixFilter($$restProps, 'input$')}
      />

Updated my REPL to include this broken case too.

Can we get the fix PR #6758 merged please, assuming there is no reason not to merge it?

@baseballyama
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug compiler Changes relating to the compiler
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants