[
https://issues.apache.org/jira/browse/WICKET-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kappler updated WICKET-4122:
------------------------------------
Description:
We are using HtmlUnit for functional testing of a wicket application. We have
several issues with it but one of the more critical problems arises whenever a
multipart form is submitted via AJAX. Internally wicket apparently uses an
iframe to submit the request and listens for the "load" event of this iframe to
detect the success of the request.
The problem is that HtmlUnit fires the "load" event twice. I am not sure if
this is a HtmlUnit problem (I do suspect that it is), but when looking at the
wicket code I am wondering about these lines of javascript code:
Here in wicket-ajax.js:1215 the event is attached
Wicket.Event.add(iframe, "load", this.handleMultipartComplete.bind(this));
And later in wicket-ajax.js:1246 it is detached
// remove the event
if (iframe.detachEvent)
iframe.detachEvent("onload", this.handleMultipartComplete);
else
iframe.removeEventListener("load", this.handleMultipartComplete, false);
But because the bind function returns a new object this should never work,
right? I have attached a patch that fixes the problem in my environment, please
take a look at it if this makes sense.
was:
We are using HtmlUnit for functional testing of a wicket application. We have
several issues with it but one of the more critical problems arises whenever a
multipart form is submitted via AJAX. Internally wicket apparently uses an
iframe to submit the request and listens for the "load" event of this iframe to
detect the success of the request.
The problem is that HtmlUnit fires the "load" event twice. I am not sure if
this is a HtmlUnit problem (I do suspect that it is), but when looking at the
wicket code I am wondering about these lines of javascript code:
Here in wicket-ajax.js:1215 the event is attached
{code:javascript}
Wicket.Event.add(iframe, "load", this.handleMultipartComplete.bind(this));
{code}
And later in wicket-ajax.js:1246 it is detached
{code:javascript}
// remove the event
if (iframe.detachEvent)
iframe.detachEvent("onload", this.handleMultipartComplete);
else
iframe.removeEventListener("load", this.handleMultipartComplete, false);
{code}
But because the bind function returns a new object this should never work,
right? I have attached a patch that fixes the problem in my environment, please
take a look at it if this makes sense.
> Event listener not properly detached for multipart AJAX requests
> ----------------------------------------------------------------
>
> Key: WICKET-4122
> URL: https://issues.apache.org/jira/browse/WICKET-4122
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5.0
> Environment: HtmlUnit
> Reporter: Andreas Kappler
> Priority: Minor
> Labels: ajax, htmlunit, javascript, multipart, wicket-ajax.js
> Attachments: wicket-ajax-patch.patch
>
>
> We are using HtmlUnit for functional testing of a wicket application. We have
> several issues with it but one of the more critical problems arises whenever
> a multipart form is submitted via AJAX. Internally wicket apparently uses an
> iframe to submit the request and listens for the "load" event of this iframe
> to detect the success of the request.
> The problem is that HtmlUnit fires the "load" event twice. I am not sure if
> this is a HtmlUnit problem (I do suspect that it is), but when looking at the
> wicket code I am wondering about these lines of javascript code:
> Here in wicket-ajax.js:1215 the event is attached
> Wicket.Event.add(iframe, "load", this.handleMultipartComplete.bind(this));
> And later in wicket-ajax.js:1246 it is detached
> // remove the event
> if (iframe.detachEvent)
> iframe.detachEvent("onload", this.handleMultipartComplete);
> else
> iframe.removeEventListener("load", this.handleMultipartComplete, false);
> But because the bind function returns a new object this should never work,
> right? I have attached a patch that fixes the problem in my environment,
> please take a look at it if this makes sense.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
