[Fixed]-How to modify jQuery mobile history Back Button behavior

by

0👍

✅

Okay so the solution was close to the update I posted. The issue with the previous solution was that there were to many things bind-ed to the “Back” button. While my new bind action may have been working sometimes, the other actions would take place too, I tried unbind() but still no worky.

My solution is a bit of smoke and mirrors. I check to see if the the previous page was the review page and then if so, I swap out the old back button for my new faux button with the history back step like so:

$('div#wine_detail').live('pageshow',function(event, ui){
  var last = $.mobile.urlHistory.stack.length - 1;
  var last_url = $.mobile.urlHistory.stack[last].url;
  var review_url = /review/g;
  if (last_url.match(review_url) )
    {
      $('a.ui-btn-left').replaceWith('<a href="" id="time_machine" class="ui-btn-left ui-btn ui-btn-icon-left ui-btn-corner-all ui-shadow ui-btn-up-a" data-icon="arrow-l"><span class="ui-btn-inner ui-btn-corner-all"><span class="ui-btn-text">Back</span><span class="ui-icon ui-icon-arrow-l ui-icon-shadow"></span></span></a>');

      $('#time_machine').bind( 'click', function( ) {  
        console.log("click should be bound and going back in time...")
        window.history.go(-3);
        });
    }
  else
    {
      console.log('err nope its: ' + last_url);
    }

It looks exactly the same, and no one is the wiser. it could probably be improved by using the the jQm method pagebeforeshow so user could never see the swap. Hope this helps someone.

👤bmartinek

3👍

I’d prefer not to splice/pop/push with the urlHistory. How about redirect on pagebeforechange like so:

$(document).on("pagebeforechange", function (e, data) {

    var overrideToPage;

    // some for-loop to go through the urlHistory TOP>DOWN
    for (var i = $.mobile.urlHistory.activeIndex - 1; i >= 0; i--) {
        // this checks if # = your target id. You probably need to adapt this;
        if ($.mobile.urlHistory.stack[i].url = $('#yourPageId').attr('id')) {
            // save and break
            overrideToPage = $.mobile.urlHistory.stack[i].url;
            break;
        }
        // set new Page
        data.toPage = overrideToPage;
    }
});

This captures your back button changePage call and redirects to the page you want. You could also just set data.toPage = winelist directly of course.

I’m only doing this with #internal pages, but it shoudn’t be so hard to set this up with winelist.html etc.

For more info, check the event page in the JQM docs

👤frequent

2👍

Why not have a back button in the header section of your page? Something like this:

<div data-role="header">
    <a data-direction="reverse" data-role="button" href="#winelist" data-icon="back">Back</a>
    <h1>Wine Detail</h1>
</div><!-- /header -->
👤jtsnr

1👍

I wrestled with this recently as well. After thinking about it, I realized I could rewrite my JQM application to use Pop Up “windows” for those pages that I didn’t want in my history. This ended up being an easier and cleaner fix than mucking around with browser history.

Now users can intuitively use the browser back button, and I don’t have to code application back buttons.

The only thing you have to ensure is that the popups don’t themselves make it into the browser history, so make sure to set the “history” option to false like so:

$('#some_popup').popup( { history: false } );
👤Cosmacelf

0👍

If you have the situation that you want the close button refer to an arbitrary (not the last) page, you could also change first to the target page and open the dialog afterwards. Therefore the close button at the dialog will open the target page.

// First: change to the target page
$.mobile.changePage('#target_page');

Afterwards open the dialog like this.

// Second: change to the dialog 
window.setTimeout(
   // for some reason you have to wrap it in a timeout  
   function(){
      $.mobile.changePage('#dialog');
   },
   1
);

Now you can open the dialog and the close button will open #target_page.

Advantages:

  • solution works for single dialogs rather than removing all close buttons from all dialogs
  • seamless integration on a single point of code
  • history manipulation is not needed
👤stot

-1👍

I have seen similar issues before when using jquery mobile and it is addressed in the documentation. When setting up your Javascript “at the beginning of your page” use pageinit instead of ready or maybe in your case pageshow. I think this will address your issue without having to workaround the history queue.

👤webdevmatt

Leave a comment