Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2.2, 1.2.3, 1.2.6
    • Fix Version/s: 1.2.7
    • Component/s: wicket
    • Labels:
      None

      Description

      We are still getting page expired using wicket with ajax. The problem is related to the PageMap and occurs as following:

      1. We have a page with an ajax time behavior that updates a status every 2 sec. This page is the most top one on the page map stack.
      2. On this page you click the link to go to another page. The new page is added to the page stack but the response is expensive, let's say it take 1-2 sec. to build the page.
      3. During the response is processed, the browser triggers the ajax request, to the server. The request goes to the PageMap to get the current page.
      The page of the ajax request is the second top one on the stack, so the current code assumes the user clicked the back button and removes the
      top one page.
      4. In the browser everything seams to be ok, but the page in the browser and in the PageMap don't match anymore. So any new request to the server will cause page expired.

      This is very simple to reproduce, following is a snippet for the quickstart:

      — Index.java —
      public class Index extends QuickStartPage
      {

      public Index(final PageParameters parameters)
      {
      // link to the same page
      Link link = new Link("link")
      {
      public void onClick()

      { setResponsePage(Index.class); }

      };
      add(link);

      // we just need a delayed call to the server
      AjaxEventBehavior behavrior = new AjaxEventBehavior("onClick")
      {
      protected void onEvent(AjaxRequestTarget target)
      {
      }
      };
      behavrior.setThrottleDelay(Duration.milliseconds(200));
      link.add(behavrior);

      }

      protected void onAfterRender()
      {
      // simulate expensive response
      try

      { Thread.sleep(500); }

      catch (InterruptedException e)

      { e.printStackTrace(); }

      }

      }

      — Index.html —
      <html>
      <body>
      <a wicket:id="link">Click</a>
      </body>
      </html>

      I used Firefox only to reproduce it, not sure if this occurs with other browser as well.

      We have a small workaround('fix') for it. In DefaultRequestTargetResolverStrategy we check the type of the request. If it is a IUnversionedBehaviorListener, we don't update the PageMap in the access() method. It is not a clean solution but it works so far.

        Activity

        Hide
        Matteo Vaccari added a comment -

        I also have this problem, but I cannot find any reference to "target-only-active-page" in the 1.3.6 sources. Can you please point me to some reference to this solution?

        Show
        Matteo Vaccari added a comment - I also have this problem, but I cannot find any reference to "target-only-active-page" in the 1.3.6 sources. Can you please point me to some reference to this solution?
        Hide
        Igor Vaynberg added a comment -

        the solution for this in 1.3 (target-only-active-page url marker) required api breaks in ajax behaviors so we cannot apply it to 1.2.7. if this is a problem people should be upgrading to 1.3.

        Show
        Igor Vaynberg added a comment - the solution for this in 1.3 (target-only-active-page url marker) required api breaks in ajax behaviors so we cannot apply it to 1.2.7. if this is a problem people should be upgrading to 1.3.
        Hide
        Johan Compagner added a comment -

        do you have an patch that we can apply for 1.2.7?

        Show
        Johan Compagner added a comment - do you have an patch that we can apply for 1.2.7?
        Hide
        Adam Smyczek added a comment -

        Sorry, but this bug is not fix 1.2.x. I just reproduced this in 1.2.6 using the quickstart code snippet above. Our workaround is still working.

        Show
        Adam Smyczek added a comment - Sorry, but this bug is not fix 1.2.x. I just reproduced this in 1.2.6 using the quickstart code snippet above. Our workaround is still working.
        Hide
        Johan Compagner added a comment -

        if this is still a problem in the latest 1.2.x code and it is really something that people wants to have fixed/looked at?

        Show
        Johan Compagner added a comment - if this is still a problem in the latest 1.2.x code and it is really something that people wants to have fixed/looked at?
        Hide
        Jean-Baptiste Quenot added a comment -

        Johan you said it's fixed, so can we close this issue now?

        Show
        Jean-Baptiste Quenot added a comment - Johan you said it's fixed, so can we close this issue now?
        Hide
        Johan Compagner added a comment -

        this is fixed in 1.3 and 2.0 because we can get all the pages and page versions back

        But i thought in 1.2 we have an option that the ajax request is only handled when it is the latest page on the stack?
        And if another page is created that cost a lot that wont be on the stack yet so the ajax request sees that it still can do its job
        then the page that did take time put itself on the top. So there shouldn't be any problem

        If it is the other way. The long init page is already on the stack then the ajax request shouldn't do anything..

        Show
        Johan Compagner added a comment - this is fixed in 1.3 and 2.0 because we can get all the pages and page versions back But i thought in 1.2 we have an option that the ajax request is only handled when it is the latest page on the stack? And if another page is created that cost a lot that wont be on the stack yet so the ajax request sees that it still can do its job then the page that did take time put itself on the top. So there shouldn't be any problem If it is the other way. The long init page is already on the stack then the ajax request shouldn't do anything..

          People

          • Assignee:
            Johan Compagner
            Reporter:
            Adam Smyczek
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development