feature request: fallback alert/confirm on popups

[frequent]

@gabrielschulhof:

As I'm struggling with the popup closing hashChange I set up fallback alert/confirm messages as a fallback. Would be nice to have this as an option, so if a popup had a class of popContent and looked like so:

<div data-role="popup" id="pop_entry" data-theme="a" data-fallback="alert">          
        <div class="ui-content popContent">#tx_basket_pop_info#</br></br>#tx_basket_pop_hint#</div>           
</div>  

I'm now fallback to something like this when opening the popup:

var txt = $('#pop_entry.popContent').text();
alert( txt );

Could also be done with a confirm (data-true/false=respective_action)

On the other hand, maybe this is a little against the idea of the widget. Nevertheless, features request :-)

[gabrielschulhof]

IIUC, you could use a "popupbeforeclose" event whose default can be prevented, causing the popup to stay on screen. We already have "popupbeforeopen" which cannot be used to prevent the popup from opening, but which gives the developer an opportunity to improve the cosmetics of the popup before it appears on screen (such as auto-scaling images to fit the current window size).

Realize though that popups can also be dismissed via the "Back" button, so, if we wanted to prevent that as well, we'd have to do an ugly thing where the user is hitting "Back", and our code says "Back? Nononono ... go forward again, to the popup!", resulting in a quick-succession back->forward in the browser history like those annoying sites where you click "Back" and it won't let you go back. Now, I don't know for sure that this cannot be made smooth, but I have a nagging suspicion that it may involve some ugly code. I hope I'm wrong.

[arschmitz]

What if you have an option to prevent the popup from being tracked in history. So then when you click back it goes back to the previous page . So it would work basically like a jquery ui dialog.

[gabrielschulhof]

You do have this option: $.mobile.enableHashListening ... however, this option turns hash listening on and off for popups, pages, and dialogs, so you basically have to provide navigation yourself.

We have considered doing a special case where popups and dialogs behave as they would in the$.mobile.enableHashListening = false case - namely, when the dialog or popup is opened from a page that was itself added with changePage(, url, { changeHash: false } ), but we have decided not to handle that special case because it would further complicate the navigation model (#4595).

As I said in my previous comment, if we were to implement this prevent-popup-from-being-closed-by-the-user scenario, it can be implemented, but I'm not sure how elegant the implementation would be.

[frequent]

@gabrielschulhof - hm. let me check back into this. I will need a few days to finish my current project, then I will have a look . Since I replaced all popups in my project with alerts to "tame" the browser going back, I have not really paid much attention to popups anymore. Alerts sure a nice... :-)

[jaspermdegroot]

@frequent

I am closing this ticket for now as a feature request and added a link here https://github.com/jquery/jquery-mobile/wiki/Feature-Requests.