preventDefault does not prevent history change during pagebeforechange event #3136

kirk911 opened this Issue Nov 22, 2011 · 11 comments


None yet
9 participants

kirk911 commented Nov 22, 2011

We intercept the pagebeforechange event and sometimes cancel the event using preventDefault. When pagebeforechange is fired from a back button with data-rel="back", even though the pagebeforechange event is cancelled using preventDefault, the url has already decremented one page in history. I don't know how to setup a multipage environment with history within jsfiddle, or I'd setup an example. Removing data-rel="back" and setting an href in the back button does not cause this behavior. This is happening in version 1.0.

kirk911 commented Nov 22, 2011

FYI, we trap pagebeforechange and cancel to prevent loss of data that has changed on the active page. Looks like the history change is said and done prior to changepage being called:

\\ line 3264
                if ($":jqmData(rel='back')")) {
                    return false;

jblas was assigned Dec 12, 2011

I fixed this behaviour for me by (temporarily) disable pushState: $.mobile.pushStateEnabled = false;

kirk911 commented Apr 17, 2012

Setting $.mobile.pushStateEnabled = false worked for us as a temporary workaround. @neolution, thanks for the tip.


johnbender commented May 21, 2012


We handle the data-rel="back" by using the browser history, ie window.history.back() so that the behavior is consistent. This is the reason the hash has changed, and that change is what triggers the pagebeforechange. Is the issue that, when preventing default the browser history gets out of sync with jqm's representation of history?

Can you produce a jsbin using a couple embedded pages?

johnbender referenced this issue May 21, 2012


4005 fix #4179

johnbender was assigned May 21, 2012


arschmitz commented Oct 26, 2012

@toddparker @ugomobi There is no answer to @johnbender's questions and no test page provided in 5 months i would close as stale


toddparker commented Oct 26, 2012

I agree @arschmitz. Closing as cannot reproduce. We'll re-open if someone can provide detailed information to illustrate this is still an issue in the latest code.

toddparker closed this Oct 26, 2012


gabrielschulhof commented Nov 28, 2012

I have reproduced the issue here: ... hoping @johnbender's nav refactor will help.


Reproduced this problem on my side too...
Adjusted your example to additional problem case when header contains link button with data-rel="back" attribute.

Is there progress on this issue at all?

Sadly I have now also hit this issue. I was using preventDefault() to ensure users would commit changes if the page was "dirty". The example that DzenisevichK posted works very well to illustrate this.


gabrielschulhof commented Jun 10, 2014

I'm not sure we should be handling this case in the library, because any attempt to do so is bound to add a lot of complexity. The basic problem is this:

If you click the back button, whether via the browser's own, or via our data-rel="back" link, the very first thing that happens is that the browser history retreats by one entry. Everything we do in the framework, including triggering pagebeforechange and honouring its prevented default we do in response to what has already happened in the browser history.

If we wanted to do what you ask, we would actually have to do a window.history.forward() upon being notified that the default for pagebeforechange has been prevented. The implications of doing that for our navigation system are pretty intricate, so I'm fairly certain we won't attempt to implement this anytime soon.

gabrielschulhof added this to the 1.5.0 milestone Jan 14, 2015


gabrielschulhof commented Jan 14, 2015

@arschmitz I propose we close this, unless we want to implement forcefully preventing someone from retreating in the browser history by moving forward whenever they attempt to move back and the consequent pagebeforechange event's default is prevented.

arschmitz closed this Jun 29, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment