[
https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656629#action_12656629
]
Jani Väisänen commented on WICKET-1971:
---------------------------------------
Is this possible workaround or could this break anything:
If we alter the function initialize in the wicket-ajax.js, our case seems to
work.
If you replace this line:
this.url = url;
with this one:
this.url = Wicket.replaceAll(url,"&", "&");
Wicket.Ajax.Request.prototype = {
// Creates a new request object.
initialize: function(url, loadedCallback, parseResponse, randomURL,
failureHandler, channel) {
this.url = Wicket.replaceAll(url,"&", "&");
this.loadedCallback = loadedCallback;
// whether we should give the loadedCallback parsed response
(DOM tree) or the raw string
this.parseResponse = parseResponse != null ? parseResponse :
true;
this.randomURL = randomURL != null ? randomURL : true;
this.failureHandler = failureHandler != null ? failureHandler :
function() { };
this.async = true;
this.channel = channel;
this.precondition = function() { return true; } // allow a
condition to block request
// when suppressDone is set, the loadedCallback is responsible
for calling
// Ajax.Request.done() to process possibly pendings requests in
the channel.
this.suppressDone = false;
this.instance = Math.random();
this.debugContent = true;
},
done: function() {
Wicket.channelManager.done(this.channel);
},
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is
> PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired
> by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed
> back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user
> pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ?
> wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response>
> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens,
> AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But
> instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was
> added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on
> previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put
> an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link
> and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way
> this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this
> happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
