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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
