<AWT Dev> [8] Review request for 7026679 There is no MouseClicked event after MousePressed & MouseReleased events

[Anthony Petrov]

Hi Alexander,

I'm concerned with this fix. A toolkit usually captures the mouse 
pointer upon a PRESS event, and releases the capture upon a RELEASE 
event. This ensures that it will in fact receive the corresponding 
RELEASE event. It's important that the RELEASE event gets delivered to 
the same window which received the PRESS event initially. IMO, this 
applies to the CLICK events as well. Otherwise a lot of user code may 
get broken due to unbalanced PRESS/RELEASE events. At least this is what 
we do on Windows in both AWT and FX.

Is there a way to do the same on X11? How do we handle a similar 
situation on OSX?

Whatever approach we decide to take, we should run regression tests for 
Mouse and Events areas, DnD tests perhaps, and also for complex 
components such as ComboBoxes (the more the better, both open and 
closed) to ensure we don't introduce a regression.

--
best regards,
Anthony

On 05/30/2013 01:13 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>    bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7026679
>    webrev: http://cr.openjdk.java.net/~alexsch/7026679/webrev.00
>
> This is the direct fix proposed in the issue.
>
> XWindow keep track of button press-releases within the
> mouseButtonClickAllowed bitmask. The problem is it's per-window field.
> With JComboBox some events comes to XContentWindow some into XFramePeer
> due to the specifics of this component - it opens extra toplevel window
> for the dropdown.
> E.g. MOUSE_PRESS comes to XContentWindow and update its
> mouseButtonClickAllowed version with proper value (say 512 - left
> button). But MOUSE_RELEASE comes to XFramePeer which
> mouseButtonClickAllowed value is 0.
> Later on it checks for its state in XWindow.handleMousePressRelease:
>              if ((type == XConstants.ButtonRelease) &&
>                  ((mouseButtonClickAllowed &
> XConstants.buttonsMask[lbutton]) != 0) ) // No up-button in the drag-state
>              {
>                     <construct and post a CLICK_EVENT>
>
> But unfortunately it's value is 0 instead of 512 so we just skip
> MOUSE_CLICKED creation.
> It seems that making this variable static is reasonable approach to keep
> the state of the mouse.
>
>
> Thanks,
> Alexandr.
>