New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preventDefault does not prevent history change during pagebeforechange event #3136

Closed
kirk911 opened this Issue Nov 22, 2011 · 11 comments

Comments

Projects
None yet
9 participants
@kirk911

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

This comment has been minimized.

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:

\\ jquery.mobile.js line 3264
                if ($link.is(":jqmData(rel='back')")) {
                    window.history.back();
                    return false;
                }

@ghost ghost assigned jblas Dec 12, 2011

@neolution

This comment has been minimized.

neolution commented Feb 27, 2012

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

@kirk911

This comment has been minimized.

kirk911 commented Apr 17, 2012

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

@johnbender

This comment has been minimized.

Contributor

johnbender commented May 21, 2012

@kirk911

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 johnbender referenced this issue May 21, 2012

Closed

4005 fix #4179

@ghost ghost assigned johnbender May 21, 2012

@arschmitz

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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 toddparker closed this Oct 26, 2012

@gabrielschulhof

This comment has been minimized.

Contributor

gabrielschulhof commented Nov 28, 2012

I have reproduced the issue here: http://jsbin.com/uzaret/550 ... hoping @johnbender's nav refactor will help.

@DzenisevichK

This comment has been minimized.

DzenisevichK commented Apr 26, 2013

@gabrielschulhof

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?

@puckpuck

This comment has been minimized.

puckpuck commented Oct 29, 2013

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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.

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