Skip to content

popup and data-history="false" #5775

ghost opened this Issue Mar 15, 2013 · 14 comments

7 participants

ghost commented Mar 15, 2013

I have been trying to use popup with data-history="false". The reason for using false is the bug covered by e.g. the following issues #5725 #5733. Btw I do not understand why these issues were closed. The webkit bug referred to are in status resolved since two years back.

I want to do the following

$(document).bind("mobileinit", function() {
    $(document).on("pageshow", "#Home", function(event, data) {
        $( '#popupDialog' ).popup( 'open' );

#popupDialog has a close button for the user to press.

Potential bug no1 (popup opens but are immediately closed)


Reproducable on desktop Chrome:

Google Chrome 25.0.1364.172 (Official Build 187217)
OS Windows
WebKit 537.22 (@145275)
JavaScript V8

Potential bug no2 (pagechange is fired once OR twice)


If this is by design, please if you could assist with how I can identify the event to use.

Using one() instead of on() or using off() to filter out only one execution causes popup to open but immediately close. Got the same result if ignoring the second event. Therefore I tried to use the second event only as in the jsbin

On desktop Chrome the event was always fired twice

On desktop Firefox 19.02 Windows 7 the event was always fired only once

When I tested on my mobile device Firefox gave consisten behaviour also here - firing only once.

For Android Chrome and Android browser I got some unconsistent results.


@leen111 just because a bug is resolved that doesn't mean it's resolved to your satisfaction. If you read the (rather lengthy) bug, you will find that the resolution was that not creating history entries for a while after page load is actually by design - their design, anyway, since FF doesn't do something like that. It's brain-damaged IMO, but I have to live with it. The issues were closed because the bug is in webkit, and webkit is refusing to fix it because they consider the behaviour to be "by design".


@johnbender I think we have to make the navigate event popstate handler also ignore the first popstate, just like the navigator's popstate handler does. Currently, it fires a navigate event, which causes a superfluous call to changePage on startup.


any ideas on a workaround for the popup immediately closing? This is a show stopper for me to upgrade from 1.2 to 1.3.

ghost commented Mar 22, 2013

@gabrielschulhof Sure I totally understand a bug can be resolved without it beeing to my satisfaction. May I just add that the time that has passed since a design decision is also a factor. In this particular case the decision is approx two years old and the brain damages might be not as severe anymore plus that new information also might be present, e.g. the problem we are facing now. That beeing said I certainly do not have the insight into the details to say that this really is the case here. I am sure it is part of your workflow to open a new bug report with the webkit team if you feel it is relevant and not hopeless.

ghost commented Mar 22, 2013

@MartyBJones If you have a VERY simple popup you could try using pagechange instead. The duplicate events does not seem to cause problems in this case, e.g. if the popup is just static. But if you e.g. do like this:

    $(document).on("pagechange", function(event, data) {
        $( '#popupDialog' ).find("img").load(function() {
            $( '#popupDialog' ).popup( 'open' );        

that is loading an image which is part of the popup before opening it, things break down. In my app I am also filling the popup with dynamic data. Even though the data is fetched synchronously from my data source and I make sure it is only done once it makes the execution fail.

But your question gave me the idea of downgrading to 1.2, I'll try that.

ghost commented Mar 22, 2013

1.2.0 with jquery 1.8.2 seems stable so far =)

@gabrielschulhof of course I am not satisfied though ;-) One day soon I would like to use the new bells & whistles of 1.3.


My app is working fine in 1.2 but I want the new panel and the range sliders so I would really like to upgrade but I need the popup functionality that I currently have and that is to conditionally open a popup when a page shows.

@gabrielschulhof gabrielschulhof added a commit that closed this issue Mar 25, 2013
@gabrielschulhof gabrielschulhof Navigation: If the default is prevented on the originalEvent of "navi…
…gate", do not go into _handleHashChange. Fixes #5775.

This is still an issue in 1.3 as i found this past week. The popup will immediately close when data-history is false. I removed this line to fix it, but i'd rather not be editing your library as a work-around, any chance of a fix?

around line 7853

// if history alteration is disabled close on navigate events
// and leave the url as is
if( !( opts.history ) ) {
self._open( options );
//TODO Removed below to fix popup

// When histoy is disabled we have to grab the data-rel
// back link clicks so we can close the popup instead of
// relying on history to do it for us
    .delegate( opts.closeLinkSelector, opts.closeLinkEvents, function( e ) {




I am also having this issue on a normal page change without history (either with data-history=false or in the changePage function with option changeHash to false).
To make the sample in work one can add in "mobileInit" javascript$.mobile.pushStateEnabled = false;and that sample will work , but it breaks the back behavior, by sometimes returning to the page you pressed back from (moving foward through the app works).

For my case i only want to move forward without history through some pages and when clicking back to also work as expected . I didn't see how to move forward without history via code with the navigation function.
Does anyone have any leads on this?


Can this please get fixed, the one line fix above?


Still waiting on a response.

jQuery Foundation member

I cannot reproduce this issue anymore on Chrome with latest code:


Issue still not fixed in version jqm 1.4.5. The popup open but immediately closes.


I think fixing #8045 will fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.