[JBoss JIRA] Created: (RF-4317) scrollableDataTable: incorrect rows order after scrolling and other drawbacks
by Oliver P??tter (JIRA)
scrollableDataTable: incorrect rows order after scrolling and other drawbacks
-----------------------------------------------------------------------------
Key: RF-4317
URL: https://jira.jboss.org/jira/browse/RF-4317
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.2.0, 3.2.1
Environment: IE6, IE7
FF 2.x
Reporter: Oliver P??tter
Assignee: Tsikhon Kuprevich
Priority: Critical
Fix For: 3.2.2
When using a rather large number of rows
(for examle <input id="j_id1:articleList_rows_input" name="_rows_input" type="hidden" value="163586" />, but rows="30")
scrolling for a while in a scrollableDataTable with IE6 or IE7 breaks the data that is shown in the table.
The testdata that is shown in the table has an ascending row number without gaps in the data.
After scrolling for a while the row numbers of rows that are visible
in the table are not ascending anymore, there can be several blocks
of ascending rows.
If the table is in such a state then the data in the visible row does not
correspond to the data of the selected rows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 2 months
[JBoss JIRA] Updated: (RF-4352) Responses processed in different order from original requests.
by Nick Belaevski (JIRA)
[ https://jira.jboss.org/jira/browse/RF-4352?page=com.atlassian.jira.plugin... ]
Nick Belaevski updated RF-4352:
-------------------------------
Fix Version/s: Future
Affects Version/s: 3.2.2
Assignee: Alexander Smirnov
> Responses processed in different order from original requests.
> --------------------------------------------------------------
>
> Key: RF-4352
> URL: https://jira.jboss.org/jira/browse/RF-4352
> Project: RichFaces
> Issue Type: Bug
> Affects Versions: 3.2.2
> Environment: Suse Linux:
> Linux nebula 2.6.18.8-0.9-bigsmp #1 SMP Sun Feb 10 22:48:05 UTC 2008 i686 i686 i386 GNU/Linux
> n
> Jboss 4.2.2.GA
> Seam 2.0.1.GA
> Richfaces 3.2.1.GA
> Firefox 3
> Reporter: Paul Pantages
> Assignee: Alexander Smirnov
> Fix For: Future
>
> Attachments: jboss-seam-booking.ear
>
>
> I modifed Seam booking example for this test.
> I will attach example in jboss-seam-booking.ear
> (1) Deploy the ear file and point Firefox to
> http://<YOUR JBOSS IP>:8080/seam-booking
> This should take you to mytabel.seam where there will be a table and a few buttons.
> The table has 500 rows.
> A poller refreshes the table every 4s or so.
> The poll takes a while to complete as there are so many rows.
> There are some select/unselect buttons, which can be used to select the whole table.
> The select/unselect operations are very quick (compared to the poll).
> There is a status on the RHS that will show "Polling" when the poller is invoked.
> The status on the RHS will show "Working" when buttons are pressed.
> (2) Watch the status for a while and make sure the poller is running. Let it go a few polls to make sure it is working.
> (3) When the poller is running, as evidenced by the "Polling" status msg., press the SELECT_ALL button.
> When the SELECT_ALL operation completes, the table is not re-rendered, but the row styles are modified by to reflect that the "select all" request is complete.
> This is done by an oncomplete event handler on the button.
> (4) Watch the status and you should see that the select operation completes before the poll completes, and the table is "selected".
> (5) Watch the status to see the poll complete. The table is rerenderd and the rowStyles are re-written. The table appears "unselected", as the poll was processed,by the server, before the select operation
> (6) If you wait for another poll, the table will be rendered and properly selected.
> It appears that the response for the poll was processed after the select response.
> (7) Check the Log: If you tail the log file:
> tail -F ../logs/debug.log|grep myTable
> You will see some logs like this, and can tell whether the poll was processed before the
> select/unselect button or vice versa. The "get ajaxRenderList" trace indicates the poll
> was processed before "unselect all"
> Client: [myTable] get ajaxRenderList mainPanel
> Client: [myTable] get rowClasses
> Client: [myTable] unselect all
> ....
> This shows that the requests have bee processed in the proper order.
> (8) If you click the toggle alerts, an alert will pop up for the onbeforedomupdate event on the poller and select buttons. Repeat 1-6 .This can be used to verify that event for the buttons occurs before the poll, when the requests were made in the opposite order.
> (9) If necessary the page size can be adjusted 0-1000 to make the problem easier to reproduce. Dep on the performance of your host.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months