-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
mat-datepicker with touchUI emits (closed) too soon? #17560
Closed
Labels
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Comments
crisbeto
added
has pr
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
labels
Nov 17, 2019
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Nov 17, 2019
`MatDatepicker` has focus restoration which happens (almost) synchronously, whereas `MatDialog` restores focus asynchronously when the animation is finished. This means that in `touchUi` mode focus ends up being restored both by the datepicker and the dialog within a 150ms window. The problem is that if the consumer of `MatDatepicker` decides to move focus inside the `closed` event, it'll be ovewritten by the dialog 150ms later. These changes disable the dialog's focus restoration because it's unnecessary. Fixes angular#17560.
Will be fixed by #17732. Until then your workaround with the timeout should work. |
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
Mar 6, 2020
`MatDatepicker` has focus restoration which happens (almost) synchronously, whereas `MatDialog` restores focus asynchronously when the animation is finished. This means that in `touchUi` mode focus ends up being restored both by the datepicker and the dialog within a 150ms window. The problem is that if the consumer of `MatDatepicker` decides to move focus inside the `closed` event, it'll be ovewritten by the dialog 150ms later. These changes disable the dialog's focus restoration because it's unnecessary. Fixes angular#17560.
jelbourn
pushed a commit
that referenced
this issue
Apr 23, 2020
#17732) `MatDatepicker` has focus restoration which happens (almost) synchronously, whereas `MatDialog` restores focus asynchronously when the animation is finished. This means that in `touchUi` mode focus ends up being restored both by the datepicker and the dialog within a 150ms window. The problem is that if the consumer of `MatDatepicker` decides to move focus inside the `closed` event, it'll be ovewritten by the dialog 150ms later. These changes disable the dialog's focus restoration because it's unnecessary. Fixes #17560.
jelbourn
pushed a commit
that referenced
this issue
Apr 23, 2020
#17732) `MatDatepicker` has focus restoration which happens (almost) synchronously, whereas `MatDialog` restores focus asynchronously when the animation is finished. This means that in `touchUi` mode focus ends up being restored both by the datepicker and the dialog within a 150ms window. The problem is that if the consumer of `MatDatepicker` decides to move focus inside the `closed` event, it'll be ovewritten by the dialog 150ms later. These changes disable the dialog's focus restoration because it's unnecessary. Fixes #17560.
soro-google
pushed a commit
to soro-google/components
that referenced
this issue
Apr 24, 2020
angular#17732) `MatDatepicker` has focus restoration which happens (almost) synchronously, whereas `MatDialog` restores focus asynchronously when the animation is finished. This means that in `touchUi` mode focus ends up being restored both by the datepicker and the dialog within a 150ms window. The problem is that if the consumer of `MatDatepicker` decides to move focus inside the `closed` event, it'll be ovewritten by the dialog 150ms later. These changes disable the dialog's focus restoration because it's unnecessary. Fixes angular#17560.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Reproduction
Steps to reproduce:
https://stackblitz.com/edit/components-issue-oa5rhf
Expected Behavior
picker closes and then (close) emits and input.blur() is called
Actual Behavior
close emits and blur is called before the other (focus) is called?
The screen flashes in a loop and is frozen / unresponsive
Environment
see stackblitz - everything is the latest as of today AFAIK
Note: I do have a fix for this already, if i set a BIG timeout on the input.blur() of 150 MS, then it doesn't happen.
The text was updated successfully, but these errors were encountered: