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

Bug 346076

Summary: [editor][performance] SelectionListenerWithASTManager does not cancel previous selection calculation if switching editors
Product: [WebTools] JSDT Reporter: Ian Tewksbury <itewksbu>
Component: GeneralAssignee: Ian Tewksbury <itewksbu>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: normal    
Priority: P3 CC: cmjaun
Version: 3.2.3Flags: thatnitind: review+
Target Milestone: 3.3.1   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Fix Patch
none
Fix Patch - Update 1 none

Description Ian Tewksbury CLA 2011-05-17 08:35:31 EDT 
Currently the SelectionListenerWithASTManager is designed such that if the selection changes inside of a single editor then the previous selection calculation, if still running, will be canceled.  This is to save on unnecessarily type building.  If the user switches selection between editors though the selection calculation is not canceled.  The end effect of this is that if the user switches selection between multiple editors in quick succession the type hierarchy for all of those selections will be calculating in parallel using unnecessary system resources.

The fix is to cancel all selection calculations on a selection change whether they be in the same editor or a different editor from the new selection.
Comment 1 Ian Tewksbury CLA 2011-05-17 09:00:37 EDT 
Created attachment 195848 [details]
Fix Patch

This patch does three things.

It updates the SelectionListenerWithASTManager so that it will cancel all selection jobs if a the selection changes instead of just the one in the current editor.

The second thing it does is update JavaScriptUnitResolver to check its canceled status more often. More specifically now it will check it before and after every call to one of the #accept methods.

Lastly the CancelableProblemFactory is updated to throw an OperationCanceledException rather then an AbortCompilation exception so that the exception gets handled by the correct catch blocks.  As an AbortCompilation exception it would be logged, but there is no need to log this because it is a legal state to get into.
Comment 2 Nitin Dahyabhai CLA 2011-05-18 21:28:18 EDT 
Although IProgressMonitor#worked() only requires a non-negative number, I'm not comfortable with it being called with 0.
Comment 3 Ian Tewksbury CLA 2011-06-07 09:48:52 EDT 
Created attachment 197493 [details]
Fix Patch - Update 1

Same solution as my first patch except a new function is created to check the cancelled state of the monitor so 0 is no longer passed to #worked().
Comment 4 Nitin Dahyabhai CLA 2011-07-14 02:10:49 EDT 
Approved and committed.