5.3.0 problems

we upgraded to 5.3.0 a week ago and our application starts to look almost same than with old itmill-toolkit-5.3.0_trunk_20080925 we had before. Now two biggest problems are slowness and syncronization error messages with unfunctional page transition.

First hole application is slower than before and ex our calendar implementation that uses Table is much slower. Actually it often crashed the page before now I set column width and height in the code. So the problem seems to be in GWT when it counts the component/column/div widths (and heights).

Other big problem is when browsing (click button) from one (not all) page to another it often stays in the same page (some components may have been hided). When user clicks the same button again it gives Syncronization Error message and after user clicks the messagewindow the desired page will open.

There is also other circumstances when some components get hided incorrectly (space where component should been is just empty white space). If user clicks browser refresh button in this point usually some other components get hided also.

Do you got some good tips to beat these problems? Have you noticed this kind of behaviour with new ITMill? We have used IE7 and Firefox 3 for testing.

  • markus

There are major changes in the layout calculation system on client-side. Does you calendar implementation contain other widgets? My guess is that the performance problems are related to widget size calculations - for some reason your implementation calculates and resizes its children multiple times.

New features to windowing API have been added to better support multiple multiple concurrent browser windows. Have you read the docs? IT Mill Ltd is now Vaadin Ltd

The calendar implementation contains only ITMill widgets, like HorizontalLayouts and Buttons.

These synchronization errors happen when user is using only one browser window so there is some other wrong in here. This is one simple scenario when this happens:

  • user is in item’s show view
  • he clicks edit button
  • some components in show view gets hided (turns to white space)
  • he clicks again edit button
  • he gets synchronization error message
  • he clicks the error message
  • edit view is opened
  • he clicks cancel button
  • some components in edit view gets hided (turns to white space)
  • he clicks again cancel button
  • he gets synchronization error message
  • he clicks the error message
  • show view is opened

This doesn’t happen in every items show/edit views but only some ones.

I forgot to tell that when user clicks again the button and synchronization message pops up it writes to following to console:
Warning: Ignoring variable change for non-existent component, VAR_PID=PID3831

May confirm, that Im also getting “Out of sync” errors, but very seldom. It happens in only one of my several tooklit-based projects, when I click a button. There are no server-side threads spawned by my own. However, this error appears veryyyy seldom for me, so I did not investigate it yet.

I don’t know if this helps but I added this line requestRepaint(); to following code part and now when user goes to show view that component that get hided after edit button click is now immediately hided :?:

public boolean setCurrentView(AbstractView applicationView) {
applicationLayout.replaceComponent(getCurrentView(), applicationView);
return true;

I debugged more and found that ComminicationManager row 396

paintables = getDirtyVisibleComponents(window); returned VerticalLayout with our own MainMenu and AbstractView components. Why this VerticalLayout is marked as “dirty” ?

It seems that server side makes things right (because if view is refreshed correct view is shown) but something in the client (GWT) side doesn’t work.

It turned out that synchronization errors happened because of same debugIds in TabSheets in both views. We used setDebugId to set anchors to help file but now I have to make a new implementation for that.

Should have red the javadocs that says “Keeping identifiers unique throughout the Application instance is on programmers responsibility.” :oops: I’m not sure if this javadoc was present in the version we used before but in that version it didn’t caused any problems.

  • markus