Hi Semyon, > On 26 Sep 2017, at 23:46, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > Hi Dmitry, > > On 9/26/2017 1:56 AM, Dmitry Markov wrote: >> Hi Semyon, >> >> Please find my answer inline. >> >> Thanks, >> Dmitry >>> On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadet...@oracle.com> >>> <mailto:semyon.sadet...@oracle.com> wrote: >>> >>> 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? >> I was able to reproduce the issue on Windows and Mac OSX. I didn’t test >> Linux, but I guess it is present there too. >> Note: if you use VirtualBoxVM, it is necessary to enable 3D acceleration to >> reproduce the issue. > Not sure that 3D may change focus behavior. But I did not uses physical > Ubuntu to test. > I also couldn't get the test failed on Windows platform after 10 attempts: > > ssadetsk@SSADETSK-LAP1 /data/projects/client10/jdk > $ for ((n=0;n<10;n++)); do `/data/jtreg/bin/jtreg > -jdk:../build/windows-x86_64-normal-server-fastdebug/jdk -nr > test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java`; done > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > Test: extra argument ‘passed:’ > I do not have Windows at hand now, but the problem is strictly reproducible for me on OSX. >>>> 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. >> The native window loses focus if another window or dialog is displayed. >> Proposed fix is intended for the following case: >> The native window owns focus and we set the focus to one of its child >> components synchronously, (i.e. invoke doRestoreFocus() -> requestFocus()). >> At the same time another window/dialog pops up, requestFocus() fails because >> the native parent window is not the focus owner any more and we shift focus >> target to next component. > The requestFocus() calls the requestFocusHelper() which has several outcomes > that returns "false". Which one of them should be involved? As far as I remember requestFocusHelper() calls peer.requestFocus() and this invocation failed because native parent window doesn’t own focus. As a result requestFocusHelper() returns false and “Peer request failed” is printed out.
Thanks, Dmitry > > --Semyon >
