<AWT Dev> [8] Review request for 8027628: JWindow jumps to (0, 0) after mouse clicked

[Anthony Petrov]

Hi Oleg,

The XBaseWindow class is not the best place for this code. Firstly, the 
XDecoratedPeer.handleConfigureNotifyEvent() never calls its super.* 
counterpart. Secondly, all top-level windows use XWindowPeer as an 
instance for its peer, so this code actually belongs there (e.g. you can 
update x, y after calling the super method.)

However, I'd still suggest to analyze why this isn't a problem for 
decorated peers in the first place, and consider using the same 
mechanism for undecorated peers as well (perhaps we could share some 
code in this area and move some common parts to XWindowPeer, for example).

Also, the handleConfigureNotifyEvent code is *VERY* fragile. After we 
settle on some more-or-less final version of the fix, you should run 
most of Window/Frame/Dialog/Layout regression tests (both automatic and 
manual, from open and closed repos) to make sure we don't regress. This 
needs to be tested on OEL 6 (or which is the minimum supported version 
for JDK 8?) and Solaris boxes as well, because the code in this event 
handler covers many rare cases only reproducible with specific window 
managers found on old systems.

--
best regards,
Anthony

On 11/08/2013 12:00 PM, Oleg Pekhovskiy wrote:
> Hi all,
>
> please review the fix
> http://cr.openjdk.java.net/~bagiras/8027628.1/
> for
> https://bugs.openjdk.java.net/browse/JDK-8027628
>
> The issue affects all top-level windows. XConfigureEvent.x and
> XConfigureEvent.y fields
> from ConfigureNotify event could have wrong values, e.g. when the window
> is resized by not moved.
> That's why manual calculation was added.
>
> This is explained in ICCCM, in "4.1.5. Configuring the Window" section:
>
> "Advice to Implementors
>
> Clients cannot distinguish between the case where a top-level window is
> resized and moved from the case where the window is resized but not
> moved, since a real ConfigureNotify event will be received in both
> cases. Clients that are concerned with keeping track of the absolute
> position of a top-level window should keep a piece of state indicating
> whether they are certain of its position. Upon receipt of a real
> ConfigureNotify event on the top-level window, the client should note
> that the position is unknown. Upon receipt of a synthetic
> ConfigureNotify event, the client should note the position as known,
> using the position in this event. If the client receives a KeyPress ,
> KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify ,
> or LeaveNotify event on the window (or on any descendant), the client
> can deduce the top-level window's position from the difference between
> the (event-x, event-y) and (root-x, root-y) coordinates in these events.
> Only when the position is unknown does the client need to use the
> TranslateCoordinates request to find the position of a top-level window."
>
> Thanks,
> Oleg