Material: datepicker: automatically closes/doesn't open after updating to Chrome 73

[kdeclerck]

Bug, enhancement request, or proposal:

Bug. Several client libraries have this issue on Chrome 73 (for example see https://support.google.com/chrome/thread/3363391?hl=en) but figured I'd log an issue on the material repository as well. Behaviour seems better (but still sometimes breaks) after 1.1.13 probably because of this commit: https://github.com/angular/material/commit/45e92ea49ba38c4647f335f5fca0bd908ccb099e.

CodePen and steps to reproduce the issue:

CodePen Demo which demonstrates the issue:

Detailed Reproduction Steps:

Reproduce on Chrome 73:

1. Click in the date input field
2. Select a date
3. Click outside the date input field
4. Click on the date input field

What is the expected behavior?

The date picker should open when clicking inside the md-datepicker input field.

What is the current behavior?

In Chrome 73 the datepicker often closes immediately after focusing the date field (with md-open-on-focus).

What is the use-case or motivation for changing an existing behavior?

/

Which versions of AngularJS, Material, OS, and browsers are affected?

• AngularJS: Broken on 1.6.x and 1.7.x, possibly all
• AngularJS Material: Broken on < 1.1.13
• OS: Windows
• Browsers: Chrome 73

[lievenjanssen]

Other datepicker libs seem to have similar issues since Chrome 73 (and hotfixed it):

• https://github.com/amsul/pickadate.js/issues/1138
• https://github.com/GwtMaterialDesign/gwt-material/issues/901

[Splaktar]

I updated the CodePen for 1.1.18 and while it does function better than with 1.1.12, it appears that with enough use, you can get it to start closing right after opening similar to what Firefox used to do before the fix in 1.1.13.

[Splaktar]

Thanks for those links. I was able to find the related Chromium regression in the pickadate.js issue. I added a link to this issue along with some details. It's still marked "Needs Feedback", so maybe that will help them unblock this and find a solution.

[Splaktar]

It looks like the gwt-material fix was the same that we used for Firefox (moving from 0ms to 100ms timeout). However that doesn't always seem to be enough. I could perhaps try 150ms or 200ms to see if that covered most of the cases, however it would certainly be preferred to see this fixed in Chrome.

[Splaktar]

Feedback from the Chromium issue

One of the things I can imagine is to just change the mousedown to click action to open the calendar instead. Alternatively you can change the DOM structure so that the input that first user does a mousedown and the calendar that they release the mouse has a common parent that stops propagating the click event to the document which has a click handler that closes the calendar popup.

The second option is not viable as this would be a significant breaking change for users of the library.

The first option regarding possibly changing how the mouse events are handled needs investigation.

[MsCSAngel]

Hello All. Wondering if there is an update on this issue?

[Splaktar]

The latest update is that the Chromium author of the regression is claiming that the behavior was undocumented and thus it is OK to break most all date/time pickers on the internet. Library authors are pushing back on that atm.

[Splaktar]

A timeout of 200ms does indeed provide for consistent behavior on Chrome for macOS. But I need feedback from a wider range of devices to determine if this is sufficient. Please try out the version from PR https://github.com/angular/material/pull/11719 and provide feedback there.

[NavidZ]

I had a quick question here. Any reason that the date picker here chooses to open the popup on mousedown when clicking on the input box but opening it on mouseup/click when clicking on the little arrow on the right side? Can we just change that to open it on click all the time? It is more consistent and also resolves this issue.

[Splaktar]

@NavidZ thank you for taking a look over there.

We're seeing problems when triggering the panel to open via a focus event on the input:
https://github.com/angular/material/blob/4a283cecd9bb2baab924b550c8c82656bc38728f/src/components/datepicker/js/datepickerDirective.js#L540

We do have a keydown check for alt+down arrow, but that seems to be unrelated and working fine:
https://github.com/angular/material/blob/4a283cecd9bb2baab924b550c8c82656bc38728f/src/components/datepicker/js/datepickerDirective.js#L531-L537

As you mentioned, we do use the click event for the calendar icon or the triangle icon in the input
https://github.com/angular/material/blob/4a283cecd9bb2baab924b550c8c82656bc38728f/src/components/datepicker/js/datepickerDirective.js#L85-L105

But I can't find anywhere that we use the mousedown event for datepicker?
We do use touchstart for iOS compatibility. Is that what you are referring to?
https://github.com/angular/material/blob/4a283cecd9bb2baab924b550c8c82656bc38728f/src/components/datepicker/js/datepickerDirective.js#L826-L833

[NavidZ]

I see. focus does indeed happen on mousedown and that is probably what opens that trigger. So the current behavior is focus opens the popup on the input which also happens on mousedown if the element was not focused already. This does create a little inconsistency with respect to that triangle button that I personally don't like but who am I to judge. :)

I believe if we would like to achieve this intended behavior there is a more predictable way to get there instead of the timeout which is flaky and obviously depends on how long user kept the button down.

How about we use pointercapture then. Obviously the usual feature check and everything applies but before we get to how to add that feature to the code base how about you try this snippet in the Chrome Devtools and see whether the behavior sounds fine to you or not:

document.querySelector('.md-datepicker-input').addEventListener('click', e=>e.stopPropagation());
document.querySelector('.md-datepicker-input').addEventListener('pointerdown', e=>e.target.setPointerCapture(e.pointerId));

Note that you need to load that demo url in the first. Then right click on a white space on that page and inspect element (so that not only it opens DevTools but also it loads the elements so the above commands doesn't just give you error that it couldn't find the elements). Then go to console tab in the Devtools and paste those two lines. Now give it a try and let me know what you think

[Splaktar]

@NavidZ Yeah, you have a good point with concern to the user possibly pressing the mousedown longer than 200ms when moving focus to the input. This does indeed still have the auto close behavior that we're trying to solve.

The change you are suggesting appears to improve the behavior. I was concerned about the keyboard focus behavior, but it looks like that is still intact and working properly.

I will have to read up on this setPointerCapture API. Thank you for the info.

[Splaktar]

I updated the CodePen a bit to include the above snippet and a second datepicker for testing.

For Safari, it doesn't appear that the pointerdown events are even fired, so there doesn't appear to be a problem with the setPointerCapture call in the event handler. I also don't see any problematic behavior with Firefox for Android or Safari for iOS.

[Splaktar]

OK, PR https://github.com/angular/material/pull/11719 has been updated with the new approach and a wider set of browser tests have been run. Everything looks good!

@NavidZ thank you!

[NavidZ]

@Splaktar No worries. Anytime.
Btw, Safari is in the process of shipping pointerevents as far as I'm aware. But they haven't done it yet.

I know you mentioned also some other libraries that might have problem with the recent Chromium change. Feel free to cc me on the Github issues of those and I'll take at their code and see what needs to be done.

[avishaigurt-oviva]

This issue seems to be fixed in Chrome 74