<AWT Dev> [8] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

[Alexander Scherbatiy]

   Could someone review the fix?

    Thanks,
    Alexandr.

On 8/10/2012 6:00 PM, Alexander Scherbatiy wrote:
>
> Could you review the updated fix:
> http://cr.openjdk.java.net/~alexsch/7171045/webrev.02/
>
> The comments are below:
>
> On 8/7/2012 6:47 PM, Mike Swingler wrote:
>> I noticed that, NSWindow's windowNumber is NSInteger, which is 32 
>> bits wide on 32-bit and 64 bits wide on 64-bit. Chopping that to a 
>> simple 32 bit int is probably not what you intended to do.
>      fixed.
>> Also, have you considered simply calling -[NSWindow 
>> setAcceptsMouseMovedEvents:YES] in -[AWTView initWithRect:], and then 
>> removing the calls that flip it on and off in -[AWTView 
>> mouseEntered:] and -[AWTView mouseExited"]? This would also require a 
>> change in 
>> Java_sun_lwawt_macosx_CPlatformWindow_nativeSetNSWindowBounds(), 
>> which has a comment that states it only turns on mouse moved events 
>> if the window is currently under the mouse.
>      I tried it. The result that I got is that a dragging mouse from 
> one window to another does not generate mouse enter/exit events on the 
> second window in case when tracking rect is used and the 
> acceptsMouseMovedEvents flag is always set to YES.
>
>> I would think that AppKit should be more than happy to send you 
>> mouse-over/enter/exited events as long as you say you want them. Was 
>> this approach tried and didn't work for some reason?
>>> Hi, Alexander.
>>> Probably all this stuff can be simplified? Can you try to change 
>>> TrackingRect to TrackingArea with appropriate flags like 
>>> NSTrackingEnabledDuringMouseDrag etc.
>     I changed the TrackingRect to TrackingArea in the updated fix. It 
> now generates the mouse enter/exit events on the second window during 
> drag.
>     So it is not necessary to generates such events from our side.
>
>    The getTopmostWindowUnderMouse is necessary to handle mouse 
> enter/exit events for component in case when a mouse is dragged from 
> one window to another.
>    Where the second window contains it's own components and the only 
> way to know about tracking over them  are  drag events which receives 
> the first window.
>
>    I think that the LWWindowPeer class code can be simplified if we 
> assume that window mouse enter/exit events are always come to the 
> current window.
>    So the component mouse enter/exit events can be tracked only in the 
> current or topmost window.
>    For this case I separated the global lastCommonMouseEventPeer which 
> is necessary for the cursor manager and the local lastMouseEventPeer.
>
>     According to the specification: The proper order of mouse-entered 
> and mouse-exited events received by tracking-area objects in an 
> application cannot be guaranteed.
>         
> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/TrackingAreaObjects/TrackingAreaObjects.html
>    So it seems it is not possible to have one lastMouseEventPeer 
> instead of two: lastCommonMouseEventPeer  and lastMouseEventPeer.
>
>    And there are possible situations that we can receive mouse drag 
> event between enter and exit.
>    To handle this the isMouseOver flag is added to the LWWindowPeer 
> class. So the component mouse  enter/exit events are not generated if 
> the window mouse exited event is received and window mouse entered is 
> not.
>
>     There is the test: 
> test/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java
>     It shows that even using the TrackingArea some mouse enter/exit 
> events are not generateed in the following cases:
>      - window is created under the mouse
>      - window changes it's bounds so it becomes under the mouse
>
>    For this cases it still necessary to generate mouse enter/exit 
> events from our side.
>    I just moved the related code to one method 
> synthesizeMouseEnteredExitedEventsForAllWindows.
>
>   Thanks,
>   Alexandr.
>
>>> 07.08.2012 15:17, Alexander Scherbatiy wrote:
>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7171045
>>>> webrev: http://cr.openjdk.java.net/~alexsch/7171045/webrev.01/
>>>>
>>>> This is a regression after the fix 7154048 [macosx] At least drag 
>>>> twice, the toolbar can be dragged to the left side.
>>>>
>>>> In the case where a toolbar is created under a mouse and it is 
>>>> dragged over the initial window the mouse enter/exit events should 
>>>> not be generated for the components which are under the toolbar.
>>>>
>>>> The current fix is supposed to solve this regression and also to 
>>>> fix generation of mouse enter/exit events for all cases where a 
>>>> mouse is dragged from one window to another or a new window is 
>>>> created under a mouse (like it is implemented for toolbar).
>>>>
>>>> Let's see the following cases
>>>> 1) Mouse is dragged from a window and back to the same window.
>>>>   The Mac OS X system generates a mouse exit event only the first 
>>>> time when a mouse is dragged from a window and does not generate 
>>>> mouse enter/exit events next times during one drag trace.
>>>>
>>>> 2) Mouse is dragged from one window to another.
>>>>   The Mac OS X system does not generate mouse enter/exit events for 
>>>> the second window.
>>>>
>>>> 3) Mouse is dragged from one window to another and released.
>>>>   In this case the Mac OS X system generates mouse enter event for 
>>>> the second window only after releasing the mouse.
>>>>
>>>> 4) Clicking on window creates a new window after that the new 
>>>> window is dragged (toolbar dragging).
>>>>
>>>> However the Java system generates mouse enter/exit events each time 
>>>> when a mouse is dragged over any window.
>>>>
>>>> To fix this the following methods are introduced:
>>>> - Get topmost window under mouse
>>>> - Synthesize mouse enter/exit events for all windows
>>>>
>>>>
>>>> The dispatchMouseEvent method from the LWWindowPeer class is 
>>>> handled previous and next components and is able to generate mouse 
>>>> enter/exit events for them.
>>>> However the the AWTView native class contains isMouseOver flag 
>>>> which value becomes inconsistent if we do not updated it. Because 
>>>> of this the fix generates the mouse enter/exit window events on the 
>>>> native side.
>>>>
>>>> Generating mouse enter/exit events always should be in order where 
>>>> mouse exit events are generated before the mouse enter events.
>>>>
>>>> The synthesizeMouseEnteredExitedEventsForAllWindows method tries to 
>>>> generate mouse enter/exit events for all windows during mouse drag 
>>>> or window creation/window bounds changing.
>>>> However only those windows which isMouseOver flag is differ from 
>>>> the isTopMostWindowUnderMouse state are affected.
>>>> This method also tries to generate both mouse enter and exit event 
>>>> for the same window but only one of them can be applicable because 
>>>> the isTopMostWindowUnderMouse state is not changed for these calls.
>>>>
>>>> So the window enter/exit events now are always generated from the 
>>>> native system and component enter/exit events are generated in the 
>>>> LWWindowPeer class.
>>>>
>>>> LWWindowPeer class now uses three links to components: current, 
>>>> last and topmostUnderMouse. All of them are necessary because in 
>>>> case when a mouse is dragged from one window to another the current 
>>>> component receives drag events and last and topmostUnderMouse links 
>>>> handle components mouse exit/enter events on the second window.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>