Bug 330089

Description Istvan Ballok 2010-11-12 08:55:31 EST

The Problem
===========
The SetDataEvent fired by a virtual Table is used to set/update
the content of the visible TableItems.

Under certain conditions*, this event is not fired, and hence, the Table
remains empty.

*Preconditions of the problem:
==============================
1) The table is created and updated in the first, initial request, when
the application is started.
-> it is a feasible requirement.
2) Setting the Table#itemCount is performed after the initial layout.
-> this is always the case, when the update of the virtual table
(Table#setItemCount / Table#clearAll; Table#redraw methods) is triggered
in a Display#asncExec block.

If the same snippet is executed in a Button#selectionEvent,
it works fine. (because it is not the first, initial request)

If the same snippet is executed in a Display#syncExec block, it works fine.
(there are other mechanisms, such as the layouting/control size changed,
that call the private Table#checkData method directly that triggers
the firing of the SetDataEvents)

Please check the supplied patch to reproduce the problem in the
controls demo.

Explanation of the problem
==========================
see RWTLifeCycle#execute(): the first request does not run through every
phase that is executed in all other subsequent requests.

- first request: 1) prepare ui root 2) render
- subsequent requests: 1) prepare ui root 2) read data
                       3) process action  4) render
ie., the "process action" phase is missing in the initial request.
Note: This makes sense, because there are no events sent from the browser
in this case. (=this is the initial request)

The Table#redraw method that should fire the the SetDataEvents in the end,
performs this task in an indirect way:
it calls the RWTLifeCycle#fakeRedraw method to add
the control to a set stored in the Request's context;
a collection of widgets marked to be redrawn, when the "time comes".

RWTLifeCycle#doRedrawFake performs then the redraw action on the controls,
that were added to the collection in the previous step.
In the case of the Table, this results in calling the
Table#checkData(item, index) method, that at last fires the SetDataEvents.

This mechanism breaks in the specific case described in this bug.
The problem is:

The RWTLifeCycle#doRedrawFake is called in
RWTLifeCycle#afterPhaseExecution, but only if the current phase was a
"process action".

Hence, we can now understand the problem:
in the initial request, there is no "process action" phase, the widgets,
that were marked for redraw, are not 'redrawn' at all, because the
RWTLifeCycle#doRedrawFake is not called!

Note:
=====
after starting the server, the first time you start the application
in the browser, it works fine. Later, if you restart the application
in the browser, you can reproduce the problem as I described it above.

The explanation for that is, that the very first time, the text size
determination mechanism kicks in and relayouts the shell with enlarged
bounds. (See TextSizeDeterminationHandler#afterPhase(PhaseEvent))

When the size of the table is changed, the Table#checkData method is
called directly (without the mechanism above), and that fires the
SetDataEvents.