Hi,
Hi,
On Thu, Apr 10, 2014 at 1:13 PM, Tobias Gierke <[email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
--
Tobias Gierke
Development
VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany
Phone +49 40 688 900 111 Fax +49 40 688 900 199
Email [email protected] Web http://www.voipfuture.com
CEO Jan Bastian
Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Tobias Gierke
Development
VOIPFUTURE GmbH Wendenstraße 4 20097 Hamburg, Germany
Phone +49 40 688 900 111 Fax +49 40 688 900 199
Email [email protected] Web http://www.voipfuture.com
CEO Jan Bastian
Commercial Court AG Hamburg HRB 109896, VAT ID DE263738086
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
