Community
Participate
Working Groups
This problem occurs with a large VIRTUAL MULTI Table when using key navigation to scroll down. The key presses change the selection but sometimes the old selection is not cleared. See attached screenshot.
Created attachment 162415 [details] Screenshot to show the problem
After some testing I could reproduce this "double" selection ONLY under FF (tested version 3.6.6 under Windows). Other browsers not affected (tested, couldn't reproduce): IE8, Sfari 5.0.7533.16, Chrome 6.0.458.1, Opera 10.60.
The bug is still valid with 1.4M4+ and FF 3.6.13.
I cant reproduce it with the new Table, but neither with the old one. Can anyone confirm the problem is gone in HEAD?
The problem is still there - tested with HEAD (with merged Tree/Table) and Firefox 4.
With the current CVS HEAD is even worse - the old selection is not removed and new item is selected. As a result we have two items selected. Now it's reproducible in all browsers, tested with IE, Chrome, FF and Safari..
Actually, it is reproducible with SINGLE VIRTUAL table as well. We looked at it today again and I think that it could be fixed easily with Table protocol migration (move rendering of table selection to TableLCA). As we have plans to migrate the Table to the protocol in next milestone, I hope that this will be fixed in M4.
We might want to fix this for 1.4.2. aswell, but there the prototocol doesnt exist. Alternatives?
(In reply to comment #8) > We might want to fix this for 1.4.2. aswell, but there the prototocol doesnt > exist. Alternatives? The solution will be to investigate why the previous selected item is not deselected from the server-side... or maybe we can do the deselection on the client as well in this case?!
I would feel much more comfortable with a server-side solution, as changing the client table would mean also changing the client tree.
Tim, we are talking about a fix for 1.4.2. There (v14_Maintenance branch), the Tree and Table are not merged on the client :-). Fixing Table will not reflect on Tree in any way.
riiiight.... still think a java-only solution is less risky overall
After some additional investigation I found the following. The Table selection is read from the client and set on the server-side Table in TableLCA. When TableItemLCA#preserveValues is called, the new selection is already set on the Table from TableLCA. Thus, rendering of deselected item is not performed from the server. One possible solution is to wrap the code in TableLCA#readSelection in ProcessActionRunner like this: ... ProcessActionRunner.add( new Runnable() { public void run() { table.deselectAll(); table.select( newSelection ); } } ); ... With this code the deselection is performed from the server, but there is an annoying flickering on the client. The clean solution will be same refactoring which will be performed for the HEAD - handle read and *write* of selection from the same LCA (TableLCA). As this is a big refactoring I don't think that it is suitable for 1.4.2. That's why, I will prefer a client-side solution if possible.
(In reply to comment #13) > ... > With this code the deselection is performed from the server, but there is an > annoying flickering on the client. To introduce an annoying flickering is most likely not an option for the final service release ;-) > The clean solution will be same refactoring > which will be performed for the HEAD - handle read and *write* of selection from > the same LCA (TableLCA). As this is a big refactoring I don't think that it is > suitable for 1.4.2. Agree. Since this bug is rather old and didn't seem to affect too many users, I'd tend to fix it only in HEAD. > That's why, I will prefer a client-side solution if > possible. If it's simple and safe, yes, otherwise, let's look forward.
With migration of Table to the protocol I can't reproduce this issue anymore.
