Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 361525

Summary: IOOBE in Zest graph when applying a filter having a stale selection
Product: [Tools] GEF Reporter: Jan Mauersberger <mauersberger>
Component: GEF-Legacy ZestAssignee: gef-inbox <gef-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: steeg
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Jan Mauersberger CLA 2011-10-20 07:44:55 EDT
Build Identifier: M20100909-0800

I have no full reproduction scenario yet but it is different than bug 224116: my Zest graph/viewer has a selection when I add a filter to the viewer. That causes an internal refresh which creates a new Graph internally. However, the code is executed within the "preservingSelection" method and the IOOBE is thrown when the old selection is restored, probably because the graph node does not exist anymore. 

I think either selection preserve has to handle this or "unHighlightNode" must be more smart and handle the case, the node isn't there any more?


Reproducible: Always

Steps to Reproduce:
1. Have a Zest based graph viewer
2. Select the root node
3. Apply an arbitrary filter that filters some of the nodes (not the root node)
4. Select anywhere in the graph --> IOOB
Comment 1 Jan Mauersberger CLA 2011-10-20 08:26:41 EDT
Well, while fumbling around with this issue, I recognized that I might be wrong an the issue is of more general nature. It seems that while clearing the selection Zest tries to unhighlight the current selected figures in the root layer but that fails because (1) the graph was recently created and there isn't any figure yet to unhighlight but (2) the selection was set right after the graph was created (by code). Is that something that makes sense? Ian?
Comment 2 Fabian Steeg CLA 2011-10-20 17:03:14 EDT
Thanks for the bug. Could you attach the stack trace for your exception?
Comment 3 Jan Mauersberger CLA 2011-10-21 03:54:29 EDT
(In reply to comment #2)
> Thanks for the bug. Could you attach the stack trace for your exception?

The relevant stack is:

java.lang.IndexOutOfBoundsException: Index: -1, Size: 0
at java.util.ArrayList.add(ArrayList.java:367)
at org.eclipse.zest.core.widgets.internal.ZestRootLayer.unHighlightNode(ZestRootLayer.java:111)
at org.eclipse.zest.core.widgets.Graph.unhighlightNode(Graph.java:812)
at org.eclipse.zest.core.widgets.GraphNode.unhighlight(GraphNode.java:468)
at org.eclipse.zest.core.widgets.Graph.clearSelection(Graph.java:724)
at org.eclipse.zest.core.widgets.Graph.setSelection(Graph.java:322)
at org.eclipse.zest.core.viewers.internal.AbstractStylingModelFactory.clearGraph(AbstractStylingModelFactory.java:347)
at org.eclipse.zest.core.viewers.internal.AbstractStylingModelFactory.refreshGraph(AbstractStylingModelFactory.java:311)
at org.eclipse.zest.core.viewers.internal.AbstractStructuredGraphViewer.internalRefresh(AbstractStructuredGraphViewer.java:332)
at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1487)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1422)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1383)
at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1485)
at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1444)
at org.eclipse.jface.viewers.StructuredViewer.removeFilter(StructuredViewer.java:1584)
(... my code ...)
Comment 4 Jan Mauersberger CLA 2011-10-21 05:32:03 EDT
Two additional hints:
 - the viewer is based on code form Ian's bundle dependency viewer
 - it seems that problems arise when I set the selection on the viewer internally by code (e.g. in the focusOn method of Ian's viewer it's also done after new input was set
 - manually set selections (via mouse) do not seem to cause these problems
Comment 5 Fabian Steeg CLA 2011-10-21 15:24:26 EDT
Thanks for the details - looking at the code in which the exception occurs I believe this is fixed in the latest version of Zest (the -1 case is handled). Could you give it a try with the nightly build from this update site:

https://hudson.eclipse.org/hudson/job/gef-zest-nightly/lastSuccessfulBuild/artifact/targetPlatform/
Comment 6 Jan Mauersberger CLA 2011-10-27 04:49:50 EDT
Fabian,

as far as I can see the build is a 2.0.0 build and the code of the ZestRootLayer has changed a lot compared to my 1.2.0 version. From just looking at the code the behavior has completely changed and I assume that things are fixed. However, I cannot test it since our tool has'nt been migrated to 3.7 yet, which seems to be the pre-requisite for ZEST 2.0.
Comment 7 Fabian Steeg CLA 2011-10-27 20:15:20 EDT
I've added two tests that attempt to reproduce the basic problem (GraphTests#testUnHighlightNode and GraphTests#testUnHighlightConnection).

They trigger the problem with very unrealistic calls (like `new ZestRootLayer().unHighlightNode(new Figure())` for nodes), but should cover it.

Added the check for negative indexes that fixes this in Zest 1.x head.