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

Bug 33902

Summary: [Markers] Lazy creation of Tasks View causes lost selection notification
Product: [Eclipse Project] Platform Reporter: Randy Hudson <hudsonr>
Component: IDEAssignee: Tod Creasey <Tod_Creasey>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 Keywords: helpwanted
Version: 2.1   
Target Milestone: 3.4 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Bug Depends on: 162505    
Bug Blocks:    

Description Randy Hudson CLA 2003-03-05 15:16:48 EST
The Tasks view normally receives selection events from the selection service.  
Giving focus to the Java editor will cause the tasks view to display only tasks 
associated with that resource (when using "on selected resource").  So, if I 
have my Tasks view and my Search stacked, and I click on the Java editor, and 
then on the Tasks Tab, I will see the tasks associated with that editor.

But, if I shutdown the workbench and bring it back up, it doesn't work. If I 
shutdown with the Search view on top, then the Tasks view is lazily initiated.  
The first time I select the Tasks view, it is created, but it never received 
the selection event from when the EditorPart was the active part. The user 
becomes are of an implementation detail.

One possible fix is that the Tasks view poll the SelectionService for the 
current selection when it is first created.  That way, it will recover the 
selection event that it didn't receive.
Comment 1 Randy Hudson CLA 2003-09-12 14:19:19 EDT
This is sort of related.

Update:  In M3, let's assume:

1) you've hacked the Tasks View to filter ON_SELECTED_RESOURCE_AND_CHILDREN, 
because ON_ANY_RESOURCE is not productive.
2) You press F4 and open a new workbench window on a CU, and the Tasks View is 
present in the Hierarchy Perspective which appears.

Then:
You will see the Tasks View quickly populate itself with *ALL* tasks (because 
it has received NULL as selection?), and then it will immediately receive the 
CU as the selection, and then populate itself again based on the few tasks in 
the CU.

So, in short, it should know about the selection at the time it first populates 
itself, so it doesn't waste time showing you all tasts.  This is probably a 
significant portion of the time required to open the window.
Comment 2 Randy Hudson CLA 2004-06-16 10:16:51 EDT
Still broken in 3.0 RC2, and it affects both Problems and Tasks View.

I selected on a project with Red Xs, then I selected on the Problems View which 
was not yet visible.  I saw no items in the prob. view even though there should 
obviously be errors displayed.
Comment 3 Randy Hudson CLA 2005-01-25 13:12:15 EST
Another scenario, select a project in some view, and then open the problems 
view (previously closed). It should be seeded with the project as the selection.
Comment 4 Tod Creasey CLA 2005-11-02 14:57:57 EST
We now show a "Pending" notification as we calaculate
Comment 5 Randy Hudson CLA 2005-11-07 13:14:05 EST
The problem is what gets displayed, not when. It's great that displaying the 
wrong info is now done on a background thread.
Comment 6 Mike Wilson CLA 2007-06-21 13:42:29 EDT
Very odd... I tried the following steps with 3.3 (on Mac OS X):
- Starting with a stack containing Javadoc, Declaration, Problems and Tasks views
- Set Problems and Tasks to filter on selected element and children
- Bring the Declaration view to the front
- Shutdown and Restart
- Select a resource that will show both warnings and tasks -- I picked the org.eclipse.core.commands project
- Click on Problems; notice that the warnings *are* displayed properly
- Click on Tasks; notice that tasks are not shown
- Click on the resource again; notice that the tasks are shown

The strange thing is, if you swap the order of when you click on the Problems and Tasks views, you will see that the Tasks view is filled in properly, but the Problems view is not.

I'd like to make sure we at least understand why we are getting the above strangeness. Raising the priority.


Comment 7 Tod Creasey CLA 2007-06-21 15:48:36 EDT
Something to look at for a markers view rework
Comment 8 Tod Creasey CLA 2007-10-22 11:32:58 EDT
This is not an issue with the new markers view. I am going to mark this for 3.4 and retest when we make the move to the new one (M4).
Comment 9 Tod Creasey CLA 2007-12-03 15:31:04 EST
Marking fixed as the new view has been released for M4.
Comment 10 Tod Creasey CLA 2007-12-10 16:06:03 EST
Verified in I20071210-0930