You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Daniel Fernández (JIRA)" <ji...@apache.org> on 2009/04/27 23:16:30 UTC

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

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



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.


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

Posted by "Esko Suomi (JIRA)" <ji...@apache.org>.
    [ 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.


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

Posted by "Daniel Fernández (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703544#action_12703544 ] 

Daniel Fernández commented on WICKET-2246:
------------------------------------------

Well, in fact, the "DOM replacement" issue only arises in Opera... it works (or seems to) in IE. The thing that does not work in IE is that it never generates the request to get the data (as opposed to Opera which requests the data but never updates it)...

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


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

Posted by "Vjacheslav Kanivetc (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704805#action_12704805 ] 

Vjacheslav Kanivetc commented on WICKET-2246:
---------------------------------------------

Esko Suomi, innerHtml is the only valid way to change data in table (and table instead). The reason is simple, if you do manual appendChild/etc you need to recreate all that silly tags like thead and so on, in order to be rendered in IE, that is actually not really required for the table, so adds extra problems for javascript. Using innerHtml is the only method to apply DOM objects you need to the html without problem that some browser will just skip some elements as assumes if they are on bad position.

PS: Recent Chrome versions have problems with automatic updates via timer, that did not happen before... But anyhow, Wicket does not support Chrome yet...

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


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

Posted by "Daniel Fernández (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703385#action_12703385 ] 

Daniel Fernández edited comment on WICKET-2246 at 4/27/09 2:20 PM:
-------------------------------------------------------------------

Uploaded test page and panels for reproducing these issues

      was (Author: dfernandez):
    Test page and panels for reproducing these issues
  
> 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.


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

Posted by "Daniel Fernández (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Fernández updated WICKET-2246:
-------------------------------------

    Attachment: AbstractAjaxBehavior.zip

Test page and panels for reproducing these issues

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


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

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ 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.


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

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-2246.
-----------------------------------

      Assignee: Igor Vaynberg  (was: Matej Knopp)
    Resolution: Cannot Reproduce

we mustve fixed it somewhere along the way, now works even fine on opera 10.61

> 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: Igor Vaynberg
>         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.