-
Notifications
You must be signed in to change notification settings - Fork 124
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 picker closes itself #752
Comments
OK, tested the previously mentioned other form, this time making sure the login inputs are not present in the DOM. And indeed the issue does not occur. |
Ok I'll check this out tomorrow including some bugs need to be fixed on 2.0.1-SNAPSHOT. |
Is there any workaround for this bug? I didn't noticed it earlier, but now I can witness it in Chrome 73 on both Linux and Windows. Picker works (mostly) when date is initially unset, but closes immediately upon click when there is any input in it (popup just flashes briefly). |
The fixed was already patched on 2.2-SNAPSHOT And demo was migrated to https://gwtmaterialdesign.github.io/gmd-core-demo/#datePicker |
This also looks good in 2.3-SNAPSHOT. |
Cool
…On Sat, Nov 9, 2019 at 6:13 AM Jason Washo ***@***.***> wrote:
This also looks good in 2.3-SNAPSHOT.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#752?email_source=notifications&email_token=AAX6EF4PUBU5WV2L7PZMRKLQSXP7FA5CNFSM4EIKQUDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDTQCTA#issuecomment-552010060>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAX6EF74QPP5HNXJEXSRVFTQSXP7FANCNFSM4EIKQUDA>
.
|
...this, together with
Chrome pre-populating the inputs with previously stored credentials
creates circumstances under which clicking the "Next month" or the "Previous month" arrow hides the date picker.When I open the page in the incognito mode (i.e. no credentials get auto-entered) the date picker behaves correctly.
Inspecting the page revealed that for some reason
focus
gets called on the username input, which then leads to the damnedclose
event getting triggered on the date picker.I have been experiencing this also with another form that contained no password inputs. The login inputs were present in the DOM though, just hidden (after successful sign-in)... I am still trying to narrow that one down.
Not sure it can play any role in anything, but I also noticed that "close" gets called on an already closed date picker when you move focus from the date input to another widget.
The text was updated successfully, but these errors were encountered: