[13] RFR JDK-8218599 : Add test group jdk_client_sanity under jdk_desktop group
Hi All, Please review fix for the task: Task: https://bugs.openjdk.java.net/browse/JDK-8218599 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8218599/webrev.00/ Just adding the test group jdk_client_sanity under jdk_desktop group. Regards, Muneer
[13] RFR JDK-8214471 : Enable different look and feel tests in SwingSet3 demo test ToolTipDemoTest
Hi All, Please review fix for the task: Task: https://bugs.openjdk.java.net/browse/JDK-8214471 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8214471/webrev/ Tested this on windows, linux and osx platforms in 1000 iterations, on SBR(Same Binary Run) setup, and passed without any failures. Regards, Muneer
Re: [12] RFR [JDK-8213168] Enable different look and feel tests in SwingSet3 demo test FileChooserDemoTest
Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Wednesday, October 31, 2018 10:40 AM To: swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: [12] RFR [JDK-8213168] Enable different look and feel tests in SwingSet3 demo test FileChooserDemoTest Hi All, Please review fix for the task: Task: https://bugs.openjdk.java.net/browse/JDK-8213168 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8213168/webrev.00/ Changes in jemmy file JFileChooserOperator is already checked in jemmy repo by task http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/93cfbd0e4d48 . Description of fixes: There are multiple issues in different L GTK and Motif L: 1) There are two JLists according JDK implementation, one is to list folders and second one one is to list files, but current jemmy JFileChooserOperator implementation didn't consider this, it expects only one JList that is to list files. 2) Open button text is "OK", not "OPEN" Aqua, GTK and Motif L: 1) GO Home, Up Level button, List and Details view functionalities are not available. Windows & Windows Classic L: 1) There is no 'Go Home' button, but there is a toggle button to go desktop. In Windows platform 'Go Home' button usually(In metal and nimbus L) navigates to Desktop only. 2) List and Details views are implemented as a popup menu item in JDK, not toggle buttons. Regards, Muneer
[12] RFR [JDK-8213168] Enable different look and feel tests in SwingSet3 demo test FileChooserDemoTest
Hi All, Please review fix for the task: Task: https://bugs.openjdk.java.net/browse/JDK-8213168 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8213168/webrev.00/ Changes in jemmy file JFileChooserOperator is already checked in jemmy repo by task http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/93cfbd0e4d48 . Description of fixes: There are multiple issues in different L GTK and Motif L: 1) There are two JLists according JDK implementation, one is to list folders and second one one is to list files, but current jemmy JFileChooserOperator implementation didn't consider this, it expects only one JList that is to list files. 2) Open button text is "OK", not "OPEN" Aqua, GTK and Motif L: 1) GO Home, Up Level button, List and Details view functionalities are not available. Windows & Windows Classic L: 1) There is no 'Go Home' button, but there is a toggle button to go desktop. In Windows platform 'Go Home' button usually(In metal and nimbus L) navigates to Desktop only. 2) List and Details views are implemented as a popup menu item in JDK, not toggle buttons. Regards, Muneer
Re: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame
Hi Prasanta,
I tested with provided binary and issue is resolved with this fix. Thanks for
fixing this issue.
Regards,
Muneer
-Original Message-
From: Muneer Kolarkunnu
Sent: Wednesday, October 24, 2018 12:00 PM
To: Prasanta Sadhukhan ; Sergey Bylokhov
; swing-dev@openjdk.java.net
Subject: Re: [12] RFR JDK-8211703: JInternalFrame :
java.lang.AssertionError: cannot find the internal frame
Hi Prasanta,
I can verify it if you can share a binary with fix.
Regards,
Muneer
-Original Message-
From: Prasanta Sadhukhan
Sent: Wednesday, October 24, 2018 11:41 AM
To: Sergey Bylokhov ; swing-dev@openjdk.java.net;
ABDUL.KOLARKUNNU
Subject: Re: [12] RFR JDK-8211703: JInternalFrame :
java.lang.AssertionError: cannot find the internal frame
Hi Muneer,
Could you check (as a submitter) if the proposed fix works in your jemmy
environment? It seems to work for me with the command line you gave in JBS.
Regards
Prasanta
On 22-Oct-18 11:24 AM, Prasanta Sadhukhan wrote:
> Gentle reminder...
>
> Regards
> Prasanta
> On 05-Oct-18 2:31 PM, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>>
>> On 04-Oct-18 11:03 PM, Prasanta Sadhukhan wrote:
>>>
>>>
>>> On 04-Oct-18 10:44 PM, Prasanta Sadhukhan wrote:
>>>>
>>>>
>>>> On 04-Oct-18 10:29 PM, Sergey Bylokhov wrote:
>>>>> On 04/10/2018 09:44, Prasanta Sadhukhan wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Yes, this method should return JInternalFrame but there is no way
>>>>>> to get JinternalFrame object from BasicInternalFrameTitlePane
>>>>>> currently.
>>>>>
>>>>> But why it is not possible? The BasicInternalFrameTitlePane is a
>>>>> title of the internalFrame and it looks like it should be located
>>>>> somewhere inside the internalFrame, isn't it?
>>>>>
>>>> BasicInternalTitlePane has a protected variable of JInternalFrame
>>>> object and there is no public method to access that so that's why I
>>>> told it is not currently possible unless we add a public method in
>>>> this Basic* class, if I understand it correctly. Let me know if it
>>>> can be accessed some other way.
>>>>
>>> JInternalFrame.getUI().getNorthPane() probably might give
>>> BasicInternalTitlePane object but I do not think we can get
>>> viceversa, ie get JInternalFrame object from BasicInternalTitlePane.
>> I have improved the code to get JInternalFrame from
>> BasicInternalFrameTitlePane, as you have suggested
>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/
>>
>> Regards
>> Prasanta
>>>> Regards
>>>> Prasanta
>>>>> This Metacity class has the provision of accepting null value from
>>>>> this method
>>>>>> and this assertion problem is caused only when we ran with "esa"
>>>>>> [to enable assertion]. The submitter has not mentioned there is
>>>>>> any failure if we run the without esa, so I have only done away
>>>>>> with the wrong assertion for BasicInternalFrameTitlePane.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 04-Oct-18 9:43 PM, Sergey Bylokhov wrote:
>>>>>>> Hi, Prasanta.
>>>>>>> Can you please clarify this code a little bit. As far as I
>>>>>>> understand this method should return the JInternalFrame, which
>>>>>>> should be accessed via the comp passed to this method. This
>>>>>>> method already has this check:
>>>>>>> if (comp.getParent() instanceof
>>>>>>> BasicInternalFrameTitlePane) {
>>>>>>> comp = comp.getParent();
>>>>>>> }
>>>>>>>
>>>>>>> So maybe we can improve it to fetch the JInternalFrame from the
>>>>>>> BasicInternalFrameTitlePane or from another class passed to this
>>>>>>> method?
>>>>>>>
>>>>>>> On 04/10/2018 07:35, Prasanta Sadhukhan wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Please review a cleanup of the code where wrong assertion is
>>>>>>>> used when Component is an instance of BasicInternalFrameTitlePane.
>>>>>>>>
>>>>>>>> Now, BasicInternalFrameTitlePane is extended from JComponent
>>>>>>>> and not from J
Re: [12] RFR JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame
Hi Prasanta,
I can verify it if you can share a binary with fix.
Regards,
Muneer
-Original Message-
From: Prasanta Sadhukhan
Sent: Wednesday, October 24, 2018 11:41 AM
To: Sergey Bylokhov ; swing-dev@openjdk.java.net;
ABDUL.KOLARKUNNU
Subject: Re: [12] RFR JDK-8211703: JInternalFrame :
java.lang.AssertionError: cannot find the internal frame
Hi Muneer,
Could you check (as a submitter) if the proposed fix works in your jemmy
environment? It seems to work for me with the command line you gave in JBS.
Regards
Prasanta
On 22-Oct-18 11:24 AM, Prasanta Sadhukhan wrote:
> Gentle reminder...
>
> Regards
> Prasanta
> On 05-Oct-18 2:31 PM, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>>
>> On 04-Oct-18 11:03 PM, Prasanta Sadhukhan wrote:
>>>
>>>
>>> On 04-Oct-18 10:44 PM, Prasanta Sadhukhan wrote:
On 04-Oct-18 10:29 PM, Sergey Bylokhov wrote:
> On 04/10/2018 09:44, Prasanta Sadhukhan wrote:
>> Hi Sergey,
>>
>> Yes, this method should return JInternalFrame but there is no way
>> to get JinternalFrame object from BasicInternalFrameTitlePane
>> currently.
>
> But why it is not possible? The BasicInternalFrameTitlePane is a
> title of the internalFrame and it looks like it should be located
> somewhere inside the internalFrame, isn't it?
>
BasicInternalTitlePane has a protected variable of JInternalFrame
object and there is no public method to access that so that's why I
told it is not currently possible unless we add a public method in
this Basic* class, if I understand it correctly. Let me know if it
can be accessed some other way.
>>> JInternalFrame.getUI().getNorthPane() probably might give
>>> BasicInternalTitlePane object but I do not think we can get
>>> viceversa, ie get JInternalFrame object from BasicInternalTitlePane.
>> I have improved the code to get JInternalFrame from
>> BasicInternalFrameTitlePane, as you have suggested
>> http://cr.openjdk.java.net/~psadhukhan/8211703/webrev.1/
>>
>> Regards
>> Prasanta
Regards
Prasanta
> This Metacity class has the provision of accepting null value from
> this method
>> and this assertion problem is caused only when we ran with "esa"
>> [to enable assertion]. The submitter has not mentioned there is
>> any failure if we run the without esa, so I have only done away
>> with the wrong assertion for BasicInternalFrameTitlePane.
>>
>> Regards
>> Prasanta
>> On 04-Oct-18 9:43 PM, Sergey Bylokhov wrote:
>>> Hi, Prasanta.
>>> Can you please clarify this code a little bit. As far as I
>>> understand this method should return the JInternalFrame, which
>>> should be accessed via the comp passed to this method. This
>>> method already has this check:
>>> if (comp.getParent() instanceof
>>> BasicInternalFrameTitlePane) {
>>> comp = comp.getParent();
>>> }
>>>
>>> So maybe we can improve it to fetch the JInternalFrame from the
>>> BasicInternalFrameTitlePane or from another class passed to this
>>> method?
>>>
>>> On 04/10/2018 07:35, Prasanta Sadhukhan wrote:
Hi All,
Please review a cleanup of the code where wrong assertion is
used when Component is an instance of BasicInternalFrameTitlePane.
Now, BasicInternalFrameTitlePane is extended from JComponent
and not from JInternalFrame so it will never satisfy the
if-else condition if "Component is instanceof
BasicInternalFrameTitlePane", so proposed fix is to assert only
if the component is not an instance of
BasicInternalFrameTitlePane
diff -r d96a607e9594
src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Meta
city.java
---
a/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me
tacity.java
Tue Sep 18 18:32:03 2018 -0700
+++
b/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/Me
tacity.java
Thu Oct 04 19:53:10 2018 +0530
@@ -337,7 +337,9 @@
} else if (comp instanceof
JInternalFrame.JDesktopIcon) {
return
((JInternalFrame.JDesktopIcon)comp).getInternalFrame();
}
- assert false : "cannot find the internal frame";
+ if (!(comp instanceof BasicInternalFrameTitlePane)) {
+ assert false : "cannot find the internal frame";
+ }
return null;
}
Regards
Prasanta
>>>
>>>
>>
>
>
>>>
>>
>
[12] RFR [JDK-8212897] Some improvements in the EditorPaneDemotest
Hi All, Please review fix for the task: Task: https://bugs.openjdk.java.net/browse/JDK-8212897 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8212897/webrev.00/ Description: 1) In Nimbus L, background color is not white, but in the JEditorPane, always it will be white background if image is not available. So changing the pixel color check to white instead of background color. 2) Adding assertNotBlack check for captured image, otherwise test will pass if whole image is black. Regards, Muneer
[12] RFR [JDK-8211139] Increase timeout value in all tests under jdk/sanity/client/SwingSet/src
Hi All, Please review fix for the below task: Bug: https://bugs.openjdk.java.net/browse/JDK-8211139 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8211139/webrev.00/ Description: We updated most of the tests under jdk/sanity/client/SwingSet/src to run on multiple look and feel by task HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8210052"JDK-8210052. But didn't update the jtreg timeout value. Now these tests will execute in maximum 5 L(in Windows), so we have to multiply the default timeout by 5. Also we capture screenshots if there is any failures, now we save these images in same name if there is failures from multiple L and it get over written by second failure. So we have to screenshots in different name for each L Regards, Muneer
Re: [12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo
Hi Sergey, I added image validation, basically it captures image screen shot and checking some 10 pixels from inner area of the image are not default background color. New webrev : http://cr.openjdk.java.net/~akolarkunnu/8209499/webrev.01/ Regards, Muneer -Original Message- From: Alexandre (Shura) Iline Sent: Thursday, August 30, 2018 10:45 PM To: Sergey Bylokhov Cc: Muneer Kolarkunnu ; swing-dev@openjdk.java.net Subject: Re: [12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo Thank you - makes sense now. > On Aug 30, 2018, at 10:10 AM, Sergey Bylokhov > wrote: > > Hi, Alexandr. > I assume that one of the purpose of the test is to check that the html > (including images) are correctly loaded to the EditorPane and present it to > the user. > If there are some issues like > - absent of the image files > - errors in the file system > - bugs in EditorPane, etc > which prevent the correct representation of the text in EditorPane, then the > test should fail. But the test passed when I applied the patch without images. > > On 30/08/2018 09:38, Alexandre (Shura) Iline wrote: >> I am trying to understand the use case. >> The images would be checked in with the rest of the code and thus, normally, >> the images will be available. >> Are you anticipating a scenario when the images would not be present with >> the rest of the code? >> — or — >> Do you want to add a test to check that the images are not actually >> displayed on screen? >> Shura >>> >>> On 19/08/2018 22:05, Muneer Kolarkunnu wrote: >>>> Gentle Reminder. >>>> Regards, >>>> Muneer >>>> *From:*Muneer Kolarkunnu >>>> *Sent:* Tuesday, August 14, 2018 10:35 PM >>>> *To:* swing-dev@openjdk.java.net >>>> *Subject:* [12] RFR [TEST][JDK-8209499] Create test for >>>> SwingSet3 EditorPaneDemo Hi All, Please review the following, a new >>>> client sanity test case: >>>> Task: https://bugs.openjdk.java.net/browse/JDK-8209499 >>>> Webrev >>>> Link:http://cr.openjdk.java.net/~akolarkunnu/8209499/webrev.00/ >>>> <http://cr.openjdk.java.net/%7Eakolarkunnu/8209499/webrev.00/> >>>> Summary: This is a new test to automate testing of SwingSet3 >>>> EditorPaneDemo. >>>> Please see the bug description for the scenarios automated. >>>> test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java – This is the >>>> real test code, all other files are copied from swingset3 demo. >>>> Regards, >>>> Muneer >>> >>> >>> -- >>> Best regards, Sergey. > > > -- > Best regards, Sergey.
Re: [12] RFR [JDK-8211160] Handle different look and feels in JInternalFrameOperator
Yes, it is for JDK12. Typo. Regards, Muneer -Original Message- From: Sergey Bylokhov Sent: Tuesday, October 02, 2018 4:27 AM To: Muneer Kolarkunnu ; swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: Re: [11] RFR [JDK-8211160] Handle different look and feels in JInternalFrameOperator Looks fine, I assume that the fix is for jdk12 not jdk11. On 01/10/2018 01:28, Muneer Kolarkunnu wrote: > Gentle Reminder. > > Regards, > > Muneer > > *From:* Muneer Kolarkunnu > *Sent:* Thursday, September 27, 2018 6:37 AM > *To:* swing-dev@openjdk.java.net > *Cc:* Aleksandre Iline > *Subject:* [11] RFR [JDK-8211160] Handle different look > and feels in JInternalFrameOperator > > Hi All, > > Please review fix for a bug in jemmy: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211160 > > Webrev: http://cr.openjdk.java.net/~akolarkunnu/8211160/webrev.00/ > <http://cr.openjdk.java.net/%7Eakolarkunnu/8211160/webrev.00/> > > This fix is a copy of fix made in the Jemmy code-tools repository. > > http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/00c9f753cd0a > > Description: > > There are multiple issues in JInternalFrameOperator w.r.t multiple L > > In Motif L: > > JInternalFrame doesn't has tooltip text for minimize and maximize buttons. > > It doesn't have the close button. > > Reference: com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane > > So these different actions implemented using motif system menus: > InternalFramePopupMenuDriver.java. > > In Nimbus, Motif and Windows Classic L: > > We have to press two times on desktop icon to restore it to previous state. > > GTK L: > > There is a deadlock issue - Changes in API > org.netbeans.jemmy.operators.JInternalFrameOperator.JDesktopIconOperat > or.getInternalFrame() > s to handle this issue. > > There is a ClassCastException while invoking some constructors - > Changes in two constructors to handle this issue. > > Regards, > > Muneer > -- Best regards, Sergey.
Re: [11] RFR [JDK-8211160] Handle different look and feels in JInternalFrameOperator
Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Thursday, September 27, 2018 6:37 AM To: swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: [11] RFR [JDK-8211160] Handle different look and feels in JInternalFrameOperator Hi All, Please review fix for a bug in jemmy: Bug: https://bugs.openjdk.java.net/browse/JDK-8211160 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8211160/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/00c9f753cd0a Description: There are multiple issues in JInternalFrameOperator w.r.t multiple L In Motif L: JInternalFrame doesn't has tooltip text for minimize and maximize buttons. It doesn't have the close button. Reference: com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane So these different actions implemented using motif system menus: InternalFramePopupMenuDriver.java. In Nimbus, Motif and Windows Classic L: We have to press two times on desktop icon to restore it to previous state. GTK L: There is a deadlock issue - Changes in API org.netbeans.jemmy.operators.JInternalFrameOperator.JDesktopIconOperator.getInternalFrame() s to handle this issue. There is a ClassCastException while invoking some constructors - Changes in two constructors to handle this issue. Regards, Muneer
[11] RFR [JDK-8211160] Handle different look and feels in JInternalFrameOperator
Hi All, Please review fix for a bug in jemmy: Bug: https://bugs.openjdk.java.net/browse/JDK-8211160 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8211160/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/00c9f753cd0a Description: There are multiple issues in JInternalFrameOperator w.r.t multiple L In Motif L: JInternalFrame doesn't has tooltip text for minimize and maximize buttons. It doesn't have the close button. Reference: com.sun.java.swing.plaf.motif.MotifInternalFrameTitlePane So these different actions implemented using motif system menus: InternalFramePopupMenuDriver.java. In Nimbus, Motif and Windows Classic L: We have to press two times on desktop icon to restore it to previous state. GTK L: There is a deadlock issue - Changes in API org.netbeans.jemmy.operators.JInternalFrameOperator.JDesktopIconOperator.getInternalFrame() s to handle this issue. There is a ClassCastException while invoking some constructors - Changes in two constructors to handle this issue. Regards, Muneer
Re: [12] RFR [TEST][JDK-8210055] Enable different look and feel tests in SwingSet3 demo tests
Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Tuesday, September 18, 2018 3:08 PM To: Sergey Bylokhov ; swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: Re: [12] RFR [TEST][JDK-8210055] Enable different look and feel tests in SwingSet3 demo tests Hi Sergey, Hi Sergey, Thanks for feedback. Before applying the patch: That is the expected behavior. In SwingSet2 demo, we have a checkbox menu item to enable/disable tool tips.(Options->Enable Tool Tips). I used this feature to test the swing component JCheckBoxMenuItem. So after disabling tooltip, it keeps mouse pointer on thumbnail and make sure it doesn't show tooltip. It will wait for a minute(jemmy default timeout duration). After applying the patch: Default timeout for a jtreg test is 120 seconds, obviously it will take more time than this default timeout to complete test on four or five look and feels. In my local and SBR tests, I was giving timeoutFactor as 8 on jtreg command. That's why I didn't see this timeout issue. So I updated the test run command with timeout=600 seconds [5(max number of L)*120]. New webrev: http://cr.openjdk.java.net/~akolarkunnu/8210055/webrev.01/ Regards, Muneer -Original Message- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:12 AM To: Muneer Kolarkunnu mailto:abdul.kolarku...@oracle.com"abdul.kolarku...@oracle.com>; HYPERLINK "mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net Cc: Aleksandre Iline mailto:alexandre.il...@oracle.com"alexandre.il...@oracle.com> Subject: Re: [12] RFR [TEST][JDK-8210055] Enable different look and feel tests in SwingSet3 demo tests Hi, Muneer. Can you please take a look to this test: open/test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java On macOS before the fix, this test shown the frame for long period of time without any actions and then completes w/o errors. After the fix it fails because of timeout. On 16/09/2018 22:46, Muneer Kolarkunnu wrote: > Hi All, > > Please review the fix to add support for testing for all the available > look and feels for the DialogDemoTest,WindowDemoTest and SwingSet2DemoTest. > > Task: https://bugs.openjdk.java.net/browse/JDK-8210055 > > Webrev Link:http://cr.openjdk.java.net/~akolarkunnu/8210055/webrev.00/ > <http://cr.openjdk.java.net/%7Eakolarkunnu/8210055/webrev.00/> > > Summary: We use "availableLookAndFeels" dataProvider from TestHelpers > class to run the test iteratively using all the available look and feels. > > But there were some issues while running these tests directly on > different look and feels. > > Issues: > > SwingSet2DemoTest: In SwingSet 2 application, it was creating some > menus only once, because of that removed check in the review. For > different look and feel tests it will be loading application multiple > times, but some menus were not getting created. > DialogDemoTest and WindowDemoTest: Added isShown() check to get exact > active Window for each look and feel test. > > Please see the bug description for the exception stack traces. > > Regards, > > Muneer > -- Best regards, Sergey.
[12] RFR [TEST][JDK-8210994] Create test for SwingSet3 FrameDemo
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8210994 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8210994/webrev.00/ Summary: This is a new test to automate testing of SwingSet3 FrameDemo. Please see the bug description for the scenarios automated. test/jdk/sanity/client/SwingSet/src/FrameDemoTest.java - This is the real test code. test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/FrameDemo.java & test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/frame/BusyGlass.java are copied from SwingSet3 demo. I reported a bug https://bugs.openjdk.java.net/browse/JDK-8210638 during this test developement, it looks like a product bug. So as of now I used 2 seconds delay between frame state changes as a workaround. Regards, Muneer
Re: [12] RFR [TEST][JDK-8210055] Enable different look and feel tests in SwingSet3 demo tests
Hi Sergey, Hi Sergey, Thanks for feedback. Before applying the patch: That is the expected behavior. In SwingSet2 demo, we have a checkbox menu item to enable/disable tool tips.(Options->Enable Tool Tips). I used this feature to test the swing component JCheckBoxMenuItem. So after disabling tooltip, it keeps mouse pointer on thumbnail and make sure it doesn't show tooltip. It will wait for a minute(jemmy default timeout duration). After applying the patch: Default timeout for a jtreg test is 120 seconds, obviously it will take more time than this default timeout to complete test on four or five look and feels. In my local and SBR tests, I was giving timeoutFactor as 8 on jtreg command. That's why I didn't see this timeout issue. So I updated the test run command with timeout=600 seconds [5(max number of L)*120]. New webrev: http://cr.openjdk.java.net/~akolarkunnu/8210055/webrev.01/ Regards, Muneer -Original Message- From: Sergey Bylokhov Sent: Tuesday, September 18, 2018 3:12 AM To: Muneer Kolarkunnu ; swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: Re: [12] RFR [TEST][JDK-8210055] Enable different look and feel tests in SwingSet3 demo tests Hi, Muneer. Can you please take a look to this test: open/test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java On macOS before the fix, this test shown the frame for long period of time without any actions and then completes w/o errors. After the fix it fails because of timeout. On 16/09/2018 22:46, Muneer Kolarkunnu wrote: > Hi All, > > Please review the fix to add support for testing for all the available > look and feels for the DialogDemoTest,WindowDemoTest and SwingSet2DemoTest. > > Task: https://bugs.openjdk.java.net/browse/JDK-8210055 > > Webrev Link:http://cr.openjdk.java.net/~akolarkunnu/8210055/webrev.00/ > <http://cr.openjdk.java.net/%7Eakolarkunnu/8210055/webrev.00/> > > Summary: We use "availableLookAndFeels" dataProvider from TestHelpers > class to run the test iteratively using all the available look and feels. > > But there were some issues while running these tests directly on > different look and feels. > > Issues: > > SwingSet2DemoTest: In SwingSet 2 application, it was creating some > menus only once, because of that removed check in the review. For > different look and feel tests it will be loading application multiple > times, but some menus were not getting created. > DialogDemoTest and WindowDemoTest: Added isShown() check to get exact > active Window for each look and feel test. > > Please see the bug description for the exception stack traces. > > Regards, > > Muneer > -- Best regards, Sergey.
[12] RFR [TEST][JDK-8210055] Enable different look and feel tests in SwingSet3 demo tests
Hi All, Please review the fix to add support for testing for all the available look and feels for the DialogDemoTest,WindowDemoTest and SwingSet2DemoTest. Task: https://bugs.openjdk.java.net/browse/JDK-8210055 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8210055/webrev.00/ Summary: We use "availableLookAndFeels" dataProvider from TestHelpers class to run the test iteratively using all the available look and feels. But there were some issues while running these tests directly on different look and feels. Issues: SwingSet2DemoTest: In SwingSet 2 application, it was creating some menus only once, because of that removed check in the review. For different look and feel tests it will be loading application multiple times, but some menus were not getting created. DialogDemoTest and WindowDemoTest: Added isShown() check to get exact active Window for each look and feel test. Please see the bug description for the exception stack traces. Regards, Muneer
[12] RFR [TEST][JDK-8210056] Enable different look and feel tests in SwingSet3 demo test TextFieldDemoTest
Hi All, Please review the fix to add support for testing for all the available look and feels for the TextFieldDemoTest. Task: https://bugs.openjdk.java.net/browse/JDK-8210056 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8210056/webrev.00/ Summary: We use "availableLookAndFeels" dataProvider from TestHelpers class to run the test iteratively using all the available look and feels. But there were some issues while running this test directly on different look and feels. Issues: In MotifLookAndFeel it was failing because the 'passwords not match' color is not white. In NimbusLookAndFeel it was failing because the password1.getBackground() returns javax.swing.plaf.nimbus.DerivedColor object. Please see the bug description for the exception stack trace. Regards, Muneer
[12] RFR [TEST][JDK-8209993] Create a test for SwingSet3 ToolTipDemo
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8209993 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8209993/webrev.00/ Summary: This is a new test to automate testing of SwingSet3 ToolTipDemo. Please see the bug description for the scenarios automated. test/jdk/sanity/client/SwingSet/src/ToolTipDemoTest.java - This is the real test code, all other files are copied from swingset3 demo. Regards, Muneer
Re: [12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo
Hi Sergey, Thanks for review, I will check is there any way to get image loaded notification and come back to you. Regards, Muneer -Original Message- From: Sergey Bylokhov Sent: Tuesday, August 21, 2018 4:42 AM To: Muneer Kolarkunnu ; swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: Re: [12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo Hi, Muneer. Is it possible to enhance the test so it will fail if the images are not loaded by the editor pane(it will pass if you apply the patch w/o images)? On 19/08/2018 22:05, Muneer Kolarkunnu wrote: > Gentle Reminder. > > Regards, > > Muneer > > *From:*Muneer Kolarkunnu > *Sent:* Tuesday, August 14, 2018 10:35 PM > *To:* swing-dev@openjdk.java.net > *Subject:* [12] RFR [TEST][JDK-8209499] Create test for > SwingSet3 EditorPaneDemo > > Hi All, > > Please review the following, a new client sanity test case: > > Task: https://bugs.openjdk.java.net/browse/JDK-8209499 > > Webrev Link:http://cr.openjdk.java.net/~akolarkunnu/8209499/webrev.00/ > <http://cr.openjdk.java.net/%7Eakolarkunnu/8209499/webrev.00/> > > Summary: This is a new test to automate testing of SwingSet3 EditorPaneDemo. > > Please see the bug description for the scenarios automated. > > test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java - This is > the real test code, all other files are copied from swingset3 demo. > > Regards, > > Muneer > -- Best regards, Sergey.
Re: [12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo
Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Tuesday, August 14, 2018 10:35 PM To: swing-dev@openjdk.java.net Subject: [12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8209499 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8209499/webrev.00/ Summary: This is a new test to automate testing of SwingSet3 EditorPaneDemo. Please see the bug description for the scenarios automated. test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java - This is the real test code, all other files are copied from swingset3 demo. Regards, Muneer
Re: [12] RFR [TEST][JDK-8209494] Create a test for SwingSet3 InternalFrameDemo
Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Tuesday, August 14, 2018 10:32 PM To: swing-dev@openjdk.java.net Subject: [12] RFR [TEST][JDK-8209494] Create a test for SwingSet3 InternalFrameDemo Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8209494 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8209494/webrev.00/ Summary: This is a new test to automate testing of SwingSet3 InternalFrameDemo. Please see the bug description for the scenarios automated. test/jdk/sanity/client/SwingSet/src/InternalFrameDemoTest.java - This is the real test code, all other files are copied from swingset3 demo. Regards, Muneer
[12] RFR [TEST][JDK-8209499] Create test for SwingSet3 EditorPaneDemo
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8209499 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8209499/webrev.00/ Summary: This is a new test to automate testing of SwingSet3 EditorPaneDemo. Please see the bug description for the scenarios automated. test/jdk/sanity/client/SwingSet/src/EditorPaneDemoTest.java - This is the real test code, all other files are copied from swingset3 demo. Regards, Muneer
[12] RFR [TEST][JDK-8209494] Create a test for SwingSet3 InternalFrameDemo
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8209494 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8209494/webrev.00/ Summary: This is a new test to automate testing of SwingSet3 InternalFrameDemo. Please see the bug description for the scenarios automated. test/jdk/sanity/client/SwingSet/src/InternalFrameDemoTest.java - This is the real test code, all other files are copied from swingset3 demo. Regards, Muneer
Re: [12] RFR [JDK-8209418] : Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2
Thank you. I will correct the typo while checkin. Regards, Muneer -Original Message- From: Sergey Bylokhov Sent: Tuesday, August 14, 2018 7:57 AM To: Muneer Kolarkunnu ; swing-dev@openjdk.java.net Cc: Aleksandre Iline Subject: Re: [12] RFR [JDK-8209418] : Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2 Looks fine. BTW: there is a small typo: test/jdk/sanity/client/lib/jemmy/src/org/netbeans/jemmy/operators/JInternalFrameOperator.java 1393 "Jemmy doesn't support getting or intializing title" On 13/08/2018 04:50, Muneer Kolarkunnu wrote: > Hi, > > Please take a look on the set of changes brought into JDK Jemmy copy from the > code-tools Jemmy repository. > Task id: https://bugs.openjdk.java.net/browse/JDK-8209418 > Webrev: http://cr.openjdk.java.net/~akolarkunnu/8209418/webrev/ > > > This includes following 5 tasks: > https://bugs.openjdk.java.net/browse/CODETOOLS-7901960 : > JFileChooserOperator.selectFile(..) throws NullPointerException on Mac > Changed files : > src/org/netbeans/jemmy/operators/JFileChooserOperator.java > src/org/netbeans/jemmy/operators/JTableOperator.java > > https://bugs.openjdk.java.net/browse/CODETOOLS-7902172 : No class path > exception in copyright headers in Jemmy v2. code Changed all files, > just changed copyright with class path exception > > https://bugs.openjdk.java.net/browse/CODETOOLS-7902202 : [macosx]Jemmy > JInternalFrameOperator: APIs maximize(), demaximize() and iconify() are > failing with NullPointerException in Mac OSx Changed files : > src/org/netbeans/jemmy/drivers/APIDriverInstaller.java > src/org/netbeans/jemmy/drivers/windows/InternalFrameAPIDriver.java > src/org/netbeans/jemmy/operators/JInternalFrameOperator.java > src/org/netbeans/jemmy/util/Platform.java > src/org/netbeans/jemmy/version_info > > https://bugs.openjdk.java.net/browse/CODETOOLS-7902260 : Use Platform > class in jemmy to check Operating System Changed files : > src/org/netbeans/jemmy/JemmyProperties.java > src/org/netbeans/jemmy/operators/JMenuBarOperator.java > src/org/netbeans/jemmy/operators/Operator.java > > https://bugs.openjdk.java.net/browse/CODETOOLS-7902156 : Implement > clickOnReference(reference) API on JEditorPaneOperator Changed files : > src/org/netbeans/jemmy/operators/JEditorPaneOperator.java > src/org/netbeans/jemmy/version_info > > Regards, > Muneer > -- Best regards, Sergey.
[12] RFR [JDK-8209418] : Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2
Hi, Please take a look on the set of changes brought into JDK Jemmy copy from the code-tools Jemmy repository. Task id: https://bugs.openjdk.java.net/browse/JDK-8209418 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8209418/webrev/ This includes following 5 tasks: https://bugs.openjdk.java.net/browse/CODETOOLS-7901960 : JFileChooserOperator.selectFile(..) throws NullPointerException on Mac Changed files : src/org/netbeans/jemmy/operators/JFileChooserOperator.java src/org/netbeans/jemmy/operators/JTableOperator.java https://bugs.openjdk.java.net/browse/CODETOOLS-7902172 : No class path exception in copyright headers in Jemmy v2. code Changed all files, just changed copyright with class path exception https://bugs.openjdk.java.net/browse/CODETOOLS-7902202 : [macosx]Jemmy JInternalFrameOperator: APIs maximize(), demaximize() and iconify() are failing with NullPointerException in Mac OSx Changed files : src/org/netbeans/jemmy/drivers/APIDriverInstaller.java src/org/netbeans/jemmy/drivers/windows/InternalFrameAPIDriver.java src/org/netbeans/jemmy/operators/JInternalFrameOperator.java src/org/netbeans/jemmy/util/Platform.java src/org/netbeans/jemmy/version_info https://bugs.openjdk.java.net/browse/CODETOOLS-7902260 : Use Platform class in jemmy to check Operating System Changed files : src/org/netbeans/jemmy/JemmyProperties.java src/org/netbeans/jemmy/operators/JMenuBarOperator.java src/org/netbeans/jemmy/operators/Operator.java https://bugs.openjdk.java.net/browse/CODETOOLS-7902156 : Implement clickOnReference(reference) API on JEditorPaneOperator Changed files : src/org/netbeans/jemmy/operators/JEditorPaneOperator.java src/org/netbeans/jemmy/version_info Regards, Muneer
Re: [12] RFR [JDK-8209198] [macosx]Jemmy: JFileChooserOperator.selectFile(..) throws NullPointerException on Mac
Ok. Then I will include all outstanding changes in a single task. Regards, Muneer From: Alexandre (Shura) Iline Sent: Thursday, August 09, 2018 11:42 PM To: Muneer Kolarkunnu Cc: swing-dev@openjdk.java.net Subject: Re: [12] RFR [JDK-8209198] [macosx]Jemmy: JFileChooserOperator.selectFile(..) throws NullPointerException on Mac The original fix belongs to me , so I do not qualify as a reviewer. I, however, have a comment that perhaps we could import multiple changesets in code-tools/jemmy/v2 with one changeset in jdk/jdk. I have done it in the past, that’s for sure: https://bugs.openjdk.java.net/browse/JDK-8188779 Shura On Aug 9, 2018, at 10:26 AM, Muneer Kolarkunnu mailto:abdul.kolarku...@oracle.com"abdul.kolarku...@oracle.com> wrote: Hi All, Please review fix for a bug in jemmy: Bug: https://bugs.openjdk.java.net/browse/JDK-8209198 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8209198/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/b4a3749833ed Regards, Muneer
[12] RFR [JDK-8209198] [macosx]Jemmy: JFileChooserOperator.selectFile(..) throws NullPointerException on Mac
Hi All, Please review fix for a bug in jemmy: Bug: https://bugs.openjdk.java.net/browse/JDK-8209198 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8209198/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/b4a3749833ed Regards, Muneer
Re: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window
Gentle Reminder. Regards, Muneer From: Muneer Kolarkunnu Sent: Thursday, May 03, 2018 7:34 AM To: swing-dev@openjdk.java.net Subject: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197948 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.01/ Summary: This is a new test for automated testing of SwingSet2 main window using Jemmy. Aim of this is to test all swing components which are new in Swingset2 main window and are not part of SwingSet3 demos. Components to include in this test are JCheckBoxMenuItem , JRadioButtonMenuItem and different themes for Metal look and feel. Only the file test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java is newly created. All others are taken from SwingSet2 demo with necessary changes for testing (mainly removed unwanted codes). Regards, Muneer
[11] RFR [JDK-8202718] Jemmy JInternalFrameOperator: Dependency with orders of Minimize, Maximize and Close buttons
Hi All, Please review fix for a bug in jemmy: Bug: https://bugs.openjdk.java.net/browse/JDK-8202718 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202718/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/b39eb1713cff Regards, Muneer
[11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197948 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.01/ Summary: This is a new test for automated testing of SwingSet2 main window using Jemmy. Aim of this is to test all swing components which are new in Swingset2 main window and are not part of SwingSet3 demos. Components to include in this test are JCheckBoxMenuItem , JRadioButtonMenuItem and different themes for Metal look and feel. Only the file test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java is newly created. All others are taken from SwingSet2 demo with necessary changes for testing (mainly removed unwanted codes). Regards, Muneer
Re: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations
Gentle Reminder! Regards, Muneer From: Muneer Kolarkunnu Sent: Tuesday, April 24, 2018 6:10 PM To: swing-dev@openjdk.java.net Cc: Aleksandre Iline <alexandre.il...@oracle.com> Subject: Re: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Gentle Reminder! Regards, Muneer From: Muneer Kolarkunnu Sent: Friday, April 20, 2018 10:23 AM To: HYPERLINK "mailto:swing-dev@openjdk.java.net"swing-dev@openjdk.java.net Cc: Aleksandre Iline mailto:alexandre.il...@oracle.com"alexandre.il...@oracle.com> Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 Regards, Muneer
Re: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations
Gentle Reminder! Regards, Muneer From: Muneer Kolarkunnu Sent: Friday, April 20, 2018 10:23 AM To: swing-dev@openjdk.java.net Cc: Aleksandre Iline <alexandre.il...@oracle.com> Subject: [11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 Regards, Muneer
[11] RFR [JDK-8202064] Jemmy JInternalFrameOperator: Add wait for close(), activate(), resize() and move() operations
Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8202064 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8202064/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/ad21d12db156 Regards, Muneer
Re: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window
Hi Semyon, Only the file test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java is newly created. I have done some minor changes in files SwingSet2.java, swingset.properties files, mainly removed/commented unwanted codes for this test. Also I haven't included lots of other sub swingset2 demo codes(Eg: ButtonDemo.java, TableDemo.java, etc) in this as they are not necessary for this test. Regards, Muneer From: Semyon Sadetsky Sent: Wednesday, February 14, 2018 11:55 PM To: Muneer Kolarkunnu <abdul.kolarku...@oracle.com>; swing-dev@openjdk.java.net Cc: Aleksandre Iline <alexandre.il...@oracle.com> Subject: Re: [11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window Hi, can you clarify which files were newly created and which are copied from SwingSet2 without changes. Thanks. --Semyon On 02/14/2018 09:28 AM, Muneer Kolarkunnu wrote: Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197948 Webrev Link: HYPERLINK "http://cr.openjdk.java.net/%7Eakolarkunnu/8197948/webrev.00/"http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.00/ Summary: This is a new test for automated testing of SwingSet2 main window using Jemmy. Please see the bug description for the components to include in this test. Regards, Muneer
[11] RFR [TEST][JDK-8197948] Create test for SwingSet2 main window
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197948 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8197948/webrev.00/ Summary: This is a new test for automated testing of SwingSet2 main window using Jemmy. Please see the bug description for the components to include in this test. Regards, Muneer
[11] RFR [TEST][JDK-8174161] Create test for TableDemo
Hi All, Please review the following, a new client sanity test case: Task: https://bugs.openjdk.java.net/browse/JDK-8197554 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8197554/webrev.00/ Summary: This is a new test for automated testing of SwingSet3 TableDemo using Jemmy. Please see the bug for description of the scenario's automated. Regards, Muneer
[11] RFR [JDK-8197549] Implement a new method similar to waitState() on Operator which run the check on event queue
Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8197549 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8197549/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/c7aae56a10f5 Regards, Muneer
[11] RFR [JDK-8197482][TEST_BUG] Make Jemmy ComponentChooser lambda friendly
Hi All, Please review an enhancement in jemmy: Enhancement task: https://bugs.openjdk.java.net/browse/JDK-8197482 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8197482/webrev.00/ This fix is a copy of fix made in the Jemmy code-tools repository. http://hg.openjdk.java.net/code-tools/jemmy/v2/rev/5a582bf69c8f Regards, Muneer
[11][JDK-8196338][TEST_BUG] sanity/client/SwingSet/src/TextFieldDemoTest.java Failed with timeout
Hi All, Please review a fix for following bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8196338 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8196338/webrev.00/ This issue can happen if we execute this test case on midnight, test demo launch on one day 11.59:50 PM and tests execute on next day 00:00:01 AM. So instead of taking current date, taking the date from text field to calculate the day name. Regards, Muneer
Re: RFR: 8193211 : Update jtreg TEST.groups and ProblemList for client-libs
Hi Phil, jdk/internal/util \ has already removed by task https://bugs.openjdk.java.net/browse/JDK-8192958 . I think better to use group name "jdk_client_sanity" instead of "sanity/client/SwingSet \" at line no:358. Typo " commuonly" at line no: 355. Regards, Muneer -Original Message- From: Phil Race Sent: Friday, December 08, 2017 1:16 AM To: awt-...@openjdk.java.net; swing-dev@openjdk.java.net Subject: RFR: 8193211 : Update jtreg TEST.groups and ProblemList for client-libs Bug: https://bugs.openjdk.java.net/browse/JDK-8193211 Webrev: http://cr.openjdk.java.net/~prr/8193211/ adds jdk_swing_core and jdk_desktop_core test groups to jtreg Also problem lists many (by no means all) of the known jtreg failures. -phil
Re: [10] RFR JDK-8191803 : [TEST_BUG] : sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait "greater then 1349" state to be reached
Hi Sergey, I updated the webrev to incorporate your comment. New webrev: http://cr.openjdk.java.net/~akolarkunnu/8191803/webrev/webrev.01/ I kept jtreg timeout as 4 minute by considering all other operations of the test case. Regards, Muneer -Original Message- From: Sergey Bylokhov Sent: Monday, December 04, 2017 11:59 PM To: Muneer Kolarkunnu <abdul.kolarku...@oracle.com>; swing-dev@openjdk.java.net Cc: Aleksandre Iline <alexandre.il...@oracle.com> Subject: Re: [10] RFR JDK-8191803 : [TEST_BUG] : sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait "greater then 1349" state to be reached Hello. On 03/12/2017 22:54, Muneer Kolarkunnu wrote: > Issue: In usual ways itself, it is taking 30-40 seconds to complete > the progress bar. So in slow machines it may take more time. Default > timeout is 1 minute. Also in the screen shots, it is visible that demo > is not blocked anywhere, it is still continuing, but failed due to timeout. As far as I know that jtreg by default has 2 minute timeout, should it also be changed to 3 minutes? -- Best regards, Sergey.
[10] RFR JDK-8191803 : [TEST_BUG] : sanity/client/SwingSet/src/ProgressBarDemoTest.java failed with "Wait "greater then 1349" state to be reached
Hi, Please review the fix for JDK-8191803. Bug: https://bugs.openjdk.java.net/browse/JDK-8191803 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191803/webrev/webrev.00/ Issue: In usual ways itself, it is taking 30-40 seconds to complete the progress bar. So in slow machines it may take more time. Default timeout is 1 minute. Also in the screen shots, it is visible that demo is not blocked anywhere, it is still continuing, but failed due to timeout. Fix: Increase the progress bar timeout from 1 min to 3 min. Regards, Muneer
[10] RFR JDK-8190530: Compilation error in jemmy code FrameOperator.java due to missing of import statement of JemmyException
Hi All, Please review fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8190530 Webrev: http://cr.openjdk.java.net/~akolarkunnu/8190530/webrev.00/ There is a small compilation error introduced by task HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8188779"JDK-8188779. It missed the import statement of JemmyException in FrameOperator.java. In Jemmy code tool project it fixed by task CODETOOLS-7902046. Fix: Just added statement 'import org.netbeans.jemmy.JemmyException;' in FrameOperator.java Regards, Muneer
RFR JDK-8172804: SwingSet Automation: Jemmy Library : FrameOperator: maximize() and demaximize() are not properly implemented
Hi All, Please review the following: Bug : https://bugs.openjdk.java.net/browse/JDK-8172804 Webrev Link: http://cr.openjdk.java.net/~akolarkunnu/8172804/webrev.00/ Summary: This is a fix for a bug in Jemmy code, that we found while automating the SwingSet Demo. Previously maximize() was implemented using Frame.setSize() which will set frame size as screen size, but its state is not changing, it will be Frame.NORMAL itself. Now it is implementing using, Frame.setExtendedState() with Frame.MAXIMIZED_BOTH as parameter, so that its actual state also will set to Frame.MAXIMIZED_BOTH. Also demaximize() is not implemented completely. So demaximize() is implementing using Frame.setExtendedState() with Frame.NORMAL . Regards, Muneer
Re: Review request for 8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
I added the @run tag and updated the review: http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.01/ I tested with latest jtreg with and without @run tag, both are working. But there is a difference in the logs in the following line: Without @run flag: command: main bug5076514 reason: Assumed action based on file name: run main bug5076514 With @run flag: command: main bug5076514 reason: User specified action: run main bug5076514 Regards, Muneer From: prasanta sadhukhan Sent: Wednesday, April 13, 2016 7:49 PM To: Muneer Kolarkunnu; swing-dev@openjdk.java.net Subject: Re: Review request for 8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108 You need to add @run main for latest jtreg to run. Have you run against latest jtreg? Regards Prasanta On 4/13/2016 6:10 PM, Muneer Kolarkunnu wrote: Hi All, Please review the fix for test bug 8025430, Webrev: http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025430 Issue: It is a test bug, API checkSystemClipboardAccess() is deprecated. Deprecated message from java doc for your reference : "The dependency on AWTPermission creates an impediment to future modularization of the Java platform. Users of this method should instead invoke checkPermission(java.security.Permission) directly. This method will be changed in a future release to check the permission java.security.AllPermission." Fix: API checkPermission(java.security.Permission) is used instead of checkSystemClipboardAccess() Regards, Muneer
Review request for 8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
Hi All, Please review the fix for test bug 8025430, Webrev: http://cr.openjdk.java.net/~ntv/muneer/8025430/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8025430 Issue: It is a test bug, API checkSystemClipboardAccess() is deprecated. Deprecated message from java doc for your reference : "The dependency on AWTPermission creates an impediment to future modularization of the Java platform. Users of this method should instead invoke checkPermission(java.security.Permission) directly. This method will be changed in a future release to check the permission java.security.AllPermission." Fix: API checkPermission(java.security.Permission) is used instead of checkSystemClipboardAccess() Regards, Muneer
