Details
-
Bug
-
Resolution: Cannot Reproduce
-
Not Evaluated
-
5.0.1
-
None
-
OSX Mountain Lion
-
-
8238acccf028e4beaa8dadf19b768920cc1d45bb
Description
On OSX, if you have two partially overlapping windows and move your mouse from the inactive one to the active one, the inactive one continues to receive move events.
The attached application demonstrates this. It opens two windows which are partially overlapping, and prints the events each of them receive.
To reproduce:
1) start your mouse over the left one (which is behind the right one)
2) move your mouse over the right one without leaving the rect of the left one (so the mouse goes directly from being over the left window to being over the right)
3) observe that the left (inactive) one continues to receive mouse events, while the active one does not:
// Window 0 is the left (inactive) one. Here I'm moving the mouse event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 11 event QWidget(0x106934830, name = "Window 0") 5 // Here Window 1 (active/topmost) gets the Enter event, and so should now be receiving Move events event QWidget(0x10453a940, name = "Window 1") 10 // Instead, window 0 continues to receive the Move events event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5 event QWidget(0x106934830, name = "Window 0") 5
This seems to be a consequence of using NSTrackingActiveInActiveApp in qnsview.mm, and passing Move events through without checking to see if the window is the topmost window under the mouse. Both NSViews receive the move events, but only the first one to receive it gets the event all the way through to the QWidget.