BUGFIX: Ensure that <DropDown/> closes only after the current call-stack has been processed

[grebaldi]

fixes: #3305

The Problem

The behavior described in #3305 is a regression through #3211.

#3211 made sure that the <Label/> around the auto-publish checkbox is clickable. Normally, one would expect that clicking on the label would trigger a change in the corresponding checkbox input through event delegation.

To illustrate that idea:

      (User clicks on <Label/>)
                │
                │ // Click event is being delegated to the corresponding
                │ // <input type="checkbox"> element
                │
                ▼
(<CheckBox/> OnChange event happens)

Clicking inside the <DropDown.Contents/> also causes the outer <DropDown/> to close. Closing the <DropDown/> means, that the <DropDown.Contents/> are removed from the DOM.

This update mechanism is handled by React in a way that is non-deterministic (at least to us it is). This means that sometimes the <DropDown.Contents/> are removed before the Click event from the <Label/> component reaches the corresponding checkbox input:

 (User clicks on <Label/>)
            │
            💥 ◀─────── (DropDown.Contents are removed from DOM)
            ┊
            ▼
(<CheckBox/> is gone...)

The Solution

I lieu of setImmediate-support in browsers, I wrapped the toggling mechanism of the <DropDown/>-component in a setTimeout(..., 0) call.

This makes sure that components inside the <DropDown.Contents/> will receive all events that are currently scheduled, before the <DropDown.Contents/> are removed from the DOM.

[Sebobo]

Thx Wilhelm!

I don't like that we need this kind of workaround but I can confirm that it resolves the issue.
We should have a different component for this kind of mechanism which doesn't do event magic.

[crydotsnake]

Thanks! Works as expected :)!