You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Tobias Gierke <to...@voipfuture.com> on 2014/04/10 10:50:33 UTC

Strange issue with AJAX update + file download

Hi,

We're using Wicket 1.5.11 with the approach described in 
https://cwiki.apache.org/confluence/display/WICKET/AJAX+update+and+file+download+in+one+blow 
to trigger a file download from within a modal dialog. This all works 
fine, our problem is with the rendering of the page after the download 
is complete.

The page contains some dynamic images/icons that are included via 
Image/DynamicImageResource (all have a 'antiCache' parameter in their 
URL as well as a "last-modified" date that equals "now()" ). Both chrome 
and firefox re-request these images after the download has completed and 
looking at the network traffic/PCAP file I captured , I can see that 
Wicket is in fact delivering the PNGs to the browser.

But:  Chrome still renders these icons using the  'image is broken' 
placeholder icon and Firefox/firebug shows the image downloads as 'never 
completed' / 0 bytes downloaded (see attached screenshots). Firebug also 
shows a pending GET request for a JavaScript file along with the image 
download requests so the issue may be related to either caching or the 
Wicket request processing in general.

Any ideas ?

Thanks in advance,
Tobias


Solved [ Re: Strange issue with AJAX update + file download ]

Posted by Tobias Gierke <to...@voipfuture.com>.
Sorry for the noise, I just tried to validate my assumption by (again) 
setting the timeout to some really large value (20 seconds) and noticed 
that I screwed up while testing your initial suggestion , the changed 
timeout value was never in effect ...

Raising the timeout value does in fact solve the issue (although I don't 
like the solution since the required timeout value depends on the speed 
of the connection/request processing so this is bound to break sooner 
than later).

Thank you very much,
Tobias

> Hi,
>> What do you exactly mean by the rendering of the page after download
>> completed? You repaint a part of the screen via AJAX? And this is the 
>> one
>> giving problem with images?
> Good point. I just investigated the AJAX response returned by the 
> server when clicking the 'Start download' button on the modal dialog 
> and I noticed that along with the JavaScript snippet that does the 
> "setTimeout(...)" there are also a lot of AJAX component updates that 
> are obviously generated by components with overridden onEvent() 
> methods. I didn't write the code so I wasn't aware of this :/
>
> I suspect that the issue I'm seeing is caused by the Wicket AJAX 
> library being interrupted by the "setTimeout()" call while processing 
> the component updates... proving this will unfortunately take some 
> time since the page has a lot of different components that all 
> override onEvent() ...
>
> Thanks,
> Tobias
>
>
>>
>>
>>> The page contains some dynamic images/icons that are included via
>>> Image/DynamicImageResource (all have a 'antiCache' parameter in 
>>> their URL
>>> as well as a "last-modified" date that equals "now()" ). Both chrome 
>>> and
>>> firefox re-request these images after the download has completed and
>>> looking at the network traffic/PCAP file I captured , I can see that 
>>> Wicket
>>> is in fact delivering the PNGs to the browser.
>>>
>>> But:  Chrome still renders these icons using the  'image is broken'
>>> placeholder icon and Firefox/firebug shows the image downloads as 
>>> 'never
>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug 
>>> also
>>> shows a pending GET request for a JavaScript file along with the image
>>> download requests so the issue may be related to either caching or the
>>> Wicket request processing in general.
>>>
>>> Any ideas ?
>>>
>>> Thanks in advance,
>>> Tobias
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Strange issue with AJAX update + file download

Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,


On Thu, Apr 10, 2014 at 12:13 PM, Tobias Gierke <
tobias.gierke@voipfuture.com> wrote:

> Hi,
>
>  What do you exactly mean by the rendering of the page after download
>> completed? You repaint a part of the screen via AJAX? And this is the one
>> giving problem with images?
>>
> Good point. I just investigated the AJAX response returned by the server
> when clicking the 'Start download' button on the modal dialog and I noticed
> that along with the JavaScript snippet that does the "setTimeout(...)"
> there are also a lot of AJAX component updates that are obviously generated
> by components with overridden onEvent() methods. I didn't write the code so
> I wasn't aware of this :/
>
> This does not sounds very clean: you will be updating all of thos for
anything AJAX you do on the page.


> I suspect that the issue I'm seeing is caused by the Wicket AJAX library
> being interrupted by the "setTimeout()" call while processing the component
> updates... proving this will unfortunately take some time since the page
> has a lot of different components that all override onEvent() ...
>

In fact the setTimeout is "the way" of spanning a new thread on JavaScript:
that part was added by Martin Grigorov, if I recall it correctly, precisely
just to give wicket AJAX the possibility of complete processing.


>
> Thanks,
> Tobias
>
>
>
>
>>
>>  The page contains some dynamic images/icons that are included via
>>> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
>>> as well as a "last-modified" date that equals "now()" ). Both chrome and
>>> firefox re-request these images after the download has completed and
>>> looking at the network traffic/PCAP file I captured , I can see that
>>> Wicket
>>> is in fact delivering the PNGs to the browser.
>>>
>>> But:  Chrome still renders these icons using the  'image is broken'
>>> placeholder icon and Firefox/firebug shows the image downloads as 'never
>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
>>> shows a pending GET request for a JavaScript file along with the image
>>> download requests so the issue may be related to either caching or the
>>> Wicket request processing in general.
>>>
>>> Any ideas ?
>>>
>>> Thanks in advance,
>>> Tobias
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>
> --
> Tobias Gierke
> Development
>
> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
> Phone +49 40 688 900 111 Fax +49 40 688 900 199
> Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
>  CEO Jan Bastian
>
> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro

Re: Strange issue with AJAX update + file download

Posted by Tobias Gierke <to...@voipfuture.com>.
>> On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke 
>> <tobias.gierke@voipfuture.com
>>> wrote:
>>> Hi,
>>>
>>>   What do you exactly mean by the rendering of the page after download
>>>> completed? You repaint a part of the screen via AJAX? And this is 
>>>> the one
>>>> giving problem with images?
>>>>
>>> Good point. I just investigated the AJAX response returned by the 
>>> server
>>> when clicking the 'Start download' button on the modal dialog and I 
>>> noticed
>>> that along with the JavaScript snippet that does the "setTimeout(...)"
>>> there are also a lot of AJAX component updates that are obviously 
>>> generated
>>> by components with overridden onEvent() methods. I didn't write the 
>>> code so
>>> I wasn't aware of this :/
>>>
>>> I suspect that the issue I'm seeing is caused by the Wicket AJAX 
>>> library
>>> being interrupted by the "setTimeout()" call while processing the 
>>> component
>>> updates... proving this will unfortunately take some time since the 
>>> page
>>> has a lot of different components that all override onEvent() ...
>>>
>> JavaScript is single-threaded. There is no way to interrupt it.
>> By using setTimeout/setInterval functions you just add tasks to the 
>> queue
>> that this single thread processes.
> I stand corrected ;) But how come - given that  setTimeout() just adds 
> a task to some "queue" - the actual magnitude of the timeout has an 
> effect ? My queues are usually processed first-to-last ;)

Forgive my ignorance, I just read 
http://ejohn.org/blog/how-javascript-timers-work and was enlightened ;)

Cheers,
Tobias


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Strange issue with AJAX update + file download

Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
one solution might be to pull document from a mounted resource: which are
not locked.


On Thu, Apr 10, 2014 at 6:16 PM, Jesse Long <jp...@unknown.za.net> wrote:

> On 10/04/2014 12:53, Martin Grigorov wrote:
>
>> On Thu, Apr 10, 2014 at 1:44 PM, Ernesto Reinaldo Barreiro <
>> reiern70@gmail.com> wrote:
>>
>>  Hi,
>>>
>>>
>>> On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke <
>>> tobias.gierke@voipfuture.com> wrote:
>>>
>>>  Hi,
>>>>
>>>>   Hi,
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <
>>>>> tobias.gierke@voipfuture.com
>>>>>
>>>>>  wrote:
>>>>>> Hi,
>>>>>>
>>>>>>    What do you exactly mean by the rendering of the page after
>>>>>> download
>>>>>>
>>>>>>  completed? You repaint a part of the screen via AJAX? And this is the
>>>>>>> one
>>>>>>> giving problem with images?
>>>>>>>
>>>>>>>   Good point. I just investigated the AJAX response returned by the
>>>>>>>
>>>>>> server
>>>>>> when clicking the 'Start download' button on the modal dialog and I
>>>>>> noticed
>>>>>> that along with the JavaScript snippet that does the "setTimeout(...)"
>>>>>> there are also a lot of AJAX component updates that are obviously
>>>>>> generated
>>>>>> by components with overridden onEvent() methods. I didn't write the
>>>>>>
>>>>> code
>>>
>>>> so
>>>>>> I wasn't aware of this :/
>>>>>>
>>>>>> I suspect that the issue I'm seeing is caused by the Wicket AJAX
>>>>>>
>>>>> library
>>>
>>>> being interrupted by the "setTimeout()" call while processing the
>>>>>> component
>>>>>> updates... proving this will unfortunately take some time since the
>>>>>>
>>>>> page
>>>
>>>> has a lot of different components that all override onEvent() ...
>>>>>>
>>>>>>   JavaScript is single-threaded. There is no way to interrupt it.
>>>>>>
>>>>> By using setTimeout/setInterval functions you just add tasks to the
>>>>>
>>>> queue
>>>
>>>> that this single thread processes.
>>>>>
>>>>>  I stand corrected ;) But how come - given that  setTimeout() just
>>>> adds a
>>>> task to some "queue" - the actual magnitude of the timeout has an effect
>>>>
>>> ?
>>>
>>>> My queues are usually processed first-to-last ;)
>>>>
>>>>  Probably the time out just influence the download of images: e.g.
>>> maybe by
>>> making
>>>
>>> window.location.href='" + url + "'\", 100);
>>>
>>> You are telling the browser "stop loading images, we are processing anew
>>> document"
>>>
>>>  There is still something unclear here - window.location.href is
>> contributed
>> via target.appendJavaScript().
>> This means it is put into <evaluate> XML element in the Ajax response and
>> should be processed (sequentially!) later than the resource downloads by
>> Wicket.FunctionExecuter. I.e. the resources should fire their "loaded"
>> events before FunctionExecuter to move to the next task
>>
>>
>>
> Page locking maybe? Does the download lock the page for the duration of
> the download?
>
> ajax get
> ajax response
> dom modified
> browser starts downloading images in background, one (or a few) at a time
> download of file starts (page is locked on server)
> while file download is still busy, browser attempts to download other
> images. This may require page lock on server, which will make this request
> hang until file download is complete.
>
> Maybe, instead of using AJAXDownload, make like:
>
> new AjaxLink("link"){
>     @Override
>     public void onClick(AjaxRequestTarget target){
>         // do whatever
>         target.add(...);
>
> Application.get().getResourceReferenceRegistry()
> .registerResourceReference(MyDownloadResourceReference.INSTANCE);
>
> target.appendJavaScript("setTimeout(\"window.location.href='" + urlFor(
> MyDownloadResourceReference.INSTANCE, null) + "'\", 100);");
>     }
> };
>
> public class MyDownloadResourceReference
>     extends ResourceReference
> {
>     public static final MyDownloadResourceReference INSTACE = new
> MyDownloadResourceReference();
>
>     public MyDownloadResourceReference()
>     {
>          super(MyApp.class, "download-woteva");
>     }
>
>     @Override
>     public IResource getResource()
>     {
>             // return resource
>     }
> }
>
> You will need to have some sort of way of passing information from the
> page to the IResource about exactly what should be downloaded. You can do
> this with by storing temp info in the session (not so great), or by passing
> PageParameters in the urlFor() instead of null, and parsing them in the
> IResource.
>
> HTH,
> Jesse
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro

Re: Strange issue with AJAX update + file download

Posted by Jesse Long <jp...@unknown.za.net>.
On 10/04/2014 12:53, Martin Grigorov wrote:
> On Thu, Apr 10, 2014 at 1:44 PM, Ernesto Reinaldo Barreiro <
> reiern70@gmail.com> wrote:
>
>> Hi,
>>
>>
>> On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke <
>> tobias.gierke@voipfuture.com> wrote:
>>
>>> Hi,
>>>
>>>   Hi,
>>>>
>>>>
>>>> On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <
>>>> tobias.gierke@voipfuture.com
>>>>
>>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>    What do you exactly mean by the rendering of the page after download
>>>>>
>>>>>> completed? You repaint a part of the screen via AJAX? And this is the
>>>>>> one
>>>>>> giving problem with images?
>>>>>>
>>>>>>   Good point. I just investigated the AJAX response returned by the
>>>>> server
>>>>> when clicking the 'Start download' button on the modal dialog and I
>>>>> noticed
>>>>> that along with the JavaScript snippet that does the "setTimeout(...)"
>>>>> there are also a lot of AJAX component updates that are obviously
>>>>> generated
>>>>> by components with overridden onEvent() methods. I didn't write the
>> code
>>>>> so
>>>>> I wasn't aware of this :/
>>>>>
>>>>> I suspect that the issue I'm seeing is caused by the Wicket AJAX
>> library
>>>>> being interrupted by the "setTimeout()" call while processing the
>>>>> component
>>>>> updates... proving this will unfortunately take some time since the
>> page
>>>>> has a lot of different components that all override onEvent() ...
>>>>>
>>>>>   JavaScript is single-threaded. There is no way to interrupt it.
>>>> By using setTimeout/setInterval functions you just add tasks to the
>> queue
>>>> that this single thread processes.
>>>>
>>> I stand corrected ;) But how come - given that  setTimeout() just adds a
>>> task to some "queue" - the actual magnitude of the timeout has an effect
>> ?
>>> My queues are usually processed first-to-last ;)
>>>
>> Probably the time out just influence the download of images: e.g. maybe by
>> making
>>
>> window.location.href='" + url + "'\", 100);
>>
>> You are telling the browser "stop loading images, we are processing anew
>> document"
>>
> There is still something unclear here - window.location.href is contributed
> via target.appendJavaScript().
> This means it is put into <evaluate> XML element in the Ajax response and
> should be processed (sequentially!) later than the resource downloads by
> Wicket.FunctionExecuter. I.e. the resources should fire their "loaded"
> events before FunctionExecuter to move to the next task
>
>

Page locking maybe? Does the download lock the page for the duration of 
the download?

ajax get
ajax response
dom modified
browser starts downloading images in background, one (or a few) at a time
download of file starts (page is locked on server)
while file download is still busy, browser attempts to download other 
images. This may require page lock on server, which will make this 
request hang until file download is complete.

Maybe, instead of using AJAXDownload, make like:

new AjaxLink("link"){
     @Override
     public void onClick(AjaxRequestTarget target){
         // do whatever
         target.add(...);

Application.get().getResourceReferenceRegistry().registerResourceReference(MyDownloadResourceReference.INSTANCE);

target.appendJavaScript("setTimeout(\"window.location.href='" + 
urlFor(MyDownloadResourceReference.INSTANCE, null) + "'\", 100);");
     }
};

public class MyDownloadResourceReference
     extends ResourceReference
{
     public static final MyDownloadResourceReference INSTACE = new 
MyDownloadResourceReference();

     public MyDownloadResourceReference()
     {
          super(MyApp.class, "download-woteva");
     }

     @Override
     public IResource getResource()
     {
             // return resource
     }
}

You will need to have some sort of way of passing information from the 
page to the IResource about exactly what should be downloaded. You can 
do this with by storing temp info in the session (not so great), or by 
passing PageParameters in the urlFor() instead of null, and parsing them 
in the IResource.

HTH,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Strange issue with AJAX update + file download

Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Apr 10, 2014 at 1:44 PM, Ernesto Reinaldo Barreiro <
reiern70@gmail.com> wrote:

> Hi,
>
>
> On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke <
> tobias.gierke@voipfuture.com> wrote:
>
> > Hi,
> >
> >  Hi,
> >>
> >>
> >>
> >> On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <
> >> tobias.gierke@voipfuture.com
> >>
> >>> wrote:
> >>> Hi,
> >>>
> >>>   What do you exactly mean by the rendering of the page after download
> >>>
> >>>> completed? You repaint a part of the screen via AJAX? And this is the
> >>>> one
> >>>> giving problem with images?
> >>>>
> >>>>  Good point. I just investigated the AJAX response returned by the
> >>> server
> >>> when clicking the 'Start download' button on the modal dialog and I
> >>> noticed
> >>> that along with the JavaScript snippet that does the "setTimeout(...)"
> >>> there are also a lot of AJAX component updates that are obviously
> >>> generated
> >>> by components with overridden onEvent() methods. I didn't write the
> code
> >>> so
> >>> I wasn't aware of this :/
> >>>
> >>> I suspect that the issue I'm seeing is caused by the Wicket AJAX
> library
> >>> being interrupted by the "setTimeout()" call while processing the
> >>> component
> >>> updates... proving this will unfortunately take some time since the
> page
> >>> has a lot of different components that all override onEvent() ...
> >>>
> >>>  JavaScript is single-threaded. There is no way to interrupt it.
> >> By using setTimeout/setInterval functions you just add tasks to the
> queue
> >> that this single thread processes.
> >>
> > I stand corrected ;) But how come - given that  setTimeout() just adds a
> > task to some "queue" - the actual magnitude of the timeout has an effect
> ?
> > My queues are usually processed first-to-last ;)
> >
>
> Probably the time out just influence the download of images: e.g. maybe by
> making
>
> window.location.href='" + url + "'\", 100);
>
> You are telling the browser "stop loading images, we are processing anew
> document"
>

There is still something unclear here - window.location.href is contributed
via target.appendJavaScript().
This means it is put into <evaluate> XML element in the Ajax response and
should be processed (sequentially!) later than the resource downloads by
Wicket.FunctionExecuter. I.e. the resources should fire their "loaded"
events before FunctionExecuter to move to the next task


>
>
> >
> > Cheers,
> > Tobias
> >
> >
> >>
> >>  Thanks,
> >>> Tobias
> >>>
> >>>
> >>>
> >>>
> >>>    The page contains some dynamic images/icons that are included via
> >>>>
> >>>>> Image/DynamicImageResource (all have a 'antiCache' parameter in their
> >>>>> URL
> >>>>> as well as a "last-modified" date that equals "now()" ). Both chrome
> >>>>> and
> >>>>> firefox re-request these images after the download has completed and
> >>>>> looking at the network traffic/PCAP file I captured , I can see that
> >>>>> Wicket
> >>>>> is in fact delivering the PNGs to the browser.
> >>>>>
> >>>>> But:  Chrome still renders these icons using the  'image is broken'
> >>>>> placeholder icon and Firefox/firebug shows the image downloads as
> >>>>> 'never
> >>>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug
> >>>>> also
> >>>>> shows a pending GET request for a JavaScript file along with the
> image
> >>>>> download requests so the issue may be related to either caching or
> the
> >>>>> Wicket request processing in general.
> >>>>>
> >>>>> Any ideas ?
> >>>>>
> >>>>> Thanks in advance,
> >>>>> Tobias
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>  --
> >>> Tobias Gierke
> >>> Development
> >>>
> >>> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
> >>> Phone +49 40 688 900 111 Fax +49 40 688 900 199
> >>> Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
> >>>   CEO Jan Bastian
> >>>
> >>> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >>>
> >
> > --
> > Tobias Gierke
> > Development
> >
> > VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
> > Phone +49 40 688 900 111 Fax +49 40 688 900 199
> > Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
> >  CEO Jan Bastian
> >
> > Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>

Re: Strange issue with AJAX update + file download

Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,


On Thu, Apr 10, 2014 at 12:36 PM, Tobias Gierke <
tobias.gierke@voipfuture.com> wrote:

> Hi,
>
>  Hi,
>>
>>
>>
>> On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <
>> tobias.gierke@voipfuture.com
>>
>>> wrote:
>>> Hi,
>>>
>>>   What do you exactly mean by the rendering of the page after download
>>>
>>>> completed? You repaint a part of the screen via AJAX? And this is the
>>>> one
>>>> giving problem with images?
>>>>
>>>>  Good point. I just investigated the AJAX response returned by the
>>> server
>>> when clicking the 'Start download' button on the modal dialog and I
>>> noticed
>>> that along with the JavaScript snippet that does the "setTimeout(...)"
>>> there are also a lot of AJAX component updates that are obviously
>>> generated
>>> by components with overridden onEvent() methods. I didn't write the code
>>> so
>>> I wasn't aware of this :/
>>>
>>> I suspect that the issue I'm seeing is caused by the Wicket AJAX library
>>> being interrupted by the "setTimeout()" call while processing the
>>> component
>>> updates... proving this will unfortunately take some time since the page
>>> has a lot of different components that all override onEvent() ...
>>>
>>>  JavaScript is single-threaded. There is no way to interrupt it.
>> By using setTimeout/setInterval functions you just add tasks to the queue
>> that this single thread processes.
>>
> I stand corrected ;) But how come - given that  setTimeout() just adds a
> task to some "queue" - the actual magnitude of the timeout has an effect ?
> My queues are usually processed first-to-last ;)
>

Probably the time out just influence the download of images: e.g. maybe by
making

window.location.href='" + url + "'\", 100);

You are telling the browser "stop loading images, we are processing anew
document"


>
> Cheers,
> Tobias
>
>
>>
>>  Thanks,
>>> Tobias
>>>
>>>
>>>
>>>
>>>    The page contains some dynamic images/icons that are included via
>>>>
>>>>> Image/DynamicImageResource (all have a 'antiCache' parameter in their
>>>>> URL
>>>>> as well as a "last-modified" date that equals "now()" ). Both chrome
>>>>> and
>>>>> firefox re-request these images after the download has completed and
>>>>> looking at the network traffic/PCAP file I captured , I can see that
>>>>> Wicket
>>>>> is in fact delivering the PNGs to the browser.
>>>>>
>>>>> But:  Chrome still renders these icons using the  'image is broken'
>>>>> placeholder icon and Firefox/firebug shows the image downloads as
>>>>> 'never
>>>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug
>>>>> also
>>>>> shows a pending GET request for a JavaScript file along with the image
>>>>> download requests so the issue may be related to either caching or the
>>>>> Wicket request processing in general.
>>>>>
>>>>> Any ideas ?
>>>>>
>>>>> Thanks in advance,
>>>>> Tobias
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>>
>>>>  --
>>> Tobias Gierke
>>> Development
>>>
>>> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
>>> Phone +49 40 688 900 111 Fax +49 40 688 900 199
>>> Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
>>>   CEO Jan Bastian
>>>
>>> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>
> --
> Tobias Gierke
> Development
>
> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
> Phone +49 40 688 900 111 Fax +49 40 688 900 199
> Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
>  CEO Jan Bastian
>
> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro

Re: Strange issue with AJAX update + file download

Posted by Tobias Gierke <to...@voipfuture.com>.
Hi,
> Hi,
>
>
>
> On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <tobias.gierke@voipfuture.com
>> wrote:
>> Hi,
>>
>>   What do you exactly mean by the rendering of the page after download
>>> completed? You repaint a part of the screen via AJAX? And this is the one
>>> giving problem with images?
>>>
>> Good point. I just investigated the AJAX response returned by the server
>> when clicking the 'Start download' button on the modal dialog and I noticed
>> that along with the JavaScript snippet that does the "setTimeout(...)"
>> there are also a lot of AJAX component updates that are obviously generated
>> by components with overridden onEvent() methods. I didn't write the code so
>> I wasn't aware of this :/
>>
>> I suspect that the issue I'm seeing is caused by the Wicket AJAX library
>> being interrupted by the "setTimeout()" call while processing the component
>> updates... proving this will unfortunately take some time since the page
>> has a lot of different components that all override onEvent() ...
>>
> JavaScript is single-threaded. There is no way to interrupt it.
> By using setTimeout/setInterval functions you just add tasks to the queue
> that this single thread processes.
I stand corrected ;) But how come - given that  setTimeout() just adds a 
task to some "queue" - the actual magnitude of the timeout has an effect 
? My queues are usually processed first-to-last ;)

Cheers,
Tobias
>
>
>> Thanks,
>> Tobias
>>
>>
>>
>>
>>>   The page contains some dynamic images/icons that are included via
>>>> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
>>>> as well as a "last-modified" date that equals "now()" ). Both chrome and
>>>> firefox re-request these images after the download has completed and
>>>> looking at the network traffic/PCAP file I captured , I can see that
>>>> Wicket
>>>> is in fact delivering the PNGs to the browser.
>>>>
>>>> But:  Chrome still renders these icons using the  'image is broken'
>>>> placeholder icon and Firefox/firebug shows the image downloads as 'never
>>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
>>>> shows a pending GET request for a JavaScript file along with the image
>>>> download requests so the issue may be related to either caching or the
>>>> Wicket request processing in general.
>>>>
>>>> Any ideas ?
>>>>
>>>> Thanks in advance,
>>>> Tobias
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>> --
>> Tobias Gierke
>> Development
>>
>> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
>> Phone +49 40 688 900 111 Fax +49 40 688 900 199
>> Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
>>   CEO Jan Bastian
>>
>> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>


-- 
Tobias Gierke
Development

VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
Phone +49 40 688 900 111 Fax +49 40 688 900 199
Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
  
CEO Jan Bastian
	
Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Strange issue with AJAX update + file download

Posted by Martin Grigorov <mg...@apache.org>.
Hi,



On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <tobias.gierke@voipfuture.com
> wrote:

> Hi,
>
>  What do you exactly mean by the rendering of the page after download
>> completed? You repaint a part of the screen via AJAX? And this is the one
>> giving problem with images?
>>
> Good point. I just investigated the AJAX response returned by the server
> when clicking the 'Start download' button on the modal dialog and I noticed
> that along with the JavaScript snippet that does the "setTimeout(...)"
> there are also a lot of AJAX component updates that are obviously generated
> by components with overridden onEvent() methods. I didn't write the code so
> I wasn't aware of this :/
>
> I suspect that the issue I'm seeing is caused by the Wicket AJAX library
> being interrupted by the "setTimeout()" call while processing the component
> updates... proving this will unfortunately take some time since the page
> has a lot of different components that all override onEvent() ...
>

JavaScript is single-threaded. There is no way to interrupt it.
By using setTimeout/setInterval functions you just add tasks to the queue
that this single thread processes.


>
> Thanks,
> Tobias
>
>
>
>
>>
>>  The page contains some dynamic images/icons that are included via
>>> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
>>> as well as a "last-modified" date that equals "now()" ). Both chrome and
>>> firefox re-request these images after the download has completed and
>>> looking at the network traffic/PCAP file I captured , I can see that
>>> Wicket
>>> is in fact delivering the PNGs to the browser.
>>>
>>> But:  Chrome still renders these icons using the  'image is broken'
>>> placeholder icon and Firefox/firebug shows the image downloads as 'never
>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
>>> shows a pending GET request for a JavaScript file along with the image
>>> download requests so the issue may be related to either caching or the
>>> Wicket request processing in general.
>>>
>>> Any ideas ?
>>>
>>> Thanks in advance,
>>> Tobias
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>>
>
> --
> Tobias Gierke
> Development
>
> VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
> Phone +49 40 688 900 111 Fax +49 40 688 900 199
> Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
>  CEO Jan Bastian
>
> Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Strange issue with AJAX update + file download

Posted by Tobias Gierke <to...@voipfuture.com>.
Hi,
> What do you exactly mean by the rendering of the page after download
> completed? You repaint a part of the screen via AJAX? And this is the one
> giving problem with images?
Good point. I just investigated the AJAX response returned by the server 
when clicking the 'Start download' button on the modal dialog and I 
noticed that along with the JavaScript snippet that does the 
"setTimeout(...)" there are also a lot of AJAX component updates that 
are obviously generated by components with overridden onEvent() methods. 
I didn't write the code so I wasn't aware of this :/

I suspect that the issue I'm seeing is caused by the Wicket AJAX library 
being interrupted by the "setTimeout()" call while processing the 
component updates... proving this will unfortunately take some time 
since the page has a lot of different components that all override 
onEvent() ...

Thanks,
Tobias


>
>
>> The page contains some dynamic images/icons that are included via
>> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
>> as well as a "last-modified" date that equals "now()" ). Both chrome and
>> firefox re-request these images after the download has completed and
>> looking at the network traffic/PCAP file I captured , I can see that Wicket
>> is in fact delivering the PNGs to the browser.
>>
>> But:  Chrome still renders these icons using the  'image is broken'
>> placeholder icon and Firefox/firebug shows the image downloads as 'never
>> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
>> shows a pending GET request for a JavaScript file along with the image
>> download requests so the issue may be related to either caching or the
>> Wicket request processing in general.
>>
>> Any ideas ?
>>
>> Thanks in advance,
>> Tobias
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>


-- 
Tobias Gierke
Development

VOIPFUTURE GmbH   Wendenstraße 4   20097 Hamburg,  Germany
Phone +49 40 688 900 111 Fax +49 40 688 900 199
Email tobias.gierke@voipfuture.com   Web http://www.voipfuture.com
  
CEO Jan Bastian
	
Commercial Court AG Hamburg   HRB 109896, VAT ID DE263738086



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Strange issue with AJAX update + file download

Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,


On Thu, Apr 10, 2014 at 10:50 AM, Tobias Gierke <
tobias.gierke@voipfuture.com> wrote:

> Hi,
>
> We're using Wicket 1.5.11 with the approach described in
> https://cwiki.apache.org/confluence/display/WICKET/
> AJAX+update+and+file+download+in+one+blow to trigger a file download from
> within a modal dialog. This all works fine, our problem is with the
> rendering of the page after the download is complete.
>

What do you exactly mean by the rendering of the page after download
completed? You repaint a part of the screen via AJAX? And this is the one
giving problem with images?


>
> The page contains some dynamic images/icons that are included via
> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
> as well as a "last-modified" date that equals "now()" ). Both chrome and
> firefox re-request these images after the download has completed and
> looking at the network traffic/PCAP file I captured , I can see that Wicket
> is in fact delivering the PNGs to the browser.
>
> But:  Chrome still renders these icons using the  'image is broken'
> placeholder icon and Firefox/firebug shows the image downloads as 'never
> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
> shows a pending GET request for a JavaScript file along with the image
> download requests so the issue may be related to either caching or the
> Wicket request processing in general.
>
> Any ideas ?
>
> Thanks in advance,
> Tobias
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>



-- 
Regards - Ernesto Reinaldo Barreiro

Re: Strange issue with AJAX update + file download

Posted by Tobias Gierke <to...@voipfuture.com>.
Hi,

Tried both your suggestions, unfortunately none of them worked :(

Thanks anyway,
Tobias

> Hi,
>
> I have no idea but something you can try is replacing
>
> target.appendJavaScript("setTimeout(\"window.location.href='" + url + "'\",
> 100);");
>
> with a bigger timeout... or maybe $(function() { window....}); so that
> download is triggered once DOM is ready.
>
>
>
> On Thu, Apr 10, 2014 at 11:02 AM, Tobias Gierke <
> tobias.gierke@voipfuture.com> wrote:
>
>> ...sorry, forgot that sending attachments to mailing-lists does not
>> generally work...
>>
>> http://picpaste.com/firebug.png
>> http://picpaste.com/chrome_after_download.png
>>
>>
>>   Hi,
>>> We're using Wicket 1.5.11 with the approach described in
>>> https://cwiki.apache.org/confluence/display/WICKET/
>>> AJAX+update+and+file+download+in+one+blow to trigger a file download
>>> from within a modal dialog. This all works fine, our problem is with the
>>> rendering of the page after the download is complete.
>>>
>>> The page contains some dynamic images/icons that are included via
>>> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
>>> as well as a "last-modified" date that equals "now()" ). Both chrome and
>>> firefox re-request these images after the download has completed and
>>> looking at the network traffic/PCAP file I captured , I can see that Wicket
>>> is in fact delivering the PNGs to the browser.
>>>
>>> But:  Chrome still renders these icons using the  'image is broken'
>>> placeholder icon and Firefox/firebug shows the image downloads as 'never
>>> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
>>> shows a pending GET request for a JavaScript file along with the image
>>> download requests so the issue may be related to either caching or the
>>> Wicket request processing in general.
>>>
>>> Any ideas ?
>>>
>>> Thanks in advance,
>>> Tobias
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Strange issue with AJAX update + file download

Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,

I have no idea but something you can try is replacing

target.appendJavaScript("setTimeout(\"window.location.href='" + url + "'\",
100);");

with a bigger timeout... or maybe $(function() { window....}); so that
download is triggered once DOM is ready.



On Thu, Apr 10, 2014 at 11:02 AM, Tobias Gierke <
tobias.gierke@voipfuture.com> wrote:

> ...sorry, forgot that sending attachments to mailing-lists does not
> generally work...
>
> http://picpaste.com/firebug.png
> http://picpaste.com/chrome_after_download.png
>
>
>  Hi,
>>
>> We're using Wicket 1.5.11 with the approach described in
>> https://cwiki.apache.org/confluence/display/WICKET/
>> AJAX+update+and+file+download+in+one+blow to trigger a file download
>> from within a modal dialog. This all works fine, our problem is with the
>> rendering of the page after the download is complete.
>>
>> The page contains some dynamic images/icons that are included via
>> Image/DynamicImageResource (all have a 'antiCache' parameter in their URL
>> as well as a "last-modified" date that equals "now()" ). Both chrome and
>> firefox re-request these images after the download has completed and
>> looking at the network traffic/PCAP file I captured , I can see that Wicket
>> is in fact delivering the PNGs to the browser.
>>
>> But:  Chrome still renders these icons using the  'image is broken'
>> placeholder icon and Firefox/firebug shows the image downloads as 'never
>> completed' / 0 bytes downloaded (see attached screenshots). Firebug also
>> shows a pending GET request for a JavaScript file along with the image
>> download requests so the issue may be related to either caching or the
>> Wicket request processing in general.
>>
>> Any ideas ?
>>
>> Thanks in advance,
>> Tobias
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro

Re: Strange issue with AJAX update + file download

Posted by Tobias Gierke <to...@voipfuture.com>.
...sorry, forgot that sending attachments to mailing-lists does not 
generally work...

http://picpaste.com/firebug.png
http://picpaste.com/chrome_after_download.png

> Hi,
>
> We're using Wicket 1.5.11 with the approach described in 
> https://cwiki.apache.org/confluence/display/WICKET/AJAX+update+and+file+download+in+one+blow 
> to trigger a file download from within a modal dialog. This all works 
> fine, our problem is with the rendering of the page after the download 
> is complete.
>
> The page contains some dynamic images/icons that are included via 
> Image/DynamicImageResource (all have a 'antiCache' parameter in their 
> URL as well as a "last-modified" date that equals "now()" ). Both 
> chrome and firefox re-request these images after the download has 
> completed and looking at the network traffic/PCAP file I captured , I 
> can see that Wicket is in fact delivering the PNGs to the browser.
>
> But:  Chrome still renders these icons using the  'image is broken' 
> placeholder icon and Firefox/firebug shows the image downloads as 
> 'never completed' / 0 bytes downloaded (see attached screenshots). 
> Firebug also shows a pending GET request for a JavaScript file along 
> with the image download requests so the issue may be related to either 
> caching or the Wicket request processing in general.
>
> Any ideas ?
>
> Thanks in advance,
> Tobias
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org