Chrome version 73 causing problems

[hydemalion]

In Chrome 73 desktop we're seeing various odd behaviors in both the newest version of pickadate and the older version we were using.

One user reported the datepicker opens as soon as the page loads instead of waiting for him to click on the input. (unable to reproduce as of yet).

I myself am seeing the datepicker close and run the OnClose event immediately after clicking to open it.

On the examples on your demo site https://amsul.ca/pickadate.js/, I'm seeing what appears to be the datepicker opening twice; it flashes up, then flashes down, then flashes up again. In the console, for the events example that logs the events I see "opened up", "closed now", and then "opened up" again.

I don't see any of this behavior in Edge or Firefox. I also didn't see the problem in Chrome 72,

[nicolomonili]

Yes the problem is solved (in my case). I did the tests on Google Chrome v73.0.3683.75. I tried with 50/60/70/80/90/100.

[hydemalion]

With a value of 100 seems to be much better!

Does it solve your problem?

@amsul should we increase it? Keep in mind that we also have to change it in the tests then.

@DanielRuf I also have found that 50 isn't a long enough timeout for me, in testing.

[DanielRuf]

https://github.com/amsul/pickadate.js/pull/1142 should improve this.

[mvaragnat]

I tested the patch proposed by @caseyjhol (on version 3.5, for CSS reasons. I hope it doesn't change the logic below). It seems to me that it works better than the implemented solution...

My understanding of the problem : Using a Mac Pro trackpad, a "click" triggers a parasit click event on Chrome 73, when the finger is released. This click event does not have the right target for reasons that escape me. It therefore triggers the click listener set in the "open" function, to close the picker.

• the implemented solution adds a minimum delay for the closing click. This filters out most parasit clicks from Chrome 73. However if the user takes too much time to release her finger, the delay can easily be larger than the min delay, and the picker will be closed

• the patch from @caseyjhol sets the right path for the event. I don't fully understand what is going on with the event etc, but it is less fragile to user behavior

Am I missing something? Thanks for your code and reactivity in any case

[DanielRuf]

See https://github.com/amsul/pickadate.js/issues/1138#issuecomment-473347446

[DanielRuf]

@caseyjhol not sure if your code + mine correctly resolves it. Currently it is a nasty regression in Chromium and we should not try to fix browser bugs especially if they are so complicated.

[mvaragnat]

I think it's good that you guys have worked on a patch because it's breaking for our users 👍 perhaps a combination of both solutions could be the most robust I don't know

[leads]

Our team had this issue. FWIW we are using the classic theme and it was only an issue when the datepicker opened directly above the input. In the end we just changed the CSS so the .picker opened below the input.

[ConradSollitt]

This is still an ongoing issue in Chrome 85 and I see pickadate.js has not been updated in over a year so I'm not sure if this project is abandoned or not.

Anyways in case other developers find this here is a solution on how to solve this.

https://stackoverflow.com/questions/55200244/materialize-date-picker-automatically-hide-after-opening-problem-on-chrome

var $input = $('.datepicker').pickadate({
    selectMonths: true,
    selectYears: true,
    format: 'yyyy-mm-dd',
});
$input.on('mousedown', function cancelEvent(evt) {
    evt.preventDefault();
});

[DanielRuf]

@ConradSollitt it should be fixed in the latest release

Materialize (I'm currently one of the maintainers of a fork and I worked on it too) bundles a custom and old version of pickadate.

Still, Google has to fix their stuff. I guess the bugreport is still open.