Bug 1223 - GLWindow loses focus after maximizing (OSX)
Summary: GLWindow loses focus after maximizing (OSX)
Status: RESOLVED WORKSFORME
Alias: None
Product: Newt
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2.3.2
Hardware: All all
: --- minor
Assignee: Sven Gothel
URL:
: 977 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-09-19 00:39 CEST by ac
Modified: 2015-10-13 20:36 CEST (History)
1 user (show)

See Also:
Type: DEFECT
SCM Refs:
03909cb24ab6f5648e7fc6e696024ca460b37070 fbf14fd09bcc8eccaf819e953a82b3619e6de796 8790d4a25410c51e747f4cdd7954ef8abbb7a68b
Workaround: ---


Attachments
log file (40.08 KB, text/plain)
2015-10-13 20:34 CEST, ac
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ac 2015-09-19 00:39:04 CEST
NEWT's mouse listener does not generate new events after maximizing the GLWindow, unless one clicks on the title bar of the window, or switches back and forth with other open applications. 

I tested it on Mac OS X 10.9.5, with the test build of JOGL from September 1. Windows and Linux don't exhibit this problem. 

Here you have my test code: 

https://github.com/codeanticode/jogl2-tests/blob/master/src/test/windows/WindowFocusNEWT.java
Comment 1 Sven Gothel 2015-09-22 01:12:45 CEST
Is this still true w/ latest builds?

See commit 03909cb24ab6f5648e7fc6e696024ca460b37070

<http://jogamp.org/git/?p=jogl.git;a=commit;h=03909cb24ab6f5648e7fc6e696024ca460b37070>

NEWT Window Maximize: re-gain focus after maximize action (maybe lost on platforms, i.e. OSX)
Comment 2 ac 2015-09-22 01:27:42 CEST
I just tested with the september 20 release and the issue is still happening.
Comment 3 Sven Gothel 2015-09-26 03:44:21 CEST
Thx to this report and hence manual testing on OSX
I found another open issue, see Bug 1188 comment 11,
i.e. commit fa3c55b8176b284752ed14a5a24f7fee36e588a3.
Comment 4 Sven Gothel 2015-09-26 03:51:19 CEST
commit fbf14fd09bcc8eccaf819e953a82b3619e6de796:

Analysis
    
TestGearsES2NEWT reacts on key-press 'n', opening another GLWindow.
    
Procedure:
[1] Pressing 'n' (2nd GLWindow) and manual re-focus 1st GLWindow
    
[2] Pressing 'm' (single, alt, shift) on 1st GLWindow maximizes it
    Focus is still on 1st GLWindow!
    
[3] Pressing ctrl-m un-maximizes ..
    Focus is still on 1st GLWindow!
Comment 5 Sven Gothel 2015-09-26 03:52:41 CEST
Please re-open this bug if you can produce a detailed 
reproduction test case - and if the issue still exists.

Thank you.
Comment 6 ac 2015-10-04 08:23:19 CEST
It is still happening, and in fact it is a duplicate of 

https://jogamp.org/bugzilla/show_bug.cgi?id=977

where the bug is better explained. I'm not sure how to reproduce programmatically, but basically what happens is that the application does not receive any mouse events after maximizing the GLWindow, unless clicking on the title bar or switching applications back and forth.
Comment 7 Sven Gothel 2015-10-05 07:10:38 CEST
(In reply to ac from comment #6)
> It is still happening, and in fact it is a duplicate of 
> 
> https://jogamp.org/bugzilla/show_bug.cgi?id=977
> 
> where the bug is better explained. I'm not sure how to reproduce
> programmatically, but basically what happens is that the application does
> not receive any mouse events after maximizing the GLWindow, unless clicking
> on the title bar or switching applications back and forth.

you mean 'maximized by pressing the green "plus" button on the window decoration',
and not via our new programmatic way?
Comment 8 Sven Gothel 2015-10-05 09:01:26 CEST
TestGearsES2NEWT shows me that mouse events are received
after manually maximizing the NEWT window or doing it programmatic:

java com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT -manual -time 1000000 -traceMouse

OSX 10.10.5
java 1.8.0_60

+++

Further more, if I run your test WindowFocusNEWT:
  java -XstartOnFirstThread com.jogamp.newt.util.MainThread WindowFocusNEWT
or
  java WindowFocusNEWT

... everything works as well.

+++

Maybe it is the OSX or java version ?
Comment 9 Sven Gothel 2015-10-05 09:02:12 CEST
*** Bug 977 has been marked as a duplicate of this bug. ***
Comment 10 Sven Gothel 2015-10-05 09:05:27 CEST
(In reply to Sven Gothel from comment #8)
> java com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT
> -manual -time 1000000 -traceMouse

that should read (ofc):

java -XstartOnFirstThread com.jogamp.newt.util.MainThread \
com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT \
  -manual -time 1000000 -traceMouse
Comment 11 Sven Gothel 2015-10-05 09:07:07 CEST
commit 8790d4a25410c51e747f4cdd7954ef8abbb7a68b:
  Add '-traceMouse' commandline argument to check whether mouse events are still received after manual maximize
Comment 12 ac 2015-10-05 16:57:54 CEST
Ok, I will run the test command you just mentioned, and will report back.
Comment 13 ac 2015-10-05 21:12:34 CEST
apologies for my ignorance, but where are you supposed to run the command:

java -XstartOnFirstThread com.jogamp.newt.util.MainThread \
com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT \
  -manual -time 1000000 -traceMouse

from? I tried a couple of places, but was not able to make it work. I get "Error: Could not find or load main class com.jogamp.newt.util.MainThread"
Comment 14 Sven Gothel 2015-10-06 00:40:44 CEST
(In reply to ac from comment #13)
> apologies for my ignorance, but where are you supposed to run the command:
> 
> java -XstartOnFirstThread com.jogamp.newt.util.MainThread \
> com.jogamp.opengl.test.junit.jogl.demos.es2.newt.TestGearsES2NEWT \
>   -manual -time 1000000 -traceMouse
> 
> from? I tried a couple of places, but was not able to make it work. I get
> "Error: Could not find or load main class com.jogamp.newt.util.MainThread"

cd jogl/make
- edit scripts/tests.sh: enable that one test line only - 
bash scripts/tests-osx-x64.sh -manual -time 10000000 -traceMouse
Comment 15 ac 2015-10-06 03:06:43 CEST
Thanks for the instructions. 

Now I realize that I was behind a "non-bug", which was simply a result of how windowing toolkits work... 

I was able to reproduce the "bug" by doing the following:

* Move mouse over the green maximize button
* Press on said button, which maximizes the window
* Because the window was not initially placed at the upper left corner of the screen, after maximization the cursor falls inside the drawing area (without moving it)
* Now, moving the mouse inside the drawing area does not generate any EVENT_MOUSE_MOVED
* If I move the mouse outside of the drawing area, and then back in, EVENT_MOUSE_MOVED events are triggered again.

What happens is that the mouse leaves the window by being positioned over the maximize button, and even though after maximization the pointer falls inside the window, it is not registered as entering the window (since it didn't move). Please correct me if I'm wrong (AWT behaves in the same way, by the way)
Comment 16 Sven Gothel 2015-10-06 03:38:13 CEST
(In reply to ac from comment #15)
> Thanks for the instructions. 
> 
> Now I realize that I was behind a "non-bug", which was simply a result of
> how windowing toolkits work... 
> 
> I was able to reproduce the "bug" by doing the following:
> 
> * Move mouse over the green maximize button
> * Press on said button, which maximizes the window
> * Because the window was not initially placed at the upper left corner of
> the screen, after maximization the cursor falls inside the drawing area
> (without moving it)
> * Now, moving the mouse inside the drawing area does not generate any
> EVENT_MOUSE_MOVED
> * If I move the mouse outside of the drawing area, and then back in,
> EVENT_MOUSE_MOVED events are triggered again.
> 
> What happens is that the mouse leaves the window by being positioned over
> the maximize button, and even though after maximization the pointer falls
> inside the window, it is not registered as entering the window (since it
> didn't move). Please correct me if I'm wrong (AWT behaves in the same way,
> by the way)

That could be all right - good explanation.

Dun thing though is, that - again - here it works,
i.e. the mouse gets inside again (detected) and hence
mouse move events are arriving.

Maybe some odd setting differences of our machines?

I.e. I would expect OSX cocoa to send us the focus state
and hence we can receive the events. This seems to be not true.

BTW, we propagate EVENT_MOUSE_ENTERED and EVENT_MOUSE_EXITED
from the native NewtView.
Wonder what really happens, but I cannot reproduce it.

If you could produce a full debug log, '-Djogl.newt.debug',
maybe even compile the native NEWT stuff w/ VERBOSE_ON
../src/newt/native/NewtMacWindow.h#41: #define VERBOSE_ON 1

and make pipe a minimal test w/ our test case >& a.log,
7z it .. etc - I may get an idea :)
Comment 17 Sven Gothel 2015-10-06 03:41:13 CEST
(In reply to Sven Gothel from comment #16)
> BTW, we propagate EVENT_MOUSE_ENTERED and EVENT_MOUSE_EXITED
> from the native NewtView.
> Wonder what really happens, but I cannot reproduce it.

Further more .. if those enter/exit events are _not_ received,
we synthesize them ourselves.
Comment 18 ac 2015-10-13 20:34:34 CEST
Created attachment 762 [details]
log file
Comment 19 ac 2015-10-13 20:36:26 CEST
Hi Sven,

I run the TestGearsES2NEWT test case using the latest changes from the gluegen and jogl repos. I rebuilt jogl using #define VERBOSE_ON 1 in NewtMacWindow.h, and run the following command:

bash scripts/tests-osx-x64.sh -manual -time 10000000 -traceMouse -Djogl.newt.debug >& a.log

The EVENT_MOUSE_MOVED events are no longer generated after maximizing the GLWindow. I have attached the log file. Let me know if you want me to run other tests on my system.

Andres