Wicket
  1. Wicket
  2. WICKET-4881

IE 8 : error when handling Wicket Ajax Response

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.2.0, 6.3.0
    • Fix Version/s: 6.4.0
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      Internet Explorer 8, Windows 7 64 bits

      Description

      I have a problem with Wicket 6.2.0/6.3.0 and IE (this works perfectly with Chrome or Firefox). I have a list of items, with Ajax links in the list. The response to the Ajax link modifies a panel from the page, and redraws the list (its container).

      IE does at least some of the changes correctly, but outputs an error, and it seems that subsequent Ajax request fail:

      (... some UI code ...)
      (... Jquery and Wicket ajax references ...)
      <script type="text/javascript" id="wicket-ajax-base-url">
      /<![CDATA[/
      Wicket.Ajax.baseUrl="other/bictables/list";
      /]]>/
      </script>
      </head>]]></header-contribution><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-interaction-view-toolbar-AMEND","e":"click","c":"AMENDea"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-interaction-view-toolbar-RETURN","e":"click","c":"RETURNec"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-0-actions-view","e":"click","c":"viewf2"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-0-actions-edit","e":"click","c":"editf3"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-0-reorder-down","e":"click","c":"downf4"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-1-actions-view","e":"click","c":"viewf5"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-1-actions-edit","e":"click","c":"editf6"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-1-reorder-up","e":"click","c":"upf7"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-1-reorder-down","e":"click","c":"downf8"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-2-actions-view","e":"click","c":"viewf9"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-2-actions-edit","e":"click","c":"editfa"}

      );]]>
      (... lots of similar code from the table ...)
      <evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-17-actions-edit","e":"click","c":"edit136"}

      );]]></evaluate><evaluate><![CDATA[Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-17-reorder-up","e":"click","c":"up137"}

      );]]></evaluate></ajax-response>
      INFO: returned focused element: http://localhost:8080/payments/app/other/bictables/list?3#
      INFO: returned focused element: null
      ERROR: Wicket.Ajax.Call.processEvaluation: Exception evaluating javascript: [object Error], text: Wicket.Ajax.ajax(

      {"u":"./list?3-1.IBehaviorListener.0-entities-entitiesList-bictables-7-actions-view","e":"click","c":"view10d"}

      );
      ERROR: FunctionsExecuter.processNext: [object Error]
      ERROR: Wicket.Ajax.Call.processEvaluation: Exception evaluating javascript: [object Error], text: Wicket.Ajax.ajax(

      {"u":"./list?2-4.IBehaviorListener.0-entities-entitiesList-bictables-7-actions- view","e":"click","c":"view2cb"}

      );
      ERROR: FunctionsExecuter.processNext: [object Error]

      all subsequent Ajax requests lead to :

      INFO: Channel '0' is busy - scheduling the callback to be executed when the previous request finish

      Is this a bug in Wicket, in IE? Any way to circumvent it if it's in IE?

      1. WICKET-4881-avoid-recursion.patch
        5 kB
        Tobias Haupt
      2. WICKET-4881.patch
        1 kB
        Martin Grigorov
      3. wicket_bug_report.zip
        56 kB
        Andrea Del Bene
      4. wicket_bug_report.7z
        35 kB
        Frédéric Donckels

        Issue Links

          Activity

          Hide
          Martin Grigorov added a comment -

          Can you provide a quickstart application that reproduces the problem ?
          Or can you reproduce it at http://www.wicket-library.com/wicket-examples-6.0.x/ajax/ ?

          Show
          Martin Grigorov added a comment - Can you provide a quickstart application that reproduces the problem ? Or can you reproduce it at http://www.wicket-library.com/wicket-examples-6.0.x/ajax/ ?
          Hide
          Frédéric Donckels added a comment -

          Maven project

          Show
          Frédéric Donckels added a comment - Maven project
          Hide
          Frédéric Donckels added a comment -

          This project can be run using maven; the produced war file can be dropped in a Jboss 6 (probably 7 too).

          To reproduce the issue:
          once jboss has started the app: navigate using IE8 to : http://localhost:8080/wicket.bug.report-web-1.0.0-SNAPSHOT/app/
          after that, click on one of the magnifying glass icons.
          the "view panel" appears, but all subsequent Ajax requests fail. (and the wicket debug panel shows the error)

          Notice that the error doesn't happen if in the wicket.bug.report.web.base.AbstractListPanel.ActionsFragment class, you disable the EditAjaxLink. (even though it's not clicked)

          Show
          Frédéric Donckels added a comment - This project can be run using maven; the produced war file can be dropped in a Jboss 6 (probably 7 too). To reproduce the issue: once jboss has started the app: navigate using IE8 to : http://localhost:8080/wicket.bug.report-web-1.0.0-SNAPSHOT/app/ after that, click on one of the magnifying glass icons. the "view panel" appears, but all subsequent Ajax requests fail. (and the wicket debug panel shows the error) Notice that the error doesn't happen if in the wicket.bug.report.web.base.AbstractListPanel.ActionsFragment class, you disable the EditAjaxLink. (even though it's not clicked)
          Hide
          Andrea Del Bene added a comment - - edited

          I've modified the maven project in order to run it by just typing "maven jetty:run". Anyway, I couldn't get any error message with IE 8, everything works fine running the project with Jetty.

          Show
          Andrea Del Bene added a comment - - edited I've modified the maven project in order to run it by just typing "maven jetty:run". Anyway, I couldn't get any error message with IE 8, everything works fine running the project with Jetty.
          Hide
          Frédéric Donckels added a comment - - edited

          I downloaded your project and reproduced the issue (using mvn jetty:run).
          See here: http://www.screenr.com/GbU7
          (sorry about the sound, I turned the microphone off, but that didn't prevent it from recording some noise)

          Show
          Frédéric Donckels added a comment - - edited I downloaded your project and reproduced the issue (using mvn jetty:run). See here: http://www.screenr.com/GbU7 (sorry about the sound, I turned the microphone off, but that didn't prevent it from recording some noise)
          Hide
          Martin Grigorov added a comment -

          I cannot reproduce the problem here as well.
          I use IE9 in compatibility modes and it didn't break with any of them. I cannot install IE8 here.
          The source code of the demo application is too big to make a full code review. A brief look at it didn't show anything suspicious.

          Show
          Martin Grigorov added a comment - I cannot reproduce the problem here as well. I use IE9 in compatibility modes and it didn't break with any of them. I cannot install IE8 here. The source code of the demo application is too big to make a full code review. A brief look at it didn't show anything suspicious.
          Hide
          Andrea Del Bene added a comment -

          I suspect you may have a more general problem with AJAX and IE. Does the rest of the application work fine with AJAX? Does data pagination return any error?

          Show
          Andrea Del Bene added a comment - I suspect you may have a more general problem with AJAX and IE. Does the rest of the application work fine with AJAX? Does data pagination return any error?
          Hide
          Frédéric Donckels added a comment -

          Copy-pasted from the ##wicket IRC channel :
          inside the catch block of FunctionsExecuter, the exception message is "Out of stack space"
          depth is 41 / current is 41
          of course , I have no idea how this is supposed to work...
          the call stack is just a pretty large bunch of anonymous JScript functions

          actually, the issue happens in the processEvaluation function, of Wicket.Ajax.Call when calling eval on the Javascript provided in the Ajax response
          It's odd though: if I change the number of items per page in the pagination, everything is ok until itemsPerPage = 8 (lower is ok)

          Show
          Frédéric Donckels added a comment - Copy-pasted from the ##wicket IRC channel : inside the catch block of FunctionsExecuter, the exception message is "Out of stack space" depth is 41 / current is 41 of course , I have no idea how this is supposed to work... the call stack is just a pretty large bunch of anonymous JScript functions actually, the issue happens in the processEvaluation function, of Wicket.Ajax.Call when calling eval on the Javascript provided in the Ajax response It's odd though: if I change the number of items per page in the pagination, everything is ok until itemsPerPage = 8 (lower is ok)
          Hide
          Martin Grigorov added a comment -
          Show
          Martin Grigorov added a comment - Can you try the JavaScript from this comment https://issues.apache.org/jira/browse/WICKET-4675?focusedCommentId=13426609&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13426609 in your IE8 instance ? What is the number that it gives ?
          Hide
          Frédéric Donckels added a comment -

          LOG: 272 and then it outputs "Out of memory" (which is pretty odd and a different message). That seems quite low to run out of stack space in a Win7 64 bit environment and 8gb of memory...

          Show
          Frédéric Donckels added a comment - LOG: 272 and then it outputs "Out of memory" (which is pretty odd and a different message). That seems quite low to run out of stack space in a Win7 64 bit environment and 8gb of memory...
          Hide
          Martin Grigorov added a comment -

          Each browser has different capabilities.
          See http://stackoverflow.com/questions/7826992/browser-javascript-stack-size-limit

          It depends on how much memory you use in each stack frame.
          The test that you ran is very simple and I'm not sure why 272 is the max for you. It could be some configuration property of IE ...

          The only solution that I see is to use setTimeout() when the depth is lower. The current threshold is 1000 recursive calls. Pre-Wicket-4675 it was 50. But it fails for you at 41 which indeed is very low.

          Show
          Martin Grigorov added a comment - Each browser has different capabilities. See http://stackoverflow.com/questions/7826992/browser-javascript-stack-size-limit It depends on how much memory you use in each stack frame. The test that you ran is very simple and I'm not sure why 272 is the max for you. It could be some configuration property of IE ... The only solution that I see is to use setTimeout() when the depth is lower. The current threshold is 1000 recursive calls. Pre-Wicket-4675 it was 50. But it fails for you at 41 which indeed is very low.
          Hide
          Dmitry Derugin added a comment -

          I have the same issue on page with ~200 AjaxCheckBox components in IE7. IE9 in compatibility mode works fine.

          Show
          Dmitry Derugin added a comment - I have the same issue on page with ~200 AjaxCheckBox components in IE7. IE9 in compatibility mode works fine.
          Hide
          Martin Grigorov added a comment - - edited

          Here is a possible solution.
          If the <evaluation> elements in <ajax-response> are more than X then combine them into one.

          You can clone Wicket sources and apply the patch locally to test it.

          Show
          Martin Grigorov added a comment - - edited Here is a possible solution. If the <evaluation> elements in <ajax-response> are more than X then combine them into one. You can clone Wicket sources and apply the patch locally to test it.
          Hide
          Dmitry Derugin added a comment -

          I've tried this - doesn't help.

          Show
          Dmitry Derugin added a comment - I've tried this - doesn't help.
          Hide
          Martin Grigorov added a comment -

          Can you attach the Ajax response that leads to this problem ?

          Show
          Martin Grigorov added a comment - Can you attach the Ajax response that leads to this problem ?
          Hide
          Dmitry Derugin added a comment -

          Sorry, it was my fault with an incorrect build. Provided patch fixed the problem. Thank you.

          Show
          Dmitry Derugin added a comment - Sorry, it was my fault with an incorrect build. Provided patch fixed the problem. Thank you.
          Hide
          Frédéric Donckels added a comment -

          I'll try that patch too ASAP

          Show
          Frédéric Donckels added a comment - I'll try that patch too ASAP
          Hide
          Frédéric Donckels added a comment -

          In my specific case, I had to change the value from 50 to 30 (probably because my IE is nuts), but that does solve the issue.

          Show
          Frédéric Donckels added a comment - In my specific case, I had to change the value from 50 to 30 (probably because my IE is nuts), but that does solve the issue.
          Hide
          Martin Grigorov added a comment -

          Since 6.4.0 all prepend scripts will be combined in one <priority-evaluate> and all append scripts in one <evaluate>.

          Show
          Martin Grigorov added a comment - Since 6.4.0 all prepend scripts will be combined in one <priority-evaluate> and all append scripts in one <evaluate>.
          Hide
          Didier Villevalois added a comment -

          I'm a bit annoyed by the commit that fixes this bug: https://github.com/apache/wicket/commit/cbf76d0e8c355876e302699c0975971773941ae9
          I understand that this is needed for IE compatibility but, indeed, it does completely removes the possibility to use the notify callback in the evaluated Javascript code. (see: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L1045)

          I would need that to defer DOM replacements after a modal window close animation.

          We can keep the IE-needed concatenation of evaluations by adding some Java APIs to:
          1) Explicitly ask for a particular script to be in its own "[priority-]evaluate" element (just like IJavascriptResponse does for appended-scripts)
          2) Pass an additional string to name the notify callback name

          May I open a feature request issue for that, or should I use this bug as its fix broke an existing feature ? I can provide patches.

          Show
          Didier Villevalois added a comment - I'm a bit annoyed by the commit that fixes this bug: https://github.com/apache/wicket/commit/cbf76d0e8c355876e302699c0975971773941ae9 I understand that this is needed for IE compatibility but, indeed, it does completely removes the possibility to use the notify callback in the evaluated Javascript code. (see: https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L1045 ) I would need that to defer DOM replacements after a modal window close animation. We can keep the IE-needed concatenation of evaluations by adding some Java APIs to: 1) Explicitly ask for a particular script to be in its own " [priority-] evaluate" element (just like IJavascriptResponse does for appended-scripts) 2) Pass an additional string to name the notify callback name May I open a feature request issue for that, or should I use this bug as its fix broke an existing feature ? I can provide patches.
          Hide
          Martin Grigorov added a comment -

          Hi Didier,

          Very good timing!
          We are discussing this issue in WICKET-5039.
          Can you please add a quickstart with your requirement to it.

          Show
          Martin Grigorov added a comment - Hi Didier, Very good timing! We are discussing this issue in WICKET-5039 . Can you please add a quickstart with your requirement to it.
          Hide
          Ernesto Reinaldo Barreiro added a comment -

          Hi,

          Maybe it is just changing the regular expression pattern at

          https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L1045)

          so that it covers case function()

          {A|...}
          Show
          Ernesto Reinaldo Barreiro added a comment - Hi, Maybe it is just changing the regular expression pattern at https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/ajax/res/js/wicket-ajax-jquery.js#L1045 ) so that it covers case function() {A|...}
          Hide
          Tobias Haupt added a comment -

          Patch added that avoids recursion in most of the default evaluations

          Show
          Tobias Haupt added a comment - Patch added that avoids recursion in most of the default evaluations
          Hide
          Tobias Haupt added a comment - - edited

          I still have heavy performance problems with the deep recursion / deep stack problem. In my case I append javascript that does a lot of jquery stuff so that it builds a big stack itself. I get the too much recursion message in firefox pretty soon or the page freezes.

          I understand that recursion is necessary through the notify call if the execution of the next step needs to be deferred until something long running (like downloading scripts etc.) has happened. Most of the calls of notify do not need a deferred execution so I introduced a second callback: notifyContinue that will be called whenever it is possible to avoid recursion.

          Please see the attached patch and verify if everything is correctly adapted. In my case it avoids the Exception and speeds up the evaluation a lot.

          Show
          Tobias Haupt added a comment - - edited I still have heavy performance problems with the deep recursion / deep stack problem. In my case I append javascript that does a lot of jquery stuff so that it builds a big stack itself. I get the too much recursion message in firefox pretty soon or the page freezes. I understand that recursion is necessary through the notify call if the execution of the next step needs to be deferred until something long running (like downloading scripts etc.) has happened. Most of the calls of notify do not need a deferred execution so I introduced a second callback: notifyContinue that will be called whenever it is possible to avoid recursion. Please see the attached patch and verify if everything is correctly adapted. In my case it avoids the Exception and speeds up the evaluation a lot.
          Hide
          Martin Grigorov added a comment -

          Please create a new ticket.
          Also please add information why you think some calls do not need to wait for the previous.
          A quickstart app will really help to improve this code faster.
          Thanks!

          Show
          Martin Grigorov added a comment - Please create a new ticket. Also please add information why you think some calls do not need to wait for the previous. A quickstart app will really help to improve this code faster. Thanks!
          Hide
          Tobias Haupt added a comment -

          I understand it like that: all tasks need to wait but some finish instantly / synchronously - they don't need the deferred callback to be called at some future time.
          So they don't need further recursion and can continue with the next step in a simple loop.

          I know that there was a quickstart to check the recursion depth and stack size allready. This should be sufficient. It's hard to simulate the problem.

          Show
          Tobias Haupt added a comment - I understand it like that: all tasks need to wait but some finish instantly / synchronously - they don't need the deferred callback to be called at some future time. So they don't need further recursion and can continue with the next step in a simple loop. I know that there was a quickstart to check the recursion depth and stack size allready. This should be sufficient. It's hard to simulate the problem.

            People

            • Assignee:
              Martin Grigorov
              Reporter:
              Frédéric Donckels
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development