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
