Double click on dialog close btn cause double back

[offsky]

Go to the jqm demos and open a dialog. Press the X button twice (double click). It will cause the dialog to close (correct) AND go back one level in the navigation history (not correct).

This is especially noticeable on slower devices, since there is a several second lag between hitting the X button and anything happening, so a user may think that they didn't tap the button properly and tap again.

[toddparker]

There is a tradeoff here. We could disable all user interaction once a nav link is pressed to fix this situation, but that would mean that we'd take away the ability to change your mind and click on another link. Say, for example, you click on a list item and the loader pops up and you realize that it was the wrong item or you changed you mind, you wouldn't be able to click on another link and a refresh would be required.

We're open to ideas here, just wanted to explain why things works the way they do.

[offsky]

How about just detecting and preventing double clicks? With slow transitions between pages, people are going to be tapping multiple times on links because they think they didn't tap right the first time.

In any case, tapping a second time on the dialog close button should not be causing the previous page to get a "history back" event. It should be smart enough to realize that the dialog is already closed, and do nothing.

[offsky]

I have dug into this a little more, and I think I may have found the specific behavior that needs to change. When you click the dialog close button, it starts a chain of page show, hide, change events. Specifically, the dialog will first get a pageBeforeHide and then a pageHide event. If you happen to click the close button again between these two events, it will cause the "close" to be incorrect triggered on the page that launched the dialog instead of applying it to the dialog and discarding the event since you can't close a dialog twice.

Since some mobile devices are slow, it could take several seconds between pageBeforeHide and pageHide, especially if the transition page is doing some DOM heavy setup. During these several seconds, the user may think that the browser didn't register their click and may click again, thus triggering this bug.

I agree that we should not block events during transitions so that people can change their minds. The bug is that if you click a link during a transition, the event can be sent to the new page instead of the page that the link was on.

[gabrielschulhof]

We need not disable all user interaction, just the click handler for the dialog's close button. We can set a boolean variable during the dialog's _create() indicating that the "Close" button has never been clicked, and modify the "Close" button's click handler to only close the dialog if this variable still indicates that the "Close" button has never been clicked. During the first run of the "Close" button's click handler, we set the variable to false (indicating that the "Close" button has already been clicked once) and then we close the dialog. Thus, a second click of the "Close" button will have no effect.

We can restore the initial state of the variable during pagehide, so as not to permanently destroy the user's ability to close the dialog via the "Close" button - after all, the dialog widget may be reused - shown again later.

This is what the related PR does.