Table renders layouts incorrectly when changing containers

[Risto Yrjana]

The bug appears when using a Table containing Layouts. When rapidly changing the underlying container, Table incorrectly caches the layouts. The containers can have similar or different content, and can be of different lengths. This bug also appears when using one container but changing its contents.

Simple test:

• Create two IndexedContainers? and fill them with a layout containing one button with some text
• Create a table with the first container and then switch the container a couple of times with Table.setContainerDataSource()
• The buttons should be rendered without their contents

[Risto Yrjana]

Testcase for the ticket

[Risto Yrjana]

There is an exception thrown if you

• Make the table render layouts incorrectly
• Wait for a while
• Scroll the table

Here is the stack trace from the exception:

java.lang.ArrayIndexOutOfBoundsException?: 15

at com.itmill.toolkit.ui.Table.refreshRenderedCells(Table.java:1284) at com.itmill.toolkit.ui.Table.enableContentRefreshing(Table.java:1695) at com.itmill.toolkit.ui.Table.changeVariables(Table.java:1673) at com.itmill.toolkit.terminal.gwt.server.CommunicationManager?.handleVariables(CommunicationManager?.java:575) at com.itmill.toolkit.terminal.gwt.server.CommunicationManager?.handleUidlRequest(CommunicationManager?.java:245) at com.itmill.toolkit.terminal.gwt.server.ApplicationServlet?.service(ApplicationServlet?.java:431) at javax.servlet.http.HttpServlet?.service(HttpServlet?.java:803) at org.apache.catalina.core.ApplicationFilterChain?.internalDoFilter(ApplicationFilterChain?.java:290) at org.apache.catalina.core.ApplicationFilterChain?.doFilter(ApplicationFilterChain?.java:206) at org.apache.catalina.core.StandardWrapperValve?.invoke(StandardWrapperValve?.java:233) at org.apache.catalina.core.StandardContextValve?.invoke(StandardContextValve?.java:175) at org.apache.catalina.core.StandardHostValve?.invoke(StandardHostValve?.java:128) at org.apache.catalina.valves.ErrorReportValve?.invoke(ErrorReportValve?.java:102) at org.apache.catalina.core.StandardEngineValve?.invoke(StandardEngineValve?.java:109) at org.apache.catalina.connector.CoyoteAdapter?.service(CoyoteAdapter?.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:637)

[Matti Tahvonen]

in [5260]

Test case is in trunk

empty ("cached" in uidl) layouts were due rows were re-fetched and client side table has not that advanced sub component handling. Changed the caching so that no re-fetches should happen, since then didn't get any empty buttons. A side effect is that there may be two cache row fetches instead of one in some situations.

I didn't get out of bounds errors at all, so I may have missed something. Please re-open with more details if you continue to have problems.

[Risto Yrjana]

With the newest trunk, we still encounter this bug in our application. It is somewhat hard to reproduce in a small test case. E.g. the out of bounds error, or some gwt-exceptions. Here is another test case for the current trunk.

[Matti Tahvonen]

reduced test case 2 in [5509]

[Matti Tahvonen]

fixed in [5510]. Bug only existed if an empty container was set and after that the old one. In this case a proper cleanup of old components and properties was not done. Also made IScrollTable subtree savvy and removed hacks.

Do you need this fix be included in 5.2.x ?

Risto, tips for the future. Characteristics of a good test case:

• as simple as possible aka reduced (now the loop inside click listener was uncecessary)
• Use random only if really needed, and when needed with seeded generator if possible.

[Risto Yrjana]

My apologies for the bloated test case, it was already a reduced version of a larger test I was using. I did the refactoring in a hurry I guess. If possible, it would be nice to have this in 5.2.x, as the table bugs are troublesome in our application. I'll try this fix and see if I can find any more problems.

[Marko Gronroos]

The current fix in [5510] is not compatible with GWT 1.4, so it's not possible to merge this directly to 5.2.x branch. GWT 1.4 doesn't support LinkedList.

If you want this in 5.2.9, please provide a compatible solution asap. And reopen the ticket and target to 5.2.9.

[Matti Tahvonen]

Risto, if you still want to use 5.2 in your project, please swap LinkedList? to ArrayList? and commit it to trunk. Then the patch ought to be 1.4 compatible.

[Matti Tahvonen]

Did it by myself in [5540]