Bug 892

Summary: Newt and Java focus gained and lost events are inconsistent
Product: [JogAmp] Newt Reporter: Jesse <narf_bro>
Component: windowsAssignee: Sven Gothel <sgothel>
Status: RESOLVED FIXED    
Severity: minor CC: narf_bro
Priority: P5    
Version: 1   
Hardware: pc_x86_64   
OS: windows   
Type: --- SCM Refs:
0be87f241c0f0b2f5881d9a602ce12378b8e453d
Workaround: ---
Bug Depends on: 879    
Bug Blocks:    

Description Jesse 2013-11-05 16:41:32 CET 
Currently I'm unable to rely on the focus listener behaviour. Build: Nov01_2013 2.1.2

If I add a Java FocusListener to the NewtCanvasAWT, focus events behave like this:

- focusLost issued correctly when I lose focus
- focusGained is sometimes followed by focusLost even though the window retains focus if I click in the window. (steps: click back and forth from in window and out, about 25% of the time you'll get a focusLost after gained even though it still has focus)
- focusGained is always followed by focusLost even though the window retains focus if I click on the program in the taskbar. (steps: click away from window, select the window from the taskbar)

If I add a Newt WindowListener to the glWindow held by my NewtCanvasAWT, focus events behave like this:
- focusLost issued correctly when I lose focus
- focusGained issued correctly when I gain focus
- focusLost and focusGained issued very quickly back to back with every single click inside the window after focus has been gained.

The WindowListener is far more consistent but the back-to-back focusLost/focusGained events make it difficult to trust a focusLost event.

Expected: It should not re-issue a lost/gained event on every click inside the window. It should only issue an event when focus is actually gained or lost.

Workaround: I use the WindowListener and consider focus "actually" lost if it is not immediately followed by a focusGained.
Comment 1 Sven Gothel 2013-11-14 21:42:28 CET 
AWT [ NewtCanvasAWT.GLWindow ]:

(Not a bug)

The problem about temp. loosing and re-gaining focus is well known
and more related how we implement focus traversal between GLWindow and the underlying AWT 'tree'.

If the GLWindow requires the focus, we need to give it's AWT component the focus
first - then steal it back and transfer it to GLWindow.
This allows focus traversal back / forth within the AWT tree, 
while allowing GLWindow using the focus.

We maybe able to review the current code .. hence I keep this bug open as an earmark.

Due to a focus traversal change we lately made, 
maybe it's possible to avoid the focus ping-pong between AWT/GLWindow.
But this is a tedious validation process.
Comment 2 Jesse 2013-11-14 21:51:37 CET 
Is it simpler to just not issue the focusGained/Lost events in the case you described, rather than change the underlying functionality? If I have the GLWindow already focused I would not expect that it would issue a lose/regain focus event on every click, since it conceptually never lost focus.

As it stands now, if I want to do something simple like shut off sounds in the game when the user clicks away from the window, I cannot reliably use focusGained/Lost, because they issue even if I have clicked within the window.
Comment 3 Sven Gothel 2013-11-17 04:57:28 CET 
Fixed w/ fix of Bug 879