<AWT Dev>  Review request for 7026679 There is no MouseClicked event after MousePressed & MouseReleased events
anthony.petrov at oracle.com
Fri May 31 04:41:34 PDT 2013
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.
On 05/30/2013 01:13 PM, Alexander Scherbatiy wrote:
> 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.
More information about the awt-dev