When using 'Custom Select Menus' that display on a separate dialog page, we have a problem with change events being triggered too soon, before the dialog has closed. This is causing issues for us because we have code that relies on the calling page being the active page, when this event triggers.
I'll try and explain the issue. Our framework allows developers to build mobile applications, which is powered by jQuery Mobile behind the scenes. We have a specific situation within the framework that allows developers to define on change behaviour on a select list, and where the page will submit automatically once the select change event triggers. When this select list is a JQM custom select list that displays in the dialog, this is causing issues because the page submission code relies on the calling page being the active page. I will try and explain why, with the following overview of what happens:
So the page loads and it contains a select list with 'data-native-menu="false"', so will load a custom select menu. The user opens the select menu and the dialog page opens with the list of values.
gPageContext$ is set to the dialog, by virtue of the 'pageshow' event firing when the dialog opens.
User selects a value in the dialog.
Change event fires immediately, before the dialog closes and obviously before the 'pageshow' event fires (which would be the one we could utilise to set our 'page context' back to the active page). This results in our page submission code executing, which then fails because gPageContext$ is still set to the dialog, not the calling page.
We are investigating ways to get around this, but I wanted to ask if others thought the fact that the 'change' event fires first before the dialog closes is correct, or whether that should indeed fire when the dialog has closed, and the calling page is back to the active page again?
I don't know why you would expect the change event to be dispatched after the dialog closes. I believe that you're thinking about dialogs incorrectly. It's still treated as a separate page as far as JQM is concerned, it's just styled to look like a dialog instead of a typical page. The DOM management is slightly different for dialogs than "normal" JQM pages, but they're still treated as distinct pages by the framework.
I don't know why your event handler above isn't just using $.mobile.activePage as a reference to the current page. jQuery Mobile already stores a reference to the current active page using the 'toPage' attribute of the page change events. Speaking directly to your event handler code, I don't know why you wouldn't just use a :not selector to exclude overriding the "current page context" when your dialog is displayed.
I guess maybe I understand what you think you *want* to do but I would still question why it even makes sense to want to access the previous page or other action on the original calling page from the dialog in the first place. I'm not convinced that maybe just because you can that isn't really the appropriate way to use the framework. At the very least, I think it would be fragile and be subject to break if and when JQM navigation is refactored in future releases. Why don't you consider using the popup functionality instead of trying to force a dialog page into the behavior you want?
Leave a comment on bagman's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic