Hi Dmitry,
On 09/25/2017 01:09 PM, Dmitry Markov wrote:
Hi Semyon,
This issue and the problem addressed by 8139218 and 8159432 are slightly
different. This one is still reproducible on latest 9 and 10 builds using the
test case attached to the bug or regression test provided with the fix.
I couldn't get the test failed on 9 and 10. But I only tried it on
Ubuntu. Is the issue a platform dependent?
The problem takes place when we restore focus to a component and its parent
window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore
focus synchronously). If the parent window loses the focus during this
invocation, focus request will fail and focus target will be shifted to next in
focus traversal cycle. This case is not covered by the changes introduced by
8139218 and 8159432.
I see. What may prevent to set the input focus synchronously? Since the
native window already has the focus this should be very deterministic.
--Semyon
Thanks,
Dmitry
On 25 Sep 2017, at 15:58, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote:
Hi Dmitry,
This issue was already fixed in 9. See 8139218 & 8159432.
--Semyon
On 09/23/2017 08:25 AM, Dmitry Markov wrote:
Hello,
Could you review a fix for jdk10, please?
bug: https://bugs.openjdk.java.net/browse/JDK-8155197
webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
Problem description:
Currently we restore focus synchronously to a component if the window (which
contains it) owns the focus. However if another window/dialog is displayed at
the same time, the first window loses focus, (i.e. synchronous focus request
failed) and the focus target is shifted to the next component in the focus
traversal cycle.
Fix:
It is necessary to check the result of synchronous focus request for a
component. If the focus request’s failed because the contained window lost
focus, we should restore focus to this component next time when its parent
window obtains focus.
Testing:
I ran corresponding JCK and regression tests and did not observe any new
failures.
Thanks,
Dmitry
