In the tree page of the component-showcase, I added some debug to an the ice:tree's ice:treeNode's icon facet's ice:commandLink's actionListener. From there I found that:

• The tree's navigatedNode is correctly set to the last node that was expanded or collapsed.
• The tree's navigatedNode is accessible when expanding/collapsing or when clicking on other nodes.
• The tree's currentNode is correctly set to the current node being clicked on.
• The tree's currentNode is null when expanding/collapsing.
• The tree's nodePath is correctly set to the current node being clicked on.
• The tree's nodePath is null when expanding/collapsing.

But there is one thing not correct:

• If you get the UIComponent source of the ActionEvent, and check its clientId, then that's set to the last node's clientId. So we're probably queuing the ActionEvents to come in without setting that up properly. This for for both expanding/collapsing and node clicking actionEvents.

I also added some code to look at the DefaultMutableTreeNode's parentage for navigatedNode and currentNode, when expanding/collapsing and when clicking, and in all those cases, the nodes had the right parentage, going all the way up to the root node.

The same thing is happenning in the ValueChangeEvents as in the ActionEvents.

I went through the list of components, and updated the metadata files to make sure they had an entry for the styleClass property, and that the description made reference to the proper default CSS class names, as given in xp.css and royale.css.

Subversion 14275
<Too many files to manually list>

Ignore the last comment - it was for ICE-1745.

According to Adnan, who said that he looked into how the stock JSF component handle this, they queue the events as well, and so would not have access to the source UIComponent while it's still setup as with the proper clientId and submittedValue.

This bug can be fixed if add setCurrentVarToRequestMap(getFacesContext(), eventNode); code in broadcast method as follows:

public void broadcast(FacesEvent event) throws AbortProcessingException {

if (!(event instanceof NodeEvent))

// Set up the correct context and fire our wrapped event
NodeEvent wrapperEvent = (NodeEvent) event;
DefaultMutableTreeNode eventNode = wrapperEvent.getNode();
this.setCurrentNode(eventNode);
this.setNodePath(TreeRenderer.getPathAsString(eventNode,
(DefaultMutableTreeNode) getModel()
.getRoot()));

//fix ICE-1409 bug
setCurrentVarToRequestMap(getFacesContext(), eventNode);

FacesEvent facesEvent = wrapperEvent.getFacesEvent();
facesEvent.getComponent().broadcast(facesEvent);
}

Looks legitimate.

When I tried to reproduce this issue, I could not. The code looked like it was already covering this scenario. When I investigated the svn history of the code, I found that it had been fixed by ICE-2018.