[
https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Vaynberg reassigned WICKET-2246:
-------------------------------------
Assignee: Matej Knopp
it seems to be a weird concurrency issue that only happens when this page is
browser's first request after cold start. it seems that an ajax request will
try to pull in some header contributions even though they are already included
in the page
<?xml version="1.0" encoding="UTF-8"?><ajax-response><header-contribution
encoding="wicket1" ><![CDATA[<head
xmlns:wicket="http://wicket.apache.org";><script type="text/javascript"
src="resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js"></script>
<script type="text/javascript"
src="resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js"></script>
<script type="text/javascript"
src="resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js"></script>
<script type="text/javascript"
id="wicket-ajax-debug-enable"><!--/*--><![CDATA[/*><!--*/
wicketAjaxDebugEnable=true;
/*-->]^]^>*/</script>
if this is indeed the case, then it would make sense that this problem is
exacerbated by a slower connection to a remote server. it also makes sense that
it only happens on first request because browser will have the two resources
cached after the first request.
matej any ideas on this one?
the second issue - about opera not updating dom is an unrelated issue. wicket
has special javascript that deals with replacing table elements like tr so it
should work - maybe opera is just being quirky. need to get opera installed.
> AbstractAjaxTimerBehavior showing different issues on several browsers when
> used for polling data and updating browser's DOM
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-2246
> URL: https://issues.apache.org/jira/browse/WICKET-2246
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC2
> Environment: This issue affects several browsers. These browsers and
> versions have been used for testing:
> * Mozilla Firefox 3.0.9 (Windows XP) and 3.0.1 (Linux)
> * Internet Explorer 7.0.5730.13 (Windows XP)
> * Opera 9.64 (Windows XP and Linux)
> * Google Chrome 1.0.154.59 (Windows XP)
>
> The web application is deployed on an Apache Tomcat 5.5.27 server.
> Reporter: Daniel Fernández
> Assignee: Matej Knopp
> Attachments: AbstractAjaxBehavior.zip
>
>
> Scenario
> =========
> A page contains a dashboard, which is a table with several rows of data, in
> which each row must retrieve its data from a different business process. All
> of these rows' processes are very heavy, and they all should be executed
> concurrently when the dashboard is loaded. Each row should show its data as
> soon as it is available, not waiting for other rows to finish and
> disregarding their order or position inside the table.
> Being the busines processes heavy, they will be executed asynchronously, and
> each row will perform scheduled AJAX polling operations against the server by
> using a subclass of AbstracAjaxTimerBehavior. While the data computation is
> not complete, a typical rotating indicator image will be shown, which will be
> substituted by the data when it is available.
> This scenario and the issues that arise can be simulated with the files
> contained in the attached file, which have comments explaining their function.
> 1st issue: OPERA does not update DOM correctly
> ==============================================
> When using Opera to browse this page, after some time the "Wicket AJAX Debug"
> window will show that all the data for all the rows have already been sent to
> the browser, but Opera may not have updated the DOM for all these rows
> correctly, and so only some rows may be showing their data.
> This effect occurs in a quite random manner (it even works completely alright
> sometimes), and it gets worse with network latency (it is worse when tested
> on a remote server than it is in localhost).
> 2nd issue: FIREFOX, IE and CHROME stop polling the server after a fresh start
> =============================================================================
> When using these three browsers, it may happen that the browser suddenly
> stops sending AJAX requests for row data (or even does not send it at all for
> some rows), and so obviously it never gets loaded.
> This only happens after a fresh start of the browser, and everything works
> perfectly fine after hitting the "reload" button. It also occurs in a quite
> random manner and works completely alright sometimes, but it gets much worse
> with network latency (worse when tested on a remote server, as happens with
> issue no.1).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
