On 04/22/13 17:42, Sergey Bylokhov wrote:
On 22.04.2013 17:29, Anthony Petrov wrote:
Regarding the fix itself. Calling SunToolkit.getNativeContainer()
results in a call to Component.getNativeContainer(). And it is in this
method where the real bug resides. This method traverses the "parents"
tree w/o actually checking if it goes beyond its top-level window.
Yes, and it is used in this context on windows.
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.
I suggest to fix the root cause of the bug in shared code rather than
tweak a platform implementation. Note that there's a method
Component.getContainer() designed specifically for cases where we want
to avoid traversing owner windows.
But it does not take into account weight of the component. Peers version
relies on heavyweight components only.
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?
--
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
