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

Already on GitHub? Sign in to your account

Clicking another link should cancel first request #3414

Closed
scottjehl opened this Issue Jan 11, 2012 · 8 comments

Comments

Projects
None yet
7 participants
Contributor

scottjehl commented Jan 11, 2012

After a page has started loading, clicking another link should cancel / ignore an existing page request and go for the new one (like the browser would).

This change should apply once the new transitions land, as the new loader implementation does not disable page interaction during load.

Member

agcolom commented Mar 17, 2012

Hi Scott, have you done something for this? When I check the docs and realise I have clicked on the wrong link, I quickly click on another one, and the 1st page lands quickly followed by the 2nd one which arrives very shortly after that. Was that what you wanted or if I click for page 1 and then quickly to page 2, page 1 should never land?

Thanks,

Anne

Contributor

scottjehl commented Mar 18, 2012

I haven't done anything yet, no. I'm not sure if we should for 1.1, since there's potential for this to touch other behavior.

That said, the change is needed for sure.

On Mar 18, 2012, at 3:44 AM, Anne-Gaelle Colom wrote:

Hi Scott, have you done something for this? When I check the docs and realise I have clicked on the wrong link, I quickly click on another one, and the 1st page lands quickly followed by the 2nd one which arrives very shortly after that. Was that what you wanted or if I click for page 1 and then quickly to page 2, page 1 should never land?

Thanks,

Anne


Reply to this email directly or view it on GitHub:
#3414 (comment)

Member

agcolom commented Mar 18, 2012

Yes, I agree with you. As a user, I am happy enough for now to click 1, click 2 quickly and get page 1 and then page2 without having to go back and click 2 again.

@ghost ghost assigned scottjehl May 5, 2012

@ghost ghost assigned gseguin Sep 12, 2012

uqpik commented Oct 11, 2012

On the other hand, already fired requests should not aborted for example shopping or financial requests. So in addition the following is required:

  • Don't allow user interaction when a request is in progress.

To achive this I do the following:

Display a full screen loader, so the user can't click:

.ui-loader-curtain{
 position: absolute;
 top: -1200px;
 left: -1200px;
 width: 2400px;
 height: 2400px;
 background: white;
 opacity:      0.0;
 filter:       Alpha(Opacity=0);
}

In addition i modified the original JS Code:

        defaultHtml: "<div class='" + loaderClass + "'>" +
            "<span class='ui-icon ui-icon-loading'></span>" +
            "<h1></h1>" +
            /* JQUERY MOD: Display loader full screen, so no double submit is possible */           
            "<div class='ui-loader-curtain'></div>" +
            "</div>",

and

$.mobile.changePage = function( toPage, options ) {
    // If we are in the midst of a transition, queue the current request.
    // We'll call changePage() once we're done with the current transition to
    // service the request.
    if ( isPageTransitioning ) {
        /* MODIFICATION: do not queue page loads  */
        // pageTransitionQueue.unshift( arguments );
        return;
    }

It would be nice to enable/disable this feature via an option.

Ruffio commented Apr 17, 2014

Is this two year old high priority issue still relevant?

uqpik commented Apr 22, 2014

Hello,

still using the posted modified JS Code.

Best Regards
Joachim Piketz

From: Rasmus Christiansen notifications@github.com
To: jquery/jquery-mobile jquery-mobile@noreply.github.com,
Cc: uqpik pik@uniquare.com
Date: 17.04.2014 19:25
Subject: Re: [jquery-mobile] Clicking another link should cancel first
request (#3414)

Is this two year old high priority issue still relevant?


Reply to this email directly or view it on GitHub.

Owner

arschmitz commented Apr 25, 2014

This is still relevant and will be something we look at in upcoming navigation work.

Member

apsdehal commented May 7, 2016

Closing since this feature is not needed universally.

@apsdehal apsdehal closed this May 7, 2016

@apsdehal apsdehal self-assigned this Aug 3, 2016

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