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

Bug 367380

Summary:	FocusIn/FocusOut events are sent when application switches, not just widgets.
Product:	[Eclipse Project] Platform	Reporter:	Doug M <eclipse>
Component:	SWT	Assignee:	Platform-SWT-Inbox <platform-swt-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	lshanmug, markus.kell.r, remy.suen, tonny.madsen
Version:	4.2
Target Milestone:	---
Hardware:	Macintosh
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:	stalebug

Description Doug M

2011-12-21 19:56:39 EST

Build Identifier: swt-3.8M3-cocoa-macosx-x86_64

Focus events are sent when the user switches from on Widget to another, and when the application itself is switched in and out. In a sophisticated UI, FocusOut may, for example, signal the application to register and process user input in a text field. Merely switching to a different app and back should not initiate this action, since that is not the user's intention. For example, she might have switched to use a dictionary or check email, and still be in the middle of typing into an active text control.

SWT erroneously conflates the user actions of leaving and entering a control inside its app with switching to or from a second app. These actions have different meanings and need to be distinguished. They get mixed when both Shell.becomeKeyWindow and Shell.makeFirstResponder send the same focusIn events.

This design problem is causing a real-world UI bug in a desktop app I am currently developing. There is a text field where the user enters a name. When that field is left by tab or mouse click, the name is processed and entered into a database. While typing, the user may switch out to look up a spelling from the web or an address book. In that case, a partially typed name is erroneously entered.

I'd suggest as a start to stop sending focus events when the app switches. An ideally flexible design would be to distinguish among 1) focus events generated by switching focus between Widgets in a Shell; 2) switching between Shells; and 3) switching between apps.

Thanks!

Reproducible: Always

Steps to Reproduce:
1. Place focusIn and focusOut filters, or listeners on a Control.
2. Switch to a different app and back. Switch between Control.
3. Observe that focusIn/focusOut events for these two cases can't be distinguished.

Comment 1 Lakshmi P Shanmugam

2011-12-22 06:13:41 EST

With the current design you can still distinguish between the 2 cases by checking for the active shell using display.getActiveShell(). It returns null if no shell belonging to the currently running application is active. I think this can work for your scenario.

Comment 2 Doug M

2012-01-03 15:47:37 EST

A more specific statement of my UI's need is to distinguish between focusOut caused by shifting controls within a window from focusOut caused by switching to a different window OR app. You are right that these cases can be distinguished by using getActiveShell() and comparing it to ((Control) event.widget).getShell() in a focusOut listener. In OS X, the active shell has already changed either to the new shell or to null when focus leaves the active Control's window, therefore this method works.

I am glad to be able to proceed past this issue, so thanks for your help. But you must see that this fragile kludge does not address the underlying issue. It's just as reasonable that the current shell would switch AFTER the control receives its focusOut event, even more reasonable, because the control may want to take some action while it and its window still have focus. And it cannot solve the corresponding issue of focusIn, where the active shell has already switched at focusIn, making it impossible for the control to distinguish the type of focus change when focus is gained.

Comment 3 Eclipse Genie

2019-09-15 04:13:38 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 4 Doug M

2019-09-15 14:21:11 EDT

Dear Eclipse Genie,

Thank you for automatically responding to the bug report that I filed in 2011, eight years ago. At this point, I have moved on to other interests. The desktop app I was working on in 2012 was a failure, due to numerous bugs in SWT's text handling (many of which could not be worked around), and the glacial responsiveness of SWT's developers to addressing them. 

I can truly say that choosing SWT over Swing for this project was the worst design decision I have ever made in my career. I am sure that SWT is highly tuned to the limited needs of Eclipse, but as a UI for general apps it is unfit for purpose.

Thanks for listening, if anyone is.