From linuxhippy at gmail.com  Sun Nov  2 13:52:23 2014
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sun, 2 Nov 2014 14:52:23 +0100
Subject: <AWT Dev> Focus regression in Java8 caused by JDK-7160604
Message-ID: <CAFvQSYQF+JxBX0uSz4YxSrj7xk_NSm9e5a=gC0H4g1rjy3XSpA@mail.gmail.com>

HI,

Starting with the rollout of Java8 via the auto-updater we received
several reports that one of our applications has servere focus issues.
The application registers a KeyListener on a JTextField showing an
auto-completion JPopupMenu every time a character is typed.

Every time a key is typed, the following sequence is run:
- Hide existing JPopupMenu in case there is one
- Create new JPopupMenu and populate with contents (in this case a JTable)
- JPopupMenu.show() below the JTextField which caused the keyTyped-event
- JTextField.requestFocus(), so the user can continue typing.

I've created a self-contained testcase available here:
http://pastebin.com/GEQ1ZW28

This worked fine with Java6 & Java7, however since JDK8-b119 it failes
when the popup is heavyweight - for lightweight popups it still
succeeds (unfourtunately, we need heavyweight ones).

I tried to analyze what happend and registered a global focus listener:

This is the focus-history without the fix for JDK-7160604 - once the
JTextField got it's focus no changes can be observed, despite new
JPopups are being opened:
javax.swing.JTextField[,241,115,197x19,...
javax.swing.JRootPane[,5,27,955x384,.....
javax.swing.JTextField[,241,115,197x19,... (focus stays here, despite
new JPopups are beeing opened and old ones closed)

With the fix, the focus history looks like this:
javax.swing.JTextField[,241,115,197x19,....
javax.swing.JTextField[,241,115,197x19,....
javax.swing.JRootPane[,5,27,938x588,...(focus stays here, no further
keyEvents are received by the JTextField)


Beside some refactorings, the only functional change I can spot is
that the order of the assignment of the "popup"-member and
popup.show() have changed in JPopupMenu.showPopup():


        Popup newPopup = getUI().getPopup(this, desiredLocationX,
                                          desiredLocationY);

        popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
        popup = newPopup;
        newPopup.show();

If I change the order of newPopup.show() and popup=newPopup, the old
behaviour is restored.
At least it looks somehow suspicious the original author introduced a
variable "newPopup" (and the patch still uses it without a good
reason, "popup" could be assigned directly), so at first sight it
looks intentional to assign popup only after show() was called.

During the call to newPopup.show() the method JPopupMenu.isVisible()
is called several times.
Before the fix for JDK-7160604 it would return false, now it returns
true - the focus issue mentioned is triggered by returning "true" at
the following call-stack (full one available at
http://pastebin.com/4qG8h7Td).

        at javax.swing.JPopupMenu.isVisible(JPopupMenu.java:854)
        at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:141)
        at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
        at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
        at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
        at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
        at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocusTraversalPolicy.java:135)
        at javax.swing.SortingFocusTraversalPolicy.getFocusTraversalCycle(SortingFocusTraversalPolicy.java:110)
        at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(SortingFocusTraversalPolicy.java:445)
        at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(LayoutFocusTraversalPolicy.java:166)
        at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(SortingFocusTraversalPolicy.java:535)
        at java.awt.Window.isFocusableWindow(Window.java:2496)

If I introspect the call-stack and return "false" only when
"enumerateCycle" is contained in the stack, everything works again.
So from what I understand the JPopupMenu would never receive focus
before the fix, because during show() it wasn't believed to be
visible.

What I wonder, is the code in the testcase even supposed to work - or
did it just because of an accident?
Also a mystery remains why the JPopupMenu has to contain a JTable to
trigger the issue - with a JLabel everything works like it ever did.

Thank you in advance, Clemens

From pslack at wavedna.com  Tue Nov  4 22:38:36 2014
From: pslack at wavedna.com (Peter J Slack)
Date: Tue, 4 Nov 2014 17:38:36 -0500
Subject: <AWT Dev> Drag and Drop crash jdk 1.8.0_25
In-Reply-To: <CALitSbvVMofYa6r-_RPyPmJ+r5mvYqo_MkR2cpuEKuRnqhbbNg@mail.gmail.com>
References: <CALitSbvVMofYa6r-_RPyPmJ+r5mvYqo_MkR2cpuEKuRnqhbbNg@mail.gmail.com>
Message-ID: <CALitSbu2sWWvcNzoZ1Zv0i4NsX4t97BCtehgsiOLgLk1Exm=yQ@mail.gmail.com>

Looks like this is fixed in 1.9 ..

On Thu, Oct 30, 2014 at 1:06 PM, Peter J Slack <pslack at wavedna.com> wrote:

> Hello to all fine folks,
>
> We are very grateful for open source and communities, I hope the following
> is useful.
>
> We've managed to embed openjdk 1.8.0_25 in the mac version of our product
> and it runs very well. However,  we've encountered a problem with drag and
> drop, putting this out there to see if there is any more insights or any
> fixes available.
>
> we have discovered this portion of code, it looks like one of the
> references is bad when it checks the references
>
>
> http://cr.openjdk.java.net/~pchelko/8006941/webrev.03/src/macosx/native/sun/awt/CDragSource.m.cdiff.html
>
>
> here is our crash log:
>
>
> Process:         LiquidRhythm [28369]
> Path:
>  /Applications/LiquidRhythm.app/Contents/MacOS/./LiquidRhythm
> Identifier:      com.wavedna.liquidrhythm.app
> Version:         1.4.2 (1.4.2)
> Code Type:       X86-64 (Native)
> Parent Process:  bash [28220]
> Responsible:     Terminal [1082]
> User ID:         501
>
> Date/Time:       2014-10-29 18:43:46.564 -0400
> OS Version:      Mac OS X 10.9.4 (13E28)
> Report Version:  11
> Anonymous UUID:  408B5E9C-DE6F-0A34-177B-0812033DF562
>
> Sleep/Wake UUID: EFB703F2-9CB3-4C94-ADA5-DF0FD214DB9F
>
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Exception Type:  EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000000c
>
> VM Regions Near 0xc:
> -->
>     __TEXT                 0000000100000000-0000000100005000 [   20K]
> r-x/rwx SM=COW  /Applications/LiquidRhythm.app/Contents/MacOS/LiquidRhythm
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib         0x00007fff8d737866 __pthread_kill + 10
> 1   libsystem_pthread.dylib        0x00007fff9418935c pthread_kill + 92
> 2   libsystem_c.dylib              0x00007fff8cc59b1a abort + 125
> 3   libjvm.dylib                   0x0000000107e7002b os::abort(bool) + 25
> 4   libjvm.dylib                   0x0000000107d1de03
> jniCheck::validate_handle(JavaThread*, _jobject*) + 119
> 5   libjvm.dylib                   0x0000000107d1f02a
> checked_jni_NewGlobalRef + 207
> 6   JavaNativeFoundation           0x000000011b91bd07 JNFNewGlobalRef + 31
> 7   libawt_lwawt.dylib             0x0000000120c5fdb5 -[CDragSource
> init:component:control:transferable:triggerEvent:dragPosX:dragPosY:modifiers:clickCount:timeStamp:dragImage:dragImageOffsetX:dragImageOffsetY:sourceActions:formats:formatMap:]
> + 151
> 8   libawt_lwawt.dylib             0x0000000120c6036e
> __Java_sun_lwawt_macosx_CDragSourceContextPeer_createNativeDragSource_block_invoke_1
> + 427
> 9   JavaNativeFoundation           0x000000011b92053d +[JNFRunLoop
> _performDirectBlock:] + 12
> 10  com.apple.Foundation           0x00007fff8bd4813e
> __NSThreadPerformPerform + 229
> 11  com.apple.CoreFoundation       0x00007fff920035b1
> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
> 12  com.apple.CoreFoundation       0x00007fff91ff4c62
> __CFRunLoopDoSources0 + 242
> 13  com.apple.CoreFoundation       0x00007fff91ff43ef __CFRunLoopRun + 831
> 14  com.apple.CoreFoundation       0x00007fff91ff3e75
> CFRunLoopRunSpecific + 309
> 15  com.apple.HIToolbox            0x00007fff9269ba0d
> RunCurrentEventLoopInMode + 226
> 16  com.apple.HIToolbox            0x00007fff9269b685
> ReceiveNextEventCommon + 173
> 17  com.apple.HIToolbox            0x00007fff9269b5bc
> _BlockUntilNextEventMatchingListInModeWithFilter + 65
> 18  com.apple.AppKit               0x00007fff8ef3424e _DPSNextEvent + 1434
> 19  com.apple.AppKit               0x00007fff8ef3389b -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> 20  libswt-pi-cocoa-4430.jnilib    0x000000011f627d6a
> Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSendSuper__Lorg_eclipse_swt_internal_cocoa_objc_1super_2JJJJZ
> + 122
> 21  ???                            0x000000010bdfcbde 0 + 4494183390
> 22  ???                            0x000000010bdfedc4 0 + 4494192068
> 23  libjvm.dylib                   0x0000000107ce7516
> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
> Thread*) + 1710
> 24  libjvm.dylib                   0x0000000107d1c58b
> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 447
> 25  libjvm.dylib                   0x0000000107d14bfd
> jni_CallStaticLongMethodV + 268
> 26  libjvm.dylib                   0x0000000107d28476
> checked_jni_CallStaticLongMethodV + 277
> 27  libswt-cocoa-4430.jnilib       0x000000011f2c8f92 callback + 1344
> 28  libswt-cocoa-4430.jnilib       0x000000011f2ae525 fn3_6 + 90
> 29  libswt-pi-cocoa-4430.jnilib    0x000000011f623bc2
> Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJJJJZ + 79
> 30  ???                            0x000000010bdfc84d 0 + 4494182477
> 31  ???                            0x000000010be8f424 0 + 4494783524
> 32  ???                            0x000000010ab187e4 0 + 4474374116
> 33  ???                            0x000000010ab187e4 0 + 4474374116
> 34  ???                            0x000000010ab18710 0 + 4474373904
> 35  ???                            0x000000010ab18710 0 + 4474373904
> 36  ???                            0x000000010ab18710 0 + 4474373904
> 37  ???                            0x000000010ab114e7 0 + 4474344679
> 38  libjvm.dylib                   0x0000000107ce7516
> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
> Thread*) + 1710
> 39  libjvm.dylib                   0x0000000107eb60be
> Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool,
> objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 3576
> 40  libjvm.dylib                   0x0000000107eb65d8
> Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 364
> 41  libjvm.dylib                   0x0000000107d35b98 JVM_InvokeMethod +
> 358
> 42  ???                            0x000000010ab26694 0 + 4474431124
> 43  ???                            0x000000010ab18710 0 + 4474373904
> 44  ???                            0x000000010ab18710 0 + 4474373904
> 45  ???                            0x000000010ab187e4 0 + 4474374116
> 46  ???                            0x000000010ab18710 0 + 4474373904
> 47  ???                            0x000000010ab1898d 0 + 4474374541
> 48  ???                            0x000000010ab1898d 0 + 4474374541
> 49  ???                            0x000000010ab114e7 0 + 4474344679
> 50  libjvm.dylib                   0x0000000107ce7516
> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
> Thread*) + 1710
> 51  libjvm.dylib                   0x0000000107d1c93b
> jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 773
> 52  libjvm.dylib                   0x0000000107d0e53b jni_CallIntMethodV
> + 248
> 53  libjvm.dylib                   0x0000000107d21416
> checked_jni_CallIntMethod + 379
> 54  eclipse_1605.so                0x000000010029a43a startJavaJNI + 2090
> 55  eclipse_1605.so                0x0000000100296d12 _run + 6114
> 56  eclipse_1605.so                0x00000001002951fa run + 410
> 57  com.wavedna.liquidrhythm.app   0x00000001000023ef original_main + 1946
> 58  com.wavedna.liquidrhythm.app   0x00000001000029dc main + 1237
> 59  com.wavedna.liquidrhythm.app   0x0000000100001af8 start + 52
>
>
> PJ Slack, P.Eng
>
> --
> Senior Software Developer / IT Administrator
> Work:  (416) 466-9283
> Fax  :  (866)  855-2605
>
> <http://www.wavedna.com/>
>    <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
> <http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
> <https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
> <http://www.linkedin.com/company/wavedna>
>



-- 
Senior Software Developer / IT Administrator
Work:  (416) 466-9283
Fax  :  (866)  855-2605

<http://www.wavedna.com/>
   <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
<http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
<https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
<http://www.linkedin.com/company/wavedna>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141104/658c2b4a/attachment-0001.html>

From pooja.chopra at oracle.com  Wed Nov  5 14:28:58 2014
From: pooja.chopra at oracle.com (pooja chopra)
Date: Wed, 05 Nov 2014 19:58:58 +0530
Subject: <AWT Dev> [9] Review Request: JDK-8058805 Fix type in
 client-related package for tray.policy file missing in
 java/awt/TrayIcon/SecurityCheck/NoPermissionTest
In-Reply-To: <543E6AF5.2000602@oracle.com>
References: <541C14A9.6000304@oracle.com> <542AB418.3070107@oracle.com>
	<543E23FE.1030002@oracle.com> <543E5EE0.6060408@oracle.com>
	<543E6AF5.2000602@oracle.com>
Message-ID: <545A342A.3060208@oracle.com>

Hi All,

A gentle reminder . Please review below fix .

webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/
JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805

Regards,
Pooja
On 10/15/2014 6:09 PM, Yuri Nesterenko wrote:
> Hi Pooja,
>
> OK with me.
>
> -yan
>
> On 10/15/2014 03:47 PM, pooja chopra wrote:
>> Hi Yuri ,
>>
>> I have added an empty grant block as this test requires No 
>> Permission  :-
>>
>> //No Permission Test
>> grant{
>> };
>>
>> webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/
>> JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805
>>
>> Please review further .
>> Regards,
>> Pooja
>> On 10/15/2014 1:06 PM, Yuri Nesterenko wrote:
>>> Hi Pooja,
>>>
>>> perhaps it would be better to have _something_
>>> in this policy file, for instance a comment.
>>>
>>> Thanks,
>>> -yan
>>>
>>> On 09/30/2014 05:46 PM, pooja chopra wrote:
>>>> Hello All,
>>>> Gentle reminder . Please review below fix .
>>>>
>>>> Regards,
>>>> Pooja
>>>> On 9/19/2014 5:04 PM, pooja chopra wrote:
>>>>> |Hello, |
>>>>> ||
>>>>> |Please review a fix ||for| |the issue: |
>>>>> ||
>>>>> |8058805| |[TEST_BUG]
>>>>> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| 
>>>>>
>>>>>
>>>>> fails with Cant find Policy file error.|||
>>>>> ||
>>>>> |Test bug fix.
>>>>> |
>>>>> ||
>>>>> |https://bugs.openjdk.java.net/browse/JDK-8058805|||
>>>>> ||
>>>>> |
>>>>> The webrev is:
>>>>> |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ |
>>>>>
>>>>> |||
>>>>> ||
>>>>> |Thanks |
>>>>> |Pooja|
>>>>
>>>
>>
>


From anton.tarasov at oracle.com  Wed Nov  5 13:32:38 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Wed, 05 Nov 2014 17:32:38 +0400
Subject: <AWT Dev> Focus regression in Java8 caused by JDK-7160604
In-Reply-To: <CAFvQSYQF+JxBX0uSz4YxSrj7xk_NSm9e5a=gC0H4g1rjy3XSpA@mail.gmail.com>
References: <CAFvQSYQF+JxBX0uSz4YxSrj7xk_NSm9e5a=gC0H4g1rjy3XSpA@mail.gmail.com>
Message-ID: <545A26F6.3030704@oracle.com>

Hi Clemens,

I can't say exactly how the fix for JDK-7160604 could change the behavior like you described (this 
requires some more time to investigate).
However, an obvious question comes to my mind - why don't you make your popup non-focusable? I 
suppose you manage navigation through the content of your "auto-completion list" somehow by 
intercepting the up/down keys on the textfiled, right? In that case, you don't need your popup be a 
focusable component. Does it work for you?

Also, just a side note. As a straightforward workaround to the focus issue, you could invoke your 
requestFocus later, either via calling invokeLater() or by invoking it at the time the popup is 
shown (I'm not sure you can listen for the componentShown(), but at least, you can listen for 
focusGained() on its content). This would make the things happen in a fixed order: popup_show then 
request_focus. (Currently, it seems the order is broken somehow.) But still, making the popup simply 
non-focusable looks better.

Regards,
Anton.

On 02.11.2014 17:52, Clemens Eisserer wrote:
> HI,
>
> Starting with the rollout of Java8 via the auto-updater we received
> several reports that one of our applications has servere focus issues.
> The application registers a KeyListener on a JTextField showing an
> auto-completion JPopupMenu every time a character is typed.
>
> Every time a key is typed, the following sequence is run:
> - Hide existing JPopupMenu in case there is one
> - Create new JPopupMenu and populate with contents (in this case a JTable)
> - JPopupMenu.show() below the JTextField which caused the keyTyped-event
> - JTextField.requestFocus(), so the user can continue typing.
>
> I've created a self-contained testcase available here:
> http://pastebin.com/GEQ1ZW28
>
> This worked fine with Java6 & Java7, however since JDK8-b119 it failes
> when the popup is heavyweight - for lightweight popups it still
> succeeds (unfourtunately, we need heavyweight ones).
>
> I tried to analyze what happend and registered a global focus listener:
>
> This is the focus-history without the fix for JDK-7160604 - once the
> JTextField got it's focus no changes can be observed, despite new
> JPopups are being opened:
> javax.swing.JTextField[,241,115,197x19,...
> javax.swing.JRootPane[,5,27,955x384,.....
> javax.swing.JTextField[,241,115,197x19,... (focus stays here, despite
> new JPopups are beeing opened and old ones closed)
>
> With the fix, the focus history looks like this:
> javax.swing.JTextField[,241,115,197x19,....
> javax.swing.JTextField[,241,115,197x19,....
> javax.swing.JRootPane[,5,27,938x588,...(focus stays here, no further
> keyEvents are received by the JTextField)
>
>
> Beside some refactorings, the only functional change I can spot is
> that the order of the assignment of the "popup"-member and
> popup.show() have changed in JPopupMenu.showPopup():
>
>
>          Popup newPopup = getUI().getPopup(this, desiredLocationX,
>                                            desiredLocationY);
>
>          popupFactory.setPopupType(PopupFactory.LIGHT_WEIGHT_POPUP);
>          popup = newPopup;
>          newPopup.show();
>
> If I change the order of newPopup.show() and popup=newPopup, the old
> behaviour is restored.
> At least it looks somehow suspicious the original author introduced a
> variable "newPopup" (and the patch still uses it without a good
> reason, "popup" could be assigned directly), so at first sight it
> looks intentional to assign popup only after show() was called.
>
> During the call to newPopup.show() the method JPopupMenu.isVisible()
> is called several times.
> Before the fix for JDK-7160604 it would return false, now it returns
> true - the focus issue mentioned is triggered by returning "true" at
> the following call-stack (full one available at
> http://pastebin.com/4qG8h7Td).
>
>          at javax.swing.JPopupMenu.isVisible(JPopupMenu.java:854)
>          at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:141)
>          at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
>          at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
>          at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
>          at javax.swing.SortingFocusTraversalPolicy.enumerateCycle(SortingFocusTraversalPolicy.java:156)
>          at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle(SortingFocusTraversalPolicy.java:135)
>          at javax.swing.SortingFocusTraversalPolicy.getFocusTraversalCycle(SortingFocusTraversalPolicy.java:110)
>          at javax.swing.SortingFocusTraversalPolicy.getFirstComponent(SortingFocusTraversalPolicy.java:445)
>          at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent(LayoutFocusTraversalPolicy.java:166)
>          at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent(SortingFocusTraversalPolicy.java:535)
>          at java.awt.Window.isFocusableWindow(Window.java:2496)
>
> If I introspect the call-stack and return "false" only when
> "enumerateCycle" is contained in the stack, everything works again.
> So from what I understand the JPopupMenu would never receive focus
> before the fix, because during show() it wasn't believed to be
> visible.
>
> What I wonder, is the code in the testcase even supposed to work - or
> did it just because of an accident?
> Also a mystery remains why the JPopupMenu has to contain a JTable to
> trigger the issue - with a JLabel everything works like it ever did.
>
> Thank you in advance, Clemens


From linuxhippy at gmail.com  Wed Nov  5 18:46:31 2014
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 5 Nov 2014 19:46:31 +0100
Subject: <AWT Dev> Focus regression in Java8 caused by JDK-7160604
In-Reply-To: <545A26F6.3030704@oracle.com>
References: <CAFvQSYQF+JxBX0uSz4YxSrj7xk_NSm9e5a=gC0H4g1rjy3XSpA@mail.gmail.com>
	<545A26F6.3030704@oracle.com>
Message-ID: <CAFvQSYTpkyB4qLdkUPc10sxf6mDbWEKzCedjn02SmHCnw8AsJg@mail.gmail.com>

Hi Anton,

> I can't say exactly how the fix for JDK-7160604 could change the behavior
> like you described (this requires some more time to investigate).
> However, an obvious question comes to my mind - why don't you make your
> popup non-focusable?
> But still, making the popup simply non-focusable looks
> better.

Exactly, this is the solution I chose to fix the issue.
However, as JDK-7160604 broke an application which was working fine
since Java-1.3 days I thought reporting it wouldn't harm.
Should I open a bug-report? If so, in the jira bug-tracker or using
the "official" form?

> Also, just a side note. As a straightforward workaround to the focus issue,
> you could invoke your requestFocus later, either via calling invokeLater()

Funny thing is, I've tried this approach first - and it leads to a
very strange phenomenon and breaks in a very odd way.
When I call requestFocus inside a runnable executed via
SwingUtilities.invokeLater(), the JTextField doesn't receive any
keyboard events, even after the JPopup is closed and I click on the
JTextField again. This also seems to be a side-effect of JDK-7160604,
before it this also just works.

Best regards, Clemens

From anton.tarasov at oracle.com  Thu Nov  6 09:13:37 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 06 Nov 2014 13:13:37 +0400
Subject: <AWT Dev> Focus regression in Java8 caused by JDK-7160604
In-Reply-To: <CAFvQSYTpkyB4qLdkUPc10sxf6mDbWEKzCedjn02SmHCnw8AsJg@mail.gmail.com>
References: <CAFvQSYQF+JxBX0uSz4YxSrj7xk_NSm9e5a=gC0H4g1rjy3XSpA@mail.gmail.com>	<545A26F6.3030704@oracle.com>
	<CAFvQSYTpkyB4qLdkUPc10sxf6mDbWEKzCedjn02SmHCnw8AsJg@mail.gmail.com>
Message-ID: <545B3BC1.2060900@oracle.com>

Hi Clemens,

Sure, please file the issue. If you have an account in JIRA, please file it right there. Otherwise, 
tell us please the ID of the incident you will file and we'll accept it.

Thanks!

Anton.

On 05.11.2014 22:46, Clemens Eisserer wrote:
> Hi Anton,
>
>> I can't say exactly how the fix for JDK-7160604 could change the behavior
>> like you described (this requires some more time to investigate).
>> However, an obvious question comes to my mind - why don't you make your
>> popup non-focusable?
>> But still, making the popup simply non-focusable looks
>> better.
> Exactly, this is the solution I chose to fix the issue.
> However, as JDK-7160604 broke an application which was working fine
> since Java-1.3 days I thought reporting it wouldn't harm.
> Should I open a bug-report? If so, in the jira bug-tracker or using
> the "official" form?
>
>> Also, just a side note. As a straightforward workaround to the focus issue,
>> you could invoke your requestFocus later, either via calling invokeLater()
> Funny thing is, I've tried this approach first - and it leads to a
> very strange phenomenon and breaks in a very odd way.
> When I call requestFocus inside a runnable executed via
> SwingUtilities.invokeLater(), the JTextField doesn't receive any
> keyboard events, even after the JPopup is closed and I click on the
> JTextField again. This also seems to be a side-effect of JDK-7160604,
> before it this also just works.
>
> Best regards, Clemens


From alexandr.scherbatiy at oracle.com  Thu Nov  6 12:26:50 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 06 Nov 2014 16:26:50 +0400
Subject: <AWT Dev> [9] Review Request: JDK-8058805 Fix type in
 client-related package for tray.policy file missing in
 java/awt/TrayIcon/SecurityCheck/NoPermissionTest
In-Reply-To: <545A342A.3060208@oracle.com>
References: <541C14A9.6000304@oracle.com> <542AB418.3070107@oracle.com>
	<543E23FE.1030002@oracle.com> <543E5EE0.6060408@oracle.com>
	<543E6AF5.2000602@oracle.com> <545A342A.3060208@oracle.com>
Message-ID: <545B690A.4030102@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 11/5/2014 6:28 PM, pooja chopra wrote:
> Hi All,
>
> A gentle reminder . Please review below fix .
>
> webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/
> JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805
>
> Regards,
> Pooja
> On 10/15/2014 6:09 PM, Yuri Nesterenko wrote:
>> Hi Pooja,
>>
>> OK with me.
>>
>> -yan
>>
>> On 10/15/2014 03:47 PM, pooja chopra wrote:
>>> Hi Yuri ,
>>>
>>> I have added an empty grant block as this test requires No 
>>> Permission  :-
>>>
>>> //No Permission Test
>>> grant{
>>> };
>>>
>>> webrev Link : - http://cr.openjdk.java.net/~kshefov/8058805/webrev.01/
>>> JBS: - https://bugs.openjdk.java.net/browse/JDK-8058805
>>>
>>> Please review further .
>>> Regards,
>>> Pooja
>>> On 10/15/2014 1:06 PM, Yuri Nesterenko wrote:
>>>> Hi Pooja,
>>>>
>>>> perhaps it would be better to have _something_
>>>> in this policy file, for instance a comment.
>>>>
>>>> Thanks,
>>>> -yan
>>>>
>>>> On 09/30/2014 05:46 PM, pooja chopra wrote:
>>>>> Hello All,
>>>>> Gentle reminder . Please review below fix .
>>>>>
>>>>> Regards,
>>>>> Pooja
>>>>> On 9/19/2014 5:04 PM, pooja chopra wrote:
>>>>>> |Hello, |
>>>>>> ||
>>>>>> |Please review a fix ||for| |the issue: |
>>>>>> ||
>>>>>> |8058805| |[TEST_BUG]
>>>>>> java/awt/TrayIcon/SecurityCheck/NoPermissionTest||/|||NoPermissionTest.java| 
>>>>>>
>>>>>>
>>>>>> fails with Cant find Policy file error.|||
>>>>>> ||
>>>>>> |Test bug fix.
>>>>>> |
>>>>>> ||
>>>>>> |https://bugs.openjdk.java.net/browse/JDK-8058805|||
>>>>>> ||
>>>>>> |
>>>>>> The webrev is:
>>>>>> |http://cr.openjdk.java.net/~kshefov/8058805/webrev.00/ |
>>>>>>
>>>>>> |||
>>>>>> ||
>>>>>> |Thanks |
>>>>>> |Pooja|
>>>>>
>>>>
>>>
>>
>


From anton.tarasov at oracle.com  Thu Nov  6 13:10:40 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 06 Nov 2014 17:10:40 +0400
Subject: <AWT Dev> [7u] Review request for 8061954: 7u76 - deployment
 warning dialogs do not work on Linux
In-Reply-To: <545366F5.8040002@oracle.com>
References: <545366F5.8040002@oracle.com>
Message-ID: <545B7350.1070006@oracle.com>

Hi Anton,

The fix looks fine for me (taking into account you've launched all the focus reg tests).

However, I have a concern about the issue itself. As far as I know, any deploy warning dialog should 
belong to the deploy Thread Group which does have its own AppContext. The only TG which has null 
AppContext is the system thread group. However, no UI code should be invoked in that TG. Am I right? 
If so, then it seems to me we should identify and fix the root cause of the issue.

What do you think?

Regards,
Anton.

On 31.10.2014 14:39, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for P1 bug.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8061954
> Webrev: http://cr.openjdk.java.net/~alitvinov/8061954/webrev.00
>
> The bug consists in the fact that "java.lang.NullPointerException" is thrown from 
> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" and a button does not get the focus 
> on mouse click, when the button is located on a warning dialog which is shown during Java applet 
> loading on Linux OS.
>
> The solution consists of 2 following parts:
> 1. Reversal of the fix for JDK-6993873 in order to resolve this bug (file "XContentWindow.java").
> 2. Backport of only Linux/Solaris parts of the fix for JDK-6981400 from JDK 8 in order to again 
> resolve JDK-6993873 (the failing test 
> "jdk/test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java").
>
> The next jtreg regression tests were run on JDK 7 without/with the fix and no new test failures 
> were defined:
>     jdk/test/java/awt/Focus
>     jdk/test/java/awt/KeyboardFocusmanager
>     jdk/test/javax/swing/KeyboardManager
>     Analogous tests from closed parts of JDK 7.
>
> Thank you,
> Anton


From anton.litvinov at oracle.com  Thu Nov  6 15:38:12 2014
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Thu, 06 Nov 2014 18:38:12 +0300
Subject: <AWT Dev> [7u] Review request for 8061954: 7u76 - deployment
 warning dialogs do not work on Linux
In-Reply-To: <545B7350.1070006@oracle.com>
References: <545366F5.8040002@oracle.com> <545B7350.1070006@oracle.com>
Message-ID: <545B95E4.1030902@oracle.com>

Hello Anton,

Thank you for the review of the fix. Yes, automatic jtreg regression 
tests from the directories listed in my review request were launched.

Debugging of the issue showed that, as you said, AppContext equals null, 
because the thread, on which 
"java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" method is 
called, belongs to "system" thread group. The thread is "AWT-XAWT". And 
since the root frame of NPE's call stack is "at 
sun.awt.X11.XToolkit.run", it looks like there is nothing wrong in the 
fact that the current thread is "AWT-XAWT". Yes, I agree that it is 
necessary to fix a root cause of the issue, but in current NPE deploy 
thread is not involved.

Thank you,
Anton

On 11/6/2014 4:10 PM, Anton V. Tarasov wrote:
> Hi Anton,
>
> The fix looks fine for me (taking into account you've launched all the 
> focus reg tests).
>
> However, I have a concern about the issue itself. As far as I know, 
> any deploy warning dialog should belong to the deploy Thread Group 
> which does have its own AppContext. The only TG which has null 
> AppContext is the system thread group. However, no UI code should be 
> invoked in that TG. Am I right? If so, then it seems to me we should 
> identify and fix the root cause of the issue.
>
> What do you think?
>
> Regards,
> Anton.
>
> On 31.10.2014 14:39, Anton Litvinov wrote:
>> Hello,
>>
>> Could you please review the following fix for P1 bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061954
>> Webrev: http://cr.openjdk.java.net/~alitvinov/8061954/webrev.00
>>
>> The bug consists in the fact that "java.lang.NullPointerException" is 
>> thrown from 
>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" and a 
>> button does not get the focus on mouse click, when the button is 
>> located on a warning dialog which is shown during Java applet loading 
>> on Linux OS.
>>
>> The solution consists of 2 following parts:
>> 1. Reversal of the fix for JDK-6993873 in order to resolve this bug 
>> (file "XContentWindow.java").
>> 2. Backport of only Linux/Solaris parts of the fix for JDK-6981400 
>> from JDK 8 in order to again resolve JDK-6993873 (the failing test 
>> "jdk/test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java").
>>
>> The next jtreg regression tests were run on JDK 7 without/with the 
>> fix and no new test failures were defined:
>>     jdk/test/java/awt/Focus
>>     jdk/test/java/awt/KeyboardFocusmanager
>>     jdk/test/javax/swing/KeyboardManager
>>     Analogous tests from closed parts of JDK 7.
>>
>> Thank you,
>> Anton
>


From alan at cbfiddle.com  Thu Nov  6 18:01:28 2014
From: alan at cbfiddle.com (Alan Snyder)
Date: Thu, 6 Nov 2014 10:01:28 -0800
Subject: <AWT Dev> HiDPI and FontRenderContext
Message-ID: <276E92E0-BA0C-4E47-ADF1-FD16505F82E0@cbfiddle.com>

I?m curious about the behavior of FontRenderContext.getTransform() in HiDPI mode. The documentation says it maps points to pixels, but it doesn?t say what kind of pixels. I would have assumed virtual pixels (AWT pixels) for consistency with the rest of the API, but in fact I get a 2x mapping on a simulated Retina display. Is this a good thing or a bug?

Some API to reveal the HiDPI scaling factor is needed, but I would think it should be a new API to avoid confusing old programs that don?t know about HiDPI mode.

The larger issue - is there a plan to document HiDPI mode? I have not found any mention of it in the docs other than a cryptic message that Retina displays now work properly. All I have learned comes from mailing lists, blogs, and reading source code. Some programs need to be updated to work well in HiDPI mode, and documentation is needed on how to do that.

  Alan


From hs at tagtraum.com  Thu Nov  6 19:12:08 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 6 Nov 2014 20:12:08 +0100
Subject: <AWT Dev> HiDPI and FontRenderContext
In-Reply-To: <276E92E0-BA0C-4E47-ADF1-FD16505F82E0@cbfiddle.com>
References: <276E92E0-BA0C-4E47-ADF1-FD16505F82E0@cbfiddle.com>
Message-ID: <476EFB37-023C-4F53-9D1A-C9A3961A6DAF@tagtraum.com>

On Nov 6, 2014, at 19:01, Alan Snyder <alan at cbfiddle.com> wrote:

> I?m curious about the behavior of FontRenderContext.getTransform() in HiDPI mode. The documentation says it maps points to pixels, but it doesn?t say what kind of pixels. I would have assumed virtual pixels (AWT pixels) for consistency with the rest of the API, but in fact I get a 2x mapping on a simulated Retina display. Is this a good thing or a bug?
> 
> Some API to reveal the HiDPI scaling factor is needed, but I would think it should be a new API to avoid confusing old programs that don?t know about HiDPI mode.
> 
> The larger issue - is there a plan to document HiDPI mode? I have not found any mention of it in the docs other than a cryptic message that Retina displays now work properly. All I have learned comes from mailing lists, blogs, and reading source code. Some programs need to be updated to work well in HiDPI mode, and documentation is needed on how to do that.

This is true. Improvement of the situation would be much appreciated.
Also, bringing OS X, Windows and others onto the same page would be a good idea. Last time I checked, HiDPI behavior of Swing was very different between OS X and Windows (e.g. https://bugs.openjdk.java.net/browse/JDK-8029087).

-hendrik


From ebakke at mit.edu  Thu Nov  6 19:21:56 2014
From: ebakke at mit.edu (Eirik Bakke)
Date: Thu, 6 Nov 2014 19:21:56 +0000
Subject: <AWT Dev> HiDPI and FontRenderContext
In-Reply-To: <276E92E0-BA0C-4E47-ADF1-FD16505F82E0@cbfiddle.com>
References: <276E92E0-BA0C-4E47-ADF1-FD16505F82E0@cbfiddle.com>
Message-ID: <D08131B3.3683F%ebakke@mit.edu>

The current behavior, of assuming the transform represents a
transformation to physical pixels, makes some sense to me, since the
transform is used to decide how fonts are rendered on a low level (e.g.
whether to use hints or not). When implementing java.awt.print.Printable,
the transform in the FontRenderContext will reflect the DPI used by the
printer--could be 150 DPI, 300 DPI, etc. When printing to a PDF printer on
windows, it corresponds to a DPI of 1200. So the FontRenderContext
transform already has a well-defined meaning of mapping to _device_ pixels.

My own Swing app actually uses the value of the transform to detect HiDPI
mode in a platform-independent way. The nice thing about it is that it
works even if one window is on a HiDPI-enabled screen and another is
not--if you drag the window from one monitor to another, the Swing
component gets properly redrawn in the right mode. And it doesn't actually
assume anything about "Retina" displays--any scaling works.

But maybe the current behavior is inconsistent and needs to be split out
into a different API. Such an API probably needs to be available per
DisplayMode [1] rather than per GraphicsDevice [2] or Toolkit [3], and it
needs to allow scalings other than 2x.

Either way, the Javadoc for FontRenderContext should be updated to state
clearly which design choice is made wrt. high-resolution displays.

-- Eirik
[1] http://docs.oracle.com/javase/7/docs/api/java/awt/DisplayMode.html
[2] http://docs.oracle.com/javase/7/docs/api/java/awt/GraphicsDevice.html
[3] http://docs.oracle.com/javase/7/docs/api/java/awt/Toolkit.html




On 11/6/14, 1:01 PM, "Alan Snyder" <alan at cbfiddle.com> wrote:

>I?m curious about the behavior of FontRenderContext.getTransform() in
>HiDPI mode. The documentation says it maps points to pixels, but it
>doesn?t say what kind of pixels. I would have assumed virtual pixels (AWT
>pixels) for consistency with the rest of the API, but in fact I get a 2x
>mapping on a simulated Retina display. Is this a good thing or a bug?
>
>Some API to reveal the HiDPI scaling factor is needed, but I would think
>it should be a new API to avoid confusing old programs that don?t know
>about HiDPI mode.
>
>The larger issue - is there a plan to document HiDPI mode? I have not
>found any mention of it in the docs other than a cryptic message that
>Retina displays now work properly. All I have learned comes from mailing
>lists, blogs, and reading source code. Some programs need to be updated
>to work well in HiDPI mode, and documentation is needed on how to do that.
>
>  Alan
>


From anton.tarasov at oracle.com  Fri Nov  7 07:48:37 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 07 Nov 2014 11:48:37 +0400
Subject: <AWT Dev> [7u] Review request for 8061954: 7u76 - deployment
 warning dialogs do not work on Linux
In-Reply-To: <545B95E4.1030902@oracle.com>
References: <545366F5.8040002@oracle.com> <545B7350.1070006@oracle.com>
	<545B95E4.1030902@oracle.com>
Message-ID: <545C7955.4000103@oracle.com>

Hi Anton,

On 06.11.2014 19:38, Anton Litvinov wrote:
> Hello Anton,
>
> Thank you for the review of the fix. Yes, automatic jtreg regression tests from the directories 
> listed in my review request were launched.
>
> Debugging of the issue showed that, as you said, AppContext equals null, because the thread, on 
> which "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" method is called, belongs to 
> "system" thread group. The thread is "AWT-XAWT". And since the root frame of NPE's call stack is 
> "at sun.awt.X11.XToolkit.run", it looks like there is nothing wrong in the fact that the current 
> thread is "AWT-XAWT". Yes, I agree that it is necessary to fix a root cause of the issue, but in 
> current NPE deploy thread is not involved.

Thanks for the clarification. Now it's clear that the original problem was that we called public 
client method (Window.isActive) on the toolkit thread (that is actually obvious from the stack...). 
And that's prohibited. The NPE thus was a side effect.

So, the fix is correct as soon as it eliminates the client calls from the toolkit thread.

Regards,
Anton.

>
> Thank you,
> Anton
>
> On 11/6/2014 4:10 PM, Anton V. Tarasov wrote:
>> Hi Anton,
>>
>> The fix looks fine for me (taking into account you've launched all the focus reg tests).
>>
>> However, I have a concern about the issue itself. As far as I know, any deploy warning dialog 
>> should belong to the deploy Thread Group which does have its own AppContext. The only TG which 
>> has null AppContext is the system thread group. However, no UI code should be invoked in that TG. 
>> Am I right? If so, then it seems to me we should identify and fix the root cause of the issue.
>>
>> What do you think?
>>
>> Regards,
>> Anton.
>>
>> On 31.10.2014 14:39, Anton Litvinov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix for P1 bug.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061954
>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8061954/webrev.00
>>>
>>> The bug consists in the fact that "java.lang.NullPointerException" is thrown from 
>>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" and a button does not get the 
>>> focus on mouse click, when the button is located on a warning dialog which is shown during Java 
>>> applet loading on Linux OS.
>>>
>>> The solution consists of 2 following parts:
>>> 1. Reversal of the fix for JDK-6993873 in order to resolve this bug (file "XContentWindow.java").
>>> 2. Backport of only Linux/Solaris parts of the fix for JDK-6981400 from JDK 8 in order to again 
>>> resolve JDK-6993873 (the failing test 
>>> "jdk/test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java").
>>>
>>> The next jtreg regression tests were run on JDK 7 without/with the fix and no new test failures 
>>> were defined:
>>>     jdk/test/java/awt/Focus
>>>     jdk/test/java/awt/KeyboardFocusmanager
>>>     jdk/test/javax/swing/KeyboardManager
>>>     Analogous tests from closed parts of JDK 7.
>>>
>>> Thank you,
>>> Anton
>>
>


From anton.litvinov at oracle.com  Fri Nov  7 09:45:40 2014
From: anton.litvinov at oracle.com (Anton Litvinov)
Date: Fri, 07 Nov 2014 12:45:40 +0300
Subject: <AWT Dev> [7u] Review request for 8061954: 7u76 - deployment
 warning dialogs do not work on Linux
In-Reply-To: <545C7955.4000103@oracle.com>
References: <545366F5.8040002@oracle.com> <545B7350.1070006@oracle.com>
	<545B95E4.1030902@oracle.com> <545C7955.4000103@oracle.com>
Message-ID: <545C94C4.3020701@oracle.com>

Hello Anton,

Thank you for the response. I would just like to clarify one question. 
Did you approve this version of the fix?

Thank you,
Anton

On 11/7/2014 10:48 AM, Anton V. Tarasov wrote:
> Hi Anton,
>
> On 06.11.2014 19:38, Anton Litvinov wrote:
>> Hello Anton,
>>
>> Thank you for the review of the fix. Yes, automatic jtreg regression 
>> tests from the directories listed in my review request were launched.
>>
>> Debugging of the issue showed that, as you said, AppContext equals 
>> null, because the thread, on which 
>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" method 
>> is called, belongs to "system" thread group. The thread is 
>> "AWT-XAWT". And since the root frame of NPE's call stack is "at 
>> sun.awt.X11.XToolkit.run", it looks like there is nothing wrong in 
>> the fact that the current thread is "AWT-XAWT". Yes, I agree that it 
>> is necessary to fix a root cause of the issue, but in current NPE 
>> deploy thread is not involved.
>
> Thanks for the clarification. Now it's clear that the original problem 
> was that we called public client method (Window.isActive) on the 
> toolkit thread (that is actually obvious from the stack...). And 
> that's prohibited. The NPE thus was a side effect.
>
> So, the fix is correct as soon as it eliminates the client calls from 
> the toolkit thread.
>
> Regards,
> Anton.
>
>>
>> Thank you,
>> Anton
>>
>> On 11/6/2014 4:10 PM, Anton V. Tarasov wrote:
>>> Hi Anton,
>>>
>>> The fix looks fine for me (taking into account you've launched all 
>>> the focus reg tests).
>>>
>>> However, I have a concern about the issue itself. As far as I know, 
>>> any deploy warning dialog should belong to the deploy Thread Group 
>>> which does have its own AppContext. The only TG which has null 
>>> AppContext is the system thread group. However, no UI code should be 
>>> invoked in that TG. Am I right? If so, then it seems to me we should 
>>> identify and fix the root cause of the issue.
>>>
>>> What do you think?
>>>
>>> Regards,
>>> Anton.
>>>
>>> On 31.10.2014 14:39, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for P1 bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061954
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8061954/webrev.00
>>>>
>>>> The bug consists in the fact that "java.lang.NullPointerException" 
>>>> is thrown from 
>>>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" and 
>>>> a button does not get the focus on mouse click, when the button is 
>>>> located on a warning dialog which is shown during Java applet 
>>>> loading on Linux OS.
>>>>
>>>> The solution consists of 2 following parts:
>>>> 1. Reversal of the fix for JDK-6993873 in order to resolve this bug 
>>>> (file "XContentWindow.java").
>>>> 2. Backport of only Linux/Solaris parts of the fix for JDK-6981400 
>>>> from JDK 8 in order to again resolve JDK-6993873 (the failing test 
>>>> "jdk/test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java").
>>>>
>>>> The next jtreg regression tests were run on JDK 7 without/with the 
>>>> fix and no new test failures were defined:
>>>>     jdk/test/java/awt/Focus
>>>>     jdk/test/java/awt/KeyboardFocusmanager
>>>>     jdk/test/javax/swing/KeyboardManager
>>>>     Analogous tests from closed parts of JDK 7.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>


From anton.tarasov at oracle.com  Fri Nov  7 09:20:12 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 07 Nov 2014 13:20:12 +0400
Subject: <AWT Dev> [7u] Review request for 8061954: 7u76 - deployment
 warning dialogs do not work on Linux
In-Reply-To: <545C94C4.3020701@oracle.com>
References: <545366F5.8040002@oracle.com> <545B7350.1070006@oracle.com>
	<545B95E4.1030902@oracle.com> <545C7955.4000103@oracle.com>
	<545C94C4.3020701@oracle.com>
Message-ID: <545C8ECC.8000008@oracle.com>

On 07.11.2014 13:45, Anton Litvinov wrote:
> Hello Anton,
>
> Thank you for the response. I would just like to clarify one question. Did you approve this 
> version of the fix?

Yes, sure, I approved.

Thanks,
Anton.

>
> Thank you,
> Anton
>
> On 11/7/2014 10:48 AM, Anton V. Tarasov wrote:
>> Hi Anton,
>>
>> On 06.11.2014 19:38, Anton Litvinov wrote:
>>> Hello Anton,
>>>
>>> Thank you for the review of the fix. Yes, automatic jtreg regression tests from the directories 
>>> listed in my review request were launched.
>>>
>>> Debugging of the issue showed that, as you said, AppContext equals null, because the thread, on 
>>> which "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" method is called, belongs 
>>> to "system" thread group. The thread is "AWT-XAWT". And since the root frame of NPE's call stack 
>>> is "at sun.awt.X11.XToolkit.run", it looks like there is nothing wrong in the fact that the 
>>> current thread is "AWT-XAWT". Yes, I agree that it is necessary to fix a root cause of the 
>>> issue, but in current NPE deploy thread is not involved.
>>
>> Thanks for the clarification. Now it's clear that the original problem was that we called public 
>> client method (Window.isActive) on the toolkit thread (that is actually obvious from the 
>> stack...). And that's prohibited. The NPE thus was a side effect.
>>
>> So, the fix is correct as soon as it eliminates the client calls from the toolkit thread.
>>
>> Regards,
>> Anton.
>>
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 11/6/2014 4:10 PM, Anton V. Tarasov wrote:
>>>> Hi Anton,
>>>>
>>>> The fix looks fine for me (taking into account you've launched all the focus reg tests).
>>>>
>>>> However, I have a concern about the issue itself. As far as I know, any deploy warning dialog 
>>>> should belong to the deploy Thread Group which does have its own AppContext. The only TG which 
>>>> has null AppContext is the system thread group. However, no UI code should be invoked in that 
>>>> TG. Am I right? If so, then it seems to me we should identify and fix the root cause of the issue.
>>>>
>>>> What do you think?
>>>>
>>>> Regards,
>>>> Anton.
>>>>
>>>> On 31.10.2014 14:39, Anton Litvinov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review the following fix for P1 bug.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061954
>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8061954/webrev.00
>>>>>
>>>>> The bug consists in the fact that "java.lang.NullPointerException" is thrown from 
>>>>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" and a button does not get the 
>>>>> focus on mouse click, when the button is located on a warning dialog which is shown during 
>>>>> Java applet loading on Linux OS.
>>>>>
>>>>> The solution consists of 2 following parts:
>>>>> 1. Reversal of the fix for JDK-6993873 in order to resolve this bug (file "XContentWindow.java").
>>>>> 2. Backport of only Linux/Solaris parts of the fix for JDK-6981400 from JDK 8 in order to 
>>>>> again resolve JDK-6993873 (the failing test 
>>>>> "jdk/test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java").
>>>>>
>>>>> The next jtreg regression tests were run on JDK 7 without/with the fix and no new test 
>>>>> failures were defined:
>>>>>     jdk/test/java/awt/Focus
>>>>>     jdk/test/java/awt/KeyboardFocusmanager
>>>>>     jdk/test/javax/swing/KeyboardManager
>>>>>     Analogous tests from closed parts of JDK 7.
>>>>>
>>>>> Thank you,
>>>>> Anton
>>>>
>>>
>>
>


From dmitriy.ermashov at oracle.com  Fri Nov  7 09:48:07 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Fri, 07 Nov 2014 13:48:07 +0400
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <5453C3FF.5000003@oracle.com>
References: <5379F43E.8060000@oracle.com>
	<538DAFAD.3000409@oracle.com>	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
	<538ECECD.90208@oracle.com> <5453C3FF.5000003@oracle.com>
Message-ID: <545C9557.60405@oracle.com>

Hi Sergey,

Most of them fails on OS X 10.10 because of 
https://bugs.openjdk.java.net/browse/JDK-8013450.
java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java test is 
marked with corresponding @bug tag.

Others fails because of different shadows rendering on new OS X and 
should be fixed, I believe. As I can see CR 8061236 is already started 
for tracking it.

Thanks,
Dima

On 31.10.2014 21:16, Sergey Bylokhov wrote:
> Hi, Dmitriy.
> These tests were passed on all platforms without problems?
>
> On 04.06.2014 11:46, Dmitriy Ermashov wrote:
>> Hi Petr, all,
>>
>> Please review next revision of webrev:
>> http://cr.openjdk.java.net/~yan/8043131/webrev.02/
>>
>> 1. Set -Xmx20m key for GC tests
>> 2. Added @Override annotation for all corresponding self written 
>> methods.
>>
>> Thanks,
>> Dima
>>
>> On 03.06.2014 16:33, Petr Pchelko wrote:
>>> Hello, Dmitriy.
>>>
>>> I think that it worths adding -Xmx option to the GC tests as default 
>>> max heap size is quite big.
>>> Also could you please add @Override to the initGui method as now 
>>> it's not obvious where is it called from.
>>>
>>> Thank you.
>>> With best regards. Petr.
>>>
>>> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov 
>>> <dmitriy.ermashov at oracle.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Please review the last version of fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>
>>>> The webrev is here:
>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>>>
>>>> Test colocation for remaining ShapedAndTranslucent part of 
>>>> functional tests.
>>>> The fix also includes remarks for the first part of this batch. 
>>>> E.g. retrieved "@author mrkam" tag and full description for each test.
>>>> GC tests also reverted as they are not similar to 
>>>> java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could be 
>>>> useful for finding bugs.
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the changeset for bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>>>
>>>>> This is one more batch of functional AWT 
>>>>> (ShapedAndTranslucentWindows and GC) tests are ought to be moved 
>>>>> to regression tree.
>>>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Nov  7 10:55:18 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 07 Nov 2014 13:55:18 +0300
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <545C9557.60405@oracle.com>
References: <5379F43E.8060000@oracle.com>
	<538DAFAD.3000409@oracle.com>	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
	<538ECECD.90208@oracle.com> <5453C3FF.5000003@oracle.com>
	<545C9557.60405@oracle.com>
Message-ID: <545CA516.8000703@oracle.com>

On 07.11.2014 12:48, Dmitriy Ermashov wrote:
> Hi Sergey,
>
> Most of them fails on OS X 10.10 because of 
> https://bugs.openjdk.java.net/browse/JDK-8013450.
> java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java test is 
> marked with corresponding @bug tag.
>
> Others fails because of different shadows rendering on new OS X and 
> should be fixed, I believe. As I can see CR 8061236 is already started 
> for tracking it.
My guess was that they fail before transition as well, since the tests 
are old and this problem is not a regression? I mean CR for this should 
exist already?
>
> Thanks,
> Dima
>
> On 31.10.2014 21:16, Sergey Bylokhov wrote:
>> Hi, Dmitriy.
>> These tests were passed on all platforms without problems?
>>
>> On 04.06.2014 11:46, Dmitriy Ermashov wrote:
>>> Hi Petr, all,
>>>
>>> Please review next revision of webrev:
>>> http://cr.openjdk.java.net/~yan/8043131/webrev.02/
>>>
>>> 1. Set -Xmx20m key for GC tests
>>> 2. Added @Override annotation for all corresponding self written 
>>> methods.
>>>
>>> Thanks,
>>> Dima
>>>
>>> On 03.06.2014 16:33, Petr Pchelko wrote:
>>>> Hello, Dmitriy.
>>>>
>>>> I think that it worths adding -Xmx option to the GC tests as 
>>>> default max heap size is quite big.
>>>> Also could you please add @Override to the initGui method as now 
>>>> it's not obvious where is it called from.
>>>>
>>>> Thank you.
>>>> With best regards. Petr.
>>>>
>>>> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov 
>>>> <dmitriy.ermashov at oracle.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review the last version of fix for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>
>>>>> The webrev is here:
>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>>>>
>>>>> Test colocation for remaining ShapedAndTranslucent part of 
>>>>> functional tests.
>>>>> The fix also includes remarks for the first part of this batch. 
>>>>> E.g. retrieved "@author mrkam" tag and full description for each 
>>>>> test.
>>>>> GC tests also reverted as they are not similar to 
>>>>> java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could 
>>>>> be useful for finding bugs.
>>>>>
>>>>> Thanks,
>>>>> Dima
>>>>>
>>>>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the changeset for bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>>>>
>>>>>> This is one more batch of functional AWT 
>>>>>> (ShapedAndTranslucentWindows and GC) tests are ought to be moved 
>>>>>> to regression tree.
>>>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Fri Nov  7 13:23:16 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 07 Nov 2014 16:23:16 +0300
Subject: <AWT Dev> [7u] Review request for 8061954: 7u76 - deployment
 warning dialogs do not work on Linux
In-Reply-To: <545C8ECC.8000008@oracle.com>
References: <545366F5.8040002@oracle.com>
	<545B7350.1070006@oracle.com>	<545B95E4.1030902@oracle.com>
	<545C7955.4000103@oracle.com>	<545C94C4.3020701@oracle.com>
	<545C8ECC.8000008@oracle.com>
Message-ID: <545CC7C4.30008@oracle.com>

The fix looks fine to me too.

On 07.11.2014 12:20, Anton V. Tarasov wrote:
> On 07.11.2014 13:45, Anton Litvinov wrote:
>> Hello Anton,
>>
>> Thank you for the response. I would just like to clarify one 
>> question. Did you approve this version of the fix?
>
> Yes, sure, I approved.
>
> Thanks,
> Anton.
>
>>
>> Thank you,
>> Anton
>>
>> On 11/7/2014 10:48 AM, Anton V. Tarasov wrote:
>>> Hi Anton,
>>>
>>> On 06.11.2014 19:38, Anton Litvinov wrote:
>>>> Hello Anton,
>>>>
>>>> Thank you for the review of the fix. Yes, automatic jtreg 
>>>> regression tests from the directories listed in my review request 
>>>> were launched.
>>>>
>>>> Debugging of the issue showed that, as you said, AppContext equals 
>>>> null, because the thread, on which 
>>>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" 
>>>> method is called, belongs to "system" thread group. The thread is 
>>>> "AWT-XAWT". And since the root frame of NPE's call stack is "at 
>>>> sun.awt.X11.XToolkit.run", it looks like there is nothing wrong in 
>>>> the fact that the current thread is "AWT-XAWT". Yes, I agree that 
>>>> it is necessary to fix a root cause of the issue, but in current 
>>>> NPE deploy thread is not involved.
>>>
>>> Thanks for the clarification. Now it's clear that the original 
>>> problem was that we called public client method (Window.isActive) on 
>>> the toolkit thread (that is actually obvious from the stack...). And 
>>> that's prohibited. The NPE thus was a side effect.
>>>
>>> So, the fix is correct as soon as it eliminates the client calls 
>>> from the toolkit thread.
>>>
>>> Regards,
>>> Anton.
>>>
>>>>
>>>> Thank you,
>>>> Anton
>>>>
>>>> On 11/6/2014 4:10 PM, Anton V. Tarasov wrote:
>>>>> Hi Anton,
>>>>>
>>>>> The fix looks fine for me (taking into account you've launched all 
>>>>> the focus reg tests).
>>>>>
>>>>> However, I have a concern about the issue itself. As far as I 
>>>>> know, any deploy warning dialog should belong to the deploy Thread 
>>>>> Group which does have its own AppContext. The only TG which has 
>>>>> null AppContext is the system thread group. However, no UI code 
>>>>> should be invoked in that TG. Am I right? If so, then it seems to 
>>>>> me we should identify and fix the root cause of the issue.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Regards,
>>>>> Anton.
>>>>>
>>>>> On 31.10.2014 14:39, Anton Litvinov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you please review the following fix for P1 bug.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061954
>>>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8061954/webrev.00
>>>>>>
>>>>>> The bug consists in the fact that 
>>>>>> "java.lang.NullPointerException" is thrown from 
>>>>>> "java.awt.KeyboardFocusManager.getCurrentKeyboardFocusManager" 
>>>>>> and a button does not get the focus on mouse click, when the 
>>>>>> button is located on a warning dialog which is shown during Java 
>>>>>> applet loading on Linux OS.
>>>>>>
>>>>>> The solution consists of 2 following parts:
>>>>>> 1. Reversal of the fix for JDK-6993873 in order to resolve this 
>>>>>> bug (file "XContentWindow.java").
>>>>>> 2. Backport of only Linux/Solaris parts of the fix for 
>>>>>> JDK-6981400 from JDK 8 in order to again resolve JDK-6993873 (the 
>>>>>> failing test 
>>>>>> "jdk/test/java/awt/Focus/FocusOwnerFrameOnClick/FocusOwnerFrameOnClick.java").
>>>>>>
>>>>>> The next jtreg regression tests were run on JDK 7 without/with 
>>>>>> the fix and no new test failures were defined:
>>>>>>     jdk/test/java/awt/Focus
>>>>>>     jdk/test/java/awt/KeyboardFocusmanager
>>>>>>     jdk/test/javax/swing/KeyboardManager
>>>>>>     Analogous tests from closed parts of JDK 7.
>>>>>>
>>>>>> Thank you,
>>>>>> Anton
>>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.


From anton.tarasov at oracle.com  Fri Nov  7 14:13:04 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 07 Nov 2014 18:13:04 +0400
Subject: <AWT Dev> [9] Review Request for JDK-8004148: NPE in
	sun.awt.SunToolkit.getWindowDeactivationTime
Message-ID: <545CD370.5070109@oracle.com>

Hello,

Please, review the fix.

https://bugs.openjdk.java.net/browse/JDK-8004148
http://cr.openjdk.java.net/~ant/JDK-8004148/webrev.0

There's no a test case for the original issue. However, there's another test case which reproduces 
NPE with the same stack trace. The problem was fixed in jdk8 in JDK-8001633.

However, I suggest to do a sanity check for null. I check for null AppContext which covers the case 
for null Window as well.

Thanks,
Anton.



From yuri.nesterenko at oracle.com  Fri Nov  7 16:15:49 2014
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Fri, 07 Nov 2014 19:15:49 +0300
Subject: <AWT Dev> <AWT_Dev> [9] Review request for 8063102: Change open awt
 regression tests to avoid sun.awt.SunToolkit.realSync, part 1
Message-ID: <545CF035.40202@oracle.com>

Colleagues,

please review the first batch of 34 regression tests
modified to eliminate internal references (mostly to realSync
but not only). Several closed tests moved in the open.

Change:
http://cr.openjdk.java.net/~yan/8063102/webrev.00

removal diff:
http://cr.openjdk.java.net/~yan/8063102/webrev.diff.00

These are (1) AWT tests; (2) mostly non-interactive: not
creating a Robot for automated interactions.

This batch of tests passed (and some failed as before)
on three platforms.

A change to  WarningWindowDisposeTest.java contains a hack
in passing of arguments to a child JVM process. We'll
fix that by modification of a common helper class in 8064355.

Thanks,
-yan

From petr.pchelko at oracle.com  Mon Nov 10 08:15:37 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 10 Nov 2014 12:15:37 +0400
Subject: <AWT Dev> <AWT_Dev> [9] Review request for 8063102: Change open
	awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1
In-Reply-To: <545CF035.40202@oracle.com>
References: <545CF035.40202@oracle.com>
Message-ID: <B61536E1-5A49-4440-A8A5-F33B9AC8F0FF@oracle.com>

Hello, Yuri.

As long as the classpath hack will be fixed in a separate bug, This fix looks good to me.

With best regards. Petr.

On 07 ????. 2014 ?., at 20:15, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:

> Colleagues,
> 
> please review the first batch of 34 regression tests
> modified to eliminate internal references (mostly to realSync
> but not only). Several closed tests moved in the open.
> 
> Change:
> http://cr.openjdk.java.net/~yan/8063102/webrev.00
> 
> removal diff:
> http://cr.openjdk.java.net/~yan/8063102/webrev.diff.00
> 
> These are (1) AWT tests; (2) mostly non-interactive: not
> creating a Robot for automated interactions.
> 
> This batch of tests passed (and some failed as before)
> on three platforms.
> 
> A change to  WarningWindowDisposeTest.java contains a hack
> in passing of arguments to a child JVM process. We'll
> fix that by modification of a common helper class in 8064355.
> 
> Thanks,
> -yan


From Sergey.Bylokhov at oracle.com  Mon Nov 10 12:12:00 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Nov 2014 15:12:00 +0300
Subject: <AWT Dev> [9] Review Request: 8057788 [macosx] "Pinch to zoom"
 does not work since jdk7
In-Reply-To: <D7041F2F-419C-42EB-9AFD-1E4381F43237@gmail.com>
References: <D7041F2F-419C-42EB-9AFD-1E4381F43237@gmail.com>
Message-ID: <5460AB90.1020805@oracle.com>

Hi, Denis.
The fix looks fine.
Updated webrev for the current jdk layout:
http://cr.openjdk.java.net/~serb/denis/8057788/webrev.00

On 08.09.2014 16:12, Denis Fokin wrote:
> Hi AWT team,
>
> I know a lot of people who miss ?pinch to zoom? feature in Java.
>
> It is implemented for jdk 6 but the functionality does not work in jdk 
> 7 and latter releases.
>
> Gesture related callbacks were mistakenly placed in NSWindowDelegate 
> instead of NSWindow.
>
> Please take a look at this simple move refactoring.
>
> http://web-dot.ru/openjdk/pinch-to-zoom-fix/webrev.00/index.html
>
> Actually, I would eliminate the macros  AWT_NS_WINDOW_IMPLEMENTATION. 
> It is difficult to debug. Looks like it was added to avoid code 
> duplication but if AWTWindow_Normal and AWTWindow_Panel 
> implementations are the same we should reuse the same class.
>
> I have submitted a bug about the issue but it is not visible yet.
>
> Thank you,
>   Denis.


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141110/86b82023/attachment-0001.html>

From dmitriy.ermashov at oracle.com  Mon Nov 10 12:18:16 2014
From: dmitriy.ermashov at oracle.com (Dmitriy Ermashov)
Date: Mon, 10 Nov 2014 15:18:16 +0300
Subject: <AWT Dev> Review request for JDK-8043131: Move
 ShapedAndTranslucentWindows and GC functional AWT tests to regression tree
In-Reply-To: <545CA516.8000703@oracle.com>
References: <5379F43E.8060000@oracle.com>
	<538DAFAD.3000409@oracle.com>	<A5DF7FFD-728E-40C9-AE40-50C48216D456@oracle.com>
	<538ECECD.90208@oracle.com> <5453C3FF.5000003@oracle.com>
	<545C9557.60405@oracle.com> <545CA516.8000703@oracle.com>
Message-ID: <5460AD08.5040706@oracle.com>

These tests have been failing previously:
java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java
java/awt/Window/ShapedAndTranslucentWindows/SetShapeAndClick.java
java/awt/Window/ShapedAndTranslucentWindows/SetShapeDynamicallyAndClick.java
java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucentWindowClick.java
The bug is https://bugs.openjdk.java.net/browse/JDK-8013450

Other failures are new. The tests have been pass in past.

Thanks,
Dima

On 11/07/2014 01:55 PM, Sergey Bylokhov wrote:
> On 07.11.2014 12:48, Dmitriy Ermashov wrote:
>> Hi Sergey,
>>
>> Most of them fails on OS X 10.10 because of 
>> https://bugs.openjdk.java.net/browse/JDK-8013450.
>> java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java test is 
>> marked with corresponding @bug tag.
>>
>> Others fails because of different shadows rendering on new OS X and 
>> should be fixed, I believe. As I can see CR 8061236 is already 
>> started for tracking it.
> My guess was that they fail before transition as well, since the tests 
> are old and this problem is not a regression? I mean CR for this 
> should exist already?
>>
>> Thanks,
>> Dima
>>
>> On 31.10.2014 21:16, Sergey Bylokhov wrote:
>>> Hi, Dmitriy.
>>> These tests were passed on all platforms without problems?
>>>
>>> On 04.06.2014 11:46, Dmitriy Ermashov wrote:
>>>> Hi Petr, all,
>>>>
>>>> Please review next revision of webrev:
>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.02/
>>>>
>>>> 1. Set -Xmx20m key for GC tests
>>>> 2. Added @Override annotation for all corresponding self written 
>>>> methods.
>>>>
>>>> Thanks,
>>>> Dima
>>>>
>>>> On 03.06.2014 16:33, Petr Pchelko wrote:
>>>>> Hello, Dmitriy.
>>>>>
>>>>> I think that it worths adding -Xmx option to the GC tests as 
>>>>> default max heap size is quite big.
>>>>> Also could you please add @Override to the initGui method as now 
>>>>> it's not obvious where is it called from.
>>>>>
>>>>> Thank you.
>>>>> With best regards. Petr.
>>>>>
>>>>> On 03 ???? 2014 ?., at 15:21, Dmitriy Ermashov 
>>>>> <dmitriy.ermashov at oracle.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Please review the last version of fix for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>>
>>>>>> The webrev is here:
>>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.01/
>>>>>>
>>>>>> Test colocation for remaining ShapedAndTranslucent part of 
>>>>>> functional tests.
>>>>>> The fix also includes remarks for the first part of this batch. 
>>>>>> E.g. retrieved "@author mrkam" tag and full description for each 
>>>>>> test.
>>>>>> GC tests also reverted as they are not similar to 
>>>>>> java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java and could 
>>>>>> be useful for finding bugs.
>>>>>>
>>>>>> Thanks,
>>>>>> Dima
>>>>>>
>>>>>> On 05/19/2014 04:08 PM, Dmitriy Ermashov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the changeset for bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043131
>>>>>>>
>>>>>>> The webrev is here:
>>>>>>> http://cr.openjdk.java.net/~yan/8043131/webrev.00/
>>>>>>>
>>>>>>> This is one more batch of functional AWT 
>>>>>>> (ShapedAndTranslucentWindows and GC) tests are ought to be moved 
>>>>>>> to regression tree.
>>>>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Mon Nov 10 12:20:56 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Nov 2014 15:20:56 +0300
Subject: <AWT Dev> [9] Review Request for JDK-8004148: NPE in
	sun.awt.SunToolkit.getWindowDeactivationTime
In-Reply-To: <545CD370.5070109@oracle.com>
References: <545CD370.5070109@oracle.com>
Message-ID: <5460ADA8.7090402@oracle.com>

Hi, Anton.
The fix looks good.

On 07.11.2014 17:13, Anton V. Tarasov wrote:
> Hello,
>
> Please, review the fix.
>
> https://bugs.openjdk.java.net/browse/JDK-8004148
> http://cr.openjdk.java.net/~ant/JDK-8004148/webrev.0
>
> There's no a test case for the original issue. However, there's 
> another test case which reproduces NPE with the same stack trace. The 
> problem was fixed in jdk8 in JDK-8001633.
>
> However, I suggest to do a sanity check for null. I check for null 
> AppContext which covers the case for null Window as well.
>
> Thanks,
> Anton.
>
>


-- 
Best regards, Sergey.


From Sergey.Bylokhov at oracle.com  Mon Nov 10 12:29:53 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Nov 2014 15:29:53 +0300
Subject: <AWT Dev> <AWT_Dev> [9] Review request for 8063102: Change open
 awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1
In-Reply-To: <B61536E1-5A49-4440-A8A5-F33B9AC8F0FF@oracle.com>
References: <545CF035.40202@oracle.com>
	<B61536E1-5A49-4440-A8A5-F33B9AC8F0FF@oracle.com>
Message-ID: <5460AFC1.7090608@oracle.com>

Hi,
The fix looks fine.

On 10.11.2014 11:15, Petr Pchelko wrote:
> Hello, Yuri.
>
> As long as the classpath hack will be fixed in a separate bug, This fix looks good to me.
>
> With best regards. Petr.
>
> On 07 ????. 2014 ?., at 20:15, Yuri Nesterenko <yuri.nesterenko at oracle.com> wrote:
>
>> Colleagues,
>>
>> please review the first batch of 34 regression tests
>> modified to eliminate internal references (mostly to realSync
>> but not only). Several closed tests moved in the open.
>>
>> Change:
>> http://cr.openjdk.java.net/~yan/8063102/webrev.00
>>
>> removal diff:
>> http://cr.openjdk.java.net/~yan/8063102/webrev.diff.00
>>
>> These are (1) AWT tests; (2) mostly non-interactive: not
>> creating a Robot for automated interactions.
>>
>> This batch of tests passed (and some failed as before)
>> on three platforms.
>>
>> A change to  WarningWindowDisposeTest.java contains a hack
>> in passing of arguments to a child JVM process. We'll
>> fix that by modification of a common helper class in 8064355.
>>
>> Thanks,
>> -yan


-- 
Best regards, Sergey.


From denis.fokin at gmail.com  Mon Nov 10 14:04:34 2014
From: denis.fokin at gmail.com (Denis S. Fokin)
Date: Mon, 10 Nov 2014 17:04:34 +0300
Subject: <AWT Dev> [9] Review Request: 8057788 [macosx] "Pinch to zoom"
	does not work since jdk7
In-Reply-To: <5460AB90.1020805@oracle.com>
References: <D7041F2F-419C-42EB-9AFD-1E4381F43237@gmail.com>
	<5460AB90.1020805@oracle.com>
Message-ID: <4E9BD468-BB2B-4299-ABE7-A332C77BB68A@gmail.com>

Hi Sergey,

Thank you for the review. Do I need another reviewer to push?

Thank you,
            Denis.

> On 10 Nov 2014, at 15:12, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Denis.
> The fix looks fine.
> Updated webrev for the current jdk layout:
> http://cr.openjdk.java.net/~serb/denis/8057788/webrev.00 <http://cr.openjdk.java.net/~serb/denis/8057788/webrev.00>
> 
> On 08.09.2014 16:12, Denis Fokin wrote:
>> Hi AWT team,
>> 
>> I know a lot of people who miss ?pinch to zoom? feature in Java.
>> 
>> It is implemented for jdk 6 but the functionality does not work in jdk 7 and latter releases.
>> 
>> Gesture related callbacks were mistakenly placed in NSWindowDelegate instead of NSWindow.
>> 
>> Please take a look at this simple move refactoring.
>> 
>> http://web-dot.ru/openjdk/pinch-to-zoom-fix/webrev.00/index.html <http://web-dot.ru/openjdk/pinch-to-zoom-fix/webrev.00/index.html>
>> 
>> Actually, I would eliminate the macros  AWT_NS_WINDOW_IMPLEMENTATION. It is difficult to debug. Looks like it was added to avoid code duplication but if AWTWindow_Normal and AWTWindow_Panel implementations
>>           are the same we should reuse the same class. 
>> 
>> 
>>         
>> I have submitted a bug
>>           about the issue but it is not visible yet.
>> 
>> 
>>         
>> Thank you,
>>   Denis.
> 
> 
> -- 
> Best regards, Sergey. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141110/4e4834d7/attachment.html>

From petr.pchelko at oracle.com  Mon Nov 10 13:26:19 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 10 Nov 2014 17:26:19 +0400
Subject: <AWT Dev> [9] Review Request for 8055836: move awt tests from
	AWT_Modality to OpenJDK repository - part 9
In-Reply-To: <544E1D51.2010903@oracle.com>
References: <541C2C08.3000105@oracle.com> <54218A7A.2060502@oracle.com>
	<5422C24E.3010908@oracle.com> <544E1D51.2010903@oracle.com>
Message-ID: <5A77A51D-B3D4-4683-A8EE-FB9C15743B02@oracle.com>

Hello, Alexander.

The fix looks fine.

With best regards. Petr.

On 27 ???. 2014 ?., at 14:24, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello,
> 
> Could please anyone review this old request?
> 
> Thanks,
> Alexander
> 
> On 24.09.2014 17:08, alexander stepanov wrote:
>> Hello Sergey,
>> 
>> Thanks, fixed:
>> http://cr.openjdk.java.net/~avstepan/8055836/webrev.01/
>> 
>> Regards,
>> Alexander
>> 
>> On 23.09.2014 18:58, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> PrintDialogsTest: fields are assigned on one thread in the start(), and used on EDT in actionPerformed()..
>>> 
>>> On 19.09.2014 17:13, alexander stepanov wrote:
>>>> Hello,
>>>> 
>>>> Could you please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8055836
>>>> 
>>>> webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8055836/
>>>> 
>>>> This is the result of refactoring for corresponding portion of functional AWT tests.
>>>> 
>>>> The test was checked on Windows 7, Solaris 11, Mac OS X 10.8.5 and Ubuntu 12.04 Linux.
>>>> 
>>>> Thanks,
>>>> Alexander
>>> 
>>> 
>> 
> 


From alexander.v.stepanov at oracle.com  Mon Nov 10 14:24:28 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Mon, 10 Nov 2014 18:24:28 +0400
Subject: <AWT Dev> [9] Review Request for 8055836: move awt tests from
 AWT_Modality to OpenJDK repository - part 9
In-Reply-To: <5A77A51D-B3D4-4683-A8EE-FB9C15743B02@oracle.com>
References: <541C2C08.3000105@oracle.com> <54218A7A.2060502@oracle.com>
	<5422C24E.3010908@oracle.com> <544E1D51.2010903@oracle.com>
	<5A77A51D-B3D4-4683-A8EE-FB9C15743B02@oracle.com>
Message-ID: <5460CA9C.2080101@oracle.com>

Hello Petr,

Thanks!

Regards,
Alexander

On 10.11.2014 17:26, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks fine.
>
> With best regards. Petr.
>
> On 27 ???. 2014 ?., at 14:24, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could please anyone review this old request?
>>
>> Thanks,
>> Alexander
>>
>> On 24.09.2014 17:08, alexander stepanov wrote:
>>> Hello Sergey,
>>>
>>> Thanks, fixed:
>>> http://cr.openjdk.java.net/~avstepan/8055836/webrev.01/
>>>
>>> Regards,
>>> Alexander
>>>
>>> On 23.09.2014 18:58, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> PrintDialogsTest: fields are assigned on one thread in the start(), and used on EDT in actionPerformed()..
>>>>
>>>> On 19.09.2014 17:13, alexander stepanov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review the fix for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8055836
>>>>>
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~avstepan/8055836/
>>>>>
>>>>> This is the result of refactoring for corresponding portion of functional AWT tests.
>>>>>
>>>>> The test was checked on Windows 7, Solaris 11, Mac OS X 10.8.5 and Ubuntu 12.04 Linux.
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>>


From petr.pchelko at oracle.com  Mon Nov 10 13:38:31 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 10 Nov 2014 17:38:31 +0400
Subject: <AWT Dev> [9] Review Request for 8054143: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 6
In-Reply-To: <544E1D7A.3010100@oracle.com>
References: <5409B8B2.1010905@oracle.com> <5411B1CC.5050809@oracle.com>
	<54241371.7050103@oracle.com> <544E1D7A.3010100@oracle.com>
Message-ID: <14675C19-7E6E-4976-9CFD-574CCC28AABE@oracle.com>

Hello, Alexander.

test/java/awt/Modal/ToBack/ToBackDDFTest.java
- setModal should be volatile or final
- rightFrameOverlapsDialog: what's 7? why is it 7? I think it's better to calculate the center of the frame in case the size of window decorations will be changed in some OS version.
line 146: Here you end up calling getLocationOnScreen not on EDT, however everywhere else you try to use EDT. 

test/java/awt/Modal/ToBack/ToBackDDFTest.java
- same with setModal flag
- same with getLocationOnScreen of EDT

With best regards. Petr.

On 27 ???. 2014 ?., at 14:24, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello,
> 
> Could please anyone review this old request?
> 
> Thanks,
> Alexander
> 
> On 25.09.2014 17:06, alexander stepanov wrote:
>> Just a reminder.
>> 
>> Thanks,
>> Alexander
>> 
>> On 11.09.2014 18:29, alexander stepanov wrote:
>>> Sorry, just a reminder.
>>> 
>>> Thanks,
>>> Alexander
>>> 
>>> On 05.09.2014 17:20, alexander stepanov wrote:
>>>> Hello,
>>>> 
>>>> Could you please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8054143
>>>> 
>>>> webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8054143/
>>>> 
>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>> 
>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Windows 7, Mac OS X 10.8.5.
>>>> 
>>>> Thanks,
>>>> Alexander
>>> 
>> 
> 


From hs at tagtraum.com  Mon Nov 10 15:33:52 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 10 Nov 2014 16:33:52 +0100
Subject: <AWT Dev> Will fix be backported?
Message-ID: <4A1E0BA0-5151-4E9E-84A8-27B8926E8953@tagtraum.com>

Hey...

How can I check whether a fix is being backported to JDK8?

E.g. https://bugs.openjdk.java.net/browse/JDK-8043869 only lists emb-9 under backports. Does that mean it's not being backported to 8?

Thank you,

-hendrik

From Sergey.Bylokhov at oracle.com  Mon Nov 10 17:13:43 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 10 Nov 2014 20:13:43 +0300
Subject: <AWT Dev> [9] Review Request: 8057788 [macosx] "Pinch to zoom"
 does not work since jdk7
In-Reply-To: <4E9BD468-BB2B-4299-ABE7-A332C77BB68A@gmail.com>
References: <D7041F2F-419C-42EB-9AFD-1E4381F43237@gmail.com>
	<5460AB90.1020805@oracle.com>
	<4E9BD468-BB2B-4299-ABE7-A332C77BB68A@gmail.com>
Message-ID: <5460F247.4090209@oracle.com>

Yes, please, wait a second review.

On 10.11.2014 17:04, Denis S. Fokin wrote:
> Hi Sergey,
>
> Thank you for the review. Do I need another reviewer to push?
>
> Thank you,
>             Denis.
>
>> On 10 Nov 2014, at 15:12, Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Denis.
>> The fix looks fine.
>> Updated webrev for the current jdk layout:
>> http://cr.openjdk.java.net/~serb/denis/8057788/webrev.00
>>
>> On 08.09.2014 16:12, Denis Fokin wrote:
>>> Hi AWT team,
>>>
>>> I know a lot of people who miss ?pinch to zoom? feature in Java.
>>>
>>> It is implemented for jdk 6 but the functionality does not work in 
>>> jdk 7 and latter releases.
>>>
>>> Gesture related callbacks were mistakenly placed in NSWindowDelegate 
>>> instead of NSWindow.
>>>
>>> Please take a look at this simple move refactoring.
>>>
>>> http://web-dot.ru/openjdk/pinch-to-zoom-fix/webrev.00/index.html
>>>
>>> Actually, I would eliminate the macros 
>>>  AWT_NS_WINDOW_IMPLEMENTATION. It is difficult to debug. Looks like 
>>> it was added to avoid code duplication but if AWTWindow_Normal and 
>>> AWTWindow_Panel implementations are the same we should reuse the 
>>> same class.
>>>
>>> I have submitted a bug about the issue but it is not visible yet.
>>>
>>> Thank you,
>>>   Denis.
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141110/62a2da8a/attachment.html>

From petr.pchelko at oracle.com  Mon Nov 10 17:52:17 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Mon, 10 Nov 2014 20:52:17 +0300
Subject: <AWT Dev> [9] Review Request: 8057788 [macosx] "Pinch to zoom"
	does not work since jdk7
In-Reply-To: <4E9BD468-BB2B-4299-ABE7-A332C77BB68A@gmail.com>
References: <D7041F2F-419C-42EB-9AFD-1E4381F43237@gmail.com>
	<5460AB90.1020805@oracle.com>
	<4E9BD468-BB2B-4299-ABE7-A332C77BB68A@gmail.com>
Message-ID: <A09F8006-C280-4424-90D7-7697350DF651@oracle.com>

Hello, Denis.

Just one question: did you add this only to AWTWindow_Normal and not to AWTWindow_Panel intentionally? Why?
Will the feature still work in undecorated frames?

With best regards. Petr.

> On Nov 10, 2014, at 5:04 PM, Denis S. Fokin <denis.fokin at gmail.com> wrote:
> 
> Hi Sergey,
> 
> Thank you for the review. Do I need another reviewer to push?
> 
> Thank you,
>             Denis.
> 
>> On 10 Nov 2014, at 15:12, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>> 
>> Hi, Denis.
>> The fix looks fine.
>> Updated webrev for the current jdk layout:
>> http://cr.openjdk.java.net/~serb/denis/8057788/webrev.00 <http://cr.openjdk.java.net/~serb/denis/8057788/webrev.00>
>> 
>> On 08.09.2014 16:12, Denis Fokin wrote:
>>> Hi AWT team,
>>> 
>>> I know a lot of people who miss ?pinch to zoom? feature in Java.
>>> 
>>> It is implemented for jdk 6 but the functionality does not work in jdk 7 and latter releases.
>>> 
>>> Gesture related callbacks were mistakenly placed in NSWindowDelegate instead of NSWindow.
>>> 
>>> Please take a look at this simple move refactoring.
>>> 
>>> http://web-dot.ru/openjdk/pinch-to-zoom-fix/webrev.00/index.html <http://web-dot.ru/openjdk/pinch-to-zoom-fix/webrev.00/index.html>
>>> 
>>> Actually, I would eliminate the macros  AWT_NS_WINDOW_IMPLEMENTATION. It is difficult to debug. Looks like it was added to avoid code duplication but if AWTWindow_Normal and AWTWindow_Panel implementations
>>>           are the same we should reuse the same class. 
>>> 
>>> 
>>>         
>>> I have submitted a bug
>>>           about the issue but it is not visible yet.
>>> 
>>> 
>>>         
>>> Thank you,
>>>   Denis.
>> 
>> 
>> -- 
>> Best regards, Sergey. 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141110/6dc5b6bd/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Nov 11 15:27:18 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 11 Nov 2014 18:27:18 +0300
Subject: <AWT Dev> [9] Review request for 8064468 ownedWindowList access
 requires synchronization in Window.setAlwaysOnTop() method
Message-ID: <54622AD6.5070803@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8064468
   webrev: http://cr.openjdk.java.net/~alexsch/8064468/webrev.00

   The fix uses the copy of the owned windows list to avoid the 
synchronization issue.

Thanks,
Alexandr.


From petr.pchelko at oracle.com  Tue Nov 11 16:31:28 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Tue, 11 Nov 2014 19:31:28 +0300
Subject: <AWT Dev> [9] Review request for 8064468 ownedWindowList access
	requires synchronization in Window.setAlwaysOnTop() method
In-Reply-To: <54622AD6.5070803@oracle.com>
References: <54622AD6.5070803@oracle.com>
Message-ID: <2F7766A4-A5E1-49EB-AA53-57C2F3F9EA94@oracle.com>

Hello, Alexander.

The fix looks fine to me.

With best regards. Petr.

> On Nov 11, 2014, at 6:27 PM, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> 
> Hello,
> 
> Could you review the fix:
>  bug: https://bugs.openjdk.java.net/browse/JDK-8064468
>  webrev: http://cr.openjdk.java.net/~alexsch/8064468/webrev.00
> 
>  The fix uses the copy of the owned windows list to avoid the synchronization issue.
> 
> Thanks,
> Alexandr.
> 


From Sergey.Bylokhov at oracle.com  Wed Nov 12 10:55:23 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 12 Nov 2014 13:55:23 +0300
Subject: <AWT Dev> [9] Review request for 8064468 ownedWindowList access
 requires synchronization in Window.setAlwaysOnTop() method
In-Reply-To: <54622AD6.5070803@oracle.com>
References: <54622AD6.5070803@oracle.com>
Message-ID: <54633C9B.2080002@oracle.com>

Hi, Alexander.
Looks fine.

On 11.11.2014 18:27, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8064468
>   webrev: http://cr.openjdk.java.net/~alexsch/8064468/webrev.00
>
>   The fix uses the copy of the owned windows list to avoid the 
> synchronization issue.
>
> Thanks,
> Alexandr.
>


-- 
Best regards, Sergey.


From fishgarage at cbfiddle.com  Thu Nov 13 00:20:16 2014
From: fishgarage at cbfiddle.com (Alan Snyder)
Date: Wed, 12 Nov 2014 16:20:16 -0800
Subject: <AWT Dev> selecting an image resolution variant
Message-ID: <7B6CC96E-EACD-42DF-9923-C6E0B0AC6384@cbfiddle.com>

I?ve run into something that may be an issue.

The code to select a variant image in MultiResolutionToolkitImage looks like this:

    public Image getResolutionVariant(int width, int height) {
        return ((width <= getWidth() && height <= getHeight()))
                ? this : resolutionVariant;
    }

I am using 1x and 2x image pairs, running 1.8u25 on Mac OS 10.0.

I ran into a problem with an image that contains a 1 pixel tall horizontal line in both the 1x and 2x images which I then tried to scale horizontally on a non-HiDPI display by drawing into an area whose height matched the (nominal) image height but had a larger width. The code above selected the 2x image because of the larger width. However, the 2x image had to be reduced along the Y axis, and the result was that the 1 pixel line was not visible.

The example, in case you haven?t guessed, is using a nine slice image to create a border.

The issue is how to trade off between reduction and magnification. Using the 2x image in this example means less magnification along one axis but requires a reduction along the other axis that would not be required if the 1x image was used.

I realize that I can (with some effort) implement my own policy for this example, but I?m wondering whether a more sophisticated default policy would be a good idea. Although extra magnification might produce some blurriness, reduction can lose fine details completely, so perhaps the default policy should avoid unnecessary reduction.

Another way of saying this is that higher resolution variants are provided to make images look better, and they should be used if they might make images look worse.


From mikhail.cherkasov at oracle.com  Thu Nov 13 18:17:31 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Thu, 13 Nov 2014 21:17:31 +0300
Subject: <AWT Dev> [7] Review Request for 8001633: Wrong alt processing
 during switching between windows.
Message-ID: <5464F5BB.7070904@oracle.com>

Hello all,

Could you please review a backport to jdk7 for the following bug:

bug: https://bugs.openjdk.java.net/browse/JDK-8001633
Webrev: http://cr.openjdk.java.net/~mcherkas/8001633/jdk7/webrev.00/
review for jdk8: 
http://mail.openjdk.java.net/pipermail/awt-dev/2012-October/003732.html

It's direct backport except a test case, the test case was replaced with 
a new one, because
jdk8's test case doesn't reproduce the problem for jdk7.

Thanks,
Mikhail.

From petr.pchelko at oracle.com  Fri Nov 14 08:47:49 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 14 Nov 2014 12:47:49 +0400
Subject: <AWT Dev> [9] Review Request for 8054359: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 8
In-Reply-To: <544E1DA5.4070404@oracle.com>
References: <53F76D0E.1000809@oracle.com> <5411B233.9080607@oracle.com>
	<5412B38F.2090308@oracle.com> <5412D41D.20701@oracle.com>
	<542413E6.7090702@oracle.com> <544E1DA5.4070404@oracle.com>
Message-ID: <63626A0C-EFBD-4EE4-A175-0E8CFFABD0DC@oracle.com>

Hello, Alexander.

The fix looks good to me. 

With best regards. Petr.

On 27 ???. 2014 ?., at 14:25, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello,
> 
> Could please anyone review this old request?
> 
> Thanks,
> Alexander
> 
> On 25.09.2014 17:08, alexander stepanov wrote:
>> Sorry, just a reminder.
>> 
>> Thanks,
>> Alexander
>> 
>> On 12.09.2014 15:08, alexander stepanov wrote:
>>> Hello Alexandr,
>>> 
>>> Fixed; please see the updated webrev:
>>> http://cr.openjdk.java.net/~avstepan/8054359/webrev.01/
>>> 
>>> Thanks,
>>> Alexander
>>> 
>>> On 12.09.2014 12:49, Alexander Scherbatiy wrote:
>>>> 
>>>>  75         int x = Toolkit.getDefaultToolkit().getScreenSize().width - 200;
>>>>  76         parent.setLocation(x, 50);
>>>>  77         window.setLocation(x, 250);
>>>>  78         dialog.setLocation(x, 450);
>>>> 
>>>> It is better to use part of the screen or frame size instead of absolute values like 200, 50 and 450.
>>>> 
>>>> Thanks,
>>>> Alexandr.
>>>> 
>>>> On 9/11/2014 6:31 PM, alexander stepanov wrote:
>>>>> Sorry, just a reminder. Could anyone please review that?
>>>>> 
>>>>> Thanks,
>>>>> Alexander
>>>>> 
>>>>> 
>>>>> On 22.08.2014 20:17, alexander stepanov wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Could you please review the fix for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054359
>>>>>> 
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~avstepan/8054359/
>>>>>> 
>>>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>> 
>>>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11 and Windows 7.
>>>>>> 
>>>>>> On Mac OS X 10.8.5 they are failing due to unfixed
>>>>>> https://bugs.openjdk.java.net/browse/JDK-7186009
>>>>>> 
>>>>>> Some of them are also failing because of
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8055752
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexander
>>>>> 
>>>> 
>>> 
>> 
> 


From petr.pchelko at oracle.com  Fri Nov 14 08:53:33 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 14 Nov 2014 12:53:33 +0400
Subject: <AWT Dev> [9] Review Request for 8054358: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 7
In-Reply-To: <544E1DC7.50303@oracle.com>
References: <53EDC2AA.9080802@oracle.com> <5411B150.1000803@oracle.com>
	<5424144F.6090206@oracle.com> <544E1DC7.50303@oracle.com>
Message-ID: <5D32DC02-4C85-4519-B708-F23D518BD039@oracle.com>

Hello, Alexander.

The fix looks fine, just the frame and dialogs fields should be volatile. 
The new webrev is not needed for this little change.

With best regards. Petr.

On 27 ???. 2014 ?., at 14:26, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello,
> 
> Could please anyone review this old request?
> 
> Thanks,
> Alexander
> 
> On 25.09.2014 17:10, alexander stepanov wrote:
>> Sorry, just a reminder.
>> 
>> Thanks,
>> Alexander
>> 
>> On 11.09.2014 18:27, alexander stepanov wrote:
>>> Could anyone review this old request?
>>> 
>>> Thanks,
>>> Alexander
>>> 
>>> On 15.08.2014 12:19, alexander stepanov wrote:
>>>> Hello,
>>>> 
>>>> Could you please review the fix for
>>>> https://bugs.openjdk.java.net/browse/JDK-8054358
>>>> 
>>>> webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8054358/
>>>> 
>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>> 
>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Mac OS X 10.8.5 and Windows 7.
>>>> 
>>>> Thanks,
>>>> Alexander
>>> 
>> 
> 


From alexander.v.stepanov at oracle.com  Fri Nov 14 10:39:20 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Fri, 14 Nov 2014 14:39:20 +0400
Subject: <AWT Dev> [9] Review Request for 8054359: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 8
In-Reply-To: <63626A0C-EFBD-4EE4-A175-0E8CFFABD0DC@oracle.com>
References: <53F76D0E.1000809@oracle.com> <5411B233.9080607@oracle.com>
	<5412B38F.2090308@oracle.com> <5412D41D.20701@oracle.com>
	<542413E6.7090702@oracle.com> <544E1DA5.4070404@oracle.com>
	<63626A0C-EFBD-4EE4-A175-0E8CFFABD0DC@oracle.com>
Message-ID: <5465DBD8.8000808@oracle.com>

Hello Petr,

Thanks!

Regards,
Alexander

On 14.11.2014 12:47, Petr Pchelko wrote:
> Hello, Alexander.
>
> The fix looks good to me.
>
> With best regards. Petr.
>
> On 27 ???. 2014 ?., at 14:25, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could please anyone review this old request?
>>
>> Thanks,
>> Alexander
>>
>> On 25.09.2014 17:08, alexander stepanov wrote:
>>> Sorry, just a reminder.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 12.09.2014 15:08, alexander stepanov wrote:
>>>> Hello Alexandr,
>>>>
>>>> Fixed; please see the updated webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8054359/webrev.01/
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 12.09.2014 12:49, Alexander Scherbatiy wrote:
>>>>>   75         int x = Toolkit.getDefaultToolkit().getScreenSize().width - 200;
>>>>>   76         parent.setLocation(x, 50);
>>>>>   77         window.setLocation(x, 250);
>>>>>   78         dialog.setLocation(x, 450);
>>>>>
>>>>> It is better to use part of the screen or frame size instead of absolute values like 200, 50 and 450.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>> On 9/11/2014 6:31 PM, alexander stepanov wrote:
>>>>>> Sorry, just a reminder. Could anyone please review that?
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>>
>>>>>> On 22.08.2014 20:17, alexander stepanov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you please review the fix for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054359
>>>>>>>
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~avstepan/8054359/
>>>>>>>
>>>>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>>>
>>>>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11 and Windows 7.
>>>>>>>
>>>>>>> On Mac OS X 10.8.5 they are failing due to unfixed
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7186009
>>>>>>>
>>>>>>> Some of them are also failing because of
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8055752
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander


From petr.pchelko at oracle.com  Fri Nov 14 11:39:48 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 14 Nov 2014 15:39:48 +0400
Subject: <AWT Dev> Fwd: [9] Review request: JDK-8023723 Can not paste and
	copy the text from the text area into the editor
References: <96108E3F-79C2-4506-95B1-27746CFC0445@oracle.com>
Message-ID: <41080FBA-2D80-4917-9CC0-B7D4383E05FA@oracle.com>

[forgot to add awt-dev]

Begin forwarded message:

> From: Petr Pchelko <petr.pchelko at oracle.com>
> Subject: [9] Review request: JDK-8023723 Can not paste and copy the text from the text area into the editor
> Date: 14 ?????? 2014 ?., 15:36:51 GMT+4
> To: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com>
> 
> Hello, AWT Team.
> 
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8023723
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8023723/webrev/
> 
> The problem was fixed in JDK8u by some of datatransfer fixes. However in JDK-9 it's broken again, by datatransfer modularization.
> In particular, the location of the service manifest file is wrong. There's no regression test because there's a JCK test covering this.
> 
> With best regards. Petr.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141114/4cac641f/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Fri Nov 14 12:57:41 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 14 Nov 2014 15:57:41 +0300
Subject: <AWT Dev> Fwd: [9] Review request: JDK-8023723 Can not paste
 and copy the text from the text area into the editor
In-Reply-To: <41080FBA-2D80-4917-9CC0-B7D4383E05FA@oracle.com>
References: <96108E3F-79C2-4506-95B1-27746CFC0445@oracle.com>
	<41080FBA-2D80-4917-9CC0-B7D4383E05FA@oracle.com>
Message-ID: <5465FC45.8050508@oracle.com>

HI, Petr.
The fix looks good.

On 14.11.2014 14:39, Petr Pchelko wrote:
> [forgot to add awt-dev]
>
> Begin forwarded message:
>
>> *From: *Petr Pchelko <petr.pchelko at oracle.com 
>> <mailto:petr.pchelko at oracle.com>>
>> *Subject: **[9] Review request: JDK-8023723 Can not paste and copy 
>> the text from the text area into the editor*
>> *Date: *14 ?????? 2014 ?., 15:36:51 GMT+4
>> *To: *Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>> <mailto:Sergey.Bylokhov at oracle.com>>, Alexander Scherbatiy 
>> <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>
>> Hello, AWT Team.
>>
>> Please review the fix for the issue:
>> https://bugs.openjdk.java.net/browse/JDK-8023723
>> The fix is available at:
>> http://cr.openjdk.java.net/~pchelko/9/8023723/webrev/
>>
>> The problem was fixed in JDK8u by some of datatransfer fixes. However 
>> in JDK-9 it's broken again, by datatransfer modularization.
>> In particular, the location of the service manifest file is wrong. 
>> There's no regression test because there's a JCK test covering this.
>>
>> With best regards. Petr.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141114/4dbb96af/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Nov 14 13:12:43 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 14 Nov 2014 16:12:43 +0300
Subject: <AWT Dev> Fwd: [9] Review request: JDK-8023723 Can not paste
 and copy the text from the text area into the editor
In-Reply-To: <5465FC45.8050508@oracle.com>
References: <96108E3F-79C2-4506-95B1-27746CFC0445@oracle.com>
	<41080FBA-2D80-4917-9CC0-B7D4383E05FA@oracle.com>
	<5465FC45.8050508@oracle.com>
Message-ID: <5465FFCB.9060203@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 11/14/2014 3:57 PM, Sergey Bylokhov wrote:
> HI, Petr.
> The fix looks good.
>
> On 14.11.2014 14:39, Petr Pchelko wrote:
>> [forgot to add awt-dev]
>>
>> Begin forwarded message:
>>
>>> *From: *Petr Pchelko <petr.pchelko at oracle.com 
>>> <mailto:petr.pchelko at oracle.com>>
>>> *Subject: **[9] Review request: JDK-8023723 Can not paste and copy 
>>> the text from the text area into the editor*
>>> *Date: *14 ?????? 2014 ?., 15:36:51 GMT+4
>>> *To: *Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>>> <mailto:Sergey.Bylokhov at oracle.com>>, Alexander Scherbatiy 
>>> <alexandr.scherbatiy at oracle.com <mailto:alexandr.scherbatiy at oracle.com>>
>>>
>>> Hello, AWT Team.
>>>
>>> Please review the fix for the issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8023723
>>> The fix is available at:
>>> http://cr.openjdk.java.net/~pchelko/9/8023723/webrev/
>>>
>>> The problem was fixed in JDK8u by some of datatransfer fixes. 
>>> However in JDK-9 it's broken again, by datatransfer modularization.
>>> In particular, the location of the service manifest file is wrong. 
>>> There's no regression test because there's a JCK test covering this.
>>>
>>> With best regards. Petr.
>>
>
>
> -- 
> Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Fri Nov 14 13:16:10 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 14 Nov 2014 16:16:10 +0300
Subject: <AWT Dev> Will fix be backported?
In-Reply-To: <4A1E0BA0-5151-4E9E-84A8-27B8926E8953@tagtraum.com>
References: <4A1E0BA0-5151-4E9E-84A8-27B8926E8953@tagtraum.com>
Message-ID: <5466009A.7090406@oracle.com>

On 11/10/2014 6:33 PM, Hendrik Schreiber wrote:
> Hey...
>
> How can I check whether a fix is being backported to JDK8?
>
> E.g. https://bugs.openjdk.java.net/browse/JDK-8043869 only lists emb-9 under backports. Does that mean it's not being backported to 8?

      I have created the backport to JDK 8: 
https://bugs.openjdk.java.net/browse/JDK-8064884

     Thanks,
     Alexandr.
>
> Thank you,
>
> -hendrik


From hs at tagtraum.com  Fri Nov 14 13:31:48 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 14 Nov 2014 14:31:48 +0100
Subject: <AWT Dev> Will fix be backported?
In-Reply-To: <5466009A.7090406@oracle.com>
References: <4A1E0BA0-5151-4E9E-84A8-27B8926E8953@tagtraum.com>
	<5466009A.7090406@oracle.com>
Message-ID: <CF0A4028-4A1E-4E06-AD1A-443E5C2FA63C@tagtraum.com>



On Nov 14, 2014, at 14:16, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:

> On 11/10/2014 6:33 PM, Hendrik Schreiber wrote:
>> How can I check whether a fix is being backported to JDK8?
>> 
>> E.g. https://bugs.openjdk.java.net/browse/JDK-8043869 only lists emb-9 under backports. Does that mean it's not being backported to 8?
> 
>     I have created the backport to JDK 8: https://bugs.openjdk.java.net/browse/JDK-8064884

Great - thanks!
Much appreciated.

So I guess I can safely assume, that unless something like 8u40 (i.e. 8uXX) is listed in the backport section of a bug, it has not been backported.

Cheers,

-hendrik

From alexandr.scherbatiy at oracle.com  Fri Nov 14 13:40:38 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 14 Nov 2014 16:40:38 +0300
Subject: <AWT Dev> Will fix be backported?
In-Reply-To: <CF0A4028-4A1E-4E06-AD1A-443E5C2FA63C@tagtraum.com>
References: <4A1E0BA0-5151-4E9E-84A8-27B8926E8953@tagtraum.com>
	<5466009A.7090406@oracle.com>
	<CF0A4028-4A1E-4E06-AD1A-443E5C2FA63C@tagtraum.com>
Message-ID: <54660656.8030303@oracle.com>

On 11/14/2014 4:31 PM, Hendrik Schreiber wrote:
>
> On Nov 14, 2014, at 14:16, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
>
>> On 11/10/2014 6:33 PM, Hendrik Schreiber wrote:
>>> How can I check whether a fix is being backported to JDK8?
>>>
>>> E.g. https://bugs.openjdk.java.net/browse/JDK-8043869 only lists emb-9 under backports. Does that mean it's not being backported to 8?
>>      I have created the backport to JDK 8: https://bugs.openjdk.java.net/browse/JDK-8064884
> Great - thanks!
> Much appreciated.
>
> So I guess I can safely assume, that unless something like 8u40 (i.e. 8uXX) is listed in the backport
      It also should have  resolved/fixed status.

     Thanks,
     Alexandr.
> section of a bug, it has not been backported.
>
> Cheers,
>
> -hendrik


From anton.tarasov at oracle.com  Fri Nov 14 12:54:24 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 14 Nov 2014 16:54:24 +0400
Subject: <AWT Dev> [7] Review Request for 8001633: Wrong alt processing
 during switching between windows.
In-Reply-To: <5464F5BB.7070904@oracle.com>
References: <5464F5BB.7070904@oracle.com>
Message-ID: <5465FB80.4040503@oracle.com>

Looks fine for me.

Regards,
Anton.

On 13.11.2014 22:17, mikhail cherkasov wrote:
> Hello all,
>
> Could you please review a backport to jdk7 for the following bug:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8001633
> Webrev: http://cr.openjdk.java.net/~mcherkas/8001633/jdk7/webrev.00/
> review for jdk8: http://mail.openjdk.java.net/pipermail/awt-dev/2012-October/003732.html
>
> It's direct backport except a test case, the test case was replaced with a new one, because
> jdk8's test case doesn't reproduce the problem for jdk7.
>
> Thanks,
> Mikhail.


From mikhail.cherkasov at oracle.com  Fri Nov 14 14:06:13 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 14 Nov 2014 17:06:13 +0300
Subject: <AWT Dev> [7] Review Request for 8001633: Wrong alt processing
 during switching between windows.
In-Reply-To: <5465FB80.4040503@oracle.com>
References: <5464F5BB.7070904@oracle.com> <5465FB80.4040503@oracle.com>
Message-ID: <54660C55.2060502@oracle.com>

Hi Petr, could you please make the second review?

On 11/14/2014 3:54 PM, Anton V. Tarasov wrote:
> Looks fine for me.
>
> Regards,
> Anton.
>
> On 13.11.2014 22:17, mikhail cherkasov wrote:
>> Hello all,
>>
>> Could you please review a backport to jdk7 for the following bug:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8001633
>> Webrev: http://cr.openjdk.java.net/~mcherkas/8001633/jdk7/webrev.00/
>> review for jdk8: 
>> http://mail.openjdk.java.net/pipermail/awt-dev/2012-October/003732.html
>>
>> It's direct backport except a test case, the test case was replaced 
>> with a new one, because
>> jdk8's test case doesn't reproduce the problem for jdk7.
>>
>> Thanks,
>> Mikhail.
>


From petr.pchelko at oracle.com  Fri Nov 14 13:13:53 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Fri, 14 Nov 2014 17:13:53 +0400
Subject: <AWT Dev> [7] Review Request for 8001633: Wrong alt processing
	during switching between windows.
In-Reply-To: <54660C55.2060502@oracle.com>
References: <5464F5BB.7070904@oracle.com> <5465FB80.4040503@oracle.com>
	<54660C55.2060502@oracle.com>
Message-ID: <BD9525D8-AAF1-4F5B-B165-890C4C2D5ED0@oracle.com>

Hello, Mikhail.

The fix looks good to me.

With best regards. Petr.

On 14 ????. 2014 ?., at 18:06, mikhail cherkasov <mikhail.cherkasov at oracle.com> wrote:

> Hi Petr, could you please make the second review?
> 
> On 11/14/2014 3:54 PM, Anton V. Tarasov wrote:
>> Looks fine for me.
>> 
>> Regards,
>> Anton.
>> 
>> On 13.11.2014 22:17, mikhail cherkasov wrote:
>>> Hello all,
>>> 
>>> Could you please review a backport to jdk7 for the following bug:
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8001633
>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8001633/jdk7/webrev.00/
>>> review for jdk8: http://mail.openjdk.java.net/pipermail/awt-dev/2012-October/003732.html
>>> 
>>> It's direct backport except a test case, the test case was replaced with a new one, because
>>> jdk8's test case doesn't reproduce the problem for jdk7.
>>> 
>>> Thanks,
>>> Mikhail.
>> 
> 


From mikhail.cherkasov at oracle.com  Fri Nov 14 14:57:06 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 14 Nov 2014 17:57:06 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
Message-ID: <54661842.6050800@oracle.com>

Hello all,

Could you please review a simple fix of closed test, the test was moved 
to open repo
and requestFocus was replaced requestFocusInWindow.

Because "requestFocus" cause infinite war for focus between two windows, 
however this
behavior is correct and doesn't violet spec.

[TESTBUG] closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html 
fails intermittently
bug: https://bugs.openjdk.java.net/browse/JDK-8047961
Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/

Thanks,
Mikhail.


From anton.tarasov at oracle.com  Fri Nov 14 14:07:00 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Fri, 14 Nov 2014 18:07:00 +0400
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <54661842.6050800@oracle.com>
References: <54661842.6050800@oracle.com>
Message-ID: <54660C84.606@oracle.com>

Hi Mikhail,

Looks fine for me. Thanks! This was an old one... Do you have any plans to fix it in 8/9 as well?

Regards,
Anton.

On 14.11.2014 18:57, mikhail cherkasov wrote:
> Hello all,
>
> Could you please review a simple fix of closed test, the test was moved to open repo
> and requestFocus was replaced requestFocusInWindow.
>
> Because "requestFocus" cause infinite war for focus between two windows, however this
> behavior is correct and doesn't violet spec.
>
> [TESTBUG] closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails intermittently
> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>
> Thanks,
> Mikhail.
>


From mikhail.cherkasov at oracle.com  Fri Nov 14 15:15:41 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 14 Nov 2014 18:15:41 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <54660C84.606@oracle.com>
References: <54661842.6050800@oracle.com> <54660C84.606@oracle.com>
Message-ID: <54661C9D.4010703@oracle.com>

the test works fine in newer versions of jdk, there's no strong reason 
for forward port,
I'll add forward port tasks as low priority tasks.

On 11/14/2014 5:07 PM, Anton V. Tarasov wrote:
> Hi Mikhail,
>
> Looks fine for me. Thanks! This was an old one... Do you have any 
> plans to fix it in 8/9 as well?
>
> Regards,
> Anton.
>
> On 14.11.2014 18:57, mikhail cherkasov wrote:
>> Hello all,
>>
>> Could you please review a simple fix of closed test, the test was 
>> moved to open repo
>> and requestFocus was replaced requestFocusInWindow.
>>
>> Because "requestFocus" cause infinite war for focus between two 
>> windows, however this
>> behavior is correct and doesn't violet spec.
>>
>> [TESTBUG] 
>> closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails 
>> intermittently
>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>
>> Thanks,
>> Mikhail.
>>
>


From son.two at gmail.com  Fri Nov 14 15:24:36 2014
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Fri, 14 Nov 2014 19:24:36 +0400
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <54660C84.606@oracle.com>
References: <54661842.6050800@oracle.com>
	<54660C84.606@oracle.com>
Message-ID: <CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>

Sorry to interrupt you but since I do know the test let me say that
requestFocus() is an important part of the test,
if you are going to replace it with requestFocusInWindow() you
(effectively) remove it from list of regression tests.
Please check 4369903 bug for more information.

Regards, Oleg.

P.S. feel free to ask more questions if you need.

On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
<anton.tarasov at oracle.com> wrote:
> Hi Mikhail,
>
> Looks fine for me. Thanks! This was an old one... Do you have any plans to
> fix it in 8/9 as well?
>
> Regards,
> Anton.
>
>
> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>
>> Hello all,
>>
>> Could you please review a simple fix of closed test, the test was moved to
>> open repo
>> and requestFocus was replaced requestFocusInWindow.
>>
>> Because "requestFocus" cause infinite war for focus between two windows,
>> however this
>> behavior is correct and doesn't violet spec.
>>
>> [TESTBUG] closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>> fails intermittently
>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>
>> Thanks,
>> Mikhail.
>>
>

From anton.tarasov at oracle.com  Mon Nov 17 11:01:14 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 17 Nov 2014 14:01:14 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>
References: <54661842.6050800@oracle.com>	<54660C84.606@oracle.com>
	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>
Message-ID: <5469D57A.9050606@oracle.com>

Hi Oleg,

Glad to hear from you :)

On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
> Sorry to interrupt you but since I do know the test let me say that
> requestFocus() is an important part of the test,
> if you are going to replace it with requestFocusInWindow() you
> (effectively) remove it from list of regression tests.
> Please check 4369903 bug for more information.

In the bug I see the description of why the infinite loop happens and a suggestion to use 
requestFocusInWindow to prevent it. From my point of view, the behavior is expected taking into 
account the asynchronous nature of java focus.

By default, when a toplevel window gains activation, KeyboardFocusManager requests focus in it by 
means of calling the requestFocusInWindow method. Thus, the test case creates an artificial 
situation with unclear goals. It doesn't seem to reflect a real use case (I can see the bug was 
filed by an internal engineer, not refering to any customer or user application). In case a 
developer wants to alter the component receiving focus at the toplevels's activation, he/she can 
achieve this by means of customizing the focus traversal policy, for instance.

The javadoc [1] for the JComponent.requestFocus method warns developers about its usage:

<<Note that the use of this method is discouraged because its behavior is platform dependent. 
Instead we recommend the use of requestFocusInWindow().>>

What I'm trying to say is that we'd rather avoid hacking the focus subsystem in order to just solve 
the infinite loop problem.

However, originally the reporter of the bug complains about the following:

<<Setting focus during window activation often sends focus to the wrong place, or to multiple places.>>

This behavior is incorrect, indeed. But we can verify it with the test case. When a component gains 
focus we can check that:

1. it is the current focus owner reported by KFM, and the current focused window is its container
2. the opposite component has lost focus prior to that (that is, every FOCUS_GAINED precedes a 
FOCUS_LOST received by the opposite component)
3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair

The test should be ready for the infinite loop and I can suggest to simply stop requesting focus 
after a couple of iterations.

This could be a compromize. What do you think, Oleg, Mikhail?

Thanks,
Anton.

[1] https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--

>
> Regards, Oleg.
>
> P.S. feel free to ask more questions if you need.
>
> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com> wrote:
>> Hi Mikhail,
>>
>> Looks fine for me. Thanks! This was an old one... Do you have any plans to
>> fix it in 8/9 as well?
>>
>> Regards,
>> Anton.
>>
>>
>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>> Hello all,
>>>
>>> Could you please review a simple fix of closed test, the test was moved to
>>> open repo
>>> and requestFocus was replaced requestFocusInWindow.
>>>
>>> Because "requestFocus" cause infinite war for focus between two windows,
>>> however this
>>> behavior is correct and doesn't violet spec.
>>>
>>> [TESTBUG] closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>> fails intermittently
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>
>>> Thanks,
>>> Mikhail.
>>>


From son.two at gmail.com  Mon Nov 17 12:01:01 2014
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 17 Nov 2014 16:01:01 +0400
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <5469D57A.9050606@oracle.com>
References: <54661842.6050800@oracle.com> <54660C84.606@oracle.com>
	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>
	<5469D57A.9050606@oracle.com>
Message-ID: <CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>

Hi Anton,

the bug was a regression introduced in 1.4 (comparing with 1.3.1) this
is why it was fixed and the test was written.
Indeed the spec doesn't guarantee that the test will work but at the
time we were working on the ticket it was decided that we should not
allow such regressions.
If (according to the current policy) the spec is more important than
compatibility in this case I'd suggest to remove the test completely
since its new version doesn't test for the regression we had earlier
but just test spec in a very strange/complicated way.

So, it is you whole should make the final decision but I just do not
see a reason to keep a test which doesn't test for the particular
regression in regression tests suite.

Regards, Oleg.

On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
<anton.tarasov at oracle.com> wrote:
> Hi Oleg,
>
> Glad to hear from you :)
>
> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>
>> Sorry to interrupt you but since I do know the test let me say that
>> requestFocus() is an important part of the test,
>> if you are going to replace it with requestFocusInWindow() you
>> (effectively) remove it from list of regression tests.
>> Please check 4369903 bug for more information.
>
>
> In the bug I see the description of why the infinite loop happens and a
> suggestion to use requestFocusInWindow to prevent it. From my point of view,
> the behavior is expected taking into account the asynchronous nature of java
> focus.
>
> By default, when a toplevel window gains activation, KeyboardFocusManager
> requests focus in it by means of calling the requestFocusInWindow method.
> Thus, the test case creates an artificial situation with unclear goals. It
> doesn't seem to reflect a real use case (I can see the bug was filed by an
> internal engineer, not refering to any customer or user application). In
> case a developer wants to alter the component receiving focus at the
> toplevels's activation, he/she can achieve this by means of customizing the
> focus traversal policy, for instance.
>
> The javadoc [1] for the JComponent.requestFocus method warns developers
> about its usage:
>
> <<Note that the use of this method is discouraged because its behavior is
> platform dependent. Instead we recommend the use of
> requestFocusInWindow().>>
>
> What I'm trying to say is that we'd rather avoid hacking the focus subsystem
> in order to just solve the infinite loop problem.
>
> However, originally the reporter of the bug complains about the following:
>
> <<Setting focus during window activation often sends focus to the wrong
> place, or to multiple places.>>
>
> This behavior is incorrect, indeed. But we can verify it with the test case.
> When a component gains focus we can check that:
>
> 1. it is the current focus owner reported by KFM, and the current focused
> window is its container
> 2. the opposite component has lost focus prior to that (that is, every
> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite component)
> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>
> The test should be ready for the infinite loop and I can suggest to simply
> stop requesting focus after a couple of iterations.
>
> This could be a compromize. What do you think, Oleg, Mikhail?
>
> Thanks,
> Anton.
>
> [1]
> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--
>
>
>>
>> Regards, Oleg.
>>
>> P.S. feel free to ask more questions if you need.
>>
>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>> <anton.tarasov at oracle.com> wrote:
>>>
>>> Hi Mikhail,
>>>
>>> Looks fine for me. Thanks! This was an old one... Do you have any plans
>>> to
>>> fix it in 8/9 as well?
>>>
>>> Regards,
>>> Anton.
>>>
>>>
>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>
>>>> Hello all,
>>>>
>>>> Could you please review a simple fix of closed test, the test was moved
>>>> to
>>>> open repo
>>>> and requestFocus was replaced requestFocusInWindow.
>>>>
>>>> Because "requestFocus" cause infinite war for focus between two windows,
>>>> however this
>>>> behavior is correct and doesn't violet spec.
>>>>
>>>> [TESTBUG] closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>> fails intermittently
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>
>>>> Thanks,
>>>> Mikhail.
>>>>
>

From anton.tarasov at oracle.com  Mon Nov 17 13:34:38 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 17 Nov 2014 16:34:38 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>
References: <54661842.6050800@oracle.com>	<54660C84.606@oracle.com>	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>	<5469D57A.9050606@oracle.com>
	<CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>
Message-ID: <5469F96E.5060203@oracle.com>

On 17.11.2014 15:01, Oleg Sukhodolsky wrote:
> Hi Anton,
>
> the bug was a regression introduced in 1.4 (comparing with 1.3.1) this
> is why it was fixed and the test was written.
> Indeed the spec doesn't guarantee that the test will work but at the
> time we were working on the ticket it was decided that we should not
> allow such regressions.
> If (according to the current policy) the spec is more important than
> compatibility in this case I'd suggest to remove the test completely
> since its new version doesn't test for the regression we had earlier
> but just test spec in a very strange/complicated way.

The test passes on Windows, but fails on Mac and I suppose Linux. I recall I made attemps to fix the 
failure on Linux (in 1.6 or 1.7) but that was quite complicated to make something reliable, due to 
the fact that in XToolkit even native focus is asynchronous, like in CToolkit. So, from my point of 
view hacking it doesn't worth the candles, taking into account all I've said below.

I still like the idea of  replacing requestFocus with requestFocusInWindow. We can add comments 
saying that the original test was modified to avoid the endless loop. It didn't actually test for 
the endless loop, as otherwise it would have had a timer. It tested for focus gains count per 
window, that remains relevant even in its new form. That's my personal opinion, I won't insist on 
keeping it if you both vote for the opposite...

Thanks,
Anton.

>
> So, it is you whole should make the final decision but I just do not
> see a reason to keep a test which doesn't test for the particular
> regression in regression tests suite.
>
> Regards, Oleg.
>
> On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com> wrote:
>> Hi Oleg,
>>
>> Glad to hear from you :)
>>
>> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>> Sorry to interrupt you but since I do know the test let me say that
>>> requestFocus() is an important part of the test,
>>> if you are going to replace it with requestFocusInWindow() you
>>> (effectively) remove it from list of regression tests.
>>> Please check 4369903 bug for more information.
>>
>> In the bug I see the description of why the infinite loop happens and a
>> suggestion to use requestFocusInWindow to prevent it. From my point of view,
>> the behavior is expected taking into account the asynchronous nature of java
>> focus.
>>
>> By default, when a toplevel window gains activation, KeyboardFocusManager
>> requests focus in it by means of calling the requestFocusInWindow method.
>> Thus, the test case creates an artificial situation with unclear goals. It
>> doesn't seem to reflect a real use case (I can see the bug was filed by an
>> internal engineer, not refering to any customer or user application). In
>> case a developer wants to alter the component receiving focus at the
>> toplevels's activation, he/she can achieve this by means of customizing the
>> focus traversal policy, for instance.
>>
>> The javadoc [1] for the JComponent.requestFocus method warns developers
>> about its usage:
>>
>> <<Note that the use of this method is discouraged because its behavior is
>> platform dependent. Instead we recommend the use of
>> requestFocusInWindow().>>
>>
>> What I'm trying to say is that we'd rather avoid hacking the focus subsystem
>> in order to just solve the infinite loop problem.
>>
>> However, originally the reporter of the bug complains about the following:
>>
>> <<Setting focus during window activation often sends focus to the wrong
>> place, or to multiple places.>>
>>
>> This behavior is incorrect, indeed. But we can verify it with the test case.
>> When a component gains focus we can check that:
>>
>> 1. it is the current focus owner reported by KFM, and the current focused
>> window is its container
>> 2. the opposite component has lost focus prior to that (that is, every
>> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite component)
>> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>>
>> The test should be ready for the infinite loop and I can suggest to simply
>> stop requesting focus after a couple of iterations.
>>
>> This could be a compromize. What do you think, Oleg, Mikhail?
>>
>> Thanks,
>> Anton.
>>
>> [1]
>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--
>>
>>
>>> Regards, Oleg.
>>>
>>> P.S. feel free to ask more questions if you need.
>>>
>>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>>> <anton.tarasov at oracle.com> wrote:
>>>> Hi Mikhail,
>>>>
>>>> Looks fine for me. Thanks! This was an old one... Do you have any plans
>>>> to
>>>> fix it in 8/9 as well?
>>>>
>>>> Regards,
>>>> Anton.
>>>>
>>>>
>>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>> Hello all,
>>>>>
>>>>> Could you please review a simple fix of closed test, the test was moved
>>>>> to
>>>>> open repo
>>>>> and requestFocus was replaced requestFocusInWindow.
>>>>>
>>>>> Because "requestFocus" cause infinite war for focus between two windows,
>>>>> however this
>>>>> behavior is correct and doesn't violet spec.
>>>>>
>>>>> [TESTBUG] closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>>> fails intermittently
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Mikhail.
>>>>>


From son.two at gmail.com  Mon Nov 17 14:21:49 2014
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 17 Nov 2014 18:21:49 +0400
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <5469F96E.5060203@oracle.com>
References: <54661842.6050800@oracle.com> <54660C84.606@oracle.com>
	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>
	<5469D57A.9050606@oracle.com>
	<CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>
	<5469F96E.5060203@oracle.com>
Message-ID: <CAK6==_mKajuXLwMVyC8L3YGxsyj112-NwHOocu0zR1Cys0QLVw@mail.gmail.com>

On Mon, Nov 17, 2014 at 4:34 PM, Anton V. Tarasov
<anton.tarasov at oracle.com> wrote:
> On 17.11.2014 15:01, Oleg Sukhodolsky wrote:
>>
>> Hi Anton,
>>
>> the bug was a regression introduced in 1.4 (comparing with 1.3.1) this
>> is why it was fixed and the test was written.
>> Indeed the spec doesn't guarantee that the test will work but at the
>> time we were working on the ticket it was decided that we should not
>> allow such regressions.
>> If (according to the current policy) the spec is more important than
>> compatibility in this case I'd suggest to remove the test completely
>> since its new version doesn't test for the regression we had earlier
>> but just test spec in a very strange/complicated way.
>
>
> The test passes on Windows, but fails on Mac and I suppose Linux. I recall I
> made attemps to fix the failure on Linux (in 1.6 or 1.7) but that was quite
> complicated to make something reliable, due to the fact that in XToolkit
> even native focus is asynchronous, like in CToolkit. So, from my point of
> view hacking it doesn't worth the candles, taking into account all I've said
> below.
>
> I still like the idea of  replacing requestFocus with requestFocusInWindow.
> We can add comments saying that the original test was modified to avoid the
> endless loop. It didn't actually test for the endless loop, as otherwise it
> would have had a timer. It tested for focus gains count per window, that
> remains relevant even in its new form. That's my personal opinion, I won't
> insist on keeping it if you both vote for the opposite...

if you do not plan to fix the problem the test reproduces then I'd
vote for removing the test (you have enough tests in regression tests
suite ;)

Regards, Oleg.
>
> Thanks,
> Anton.
>
>
>>
>> So, it is you whole should make the final decision but I just do not
>> see a reason to keep a test which doesn't test for the particular
>> regression in regression tests suite.
>>
>> Regards, Oleg.
>>
>> On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
>> <anton.tarasov at oracle.com> wrote:
>>>
>>> Hi Oleg,
>>>
>>> Glad to hear from you :)
>>>
>>> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>>>
>>>> Sorry to interrupt you but since I do know the test let me say that
>>>> requestFocus() is an important part of the test,
>>>> if you are going to replace it with requestFocusInWindow() you
>>>> (effectively) remove it from list of regression tests.
>>>> Please check 4369903 bug for more information.
>>>
>>>
>>> In the bug I see the description of why the infinite loop happens and a
>>> suggestion to use requestFocusInWindow to prevent it. From my point of
>>> view,
>>> the behavior is expected taking into account the asynchronous nature of
>>> java
>>> focus.
>>>
>>> By default, when a toplevel window gains activation, KeyboardFocusManager
>>> requests focus in it by means of calling the requestFocusInWindow method.
>>> Thus, the test case creates an artificial situation with unclear goals.
>>> It
>>> doesn't seem to reflect a real use case (I can see the bug was filed by
>>> an
>>> internal engineer, not refering to any customer or user application). In
>>> case a developer wants to alter the component receiving focus at the
>>> toplevels's activation, he/she can achieve this by means of customizing
>>> the
>>> focus traversal policy, for instance.
>>>
>>> The javadoc [1] for the JComponent.requestFocus method warns developers
>>> about its usage:
>>>
>>> <<Note that the use of this method is discouraged because its behavior is
>>> platform dependent. Instead we recommend the use of
>>> requestFocusInWindow().>>
>>>
>>> What I'm trying to say is that we'd rather avoid hacking the focus
>>> subsystem
>>> in order to just solve the infinite loop problem.
>>>
>>> However, originally the reporter of the bug complains about the
>>> following:
>>>
>>> <<Setting focus during window activation often sends focus to the wrong
>>> place, or to multiple places.>>
>>>
>>> This behavior is incorrect, indeed. But we can verify it with the test
>>> case.
>>> When a component gains focus we can check that:
>>>
>>> 1. it is the current focus owner reported by KFM, and the current focused
>>> window is its container
>>> 2. the opposite component has lost focus prior to that (that is, every
>>> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite component)
>>> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>>>
>>> The test should be ready for the infinite loop and I can suggest to
>>> simply
>>> stop requesting focus after a couple of iterations.
>>>
>>> This could be a compromize. What do you think, Oleg, Mikhail?
>>>
>>> Thanks,
>>> Anton.
>>>
>>> [1]
>>>
>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--
>>>
>>>
>>>> Regards, Oleg.
>>>>
>>>> P.S. feel free to ask more questions if you need.
>>>>
>>>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>>>> <anton.tarasov at oracle.com> wrote:
>>>>>
>>>>> Hi Mikhail,
>>>>>
>>>>> Looks fine for me. Thanks! This was an old one... Do you have any plans
>>>>> to
>>>>> fix it in 8/9 as well?
>>>>>
>>>>> Regards,
>>>>> Anton.
>>>>>
>>>>>
>>>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> Could you please review a simple fix of closed test, the test was
>>>>>> moved
>>>>>> to
>>>>>> open repo
>>>>>> and requestFocus was replaced requestFocusInWindow.
>>>>>>
>>>>>> Because "requestFocus" cause infinite war for focus between two
>>>>>> windows,
>>>>>> however this
>>>>>> behavior is correct and doesn't violet spec.
>>>>>>
>>>>>> [TESTBUG]
>>>>>> closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>>>> fails intermittently
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Mikhail.
>>>>>>
>

From anton.tarasov at oracle.com  Mon Nov 17 14:31:12 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 17 Nov 2014 17:31:12 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <CAK6==_mKajuXLwMVyC8L3YGxsyj112-NwHOocu0zR1Cys0QLVw@mail.gmail.com>
References: <54661842.6050800@oracle.com>	<54660C84.606@oracle.com>	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>	<5469D57A.9050606@oracle.com>	<CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>	<5469F96E.5060203@oracle.com>
	<CAK6==_mKajuXLwMVyC8L3YGxsyj112-NwHOocu0zR1Cys0QLVw@mail.gmail.com>
Message-ID: <546A06B0.2070406@oracle.com>

On 17.11.2014 17:21, Oleg Sukhodolsky wrote:
> On Mon, Nov 17, 2014 at 4:34 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com> wrote:
>> On 17.11.2014 15:01, Oleg Sukhodolsky wrote:
>>> Hi Anton,
>>>
>>> the bug was a regression introduced in 1.4 (comparing with 1.3.1) this
>>> is why it was fixed and the test was written.
>>> Indeed the spec doesn't guarantee that the test will work but at the
>>> time we were working on the ticket it was decided that we should not
>>> allow such regressions.
>>> If (according to the current policy) the spec is more important than
>>> compatibility in this case I'd suggest to remove the test completely
>>> since its new version doesn't test for the regression we had earlier
>>> but just test spec in a very strange/complicated way.
>>
>> The test passes on Windows, but fails on Mac and I suppose Linux. I recall I
>> made attemps to fix the failure on Linux (in 1.6 or 1.7) but that was quite
>> complicated to make something reliable, due to the fact that in XToolkit
>> even native focus is asynchronous, like in CToolkit. So, from my point of
>> view hacking it doesn't worth the candles, taking into account all I've said
>> below.
>>
>> I still like the idea of  replacing requestFocus with requestFocusInWindow.
>> We can add comments saying that the original test was modified to avoid the
>> endless loop. It didn't actually test for the endless loop, as otherwise it
>> would have had a timer. It tested for focus gains count per window, that
>> remains relevant even in its new form. That's my personal opinion, I won't
>> insist on keeping it if you both vote for the opposite...
> if you do not plan to fix the problem the test reproduces then I'd
> vote for removing the test (you have enough tests in regression tests
> suite ;)

I'm afraid I don't, as I don't think this is a real problem :)

Regards,
Anton.

>
> Regards, Oleg.
>> Thanks,
>> Anton.
>>
>>
>>> So, it is you whole should make the final decision but I just do not
>>> see a reason to keep a test which doesn't test for the particular
>>> regression in regression tests suite.
>>>
>>> Regards, Oleg.
>>>
>>> On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
>>> <anton.tarasov at oracle.com> wrote:
>>>> Hi Oleg,
>>>>
>>>> Glad to hear from you :)
>>>>
>>>> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>>>> Sorry to interrupt you but since I do know the test let me say that
>>>>> requestFocus() is an important part of the test,
>>>>> if you are going to replace it with requestFocusInWindow() you
>>>>> (effectively) remove it from list of regression tests.
>>>>> Please check 4369903 bug for more information.
>>>>
>>>> In the bug I see the description of why the infinite loop happens and a
>>>> suggestion to use requestFocusInWindow to prevent it. From my point of
>>>> view,
>>>> the behavior is expected taking into account the asynchronous nature of
>>>> java
>>>> focus.
>>>>
>>>> By default, when a toplevel window gains activation, KeyboardFocusManager
>>>> requests focus in it by means of calling the requestFocusInWindow method.
>>>> Thus, the test case creates an artificial situation with unclear goals.
>>>> It
>>>> doesn't seem to reflect a real use case (I can see the bug was filed by
>>>> an
>>>> internal engineer, not refering to any customer or user application). In
>>>> case a developer wants to alter the component receiving focus at the
>>>> toplevels's activation, he/she can achieve this by means of customizing
>>>> the
>>>> focus traversal policy, for instance.
>>>>
>>>> The javadoc [1] for the JComponent.requestFocus method warns developers
>>>> about its usage:
>>>>
>>>> <<Note that the use of this method is discouraged because its behavior is
>>>> platform dependent. Instead we recommend the use of
>>>> requestFocusInWindow().>>
>>>>
>>>> What I'm trying to say is that we'd rather avoid hacking the focus
>>>> subsystem
>>>> in order to just solve the infinite loop problem.
>>>>
>>>> However, originally the reporter of the bug complains about the
>>>> following:
>>>>
>>>> <<Setting focus during window activation often sends focus to the wrong
>>>> place, or to multiple places.>>
>>>>
>>>> This behavior is incorrect, indeed. But we can verify it with the test
>>>> case.
>>>> When a component gains focus we can check that:
>>>>
>>>> 1. it is the current focus owner reported by KFM, and the current focused
>>>> window is its container
>>>> 2. the opposite component has lost focus prior to that (that is, every
>>>> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite component)
>>>> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>>>>
>>>> The test should be ready for the infinite loop and I can suggest to
>>>> simply
>>>> stop requesting focus after a couple of iterations.
>>>>
>>>> This could be a compromize. What do you think, Oleg, Mikhail?
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>> [1]
>>>>
>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--
>>>>
>>>>
>>>>> Regards, Oleg.
>>>>>
>>>>> P.S. feel free to ask more questions if you need.
>>>>>
>>>>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>>>>> <anton.tarasov at oracle.com> wrote:
>>>>>> Hi Mikhail,
>>>>>>
>>>>>> Looks fine for me. Thanks! This was an old one... Do you have any plans
>>>>>> to
>>>>>> fix it in 8/9 as well?
>>>>>>
>>>>>> Regards,
>>>>>> Anton.
>>>>>>
>>>>>>
>>>>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> Could you please review a simple fix of closed test, the test was
>>>>>>> moved
>>>>>>> to
>>>>>>> open repo
>>>>>>> and requestFocus was replaced requestFocusInWindow.
>>>>>>>
>>>>>>> Because "requestFocus" cause infinite war for focus between two
>>>>>>> windows,
>>>>>>> however this
>>>>>>> behavior is correct and doesn't violet spec.
>>>>>>>
>>>>>>> [TESTBUG]
>>>>>>> closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>>>>> fails intermittently
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Mikhail.
>>>>>>>


From son.two at gmail.com  Mon Nov 17 14:38:38 2014
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Mon, 17 Nov 2014 18:38:38 +0400
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <546A06B0.2070406@oracle.com>
References: <54661842.6050800@oracle.com> <54660C84.606@oracle.com>
	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>
	<5469D57A.9050606@oracle.com>
	<CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>
	<5469F96E.5060203@oracle.com>
	<CAK6==_mKajuXLwMVyC8L3YGxsyj112-NwHOocu0zR1Cys0QLVw@mail.gmail.com>
	<546A06B0.2070406@oracle.com>
Message-ID: <CAK6==_mPfwoQmtRPA1BKtSSoEG-oLopt_Rrf6cHz+ws7j0e=Zg@mail.gmail.com>

On Mon, Nov 17, 2014 at 5:31 PM, Anton V. Tarasov
<anton.tarasov at oracle.com> wrote:
> On 17.11.2014 17:21, Oleg Sukhodolsky wrote:
>>
>> On Mon, Nov 17, 2014 at 4:34 PM, Anton V. Tarasov
>> <anton.tarasov at oracle.com> wrote:
>>>
>>> On 17.11.2014 15:01, Oleg Sukhodolsky wrote:
>>>>
>>>> Hi Anton,
>>>>
>>>> the bug was a regression introduced in 1.4 (comparing with 1.3.1) this
>>>> is why it was fixed and the test was written.
>>>> Indeed the spec doesn't guarantee that the test will work but at the
>>>> time we were working on the ticket it was decided that we should not
>>>> allow such regressions.
>>>> If (according to the current policy) the spec is more important than
>>>> compatibility in this case I'd suggest to remove the test completely
>>>> since its new version doesn't test for the regression we had earlier
>>>> but just test spec in a very strange/complicated way.
>>>
>>>
>>> The test passes on Windows, but fails on Mac and I suppose Linux. I
>>> recall I
>>> made attemps to fix the failure on Linux (in 1.6 or 1.7) but that was
>>> quite
>>> complicated to make something reliable, due to the fact that in XToolkit
>>> even native focus is asynchronous, like in CToolkit. So, from my point of
>>> view hacking it doesn't worth the candles, taking into account all I've
>>> said
>>> below.
>>>
>>> I still like the idea of  replacing requestFocus with
>>> requestFocusInWindow.
>>> We can add comments saying that the original test was modified to avoid
>>> the
>>> endless loop. It didn't actually test for the endless loop, as otherwise
>>> it
>>> would have had a timer. It tested for focus gains count per window, that
>>> remains relevant even in its new form. That's my personal opinion, I
>>> won't
>>> insist on keeping it if you both vote for the opposite...
>>
>> if you do not plan to fix the problem the test reproduces then I'd
>> vote for removing the test (you have enough tests in regression tests
>> suite ;)
>
>
> I'm afraid I don't, as I don't think this is a real problem :)

so just remove the test, you do not need it ;)

Oleg.
>
> Regards,
> Anton.
>
>
>>
>> Regards, Oleg.
>>>
>>> Thanks,
>>> Anton.
>>>
>>>
>>>> So, it is you whole should make the final decision but I just do not
>>>> see a reason to keep a test which doesn't test for the particular
>>>> regression in regression tests suite.
>>>>
>>>> Regards, Oleg.
>>>>
>>>> On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
>>>> <anton.tarasov at oracle.com> wrote:
>>>>>
>>>>> Hi Oleg,
>>>>>
>>>>> Glad to hear from you :)
>>>>>
>>>>> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>>>>>
>>>>>> Sorry to interrupt you but since I do know the test let me say that
>>>>>> requestFocus() is an important part of the test,
>>>>>> if you are going to replace it with requestFocusInWindow() you
>>>>>> (effectively) remove it from list of regression tests.
>>>>>> Please check 4369903 bug for more information.
>>>>>
>>>>>
>>>>> In the bug I see the description of why the infinite loop happens and a
>>>>> suggestion to use requestFocusInWindow to prevent it. From my point of
>>>>> view,
>>>>> the behavior is expected taking into account the asynchronous nature of
>>>>> java
>>>>> focus.
>>>>>
>>>>> By default, when a toplevel window gains activation,
>>>>> KeyboardFocusManager
>>>>> requests focus in it by means of calling the requestFocusInWindow
>>>>> method.
>>>>> Thus, the test case creates an artificial situation with unclear goals.
>>>>> It
>>>>> doesn't seem to reflect a real use case (I can see the bug was filed by
>>>>> an
>>>>> internal engineer, not refering to any customer or user application).
>>>>> In
>>>>> case a developer wants to alter the component receiving focus at the
>>>>> toplevels's activation, he/she can achieve this by means of customizing
>>>>> the
>>>>> focus traversal policy, for instance.
>>>>>
>>>>> The javadoc [1] for the JComponent.requestFocus method warns developers
>>>>> about its usage:
>>>>>
>>>>> <<Note that the use of this method is discouraged because its behavior
>>>>> is
>>>>> platform dependent. Instead we recommend the use of
>>>>> requestFocusInWindow().>>
>>>>>
>>>>> What I'm trying to say is that we'd rather avoid hacking the focus
>>>>> subsystem
>>>>> in order to just solve the infinite loop problem.
>>>>>
>>>>> However, originally the reporter of the bug complains about the
>>>>> following:
>>>>>
>>>>> <<Setting focus during window activation often sends focus to the wrong
>>>>> place, or to multiple places.>>
>>>>>
>>>>> This behavior is incorrect, indeed. But we can verify it with the test
>>>>> case.
>>>>> When a component gains focus we can check that:
>>>>>
>>>>> 1. it is the current focus owner reported by KFM, and the current
>>>>> focused
>>>>> window is its container
>>>>> 2. the opposite component has lost focus prior to that (that is, every
>>>>> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite component)
>>>>> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>>>>>
>>>>> The test should be ready for the infinite loop and I can suggest to
>>>>> simply
>>>>> stop requesting focus after a couple of iterations.
>>>>>
>>>>> This could be a compromize. What do you think, Oleg, Mikhail?
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--
>>>>>
>>>>>
>>>>>> Regards, Oleg.
>>>>>>
>>>>>> P.S. feel free to ask more questions if you need.
>>>>>>
>>>>>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>>>>>> <anton.tarasov at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Mikhail,
>>>>>>>
>>>>>>> Looks fine for me. Thanks! This was an old one... Do you have any
>>>>>>> plans
>>>>>>> to
>>>>>>> fix it in 8/9 as well?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anton.
>>>>>>>
>>>>>>>
>>>>>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> Could you please review a simple fix of closed test, the test was
>>>>>>>> moved
>>>>>>>> to
>>>>>>>> open repo
>>>>>>>> and requestFocus was replaced requestFocusInWindow.
>>>>>>>>
>>>>>>>> Because "requestFocus" cause infinite war for focus between two
>>>>>>>> windows,
>>>>>>>> however this
>>>>>>>> behavior is correct and doesn't violet spec.
>>>>>>>>
>>>>>>>> [TESTBUG]
>>>>>>>> closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>>>>>> fails intermittently
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Mikhail.
>>>>>>>>
>

From anton.tarasov at oracle.com  Mon Nov 17 14:42:13 2014
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Mon, 17 Nov 2014 17:42:13 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <CAK6==_mPfwoQmtRPA1BKtSSoEG-oLopt_Rrf6cHz+ws7j0e=Zg@mail.gmail.com>
References: <54661842.6050800@oracle.com>	<54660C84.606@oracle.com>	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>	<5469D57A.9050606@oracle.com>	<CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>	<5469F96E.5060203@oracle.com>	<CAK6==_mKajuXLwMVyC8L3YGxsyj112-NwHOocu0zR1Cys0QLVw@mail.gmail.com>	<546A06B0.2070406@oracle.com>
	<CAK6==_mPfwoQmtRPA1BKtSSoEG-oLopt_Rrf6cHz+ws7j0e=Zg@mail.gmail.com>
Message-ID: <546A0945.3000209@oracle.com>

On 17.11.2014 17:38, Oleg Sukhodolsky wrote:
> On Mon, Nov 17, 2014 at 5:31 PM, Anton V. Tarasov
> <anton.tarasov at oracle.com> wrote:
>> On 17.11.2014 17:21, Oleg Sukhodolsky wrote:
>>> On Mon, Nov 17, 2014 at 4:34 PM, Anton V. Tarasov
>>> <anton.tarasov at oracle.com> wrote:
>>>> On 17.11.2014 15:01, Oleg Sukhodolsky wrote:
>>>>> Hi Anton,
>>>>>
>>>>> the bug was a regression introduced in 1.4 (comparing with 1.3.1) this
>>>>> is why it was fixed and the test was written.
>>>>> Indeed the spec doesn't guarantee that the test will work but at the
>>>>> time we were working on the ticket it was decided that we should not
>>>>> allow such regressions.
>>>>> If (according to the current policy) the spec is more important than
>>>>> compatibility in this case I'd suggest to remove the test completely
>>>>> since its new version doesn't test for the regression we had earlier
>>>>> but just test spec in a very strange/complicated way.
>>>>
>>>> The test passes on Windows, but fails on Mac and I suppose Linux. I
>>>> recall I
>>>> made attemps to fix the failure on Linux (in 1.6 or 1.7) but that was
>>>> quite
>>>> complicated to make something reliable, due to the fact that in XToolkit
>>>> even native focus is asynchronous, like in CToolkit. So, from my point of
>>>> view hacking it doesn't worth the candles, taking into account all I've
>>>> said
>>>> below.
>>>>
>>>> I still like the idea of  replacing requestFocus with
>>>> requestFocusInWindow.
>>>> We can add comments saying that the original test was modified to avoid
>>>> the
>>>> endless loop. It didn't actually test for the endless loop, as otherwise
>>>> it
>>>> would have had a timer. It tested for focus gains count per window, that
>>>> remains relevant even in its new form. That's my personal opinion, I
>>>> won't
>>>> insist on keeping it if you both vote for the opposite...
>>> if you do not plan to fix the problem the test reproduces then I'd
>>> vote for removing the test (you have enough tests in regression tests
>>> suite ;)
>>
>> I'm afraid I don't, as I don't think this is a real problem :)
> so just remove the test, you do not need it ;)

No, I won't. I'd leave it at Mikhail's discretion, as he is the author of the request.

Mikhail, you have a chance to save the test :)

Regards,
Anton.

>
> Oleg.
>> Regards,
>> Anton.
>>
>>
>>> Regards, Oleg.
>>>> Thanks,
>>>> Anton.
>>>>
>>>>
>>>>> So, it is you whole should make the final decision but I just do not
>>>>> see a reason to keep a test which doesn't test for the particular
>>>>> regression in regression tests suite.
>>>>>
>>>>> Regards, Oleg.
>>>>>
>>>>> On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
>>>>> <anton.tarasov at oracle.com> wrote:
>>>>>> Hi Oleg,
>>>>>>
>>>>>> Glad to hear from you :)
>>>>>>
>>>>>> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>>>>>> Sorry to interrupt you but since I do know the test let me say that
>>>>>>> requestFocus() is an important part of the test,
>>>>>>> if you are going to replace it with requestFocusInWindow() you
>>>>>>> (effectively) remove it from list of regression tests.
>>>>>>> Please check 4369903 bug for more information.
>>>>>>
>>>>>> In the bug I see the description of why the infinite loop happens and a
>>>>>> suggestion to use requestFocusInWindow to prevent it. From my point of
>>>>>> view,
>>>>>> the behavior is expected taking into account the asynchronous nature of
>>>>>> java
>>>>>> focus.
>>>>>>
>>>>>> By default, when a toplevel window gains activation,
>>>>>> KeyboardFocusManager
>>>>>> requests focus in it by means of calling the requestFocusInWindow
>>>>>> method.
>>>>>> Thus, the test case creates an artificial situation with unclear goals.
>>>>>> It
>>>>>> doesn't seem to reflect a real use case (I can see the bug was filed by
>>>>>> an
>>>>>> internal engineer, not refering to any customer or user application).
>>>>>> In
>>>>>> case a developer wants to alter the component receiving focus at the
>>>>>> toplevels's activation, he/she can achieve this by means of customizing
>>>>>> the
>>>>>> focus traversal policy, for instance.
>>>>>>
>>>>>> The javadoc [1] for the JComponent.requestFocus method warns developers
>>>>>> about its usage:
>>>>>>
>>>>>> <<Note that the use of this method is discouraged because its behavior
>>>>>> is
>>>>>> platform dependent. Instead we recommend the use of
>>>>>> requestFocusInWindow().>>
>>>>>>
>>>>>> What I'm trying to say is that we'd rather avoid hacking the focus
>>>>>> subsystem
>>>>>> in order to just solve the infinite loop problem.
>>>>>>
>>>>>> However, originally the reporter of the bug complains about the
>>>>>> following:
>>>>>>
>>>>>> <<Setting focus during window activation often sends focus to the wrong
>>>>>> place, or to multiple places.>>
>>>>>>
>>>>>> This behavior is incorrect, indeed. But we can verify it with the test
>>>>>> case.
>>>>>> When a component gains focus we can check that:
>>>>>>
>>>>>> 1. it is the current focus owner reported by KFM, and the current
>>>>>> focused
>>>>>> window is its container
>>>>>> 2. the opposite component has lost focus prior to that (that is, every
>>>>>> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite component)
>>>>>> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>>>>>>
>>>>>> The test should be ready for the infinite loop and I can suggest to
>>>>>> simply
>>>>>> stop requesting focus after a couple of iterations.
>>>>>>
>>>>>> This could be a compromize. What do you think, Oleg, Mikhail?
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>>
>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus--
>>>>>>
>>>>>>
>>>>>>> Regards, Oleg.
>>>>>>>
>>>>>>> P.S. feel free to ask more questions if you need.
>>>>>>>
>>>>>>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>>>>>>> <anton.tarasov at oracle.com> wrote:
>>>>>>>> Hi Mikhail,
>>>>>>>>
>>>>>>>> Looks fine for me. Thanks! This was an old one... Do you have any
>>>>>>>> plans
>>>>>>>> to
>>>>>>>> fix it in 8/9 as well?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> Could you please review a simple fix of closed test, the test was
>>>>>>>>> moved
>>>>>>>>> to
>>>>>>>>> open repo
>>>>>>>>> and requestFocus was replaced requestFocusInWindow.
>>>>>>>>>
>>>>>>>>> Because "requestFocus" cause infinite war for focus between two
>>>>>>>>> windows,
>>>>>>>>> however this
>>>>>>>>> behavior is correct and doesn't violet spec.
>>>>>>>>>
>>>>>>>>> [TESTBUG]
>>>>>>>>> closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>>>>>>> fails intermittently
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Mikhail.
>>>>>>>>>


From alexandr.scherbatiy at oracle.com  Tue Nov 18 16:17:54 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 18 Nov 2014 19:17:54 +0300
Subject: <AWT Dev> [9] Review request for 8044444 The output's 'Page-n'
 footer does not show completely.
In-Reply-To: <54529B46.6040705@oracle.com>
References: <53C5104C.4020706@oracle.com> <544FF6A8.4090007@oracle.com>
	<54529B46.6040705@oracle.com>
Message-ID: <546B7132.8020405@oracle.com>



   Hi Phil,

     Before the 8011069 fix 
RasterPrinterJob.getPageFormatFromAttributes() method returns null for 
null attributes
  and native page size for ImageableArea has been used.
  After the 8011069 fix the attributes are not null and 
updateAttributesWithPageFormat() method rewrites
  the ImageableArea size to the default constants.

   The question is which ImageableArea size is correct?  If there should 
be used default values then the 8044444 is not an issue as all works as 
expected.
   If it is necessary to use native size then I can update the fix to do 
that.

   Thanks,
   Alexandr.


On 10/30/2014 11:10 PM, Phil Race wrote:
> When we reach this code everything in the job is already configured by a
> combination of initial settings and user updates and and we just need 
> to read
> the settings and pass it on to the native NSPrintInfo.
> So surely switching the order should not matter unless one of these
> is using the 'wrong' PageFormat ?
>
> -----------------
> the body of the method called here :-
>
> javaPrinterJobToNSPrintInfo(env, jthis, pageable, printInfo);
>
> gets its PageFormat as follows :-
>
>     static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob, 
> "getPageFormatFromAttributes", "()Ljava/awt/print/PageFormat;");
> ....
>
>     jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
> jm_getPageFormat);
>     if (page != NULL) {
>         javaPageFormatToNSPrintInfo(env, NULL, page, dst);
>     }
>
>
> So this uses the result of making a call to 
> RasterPrinterJob.getPageFormatFromAttributes()
>
>    protected PageFormat getPageFormatFromAttributes() {
>        if (attributes == null) {
>             return null;
>         }
>         return attributeToPageFormat(getPrintService(), this.attributes);
>    }
>
> -----------------------------
>
> whereas
>
> javaPageFormatToNSPrintInfo(env, jthis, page, printInfo);
>
> is using a PageFormat obtained as follows :-
>
>     static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob, 
> "getPageFormat", "(I)Ljava/awt/print/PageFormat;");
>
>     jobject page = JNFCallObjectMethod(env, jthis, jm_getPageFormat, 0);
>
> This is CPrinterJob.getPageFormat() { .. }
>
>
> Although its not easily apparent what the returned values are in each 
> of these cases
> it does seem they must be different.
>
> The latter one appears 'correct' in this case since applying it second
> fixes the output but I don't have enough information  to know why the
> values differ.
>
> Looking at the fix for 8011069, it avoided an NPE by always
> creating an 'attributes' map, albeit an empty one.
> This can change the result of calling getPageFormatFromAttributes from
> 'null' to a PageFormat built from an empty attribute set.
> If the no-args native printDialog() and the no-args print() call is 
> used this will be empty.
>
> So the method will indeed build - at that moment - a page format built 
> from
> default values.
>
> Now. If we *do* use the printDialog(PrintRequestAttributeSet) and
> print(PrintRequestAttributeSet) methods, then it may well be that this
> method is the one that should be called.
>
> And I think we were previously only in this block of code if that were 
> the case
> by virtue of the block being guarded by "if (page != NULL)", which means
> there is an attributeset, which previously meant one of those "with args"
> methods had been used.
>
> So I wonder/suspect if the switching of the order will introduce the 
> equivalent
> problem in that 'with args' case.
>
> As you can tell just looking at the webrev its nigh on impossible to tell
> for sure and you'd probably need to play around with testing changing
> paper size and orientation in native and cross-platform dialogs to 
> test it.
>
> You could start by seeing if the test 'passes' simply by switching to
> 'with args' before & after your fix - ensuring that the same paper sizes
> are being used. I am not sure what the default settings were that were
> created for the empty attribute set vs the ones that are used when you
> fixed this. You'll have to tell me that.
>
> Perhaps what is needed is a unified call to get the PageFormat which
> can figure out whether to use the attributes or not. And you could
> check if the call to CPrinterJob.getPageFormat() already performs that ..
>
> -phil.
>
>
> On 10/28/2014 01:03 PM, Alexander Scherbatiy wrote:
>>
>>  Hello,
>>
>>  Could you review the fix?
>>
>>  Thanks,
>>  Alexandr.
>>
>> On 7/15/2014 3:28 PM, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the fix:
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8044444
>>>   webrev: http://cr.openjdk.java.net/~alexsch/8044444/webrev.00
>>>
>>>   Native method printLoop from CPrinterJob calls 
>>> javaPrinterJobToNSPrintInfo(...) method after 
>>> javaPageFormatToNSPrintInfo(...).
>>>   Both methods set the page size. The initial page size is set in 
>>> defaultPage(PageFormat) method.
>>>   After the fix 8011069 the printDialog() initializes attributes 
>>> which leads that new page size is created in the 
>>> attributeToPageFormat(PrintService, PrintRequestAttributeSet) method.
>>>
>>>   The fix changes order of the javaPrinterJobToNSPrintInfo(...) 
>>> javaPageFormatToNSPrintInfo(...) call so initial page size is set at 
>>> the end.
>>>
>>>   There is the JCK test that covers the issue.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>
>


From alexander.v.stepanov at oracle.com  Wed Nov 19 09:14:28 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 19 Nov 2014 13:14:28 +0400
Subject: <AWT Dev> [9] Review Request for 8054143: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 6
In-Reply-To: <14675C19-7E6E-4976-9CFD-574CCC28AABE@oracle.com>
References: <5409B8B2.1010905@oracle.com> <5411B1CC.5050809@oracle.com>
	<54241371.7050103@oracle.com> <544E1D7A.3010100@oracle.com>
	<14675C19-7E6E-4976-9CFD-574CCC28AABE@oracle.com>
Message-ID: <546C5F74.5070105@oracle.com>

Hello Petr,

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8054143/webrev.01/

 > Here you end up calling getLocationOnScreen not on EDT
The checks using 'getLocationOnScreen' are on EDT now;

 > it's better to calculate the center
Fixed, but cannot use the center - there are some buttons there.

Thanks,
Alexander

On 10.11.2014 17:38, Petr Pchelko wrote:
> Hello, Alexander.
>
> test/java/awt/Modal/ToBack/ToBackDDFTest.java
> - setModal should be volatile or final
> - rightFrameOverlapsDialog: what's 7? why is it 7? I think it's better to calculate the center of the frame in case the size of window decorations will be changed in some OS version.
> line 146: Here you end up calling getLocationOnScreen not on EDT, however everywhere else you try to use EDT.
>
> test/java/awt/Modal/ToBack/ToBackDDFTest.java
> - same with setModal flag
> - same with getLocationOnScreen of EDT
>
> With best regards. Petr.
>
> On 27 ???. 2014 ?., at 14:24, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could please anyone review this old request?
>>
>> Thanks,
>> Alexander
>>
>> On 25.09.2014 17:06, alexander stepanov wrote:
>>> Just a reminder.
>>>
>>> Thanks,
>>> Alexander
>>>
>>> On 11.09.2014 18:29, alexander stepanov wrote:
>>>> Sorry, just a reminder.
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 05.09.2014 17:20, alexander stepanov wrote:
>>>>> Hello,
>>>>>
>>>>> Could you please review the fix for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8054143
>>>>>
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~avstepan/8054143/
>>>>>
>>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>
>>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Windows 7, Mac OS X 10.8.5.
>>>>>
>>>>> Thanks,
>>>>> Alexander


From petr.pchelko at oracle.com  Wed Nov 19 08:39:18 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 19 Nov 2014 12:39:18 +0400
Subject: <AWT Dev> [9] Review Request for 8054143: move awt automated
	tests from AWT_Modality to OpenJDK repository - part 6
In-Reply-To: <546C5F74.5070105@oracle.com>
References: <5409B8B2.1010905@oracle.com> <5411B1CC.5050809@oracle.com>
	<54241371.7050103@oracle.com> <544E1D7A.3010100@oracle.com>
	<14675C19-7E6E-4976-9CFD-574CCC28AABE@oracle.com>
	<546C5F74.5070105@oracle.com>
Message-ID: <B1A9B702-9B4A-4BC9-9ED8-3E30DA9AB2A4@oracle.com>

Hello, Alexander.

Looks good.

> > it's better to calculate the center
> Fixed, but cannot use the center - there are some buttons there.
It was just an example.

With best regards. Petr.

On 19 ????. 2014 ?., at 13:14, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:

> Hello Petr,
> 
> Please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8054143/webrev.01/
> 
> > Here you end up calling getLocationOnScreen not on EDT
> The checks using 'getLocationOnScreen' are on EDT now;
> 
> > it's better to calculate the center
> Fixed, but cannot use the center - there are some buttons there.
> 
> Thanks,
> Alexander
> 
> On 10.11.2014 17:38, Petr Pchelko wrote:
>> Hello, Alexander.
>> 
>> test/java/awt/Modal/ToBack/ToBackDDFTest.java
>> - setModal should be volatile or final
>> - rightFrameOverlapsDialog: what's 7? why is it 7? I think it's better to calculate the center of the frame in case the size of window decorations will be changed in some OS version.
>> line 146: Here you end up calling getLocationOnScreen not on EDT, however everywhere else you try to use EDT.
>> 
>> test/java/awt/Modal/ToBack/ToBackDDFTest.java
>> - same with setModal flag
>> - same with getLocationOnScreen of EDT
>> 
>> With best regards. Petr.
>> 
>> On 27 ???. 2014 ?., at 14:24, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Could please anyone review this old request?
>>> 
>>> Thanks,
>>> Alexander
>>> 
>>> On 25.09.2014 17:06, alexander stepanov wrote:
>>>> Just a reminder.
>>>> 
>>>> Thanks,
>>>> Alexander
>>>> 
>>>> On 11.09.2014 18:29, alexander stepanov wrote:
>>>>> Sorry, just a reminder.
>>>>> 
>>>>> Thanks,
>>>>> Alexander
>>>>> 
>>>>> On 05.09.2014 17:20, alexander stepanov wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Could you please review the fix for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054143
>>>>>> 
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~avstepan/8054143/
>>>>>> 
>>>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>> 
>>>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Windows 7, Mac OS X 10.8.5.
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexander
> 


From alexander.v.stepanov at oracle.com  Wed Nov 19 10:05:16 2014
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 19 Nov 2014 14:05:16 +0400
Subject: <AWT Dev> [9] Review Request for 8054143: move awt automated
 tests from AWT_Modality to OpenJDK repository - part 6
In-Reply-To: <B1A9B702-9B4A-4BC9-9ED8-3E30DA9AB2A4@oracle.com>
References: <5409B8B2.1010905@oracle.com> <5411B1CC.5050809@oracle.com>
	<54241371.7050103@oracle.com> <544E1D7A.3010100@oracle.com>
	<14675C19-7E6E-4976-9CFD-574CCC28AABE@oracle.com>
	<546C5F74.5070105@oracle.com>
	<B1A9B702-9B4A-4BC9-9ED8-3E30DA9AB2A4@oracle.com>
Message-ID: <546C6B5C.1060206@oracle.com>

Hello Petr,

Thanks!

Regards,
Alexander

On 19.11.2014 12:39, Petr Pchelko wrote:
> Hello, Alexander.
>
> Looks good.
>
>>> it's better to calculate the center
>> Fixed, but cannot use the center - there are some buttons there.
> It was just an example.
>
> With best regards. Petr.
>
> On 19 ????. 2014 ?., at 13:14, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>
>> Hello Petr,
>>
>> Please see the updated webrev:
>> http://cr.openjdk.java.net/~avstepan/8054143/webrev.01/
>>
>>> Here you end up calling getLocationOnScreen not on EDT
>> The checks using 'getLocationOnScreen' are on EDT now;
>>
>>> it's better to calculate the center
>> Fixed, but cannot use the center - there are some buttons there.
>>
>> Thanks,
>> Alexander
>>
>> On 10.11.2014 17:38, Petr Pchelko wrote:
>>> Hello, Alexander.
>>>
>>> test/java/awt/Modal/ToBack/ToBackDDFTest.java
>>> - setModal should be volatile or final
>>> - rightFrameOverlapsDialog: what's 7? why is it 7? I think it's better to calculate the center of the frame in case the size of window decorations will be changed in some OS version.
>>> line 146: Here you end up calling getLocationOnScreen not on EDT, however everywhere else you try to use EDT.
>>>
>>> test/java/awt/Modal/ToBack/ToBackDDFTest.java
>>> - same with setModal flag
>>> - same with getLocationOnScreen of EDT
>>>
>>> With best regards. Petr.
>>>
>>> On 27 ???. 2014 ?., at 14:24, alexander stepanov <alexander.v.stepanov at oracle.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Could please anyone review this old request?
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> On 25.09.2014 17:06, alexander stepanov wrote:
>>>>> Just a reminder.
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>>>
>>>>> On 11.09.2014 18:29, alexander stepanov wrote:
>>>>>> Sorry, just a reminder.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>>>
>>>>>> On 05.09.2014 17:20, alexander stepanov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you please review the fix for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054143
>>>>>>>
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~avstepan/8054143/
>>>>>>>
>>>>>>> This is the next portion of functional AWT tests prepared for migration to OpenJDK repository.
>>>>>>>
>>>>>>> The tests were checked on Ubuntu 14.04 Linux, Solaris 11, Windows 7, Mac OS X 10.8.5.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Alexander


From petr.pchelko at oracle.com  Wed Nov 19 11:19:22 2014
From: petr.pchelko at oracle.com (Petr Pchelko)
Date: Wed, 19 Nov 2014 15:19:22 +0400
Subject: <AWT Dev> [9] Review request: JDK-8058193 [macosx] Potential
	incomplete fix for JDK-8031485
Message-ID: <67A91C41-291A-40DC-8401-03E6D08221A4@oracle.com>

Hello, AWT Team.

Please review the fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8058193
The fix is available at:
http://cr.openjdk.java.net/~pchelko/9/8058193/webrev/

The problem is that we consume Enter key by a combo box action and it's not propagated up to the dialog.
Enter does not trigger any real action on the closed ComboBox, so it should be disabled if the combo popup
is not visible.

With best regards. Petr.

From Sergey.Bylokhov at oracle.com  Wed Nov 19 12:26:08 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Nov 2014 15:26:08 +0300
Subject: <AWT Dev> [9] Review request: JDK-8058193 [macosx] Potential
 incomplete fix for JDK-8031485
In-Reply-To: <67A91C41-291A-40DC-8401-03E6D08221A4@oracle.com>
References: <67A91C41-291A-40DC-8401-03E6D08221A4@oracle.com>
Message-ID: <546C8C60.8000209@oracle.com>

Hi, Petr.
The fix looks fine. But please update a @bug tag, test name and error 
message in the test as well before the push.

On 19.11.2014 14:19, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8058193
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8058193/webrev/
>
> The problem is that we consume Enter key by a combo box action and it's not propagated up to the dialog.
> Enter does not trigger any real action on the closed ComboBox, so it should be disabled if the combo popup
> is not visible.
>
> With best regards. Petr.


-- 
Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Wed Nov 19 13:26:15 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 19 Nov 2014 16:26:15 +0300
Subject: <AWT Dev> [9] Review request: JDK-8058193 [macosx] Potential
 incomplete fix for JDK-8031485
In-Reply-To: <67A91C41-291A-40DC-8401-03E6D08221A4@oracle.com>
References: <67A91C41-291A-40DC-8401-03E6D08221A4@oracle.com>
Message-ID: <546C9A77.4040303@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 11/19/2014 2:19 PM, Petr Pchelko wrote:
> Hello, AWT Team.
>
> Please review the fix for the issue:
> https://bugs.openjdk.java.net/browse/JDK-8058193
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/9/8058193/webrev/
>
> The problem is that we consume Enter key by a combo box action and it's not propagated up to the dialog.
> Enter does not trigger any real action on the closed ComboBox, so it should be disabled if the combo popup
> is not visible.
>
> With best regards. Petr.


From philip.race at oracle.com  Fri Nov 21 18:20:43 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 21 Nov 2014 10:20:43 -0800
Subject: <AWT Dev> [9] Review request for 8044444 The output's 'Page-n'
 footer does not show completely.
In-Reply-To: <546B7132.8020405@oracle.com>
References: <53C5104C.4020706@oracle.com> <544FF6A8.4090007@oracle.com>
	<54529B46.6040705@oracle.com> <546B7132.8020405@oracle.com>
Message-ID: <546F827B.5070306@oracle.com>

This seems to me to be asking about something I covered already.

 >The latter one appears 'correct' in this case since applying it second
 >fixes the output but I don't have enough information  to know why the
 >values differ.

But you have the test case and I don't ..

Did you try any of what I suggested ?

-phil.

On 11/18/14 8:17 AM, Alexander Scherbatiy wrote:
>
>
>   Hi Phil,
>
>     Before the 8011069 fix 
> RasterPrinterJob.getPageFormatFromAttributes() method returns null for 
> null attributes
>  and native page size for ImageableArea has been used.
>  After the 8011069 fix the attributes are not null and 
> updateAttributesWithPageFormat() method rewrites
>  the ImageableArea size to the default constants.
>
>   The question is which ImageableArea size is correct?  If there 
> should be used default values then the 8044444 is not an issue as all 
> works as expected.
>   If it is necessary to use native size then I can update the fix to 
> do that.
>
>   Thanks,
>   Alexandr.
>
>
> On 10/30/2014 11:10 PM, Phil Race wrote:
>> When we reach this code everything in the job is already configured by a
>> combination of initial settings and user updates and and we just need 
>> to read
>> the settings and pass it on to the native NSPrintInfo.
>> So surely switching the order should not matter unless one of these
>> is using the 'wrong' PageFormat ?
>>
>> -----------------
>> the body of the method called here :-
>>
>> javaPrinterJobToNSPrintInfo(env, jthis, pageable, printInfo);
>>
>> gets its PageFormat as follows :-
>>
>>     static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob, 
>> "getPageFormatFromAttributes", "()Ljava/awt/print/PageFormat;");
>> ....
>>
>>     jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
>> jm_getPageFormat);
>>     if (page != NULL) {
>>         javaPageFormatToNSPrintInfo(env, NULL, page, dst);
>>     }
>>
>>
>> So this uses the result of making a call to 
>> RasterPrinterJob.getPageFormatFromAttributes()
>>
>>    protected PageFormat getPageFormatFromAttributes() {
>>        if (attributes == null) {
>>             return null;
>>         }
>>         return attributeToPageFormat(getPrintService(), 
>> this.attributes);
>>    }
>>
>> -----------------------------
>>
>> whereas
>>
>> javaPageFormatToNSPrintInfo(env, jthis, page, printInfo);
>>
>> is using a PageFormat obtained as follows :-
>>
>>     static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob, 
>> "getPageFormat", "(I)Ljava/awt/print/PageFormat;");
>>
>>     jobject page = JNFCallObjectMethod(env, jthis, jm_getPageFormat, 0);
>>
>> This is CPrinterJob.getPageFormat() { .. }
>>
>>
>> Although its not easily apparent what the returned values are in each 
>> of these cases
>> it does seem they must be different.
>>
>> The latter one appears 'correct' in this case since applying it second
>> fixes the output but I don't have enough information  to know why the
>> values differ.
>>
>> Looking at the fix for 8011069, it avoided an NPE by always
>> creating an 'attributes' map, albeit an empty one.
>> This can change the result of calling getPageFormatFromAttributes from
>> 'null' to a PageFormat built from an empty attribute set.
>> If the no-args native printDialog() and the no-args print() call is 
>> used this will be empty.
>>
>> So the method will indeed build - at that moment - a page format 
>> built from
>> default values.
>>
>> Now. If we *do* use the printDialog(PrintRequestAttributeSet) and
>> print(PrintRequestAttributeSet) methods, then it may well be that this
>> method is the one that should be called.
>>
>> And I think we were previously only in this block of code if that 
>> were the case
>> by virtue of the block being guarded by "if (page != NULL)", which means
>> there is an attributeset, which previously meant one of those "with 
>> args"
>> methods had been used.
>>
>> So I wonder/suspect if the switching of the order will introduce the 
>> equivalent
>> problem in that 'with args' case.
>>
>> As you can tell just looking at the webrev its nigh on impossible to 
>> tell
>> for sure and you'd probably need to play around with testing changing
>> paper size and orientation in native and cross-platform dialogs to 
>> test it.
>>
>> You could start by seeing if the test 'passes' simply by switching to
>> 'with args' before & after your fix - ensuring that the same paper sizes
>> are being used. I am not sure what the default settings were that were
>> created for the empty attribute set vs the ones that are used when you
>> fixed this. You'll have to tell me that.
>>
>> Perhaps what is needed is a unified call to get the PageFormat which
>> can figure out whether to use the attributes or not. And you could
>> check if the call to CPrinterJob.getPageFormat() already performs 
>> that ..
>>
>> -phil.
>>
>>
>> On 10/28/2014 01:03 PM, Alexander Scherbatiy wrote:
>>>
>>>  Hello,
>>>
>>>  Could you review the fix?
>>>
>>>  Thanks,
>>>  Alexandr.
>>>
>>> On 7/15/2014 3:28 PM, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the fix:
>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8044444
>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8044444/webrev.00
>>>>
>>>>   Native method printLoop from CPrinterJob calls 
>>>> javaPrinterJobToNSPrintInfo(...) method after 
>>>> javaPageFormatToNSPrintInfo(...).
>>>>   Both methods set the page size. The initial page size is set in 
>>>> defaultPage(PageFormat) method.
>>>>   After the fix 8011069 the printDialog() initializes attributes 
>>>> which leads that new page size is created in the 
>>>> attributeToPageFormat(PrintService, PrintRequestAttributeSet) method.
>>>>
>>>>   The fix changes order of the javaPrinterJobToNSPrintInfo(...) 
>>>> javaPageFormatToNSPrintInfo(...) call so initial page size is set 
>>>> at the end.
>>>>
>>>>   There is the JCK test that covers the issue.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>
>>
>


From alexander.zvegintsev at oracle.com  Mon Nov 24 15:07:53 2014
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 24 Nov 2014 18:07:53 +0300
Subject: <AWT Dev> [9] Review reuest for 8036915: setLocationRelativeTo
 stopped working in Ubuntu 13.10 (Unity)
Message-ID: <547349C9.3040704@oracle.com>

Hello,

please review the fix
http://cr.openjdk.java.net/~azvegint/jdk/9/8036915/00/
for the issue
https://bugs.openjdk.java.net/browse/JDK-8036915

The sample in JBS issue reusing one window with setLocationRelativeTo.
This issues can be reproduced for a second and following re-appearance 
of the window,
it is shifted exactly by insets size.
This fix bypasses insets optimization for a first reparent notify event.

-- 
Thanks,

Alexander.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20141124/3df776a4/attachment.html>

From alexandr.scherbatiy at oracle.com  Tue Nov 25 12:34:44 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Tue, 25 Nov 2014 15:34:44 +0300
Subject: <AWT Dev> How to draw HiDPI image resources as BufferedImage?
In-Reply-To: <D9146F96-5931-401B-A0EF-3036BF5E2500@ultramixer.com>
References: <D9146F96-5931-401B-A0EF-3036BF5E2500@ultramixer.com>
Message-ID: <54747764.3060408@oracle.com>


   Hi Tobias,

   The public API that allows to do that is discussed on the following 
thread:
      JDK-8029339 Custom MultiResolution image support on HiDPI displays
http://mail.openjdk.java.net/pipermail/awt-dev/2014-August/008371.html

   Thanks,
   Alexandr.

On 11/25/2014 12:32 PM, Tobias Bley wrote:
> Hi,
>
> Loading and drawing an HiDPI image resource (@2x) works with JDK8 very good (Image image = Toolkit.getDefaultToolkit().getImage("/dir/image.ext?)). But how to load a HiDPI image and convert it to a HiDPI buffered image? Is it possible without creating a double sized BufferedImage and and than draw it via Graphics2D and scale 0.5?
>
> Best regards,
> Tobi
>


From jvanek at redhat.com  Wed Nov 26 17:41:47 2014
From: jvanek at redhat.com (Jiri Vanek)
Date: Wed, 26 Nov 2014 18:41:47 +0100
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <1414765858.3713.14.camel@nirvana.localdomain>
References: <5379FFBB.4050406@redhat.com> <537CBFEB.6070104@redhat.com>	
	<539EBA32.30502@redhat.com> <53A2F546.5080101@redhat.com>	
	<C708A811-E5F9-48AA-8B27-486B4684596A@oracle.com>	
	<5453947C.7010007@redhat.com>
	<1414765858.3713.14.camel@nirvana.localdomain>
Message-ID: <547610DB.5000901@redhat.com>

ping?

On 10/31/2014 03:30 PM, Mario Torre wrote:
> On Fri, 2014-10-31 at 14:54 +0100, Jiri Vanek wrote:
>> On 06/19/2014 04:46 PM, Petr Pchelko wrote:
>>> Hello, Jiri.
>>>
>>> Sorry for the delayed answer.
>>>   From the code point of view you current change looks OK to me. It's an internal package and we can change the access modifier easily.
>>>
>>> The more general question is what are you going to achieve by making this change?
>>> In JDK-9 we would have modules and you will not be able to use the sun.* packages at all, so this changeset is useless for JDK9.
>>> Do you want this to go to JDK8?
>>>
>>> In the original discussion there was a suggestion about providing a standard public interface for alternative plugins.
>>> This path looks more promising to me, because it will work in JDK9. Did any progress happen in that direction?
>>
>> hi guys!
>>
>> Do we need some JEP to make  this happen?
>
> Sorry, this one slipped off my radar.
>
> I think the general consensus here is that we need a JEP for JDK 9. I
> have no experience preparing one, but I was about to approach that for
> the look and feel idea, so I'll be happy to help.
>
> Perhaps something that will work with the new module system?
>
> We need some help from Oracle here, since there are other
> implementations of the plugins, getting to know your experience is quite
> important.
>
> Cheers,
> Mario
>
>


From philip.race at oracle.com  Wed Nov 26 18:21:39 2014
From: philip.race at oracle.com (Phil Race)
Date: Wed, 26 Nov 2014 10:21:39 -0800
Subject: <AWT Dev> Fwd: RFR: make life easier for general java plugin
In-Reply-To: <547610DB.5000901@redhat.com>
References: <5379FFBB.4050406@redhat.com>
	<537CBFEB.6070104@redhat.com>		<539EBA32.30502@redhat.com>
	<53A2F546.5080101@redhat.com>		<C708A811-E5F9-48AA-8B27-486B4684596A@oracle.com>		<5453947C.7010007@redhat.com>	<1414765858.3713.14.camel@nirvana.localdomain>
	<547610DB.5000901@redhat.com>
Message-ID: <54761A33.7090002@oracle.com>

What is the goal here ? Is it to allow icedtea-web to load an applet into
a JRE other than icedtea ?
If not and its all one bundle, you can patch the module system to
allow whatever access you need.

So what does icedtea-web need from such a standard interface ?

-phil.

On 11/26/2014 9:41 AM, Jiri Vanek wrote:
> ping?
>
> On 10/31/2014 03:30 PM, Mario Torre wrote:
>> On Fri, 2014-10-31 at 14:54 +0100, Jiri Vanek wrote:
>>> On 06/19/2014 04:46 PM, Petr Pchelko wrote:
>>>> Hello, Jiri.
>>>>
>>>> Sorry for the delayed answer.
>>>>   From the code point of view you current change looks OK to me. 
>>>> It's an internal package and we can change the access modifier easily.
>>>>
>>>> The more general question is what are you going to achieve by 
>>>> making this change?
>>>> In JDK-9 we would have modules and you will not be able to use the 
>>>> sun.* packages at all, so this changeset is useless for JDK9.
>>>> Do you want this to go to JDK8?
>>>>
>>>> In the original discussion there was a suggestion about providing a 
>>>> standard public interface for alternative plugins.
>>>> This path looks more promising to me, because it will work in JDK9. 
>>>> Did any progress happen in that direction?
>>>
>>> hi guys!
>>>
>>> Do we need some JEP to make  this happen?
>>
>> Sorry, this one slipped off my radar.
>>
>> I think the general consensus here is that we need a JEP for JDK 9. I
>> have no experience preparing one, but I was about to approach that for
>> the look and feel idea, so I'll be happy to help.
>>
>> Perhaps something that will work with the new module system?
>>
>> We need some help from Oracle here, since there are other
>> implementations of the plugins, getting to know your experience is quite
>> important.
>>
>> Cheers,
>> Mario
>>
>>
>


From alexandr.scherbatiy at oracle.com  Thu Nov 27 15:45:32 2014
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 27 Nov 2014 18:45:32 +0300
Subject: <AWT Dev> [9] Review request for 8044444 The output's 'Page-n'
 footer does not show completely.
In-Reply-To: <546F827B.5070306@oracle.com>
References: <53C5104C.4020706@oracle.com> <544FF6A8.4090007@oracle.com>
	<54529B46.6040705@oracle.com> <546B7132.8020405@oracle.com>
	<546F827B.5070306@oracle.com>
Message-ID: <5477471C.3090302@oracle.com>

On 11/21/2014 9:20 PM, Phil Race wrote:
> This seems to me to be asking about something I covered already.
>
> >The latter one appears 'correct' in this case since applying it second
> >fixes the output but I don't have enough information  to know why the
> >values differ.
>
> But you have the test case and I don't ..
>
> Did you try any of what I suggested ?

    The CPrinterJob.getPageFormat() returns right selected printer 
format. The problem is that RasterPrinterJob.attributeToPageFormat() 
method creates
    a default page with right page format and overrides page 
size/imageable area after that to predefined ones.
    This happens only because the CPrinterJob.printLoop() native method 
calls javaPrinterJobToNSPrintInfo(...) method after 
javaPageFormatToNSPrintInfo(...).

    The JCK has a set of JTable print tests. I run them using the 
predefined page size/imageable area and with the selected printer settings.
    The page number is properly printed when the selected printer 
settings are used.

    I have updated the fix to preserve the selected printer page size:
      http://cr.openjdk.java.net/~alexsch/8044444/webrev.01/

   Thanks,
   Alexandr.


>
> -phil.
>
> On 11/18/14 8:17 AM, Alexander Scherbatiy wrote:
>>
>>
>>   Hi Phil,
>>
>>     Before the 8011069 fix 
>> RasterPrinterJob.getPageFormatFromAttributes() method returns null 
>> for null attributes
>>  and native page size for ImageableArea has been used.
>>  After the 8011069 fix the attributes are not null and 
>> updateAttributesWithPageFormat() method rewrites
>>  the ImageableArea size to the default constants.
>>
>>   The question is which ImageableArea size is correct?  If there 
>> should be used default values then the 8044444 is not an issue as all 
>> works as expected.
>>   If it is necessary to use native size then I can update the fix to 
>> do that.
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>> On 10/30/2014 11:10 PM, Phil Race wrote:
>>> When we reach this code everything in the job is already configured 
>>> by a
>>> combination of initial settings and user updates and and we just 
>>> need to read
>>> the settings and pass it on to the native NSPrintInfo.
>>> So surely switching the order should not matter unless one of these
>>> is using the 'wrong' PageFormat ?
>>>
>>> -----------------
>>> the body of the method called here :-
>>>
>>> javaPrinterJobToNSPrintInfo(env, jthis, pageable, printInfo);
>>>
>>> gets its PageFormat as follows :-
>>>
>>>     static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob, 
>>> "getPageFormatFromAttributes", "()Ljava/awt/print/PageFormat;");
>>> ....
>>>
>>>     jobject page = JNFCallObjectMethod(env, srcPrinterJob, 
>>> jm_getPageFormat);
>>>     if (page != NULL) {
>>>         javaPageFormatToNSPrintInfo(env, NULL, page, dst);
>>>     }
>>>
>>>
>>> So this uses the result of making a call to 
>>> RasterPrinterJob.getPageFormatFromAttributes()
>>>
>>>    protected PageFormat getPageFormatFromAttributes() {
>>>        if (attributes == null) {
>>>             return null;
>>>         }
>>>         return attributeToPageFormat(getPrintService(), 
>>> this.attributes);
>>>    }
>>>
>>> -----------------------------
>>>
>>> whereas
>>>
>>> javaPageFormatToNSPrintInfo(env, jthis, page, printInfo);
>>>
>>> is using a PageFormat obtained as follows :-
>>>
>>>     static JNF_MEMBER_CACHE(jm_getPageFormat, sjc_CPrinterJob, 
>>> "getPageFormat", "(I)Ljava/awt/print/PageFormat;");
>>>
>>>     jobject page = JNFCallObjectMethod(env, jthis, jm_getPageFormat, 
>>> 0);
>>>
>>> This is CPrinterJob.getPageFormat() { .. }
>>>
>>>
>>> Although its not easily apparent what the returned values are in 
>>> each of these cases
>>> it does seem they must be different.
>>>
>>> The latter one appears 'correct' in this case since applying it second
>>> fixes the output but I don't have enough information  to know why the
>>> values differ.
>>>
>>> Looking at the fix for 8011069, it avoided an NPE by always
>>> creating an 'attributes' map, albeit an empty one.
>>> This can change the result of calling getPageFormatFromAttributes from
>>> 'null' to a PageFormat built from an empty attribute set.
>>> If the no-args native printDialog() and the no-args print() call is 
>>> used this will be empty.
>>>
>>> So the method will indeed build - at that moment - a page format 
>>> built from
>>> default values.
>>>
>>> Now. If we *do* use the printDialog(PrintRequestAttributeSet) and
>>> print(PrintRequestAttributeSet) methods, then it may well be that this
>>> method is the one that should be called.
>>>
>>> And I think we were previously only in this block of code if that 
>>> were the case
>>> by virtue of the block being guarded by "if (page != NULL)", which 
>>> means
>>> there is an attributeset, which previously meant one of those "with 
>>> args"
>>> methods had been used.
>>>
>>> So I wonder/suspect if the switching of the order will introduce the 
>>> equivalent
>>> problem in that 'with args' case.
>>>
>>> As you can tell just looking at the webrev its nigh on impossible to 
>>> tell
>>> for sure and you'd probably need to play around with testing changing
>>> paper size and orientation in native and cross-platform dialogs to 
>>> test it.
>>>
>>> You could start by seeing if the test 'passes' simply by switching to
>>> 'with args' before & after your fix - ensuring that the same paper 
>>> sizes
>>> are being used. I am not sure what the default settings were that were
>>> created for the empty attribute set vs the ones that are used when you
>>> fixed this. You'll have to tell me that.
>>>
>>> Perhaps what is needed is a unified call to get the PageFormat which
>>> can figure out whether to use the attributes or not. And you could
>>> check if the call to CPrinterJob.getPageFormat() already performs 
>>> that ..
>>>
>>> -phil.
>>>
>>>
>>> On 10/28/2014 01:03 PM, Alexander Scherbatiy wrote:
>>>>
>>>>  Hello,
>>>>
>>>>  Could you review the fix?
>>>>
>>>>  Thanks,
>>>>  Alexandr.
>>>>
>>>> On 7/15/2014 3:28 PM, Alexander Scherbatiy wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the fix:
>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8044444
>>>>>   webrev: http://cr.openjdk.java.net/~alexsch/8044444/webrev.00
>>>>>
>>>>>   Native method printLoop from CPrinterJob calls 
>>>>> javaPrinterJobToNSPrintInfo(...) method after 
>>>>> javaPageFormatToNSPrintInfo(...).
>>>>>   Both methods set the page size. The initial page size is set in 
>>>>> defaultPage(PageFormat) method.
>>>>>   After the fix 8011069 the printDialog() initializes attributes 
>>>>> which leads that new page size is created in the 
>>>>> attributeToPageFormat(PrintService, PrintRequestAttributeSet) method.
>>>>>
>>>>>   The fix changes order of the javaPrinterJobToNSPrintInfo(...) 
>>>>> javaPageFormatToNSPrintInfo(...) call so initial page size is set 
>>>>> at the end.
>>>>>
>>>>>   There is the JCK test that covers the issue.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>
>>>
>>
>


From mikhail.cherkasov at oracle.com  Fri Nov 28 16:09:03 2014
From: mikhail.cherkasov at oracle.com (mikhail cherkasov)
Date: Fri, 28 Nov 2014 19:09:03 +0300
Subject: <AWT Dev> [7] Review Request for 8047961: [TESTBUG]
 closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html fails
 intermittently
In-Reply-To: <546A0945.3000209@oracle.com>
References: <54661842.6050800@oracle.com>	<54660C84.606@oracle.com>	<CAK6==_kKODn+fkXmWQMNswgjO0875803Wu+S-rAh7CEC74RPFA@mail.gmail.com>	<5469D57A.9050606@oracle.com>	<CAK6==_=fX4CsGmA3n=zvLyx+LBvp1rMEZGNkVz7paj6zQXC+7A@mail.gmail.com>	<5469F96E.5060203@oracle.com>	<CAK6==_mKajuXLwMVyC8L3YGxsyj112-NwHOocu0zR1Cys0QLVw@mail.gmail.com>	<546A06B0.2070406@oracle.com>
	<CAK6==_mPfwoQmtRPA1BKtSSoEG-oLopt_Rrf6cHz+ws7j0e=Zg@mail.gmail.com>
	<546A0945.3000209@oracle.com>
Message-ID: <54789E1F.6000001@oracle.com>

Hi Anton, Oleg.

I vote for removing the test.

Rewriting test just will produce something weired that won't test what 
original regression does.
A new test won't be a regression test that check problem was found in 
jdk 1.4.
I believe jdk4 and 7 has a lot of difference in focus system and due 
those changes the test became
irrelevant.

Thanks,
Mikhail.

On 11/17/2014 5:42 PM, Anton V. Tarasov wrote:
> On 17.11.2014 17:38, Oleg Sukhodolsky wrote:
>> On Mon, Nov 17, 2014 at 5:31 PM, Anton V. Tarasov
>> <anton.tarasov at oracle.com> wrote:
>>> On 17.11.2014 17:21, Oleg Sukhodolsky wrote:
>>>> On Mon, Nov 17, 2014 at 4:34 PM, Anton V. Tarasov
>>>> <anton.tarasov at oracle.com> wrote:
>>>>> On 17.11.2014 15:01, Oleg Sukhodolsky wrote:
>>>>>> Hi Anton,
>>>>>>
>>>>>> the bug was a regression introduced in 1.4 (comparing with 1.3.1) 
>>>>>> this
>>>>>> is why it was fixed and the test was written.
>>>>>> Indeed the spec doesn't guarantee that the test will work but at the
>>>>>> time we were working on the ticket it was decided that we should not
>>>>>> allow such regressions.
>>>>>> If (according to the current policy) the spec is more important than
>>>>>> compatibility in this case I'd suggest to remove the test completely
>>>>>> since its new version doesn't test for the regression we had earlier
>>>>>> but just test spec in a very strange/complicated way.
>>>>>
>>>>> The test passes on Windows, but fails on Mac and I suppose Linux. I
>>>>> recall I
>>>>> made attemps to fix the failure on Linux (in 1.6 or 1.7) but that was
>>>>> quite
>>>>> complicated to make something reliable, due to the fact that in 
>>>>> XToolkit
>>>>> even native focus is asynchronous, like in CToolkit. So, from my 
>>>>> point of
>>>>> view hacking it doesn't worth the candles, taking into account all 
>>>>> I've
>>>>> said
>>>>> below.
>>>>>
>>>>> I still like the idea of  replacing requestFocus with
>>>>> requestFocusInWindow.
>>>>> We can add comments saying that the original test was modified to 
>>>>> avoid
>>>>> the
>>>>> endless loop. It didn't actually test for the endless loop, as 
>>>>> otherwise
>>>>> it
>>>>> would have had a timer. It tested for focus gains count per 
>>>>> window, that
>>>>> remains relevant even in its new form. That's my personal opinion, I
>>>>> won't
>>>>> insist on keeping it if you both vote for the opposite...
>>>> if you do not plan to fix the problem the test reproduces then I'd
>>>> vote for removing the test (you have enough tests in regression tests
>>>> suite ;)
>>>
>>> I'm afraid I don't, as I don't think this is a real problem :)
>> so just remove the test, you do not need it ;)
>
> No, I won't. I'd leave it at Mikhail's discretion, as he is the author 
> of the request.
>
> Mikhail, you have a chance to save the test :)
>
> Regards,
> Anton.
>
>>
>> Oleg.
>>> Regards,
>>> Anton.
>>>
>>>
>>>> Regards, Oleg.
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>>
>>>>>> So, it is you whole should make the final decision but I just do not
>>>>>> see a reason to keep a test which doesn't test for the particular
>>>>>> regression in regression tests suite.
>>>>>>
>>>>>> Regards, Oleg.
>>>>>>
>>>>>> On Mon, Nov 17, 2014 at 2:01 PM, Anton V. Tarasov
>>>>>> <anton.tarasov at oracle.com> wrote:
>>>>>>> Hi Oleg,
>>>>>>>
>>>>>>> Glad to hear from you :)
>>>>>>>
>>>>>>> On 14.11.2014 18:24, Oleg Sukhodolsky wrote:
>>>>>>>> Sorry to interrupt you but since I do know the test let me say 
>>>>>>>> that
>>>>>>>> requestFocus() is an important part of the test,
>>>>>>>> if you are going to replace it with requestFocusInWindow() you
>>>>>>>> (effectively) remove it from list of regression tests.
>>>>>>>> Please check 4369903 bug for more information.
>>>>>>>
>>>>>>> In the bug I see the description of why the infinite loop 
>>>>>>> happens and a
>>>>>>> suggestion to use requestFocusInWindow to prevent it. From my 
>>>>>>> point of
>>>>>>> view,
>>>>>>> the behavior is expected taking into account the asynchronous 
>>>>>>> nature of
>>>>>>> java
>>>>>>> focus.
>>>>>>>
>>>>>>> By default, when a toplevel window gains activation,
>>>>>>> KeyboardFocusManager
>>>>>>> requests focus in it by means of calling the requestFocusInWindow
>>>>>>> method.
>>>>>>> Thus, the test case creates an artificial situation with unclear 
>>>>>>> goals.
>>>>>>> It
>>>>>>> doesn't seem to reflect a real use case (I can see the bug was 
>>>>>>> filed by
>>>>>>> an
>>>>>>> internal engineer, not refering to any customer or user 
>>>>>>> application).
>>>>>>> In
>>>>>>> case a developer wants to alter the component receiving focus at 
>>>>>>> the
>>>>>>> toplevels's activation, he/she can achieve this by means of 
>>>>>>> customizing
>>>>>>> the
>>>>>>> focus traversal policy, for instance.
>>>>>>>
>>>>>>> The javadoc [1] for the JComponent.requestFocus method warns 
>>>>>>> developers
>>>>>>> about its usage:
>>>>>>>
>>>>>>> <<Note that the use of this method is discouraged because its 
>>>>>>> behavior
>>>>>>> is
>>>>>>> platform dependent. Instead we recommend the use of
>>>>>>> requestFocusInWindow().>>
>>>>>>>
>>>>>>> What I'm trying to say is that we'd rather avoid hacking the focus
>>>>>>> subsystem
>>>>>>> in order to just solve the infinite loop problem.
>>>>>>>
>>>>>>> However, originally the reporter of the bug complains about the
>>>>>>> following:
>>>>>>>
>>>>>>> <<Setting focus during window activation often sends focus to 
>>>>>>> the wrong
>>>>>>> place, or to multiple places.>>
>>>>>>>
>>>>>>> This behavior is incorrect, indeed. But we can verify it with 
>>>>>>> the test
>>>>>>> case.
>>>>>>> When a component gains focus we can check that:
>>>>>>>
>>>>>>> 1. it is the current focus owner reported by KFM, and the current
>>>>>>> focused
>>>>>>> window is its container
>>>>>>> 2. the opposite component has lost focus prior to that (that is, 
>>>>>>> every
>>>>>>> FOCUS_GAINED precedes a FOCUS_LOST received by the opposite 
>>>>>>> component)
>>>>>>> 3. the same about the WINDOW_LOST_FOCUS/WINDOW_GAINED_FOCUS pair
>>>>>>>
>>>>>>> The test should be ready for the infinite loop and I can suggest to
>>>>>>> simply
>>>>>>> stop requesting focus after a couple of iterations.
>>>>>>>
>>>>>>> This could be a compromize. What do you think, Oleg, Mikhail?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>>>> https://docs.oracle.com/javase/8/docs/api/javax/swing/JComponent.html#requestFocus-- 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Regards, Oleg.
>>>>>>>>
>>>>>>>> P.S. feel free to ask more questions if you need.
>>>>>>>>
>>>>>>>> On Fri, Nov 14, 2014 at 5:07 PM, Anton V. Tarasov
>>>>>>>> <anton.tarasov at oracle.com> wrote:
>>>>>>>>> Hi Mikhail,
>>>>>>>>>
>>>>>>>>> Looks fine for me. Thanks! This was an old one... Do you have any
>>>>>>>>> plans
>>>>>>>>> to
>>>>>>>>> fix it in 8/9 as well?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Anton.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 14.11.2014 18:57, mikhail cherkasov wrote:
>>>>>>>>>> Hello all,
>>>>>>>>>>
>>>>>>>>>> Could you please review a simple fix of closed test, the test 
>>>>>>>>>> was
>>>>>>>>>> moved
>>>>>>>>>> to
>>>>>>>>>> open repo
>>>>>>>>>> and requestFocus was replaced requestFocusInWindow.
>>>>>>>>>>
>>>>>>>>>> Because "requestFocus" cause infinite war for focus between two
>>>>>>>>>> windows,
>>>>>>>>>> however this
>>>>>>>>>> behavior is correct and doesn't violet spec.
>>>>>>>>>>
>>>>>>>>>> [TESTBUG]
>>>>>>>>>> closed/java/awt/Focus/ActivateFocusTest/ActivateFocusTest.html
>>>>>>>>>> fails intermittently
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8047961
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~mcherkas/8047961/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mikhail.
>>>>>>>>>>
>