Changing listview data then calling changePage causes the dom to drop html

[jostster]

I've noticed that using a list that gets refreshed then calling a changePage or navigation away after that list item is refreshed causes the previous page's HTML to get completely removed from the DOM.

I't is hard to explain but I would like to give jquery-mobile developers access to our product so they can see it. Please contact me privately for login details.

Steps to reproduce.
Add an appointment
Click Save
The changePage takes you back to the listview.
If you are using inspect element you will notice the createAppointment html is now completely removed. Click the create appointment link again now errors out because the selector cannot be found.

jqm version
1.0b2
jquery version
1.6.2

[jblas]

@jostster

There were some changes that were added to jQuery Mobile for Beta 2 to help keep the DOM from growing out of control. If you want the old behavior, you can either turn off this automatic pruning, or pick and choose what pages should be kept in memory. You can find the details here:

http://jquerymobile.com/test/#/test/docs/pages/page-cache.html

• Kin

[jblas]

Actually I meant to point you to the beta 2 version of the docs:

http://jquerymobile.com/demos/1.0b2/#/demos/1.0b2/docs/pages/page-cache.html

[jostster]

I don't think that is the issue. Visit the page does not bring it back or requery ajax. Also clicking the save button on the page that gets removed from HTML is what triggers the ajax event to save the data then request a refresh of the data from the server. If anything the html should stay there so that it can be called upon later instead of just removing it completely.

[jblas]

@jostster

Shoot me a private email via github with the details of how to view the problem first-hand.

• Kin

[jostster]

@jblas Done

[jostster]

@jblas I tried setting $.mobile.page.prototype.options.domCache = true; just to see if this would help the issue but setting the domCache to true still removes the page element from the html.

[jblas]

Ok, so I debugged this on @jostster's system. the basic setup is that he has a listview with list items that when clicked, brings up an internal page with a form on it. There are several 'custom' selects on this page several of which are dialog selects, and the rest the small overlay select.

He programatically calls change page when a 'save' button is clicked, and the changePage request is for the page we came from. The culprit removing the form page is the pagehide callback registered from the select's close() function:

    if ( self.menuType == "page" ) {
        // rebind the page remove that was unbound in the open function
        // to allow for the parent page removal from actions other than the use
        // of a dialog sized custom select
        self.thisPage.bind( "pagehide.remove", function(){
            $(this).remove();
        });

The 'this' reference in the callback is the page containing the actual select. I'm not familiar with that code, but I'm guessing it should be the custom select dialog that is getting removed. Right @jbender?

[johnbender]

@jostster and @kinblas,

First, there's a bug fix in HEAD that only binds the remove when domcache allows it. That should give you a workaround in the short term.

The purpose of that rebinding is just as the comment says. We don't want to remove the page that a dialog comes from when we open said dialog, but we do want to remove that page when we go elsewhere so we disable it temporarily and then re-enable it. The dialog itself will be removed by the other pagehide.remove binding.

So:

Page1 -> Dialog - preserve Page1
Page1 -> Dialog -> Page1 -> Page2  - remove Page1

From what it the flow here appears to be

Listview -> Form -> Dialog -> Form -> Listview

In which case the Form is being removed as we expect it to be. I would decorate the Form page with data-dom-cache false with the code from HEAD assuming I've understood the issue.

[jostster]

@johnbender I have tried the head yesterday and received a bunch of errors upon using it. However i thought the issue was happening before the domCache event.

[jblas]

@jostster

I'm not sure if you want to hand patch your source or not, but this is the 'if' check (bug fix) @johnbender was referring to in the HEAD:

https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.forms.select.custom.js#L251

if ( self.menuType == "page" ) {
    // rebind the page remove that was unbound in the open function
    // to allow for the parent page removal from actions other than the use
    // of a dialog sized custom select
    if( !self.thisPage.data("page").options.domCache ){
        self.thisPage.bind( "pagehide.remove", function() {
            $(this).remove();
        });
    }

[jblas]

@johnbender

Thinking about this a bit more. We shouldn't be removing and restoring event handlers outside of the navigation code that does the pruning. Instead, we should probably introduce a concept of a lock attribute that the remove binding checks before actually executing the remove(). That way we can keep the details of how a page is pruned in one spot in the framework.

The locking mechanism can be a $.mobile.xxx API function that sets and/or increments a lock attribute on domCache=false elements.

[jostster]

@johnbender @JBIAS Thanks, I compiled the head and it worked just fine, I was getting 404 errors because we have our images directory in our root instead of in css so I just did a search replace in the css and that fixed it.

[johnbender]

@jblas

If there isn't a TODO in there for that disjoint bit of code there should be.