You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Esko Suomi (JIRA)" <ji...@apache.org> on 2009/04/28 11:02:31 UTC

[jira] Commented: (WICKET-2246) AbstractAjaxTimerBehavior showing different issues on several browsers when used for polling data and updating browser's DOM

    [ https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703542#action_12703542 ] 

Esko Suomi commented on WICKET-2246:
------------------------------------

One possible reason/issue is that IE (most likely up to version 7, haven't checked myself) can't replace parts HTML tables using common replacement methods. See http://msdn.microsoft.com/en-us/library/ms532998(VS.85).aspx for more information. Also note that .innerHTML is the incorrect way to do the replacement within tables, it's a function introduced by IE which has been adapted over time by other browsers with various degrees of functionality.

> 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
>         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.