Trees can have "unsynchronized" TreeStores ->NullPointers

[acerberus]

Hi,

there is a bug in Tree(Panel)s caused by unsynchronized Stores. If a Tree is given a TreeStore it adds handlers to listen to store events. For example an added entry in the store causes the tree to register a new node. Certain events, however, can cause the store and tree to become unsynchronized. Examples are:

• Filtering
• Loading store data before giving the store to the tree
• Probably more

If now an update on the store occurs, the tree's onUpdate method is called:

  protected void onUpdate(StoreUpdateEvent<M> event) {
    for (M item : event.getItems()) {
      TreeNode<M> node = findNode(item);
      if (node.model != item) {
        node.model = item;
      }
      refresh(item);
    }
  }

Here the tree assumes that a node corresponding to the updated StoreModel exists. However, due to the two not being completely synched, this may not be the case. In this case findNode(item) return null and the whole thing produces a NullPointerException:

Caused by: java.lang.NullPointerException
	at com.sencha.gxt.widget.core.client.tree.Tree$TreeNode.access$1(Tree.java:345)
	at com.sencha.gxt.widget.core.client.tree.Tree.onUpdate(Tree.java:1864)
	at com.sencha.gxt.widget.core.client.tree.Tree$Handler.onUpdate(Tree.java:510)
	at com.sencha.gxt.data.shared.event.StoreUpdateEvent.dispatch(StoreUpdateEvent.java:101)
	at com.sencha.gxt.data.shared.event.StoreUpdateEvent.dispatch(StoreUpdateEvent.java:1)
	at com.google.gwt.event.shared.GwtEvent.dispatch(GwtEvent.java:1)
	at com.google.web.bindery.event.shared.EventBus.dispatchEvent(EventBus.java:40)
	at com.google.web.bindery.event.shared.SimpleEventBus.doFire(SimpleEventBus.java:193)
	at com.google.web.bindery.event.shared.SimpleEventBus.fireEvent(SimpleEventBus.java:88)
	at com.google.gwt.event.shared.HandlerManager.fireEvent(HandlerManager.java:127)
	... 40 more

A temporary bugfix is to override the onUpdate method with the following:

	protected void onUpdate(StoreUpdateEvent<M> event) {
		for (M item : event.getItems()) {
			TreeNode<M> node = findNode(item);
			if(null == node)
				register(item);
		}
		super.onUpdate(event);
	}

This causes the missing nodes first to be registered and then "updated".

[acerberus]

Thoughts?

[acerberus]

and .. one more push.

[acerberus]

at least an acknowledgment of this thread would be nice. Otherwise I don't really see the point of writing up bug reports ..

[sven]

I pushed this thread to the internal tracking system so it can be looked at. Thanks for bringing it up.

[Colin Alworth]

This has been fixed in SVN and nightly builds, and will be available in the next release.

We took a little different approach to fixing this, and tried to make it more than just the cases provided. Instead of doing a null check in the tree itself, the TreeStore is no longer firing events for nodes that are not visible, so that the Tree doesn't even need to think about them. This makes sense, since the TreeStore only exposes access to the nodes that are actually visible (i.e. not filtered out), so doing this should prevent issues like this. This was fixed for StoreAddEvents from addSubTree, StoreDataChangedEvents from replaceSubTree, and replaceChildren, and StoreUpdateEvents from update. A handful of other bugs were also demonstrated when building unit tests for this, mostly related to filtering and adding sub trees, these were fixed as well.