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

Bug 368940

Summary:	[Shell] Prevent application from having no active shells
Product:	[RT] RAP	Reporter:	Tim Buschtoens <tbuschto>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	rsternberg, tbuschto
Version:	1.5
Target Milestone:	1.5 M7
Hardware:	All
OS:	All
Whiteboard:

Description Tim Buschtoens

2012-01-18 06:32:53 EST

Using RWT.ACTIVE_KEYS and event filter to get all strokes for certain keys doesnt work if the document background is focused, i.e. no control is focused. What happens that the request IS sent with "w1" (display) as the target, but the server doesnt seem to process it.

Comment 1 Ralf Sternberg

2012-01-18 07:27:11 EST

After a discussion with Ivan, we came to the conclusion that this case will likely never happen in SWT.  An application will only receive events from the OS if one of it's shells has the keyboard focus.  There seem to be two ways to solve this issue:

a) be consistent with SWT and don't send any requests when no control is focused / no shell is active.  In this case the last active shell would have to be deactivated.  Currently, it stays active (title bar has blue background).

b) prevent the last active shell from being deactivated by clicking on the document.  As long as a shell is active, there should always be a focus control (a control or the shell itself).

I'm in favor of b).

Comment 2 Tim Buschtoens

2012-02-17 05:30:41 EST

b)

Comment 3 Ivan Furnadjiev

2012-02-17 09:22:58 EST

+1 for b) too.

Comment 4 Tim Buschtoens

2012-04-03 11:36:29 EDT

The Shell is actually still active, it's just the focus that is now on the ClientDocument. I will fix this by changing the EventHandler.js to not set focus if ClientDocument has been clicked.

Comment 5 Tim Buschtoens

2012-04-03 12:09:12 EDT

Fixed in CVS HEAD as described above.

Note that this is not the ideal solution. The document can still be focused in theory, just not by mouse (and probably not in practise). The best fix would have been to make ClientDocument explicitly non-focusable, which would require to deactivate it as a focus-root, and that would break a lot of test.