Description Markus Krüger 2013-06-27 05:12:14 EDT

Created attachment 232832 [details]
bug.app

We use the IFocusService within dialogs and wizards to enanble or diable commands within its tables or trees. No we noticed, that the focus tracking does lead to not wanted behavior when closing a dialog or wizard with ESC or the red X.

As an example I attached an RCP demo:
There is commandId "bug.app.command.focusid" and two handlers for it.
The behavior of the first handler is to open a dialog which adds a focustracker on a text control and the behavior of the second handler using the activeFocusControlId of the text control is to print "FocusIdHandler2".
Now if you open the dialog by using the context menu to execute the first handler the dialog opens and the focus is on the text control which activates the second handler. If you close the dialog with ESC or the red X and afterwards click on the hander in the contextmenu again then the second handler is still active and prints "FocusIdHandler2".

I found the reasen for that by digging a little deeper into "org.eclipse.ui.internal.menus.FocusControlSourceProvider".
The FocusControlSourceProvider uses "focusLost" to reset the current focus control and its id. Using the buttons of the dialog triggers the focus lost event and so everthing works fine. Since using ESC or the red X of the dialog does not trigger a focus lost event the current focus control and its id will not be cleared. 
There is also a DisposeListener in the FocusControlSourceProvider which gets triggered, but it does just remove the disposed control form a map and does not reset the current focus control and its id.

The solution is to change the code in widgetDisposed to:

String id = controlToId.remove(control);
if (currentId == id) {
	currentId = null;
	currentControl = null;
	fireSourceChanged(ISources.ACTIVE_MENU, getCurrentState());
}


Hope that was not too much text :-)