Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 317183 - Toolbar buttons seem to do nothing (but are enabled)
Summary: Toolbar buttons seem to do nothing (but are enabled)
Status: CLOSED DUPLICATE of bug 318460
Alias: None
Product: e4
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 1.0   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 1.0 RC1   Edit
Assignee: Project Inbox CLA
QA Contact: Paul Webster CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-17 10:35 EDT by Dani Megert CLA
Modified: 2010-11-01 09:31 EDT (History)
4 users (show)

See Also:


Attachments
Tests to reproduce the context disposal problem (2.73 KB, text/plain)
2010-06-30 06:28 EDT, Remy Suen CLA
no flags Details
Patch for RAT disposal (7.35 KB, patch)
2010-06-30 11:39 EDT, Oleg Besedin CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2010-06-17 10:35:33 EDT
http://download.eclipse.org/e4/sdk/drops/I20100616-2127/index.php.

After starting a new workbench I see toolbar icons which are all active all the time but do nothing.

The 'Pin Editor' toolbar button seems to do nothing even if editors are open.
Comment 1 Paul Webster CLA 2010-06-29 15:38:59 EDT
If I open on a clean workspace, there's a handler created for AUTOGEN:::org.eclipse.jdt.debug.ui.BreakpointViewActions/org.eclipse.jdt.debug.ui.actions.AddException

The RAT for that activation runs against (what seems to be) the window context while I switch views in the java perspective.

If I simply open the breakpoints view, the exception breakpoint dialog opens.  If I then open the Debug perspective, it appears to work.

If I open the  Debug perspective without opening the view (it goes through the perspective switcher code, not the WorkbenchPage code), the HandlerActivation is never run again.  But I'm not sure why, since the handler was never removed as participating (so it should still be a runAndTrack against the WorkbenchWindow context and it doesn't look like legacyActionPersistence was removed).

PW
Comment 2 Paul Webster CLA 2010-06-29 17:55:47 EDT
Thread [main] (Suspended (breakpoint at line 102 in TrackableComputationExt))	
	TrackableComputationExt.update(ContextChangeEvent) line: 102	
	TrackableComputationExt.doHandleInvalid(ContextChangeEvent, List<Scheduled>) line: 50	
	TrackableComputationExt(Computation).handleInvalid(ContextChangeEvent, List<Scheduled>) line: 59	
	EclipseContext.dispose() line: 191	
	ShellActivationListener$3.widgetDisposed(DisposeEvent) line: 148	
	TypedListener.handleEvent(Event) line: 123	
	EventTable.sendEvent(Event) line: 84	
	Shell(Widget).sendEvent(Event) line: 1258	
	Shell(Widget).sendEvent(int, Event, boolean) line: 1282	
	Shell(Widget).sendEvent(int) line: 1263	
	Shell(Widget).release(boolean) line: 1080	
	Shell(Control).release(boolean) line: 3302	
	Shell(Widget).dispose() line: 462	
	Shell.dispose() line: 2239	
	SelectPerspectiveDialog(Window).close() line: 335	
	SelectPerspectiveDialog(Dialog).close() line: 979	
	SelectPerspectiveDialog(Dialog).okPressed() line: 940	
	SelectPerspectiveDialog.okPressed() line: 274	
	SelectPerspectiveDialog(Dialog).buttonPressed(int) line: 472	
	Dialog$2.widgetSelected(SelectionEvent) line: 624	
	TypedListener.handleEvent(Event) line: 234	
	EventTable.sendEvent(Event) line: 84	
	Button(Widget).sendEvent(Event) line: 1258	
	Display.runDeferredEvents() line: 3552	
	Display.readAndDispatch() line: 3171	
	SelectPerspectiveDialog(Window).runEventLoop(Shell) line: 825	
	SelectPerspectiveDialog(Window).open() line: 801	
	PerspectiveSwitcher.selectPerspective() line: 396	
	PerspectiveSwitcher.access$5(PerspectiveSwitcher) line: 393	
	PerspectiveSwitcher$10.widgetSelected(SelectionEvent) line: 286	
	TypedListener.handleEvent(Event) line: 234	
	EventTable.sendEvent(Event) line: 84	
	ToolItem(Widget).sendEvent(Event) line: 1258	
	Display.runDeferredEvents() line: 3552	
	Display.readAndDispatch() line: 3171	
	PartRenderingEngine$4.run() line: 663	
	Realm.runWithDefault(Realm, Runnable) line: 332	
	PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 588	
	E4Workbench.createAndRunUI(MApplicationElement) line: 103	
	Workbench$3.run() line: 535	
	Realm.runWithDefault(Realm, Runnable) line: 332	
	Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 519	
	PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149	
	IDEApplication.start(IApplicationContext) line: 115	
	EclipseAppHandle.run(Object) line: 196	
	EclipseAppLauncher.runApplication(Object) line: 110	
	EclipseAppLauncher.start(Object) line: 79	
	EclipseStarter.run(Object) line: 369	
	EclipseStarter.run(String[], Runnable) line: 179	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	Main.invokeFramework(String[], URL[]) line: 619	
	Main.basicRun(String[]) line: 574	
	Main.run(String[]) line: 1407	
	Main.main(String[]) line: 1383
Comment 3 Paul Webster CLA 2010-06-29 18:00:42 EDT
Oleg, my RAT is against the window context, but opening the perspective dialog and closing it causes

1) the window context computation (which worked as normal), and then
2) the dialog context disposal causes the removeAll(eventsContext) in TrackableComputationExt#update(ContextChangeEvent event)

Since it was entered against the window context, I wouldn't expect a child context dispose to take it out.

PW
Comment 4 Remy Suen CLA 2010-06-30 06:28:45 EDT
Created attachment 173076 [details]
Tests to reproduce the context disposal problem

I'm not 100% sure if this is the same thing but the test certainly fails in a way I would not have expected it to fail.
Comment 5 Oleg Besedin CLA 2010-06-30 11:39:31 EDT
Created attachment 173112 [details]
Patch for RAT disposal

The patch fixes the problem demonstrated by Remy's tests. The RunAndTrack instances did not have any idea what is the contexts that they are originally created on, and, hence, treated disposal of any context they touched as a end-of-life event. 

I changed code to store the originating context for RunAndTrack instance. 

This fixes Remy's JUnits but the toolbar button still does not work.

(Patch for RAT disposal applied to CVS Head.)
Comment 6 Oleg Besedin CLA 2010-06-30 11:42:06 EDT
After some more debugging of the original problem, it seems that there is no handler for the toolbar item after swtich perspectives:

- Set up a workspace: (default) Java perspective is open; open a Debug perspective; make "Breakpoint" an active view. Restart.
- After restart click on the "add Java exception breakpoint" tool item. The dialog starts up. Cancel the dialog.
- Switch to Java perspective; switch back to Debug perspective using perspective switcher.
- Click on the "add Java exception breakpoint" tool item. Nothing happens

To see why: place a breakpoint in HandlerServiceImpl.executeHandler(). Notice that lookUpHandler(context, commandId) returns null after perspective switch. (It returns the proper handler before the perspective switch.)
Comment 7 Oleg Besedin CLA 2010-06-30 12:36:07 EDT
The immediate problem is that ISources.ACTIVE_PART_ID_NAME needed to properly evaluate enablement is set in TWO places, and only one of them tracks correctly perspective change.

- First place: E4Application's runAndTrack based on IServiceConstants.ACTIVE_PART

This sets the value on the Workbench context and is properly updated

- Second place: WorkbenchPage.updateActivePartSources()

This sets the value on the IDEWindow context (child of the Workbench context) is breaks after the first perspective change

So, after two perspective changes we have:

Workbench context -> proper value for ACTIVE_PART_ID_NAME 
 |
 child
 |
IDEWindow context -> stale value 

The IDEWindow context is used for evalueations and its stale value overrides correct value in the parent.

In the next installement: the WorkbenchPage.updateActivePartSources() seems to break because of the PartService....
Comment 8 Oleg Besedin CLA 2010-06-30 15:26:46 EDT
This is caused by the same underlying problem as the bug 318460 (PartService stops getting updates).

*** This bug has been marked as a duplicate of bug 318460 ***
Comment 9 Dani Megert CLA 2010-11-01 09:31:46 EDT
(In reply to comment #8)
> This is caused by the same underlying problem as the bug 318460 (PartService
> stops getting updates).
> 
> *** This bug has been marked as a duplicate of bug 318460 ***

Not entirely: using SDK 4.1 - I20101029-1118 'Last Edit Location' is still enabled out of the box but shouldn't be. Filed bug 329189 to track that.