Problem with two datepickers for date range on Safari

[InekeScheffers]

On Safari when you select a date on one of the datepickers and change to the other datepicker too quickly, both open the calendar and the focus on the input fields keeps switching.

[cliener]

I've seen similar oddities in iOS Safari. Looks like events are firing out of order potentially related to #597
May also be related to #830

[echarso]

Hi I am facing the same issue here with Safari

[pmacmillan]

The place where the click happens seems to matter.

If I click past the end of input, everything works fine. If I click in the middle of the input, the issue crops up.

[pmacmillan]

What I am seeing is: if I have one open and...

• click after the end of the other input, then handleCalendarClickOutside gets called
• click within the value of the other input, handleCalendarClickOutside is never called

In both cases, onBlur is called, but in the second instance the value of this.state.open is true and the component uses deferFocusInput to regain focus.

(all within src/datepicker.jsx).

In Chrome and Firefox, handleCalendarClickOutside is always called.

[pmacmillan]

Looks like Safari is event drunk.

vs

from: https://www.quirksmode.org/dom/events/tests/blurfocus.html

Basically, if you click within the content of the text input with another input element focused, you get something like:

blur on textarea
focus on text
blur on text
focus on textarea
blur on textarea
focus on text

This would explain the observed behaviour.

I suppose an approach to fix this might be to debounce the focus/blur events, reacting only to the last one... but... yikes.

[pmacmillan]

Interesting: facebook/react#10871 Related?

[pmacmillan]

At issue are the spurious events that safari seems to emit like crazy.

In thinking about this issue, I found this workaround.

As a proof of concept, I created this fiddle to demonstrate the problem and the workaround (see capture from safari below).

So, I think I'm on to a workaround here and would totally welcome feedback before plodding any further ahead ;)

[pmacmillan]

This gist provides a WIP workaround for the issue in Safari. Supplying it to DatePicker as a custom input seems to resolve the issue:

https://gist.github.com/pmacmillan/5e78836821ac22031567382dadd4a72e

But I'm not terribly happy with it and I don't think it belongs in this library (i.e. it feels like should be fixed either as part of React or as part of an environment compat polyfill).

[cliener]

The same problem here triggers a crash in Safari iOS however whatever is underlying cause seems to be different. Having stolen @pmacmillan's code, I have a test case that breaks in MacOS Safari only. Need to investigate more to find out what's causing issues in Safari.

[cliener]

I've put together a fix (in part borrowing @pmacmillan's work) though I'm unsure if it should live inside React or as a separate library. Assuming the latter, it's now available for implementation: https://github.com/cliener/input-fixer
I'm now working on a fork of react-datepicker incorporating this library. Stay tuned!

[cliener]

My fork is done https://github.com/cliener/react-datepicker
Scoped npm install if anyone's keen https://www.npmjs.com/package/@cliener/react-datepicker

I've fixed the immediate problem of the endless event loop however we're now left with the the originally opened calendar sometimes stays open. Removing outsideClickIgnoreClass={outsideClickIgnoreClass} from line 440 fixes this issue but then leaves the problem of the calendar re-rendering every time the input is clicked.

I've made some attempt at resolving this bug but don't haven't yet found a solution. I'm open to suggestions/contributions on this.

It seems a similar endless loop in iOS has also been fixed with the changes I've made. I'll test this shortly.

Any thoughts about whether I should create a PR at this point?

[cliener]

PR as above. The code is now in a better state having at least fixed the endless loop. iOS Safari is entirely happy now from my tests.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.