This code path exists in order to ensure that a heavyweight component
(e.g. a Button) has a valid native container to be inserted to.
Obviously, the container must always reside in the same top-level window
where the component itself resides. This code should never traverse
containers in other top-level windows (even though it does now, which is
the real bug here).
Note that top-level windows ensure their owner has a valid peer in the
Window.addNotify() method already, so they don't need to rely on the
logic present in WComponentPeer().
I still think that the real bug here is an absent override method
Window.getNativeContainer() that should return "this". Do you agree?
--
best regards,
Anthony
On 04/23/2013 01:37 AM, Sergey Bylokhov wrote:
Hi, Anthony.
WComponentPeer.java:762 -> WComponentPeer.java:764 ->
WWindowPeer.java:create(WComponentPeer parent).
On 23.04.2013 0:01, Anthony Petrov wrote:
I don't believe getNativeContainer() should ever traverse a hierarchy
outside of the toplevel window for component of which it's been called
(or for the window itself if it's called on a Window instance). If
some code expects otherwise, then there is a bug in that code which
needs fixing.
Could you please point me to exact locations where the code does that?
--
best regards,
Anthony
On 04/22/2013 06:24 PM, Sergey Bylokhov wrote:
On 22.04.2013 17:55, Anthony Petrov wrote:
Ah, I see the Component.getNativeContainer() checks whether the peer
is lightweight or not. I believe it needs to be overridden in the
Window class to return "this", though. Otherwise there's still a bug
in this method.
But window's implementation mix owner/container during initialization of
WWindowPeer. There is only one field "parent", which assigned from the
SunToolkit.getNativeContainer().
I assume that, when this method was added the window's parent/container
and the window's owner were one concept.
I don't quite understand this point. Please elaborate.
What I see is that we call SunToolkit.getNativeContainer() which isn't
overridden in UNIXToolkit nor XToolkit, and thus results in a call to
Toolkit.getNativeContainer(). The latter calls
Component.getNativeContainer(). Which, w/o an override suggested
above, produces an incorrect result and is the root cause of our bug,
isn't it?
The question is, what the result is correct. Currently, some code
expects the owner will be refunded.
--
best regards,
Anthony
--
best regards,
Anthony
On 04/22/13 16:06, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk 8.
SetEnable method check status of all parent containers and
windows(via
getParent() in SunToolkit.getNativeContainer()). But only
containers in
the same window should be checked.
The new method was added to return the peer of the nearest
heavyweight
container.
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7166296
Webrev can be found at:
http://cr.openjdk.java.net/~serb/7166296/webrev.00
