Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Sergey Bylokhov]

Hi, Shashi.

I checked it on the fresh build of jdk/client, and confirm that it is possible 
to select progress bar using ctrl+option+up/down/left.
Screenshot is attached to the bug.


On 04/11/2018 23:08, shashidhara.veerabhadra...@oracle.com wrote:

Hi Sergey, I enabled 'All controls' access in the 
'Keyboard->Shortcuts->Accessibility' but still was not able to get the focus 
unto the progress bar and even with the short cut that you mentioned it always 
skipped the progress bar. The control would move from 'edit text box' to 'Start 
loading text' button. Even the bug description says to use the tab key to do this 
operation.

Only with this fix, I was able to select the progress bar control and otherwise 
not and that is true as per the focus traversal policy used for this control 
type.

Thanks and regards,

Shashi


On 03/11/18 3:00 AM, Sergey Bylokhov wrote:

I am not sure that the focusable property should be changed to fix this issue.
because the property is ignored when a11y shortcuts are used, at least I am
able to select the progress bar using ctr+shift+cnd+left/right/up/down. And
VO reads the current value of the progress bar, but if the demo is in 
progress("Start
loading text" button was pressed) the VO did not read information about the new
values of the progress bar.

On 24/10/2018 22:31, Shashidhara Veerabhadraiah wrote:

Hi Sergey, While fixing this bug I did not verified the behavior of other 
components and how they behave with respect to the AT. Since the question about 
other components came up and did some debugging on that part. Below is the 
reason that I could find:

It is all about the focus traversal policy that is used for each component 
type. While the both the JProgressBar and JLabel derived from JComponent and 
then JComponent is also derived from Container and Component class. 
JProgressBar component goes via the DefaultFocusTraversalPolicy(.java) while 
the JLabel goes via the ContainerOrderFocusTraversalPolicy(.java) where there 
are overriding methods of accept() function. This builds different behavior for 
JLabel and JProressBar while focus traversal.

Since the both the components are derived out of Component class both are 
default to focusable to true(Component.java) but because of the way accept() 
method is overridden, JProgressBar's focusable state is considered only when 
the focus traversable is overridden(not FOCUS_TRAVERSABLE_DEFAULT). Now by 
calling setFocusable() explicitly overrides the current policy to 
FOCUS_TRAVERSABLE_SET, hence the focusable state of the JProgressBar is 
considered afterwards.

Hope this answers. Please let me know if you have any questions.

Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov
Sent: Thursday, October 25, 2018 3:11 AM
To: Shashidhara Veerabhadraiah ; 
awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from VoiceOver 
regarding the status of the progress bar

Hi, Shashi.
Can you please provide more information about relation of focusable state and a 
VoiceOver? The simple JLabel is not focusable, but VoiceOver reads its 
contents, and it is possible to select the label using VoiceOver's shortcuts.

On 22/10/2018 00:36, shashidhara.veerabhadra...@oracle.com wrote:

Hi All, Please review a swingset fix for the below bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-7124285

Fix: http://cr.openjdk.java.net/~sveerabhadra/7124285/webrev.00/

Problem: The JProgressBar component used in the swingset demo was not focusable 
and once it is turned on, now the progress status is getting narrated via the 
voice over.

Thanks and regards,
Shashi












--
Best regards, Sergey.

Re: [12] RFR JDK-8198334: java/awt/FileDialog/8003399/bug8003399.java fails in headless mode

[Sergey Bylokhov]

Hi, Prasanta.
In the log of Test8173145 the ClassCastException exists as well:

https://bugs.openjdk.java.net/browse/JDK-8198334?focusedCommentId=14157839=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14157839

On 07/11/2018 01:29, Prasanta Sadhukhan wrote:

Hi Sergey,

Actually, I was more concerned about the swing test failure 
com/sun/java/swing/plaf/windows/Test8173145 which I guess is failing with 
HeadlessException. I can create a separate bug for this test alone and handle 
this tag addition in the test case w.r.t that bug.
Will that be fine?

For the 1st 2 awt tests, it seems to throw ClassCastEzxception which I will 
leave alone. I was handling it only because it was mixed with this swing test.

Regards
Prasanta
- Original Message -
From: sergey.bylok...@oracle.com
To: prasanta.sadhuk...@oracle.com, swing-dev@openjdk.java.net, 
awt-...@openjdk.java.net
Sent: Wednesday, November 7, 2018 3:08:00 AM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re:  [12] RFR JDK-8198334: 
java/awt/FileDialog/8003399/bug8003399.java fails in headless mode

Hi, Prasanta.

An exception which was occurred in these tests are not HeadlessException but 
ClassCastException
which is think is a product bug.

On 05/11/2018 02:16, Prasanta Sadhukhan wrote:

Hi All,

Please review a fix for an issue where some tests are found to be failing with 
HeadlessException in mach5 systems.
Proposed fix is to mark those tests as headful.

Bug: https://bugs.openjdk.java.net/browse/JDK-8198334
webrev: http://cr.openjdk.java.net/~psadhukhan/8198334/webrev.0/

Regards
Prasanta






--
Best regards, Sergey.

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Alexey Ivanov]

Hi Shashi,

I ran a test with a native dialog-based Windows app with two progress 
bars. I used the built-in Narrator as the accessibility tool in Windows 10.


When using Tab key to navigate between controls on a dialog box, the 
progress bar without WS_TABSTOP style cannot be focused; the one with 
WS_TABSTOP style can be focused with Tab. When it's focused, Narrator 
reads its value, the range as well as its label in static control 
preceding the progress bar. Narrator also reads new value when the 
progress is updated.


At the same time, the non-focusable progress bar can be selected with 
touch. It's read by Narrator in this case.

I didn't find a way to select it with mouse though.

When the progress bar is focused, it has no focus indicators. I believe 
this is because progress bar controls aren't focusable by default as 
they don't support any user input.


So the current behaviour in Java coincides with that of Windows native 
controls.



Narrator does not work with Java apps: it sees only the top-level window 
of SwingSet2.


Regards,
Alexey

On 24/10/2018 16:19, Alexey Ivanov wrote:

Hi Shashi,

I see, setting setFocusable dynamically is not an option then. At the 
very least it will be confusing for the user: in some cases progress 
bar is skipped when traversing focus and in other cases, it's not.


Progress bar embedded in a toolbar button is another case.

Is progress bar focusable in native apps?
Usually it's not because this control only displays the progress and 
does not accept any user input: neither from keyboard nor from mouse.


Perhaps there's an additional accessibility property to make it be 
read by AT.


What about JLabels? They're also non-focusable because labels do not 
accept any user input. Are labels also required to be made focusable 
to be read by AT?



Making a progress bar focusable is acceptable as the workaround for 
SwingSet. But I don't think it's a good idea to make JProgressBar 
focusable by default. The control does not accept any user input, so I 
think it should not become focus owner. Therefore there's no need to 
add visual focus cues.


Regards,
Alexey

On 24/10/2018 06:14, Shashidhara Veerabhadraiah wrote:
Hi Alexey, Yes, their value is read by the AT. Though I could not 
find any focusability on them though. AT can be enabled on the fly 
like Command + F5 on mac and it varies platform to platform.


In certain cases the progress bars are embedded within the button 
like in the 'show downloads' button on the Safari browser/Mozilla 
browser. I tried with an native windows progress bar demo application 
and found that they are not focused. But ideally certain visual cue 
is required to see where the cursor is highlighting else it seem lost.


Thanks and regards,
Shashi

-Original Message-
From: Alexey Ivanov
Sent: Wednesday, October 24, 2018 12:16 AM
To: Shashidhara Veerabhadraiah 
; Krishna Addepalli 


Cc: awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:   [12] JDK-7124285: Nothing heard 
from VoiceOver regarding the status of the progress bar


Hi Krishna, Shashi,

I wonder how native progress bars behave. Is their value read by 
assistive technologies? Are they focusable? Are they focusable if no 
assistive technology enabled?


JLabel is not focusable. It does not accept user input directly. Are 
JLabels also skipped by assistive technologies?
If setLabelFor(Component) is called, the label is associated with a 
component. Is label read when the associated component is focused?


Regards,
Alexey

On 23/10/2018 11:49, Shashidhara Veerabhadraiah wrote:

Hi Krishna, Thanks for your review.

That was really a good observation and as you rightly said, some 
visual cue needs to be there around the progress bar, else it does 
look lost.


Thanks and regards,
Shashi

-Original Message-
From: Krishna Addepalli
Sent: Tuesday, October 23, 2018 1:54 PM
To: Shashidhara Veerabhadraiah 
Cc: awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from
VoiceOver regarding the status of the progress bar

Hi Shashi,

The fix looks good to me. Regarding the decision of placing the line 
“setFocusable(true)” in the constructor of ProgressBar, I think that 
is a good decision since the Swing users needn’t explicitly make 
that call to make it accessible.


There is one problem though:
The focus is not shown on the progress bar, and at that point, it 
feels like the focus is lost and may lead to some confusion.
I think it would be good if we can render a focus rect around the 
progress bar to let users know that it is in focus, which ofcourse 
can be addressed separately.


Thanks,
Krishna

On 22-Oct-2018, at 1:06 PM, shashidhara.veerabhadra...@oracle.com 
wrote:


Hi All, Please review a swingset fix for the below bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-7124285

Fix: http://cr.openjdk.java.net/~sveerabhadra/7124285/webrev.00/

Problem: The JProgressBar component used in the swingset 

Re: RFR 8186549: move ExtendedRobot closer to tests

[Alexandre (Shura) Iline]

Phil, Igor,

A quick check shows that indeed most of cases where a “lib” library used by 
relative path (which may or may not be the top level library) are in the client 
tests.

$ egrep -r '@library.* (../)+lib' --include "*.java" . | cut -d ':' -f 1 | cut 
-d / -f 2-3 | uniq -c
 59 java/awt
  1 tools/jimage
 15 tools/jlink
 43 com/sun
 39 javax/swing

$ egrep -r '@library.* (../)+lib' --include "*.java" com/sun | cut -d ':' -f 1 
| cut -d / -f 2-3 | uniq -c
 43 sun/jndi

Further, almost all of such cases, in client tests, is included into my last 
fix:

$ egrep -r '@library.* (../)+lib/client' --include "*.java" . | cut -d ':' -f 1 
| cut -d / -f 2-3 | uniq -c
 56 java/awt
 39 javax/swing

The is to say, I will update the webrev with using absolute path to lib/client.

Shura


> On Nov 6, 2018, at 5:30 PM, Philip Race  wrote:
> 
> I don't understand why the relative path is used  in some two cases and
> an absolute path in others. OK you didn't change that but does it make
> sense to standardise on what I hope is the absolute path which is easier
> to get right and will withstand the tests being moved ? 
> Can we do the same for "helpers" ?
> 
> -phil.
> 
> test/jdk/java/awt/Modal/ModalExclusionTests/ApplicationExcludeDialogFileTest.java
> 
> @@ -29,11 +29,11 @@
>   * @bug 8047179 8044429
>   * @summary Check whether a FileDialog blocks an application modality 
> excluded Dialog
>   *  (it shouldn't). Checks also whether setting a parent dialog to be
>   *  modality excluded excludes its children from being blocked too.
>   *
> - * @library ../helpers /lib/testlibrary/
> + * @library ../helpers /lib/client/
>   * @library /test/lib
>   * @build ExtendedRobot
>   * @build Flag
>   * @build TestDialog
>   * @build TestWindow
> 
> test/jdk/java/awt/Modal/ModalDialogOrderingTest/ModalDialogOrderingTest.java
> 
> @@ -33,11 +33,11 @@
>   * @test
>   * @key headful
>   * @bug 8008728
>   * @summary [macosx] Swing. JDialog. Modal dialog goes to background
>   * @author Alexandr Scherbatiy
> - * @library ../../../../lib/testlibrary
> + * @library ../../../../lib/client
>   * @build ExtendedRobot
>   * @run main ModalDialogOrderingTest
>   */
>  public class ModalDialogOrderingTest {
>  
> 
> -phil.
> 
> On 11/6/18, 5:21 PM, Alexandre (Shura) Iline wrote:
>> 
>> Ping.
>> 
>>> On Oct 29, 2018, at 3:02 PM, Alexandre (Shura) Iline 
>>>   wrote:
>>> 
>>> Hi.
>>> 
>>> Please take a look on this fix for JDK-8186549.
>>> 
>>> For testing I have selected tests and groups of tests which use the 
>>> ExtendedRobot class. The tests show the same pass rate. There are still few 
>>> tests which use lib/testlibrary, they are not affected by this fix.
>>> 
>>> Task: https://bugs.openjdk.java.net/browse/JDK-8186549 
>>> 
>>> Webrev: http://cr.openjdk.java.net/~shurailine/8186549/webrev.00 
>>> 
>>> Tests used for testing the fix: 
>>> http://cr.openjdk.java.net/~shurailine/8186549/extended_robot_tests 
>>> 
>>> 
>>> Shura
>>> 

Re: [12] RFR JDK-8213181:Updation of ProblemList.txt for removal of passing swing test

[Sergey Bylokhov]

On 07/11/2018 21:44, Prasanta Sadhukhan wrote:

I found that these tests are passing when ran for 100 iterations on windows
javax/swing/plaf/basic/Test6984643.java


It is necessary to check the code of the tests as well, for example the test 
above was reported in JDK-8198340.
The reason is that we have a race between shiudown of the app(caused by the 
jtreg) and initialization
of the test on EDT because the test uses invokeLater(), so the main() method is 
ended before the end of invokeLater().

And it looks like a product bug in Win32ShellFolderManager2 which should not 
throw IllegalStateException.

Others tests should be checked is a similar way.

BTW if the test is not marked as @headful it is necessary to check its 
stability in the headless environment as well.


--
Best regards, Sergey.

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Shashidhara Veerabhadraiah]

Hi Sergey, Probably we should stick with generic keys to go thro' java 
components like the TAB key traversals. Because on Windows, I just can't get 
focus onto the progress bar without explicitly setting the focusable to 
true(like in fix).
Ctrl+option+up/down/left/right is specific to the implementation of voice over 
on Mac and we do not have similar alternative ways for Windows(for JAWS) 
platform.

Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov 
Sent: Thursday, November 8, 2018 12:35 AM
To: Shashidhara Veerabhadraiah ; 
awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from VoiceOver 
regarding the status of the progress bar

Hi, Shashi.

I checked it on the fresh build of jdk/client, and confirm that it is possible 
to select progress bar using ctrl+option+up/down/left.
Screenshot is attached to the bug.


On 04/11/2018 23:08, shashidhara.veerabhadra...@oracle.com wrote:
> Hi Sergey, I enabled 'All controls' access in the 
> 'Keyboard->Shortcuts->Accessibility' but still was not able to get the focus 
> unto the progress bar and even with the short cut that you mentioned it 
> always skipped the progress bar. The control would move from 'edit text box' 
> to 'Start loading text' button. Even the bug description says to use the tab 
> key to do this operation.
> 
> Only with this fix, I was able to select the progress bar control and 
> otherwise not and that is true as per the focus traversal policy used for 
> this control type.
> 
> Thanks and regards,
> 
> Shashi
> 
> 
> On 03/11/18 3:00 AM, Sergey Bylokhov wrote:
>> I am not sure that the focusable property should be changed to fix this 
>> issue.
>> because the property is ignored when a11y shortcuts are used, at 
>> least I am able to select the progress bar using 
>> ctr+shift+cnd+left/right/up/down. And VO reads the current value of 
>> the progress bar, but if the demo is in progress("Start loading text" 
>> button was pressed) the VO did not read information about the new values of 
>> the progress bar.
>>
>> On 24/10/2018 22:31, Shashidhara Veerabhadraiah wrote:
>>> Hi Sergey, While fixing this bug I did not verified the behavior of other 
>>> components and how they behave with respect to the AT. Since the question 
>>> about other components came up and did some debugging on that part. Below 
>>> is the reason that I could find:
>>>
>>> It is all about the focus traversal policy that is used for each component 
>>> type. While the both the JProgressBar and JLabel derived from JComponent 
>>> and then JComponent is also derived from Container and Component class. 
>>> JProgressBar component goes via the DefaultFocusTraversalPolicy(.java) 
>>> while the JLabel goes via the ContainerOrderFocusTraversalPolicy(.java) 
>>> where there are overriding methods of accept() function. This builds 
>>> different behavior for JLabel and JProressBar while focus traversal.
>>>
>>> Since the both the components are derived out of Component class both are 
>>> default to focusable to true(Component.java) but because of the way 
>>> accept() method is overridden, JProgressBar's focusable state is considered 
>>> only when the focus traversable is overridden(not 
>>> FOCUS_TRAVERSABLE_DEFAULT). Now by calling setFocusable() explicitly 
>>> overrides the current policy to FOCUS_TRAVERSABLE_SET, hence the focusable 
>>> state of the JProgressBar is considered afterwards.
>>>
>>> Hope this answers. Please let me know if you have any questions.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> -Original Message-
>>> From: Sergey Bylokhov
>>> Sent: Thursday, October 25, 2018 3:11 AM
>>> To: Shashidhara Veerabhadraiah 
>>> ; awt-...@openjdk.java.net; 
>>> swing-dev@openjdk.java.net
>>> Subject: Re:  [12] JDK-7124285: Nothing heard from 
>>> VoiceOver regarding the status of the progress bar
>>>
>>> Hi, Shashi.
>>> Can you please provide more information about relation of focusable state 
>>> and a VoiceOver? The simple JLabel is not focusable, but VoiceOver reads 
>>> its contents, and it is possible to select the label using VoiceOver's 
>>> shortcuts.
>>>
>>> On 22/10/2018 00:36, shashidhara.veerabhadra...@oracle.com wrote:
 Hi All, Please review a swingset fix for the below bug.

 Bug: https://bugs.openjdk.java.net/browse/JDK-7124285

 Fix: http://cr.openjdk.java.net/~sveerabhadra/7124285/webrev.00/

 Problem: The JProgressBar component used in the swingset demo was not 
 focusable and once it is turned on, now the progress status is getting 
 narrated via the voice over.

 Thanks and regards,
 Shashi

>>>
>>>
>>
>>
> 


--
Best regards, Sergey.

Re: [12] RFR JDK-8213181:Updation of ProblemList.txt for removal of passing swing test

[Prasanta Sadhukhan]

Since some of the tests are marked generic-all and it's difficult to run 
100 iterations on all platforms, I concentrated on the tests that are 
marked failing on one platform.


I found that these tests are passing when ran for 100 iterations on windows

javax/swing/JComboBox/6607130/bug6607130.java
javax/swing/JPopupMenu/6675802/bug6675802.java
javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java
javax/swing/plaf/basic/Test6984643.java
javax/swing/text/JTextComponent/5074573/bug5074573.java
javax/swing/SwingWorker/6493680/bug6493680.java
javax/swing/UIDefaults/8149879/InternalResourceBundle.java
javax/swing/PopupFactory/8048506/bug8048506.java

and these on mac

javax/swing/JButton/8151303/PressedIconTest.java
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java

Proposed webrev:
http://cr.openjdk.java.net/~psadhukhan/8213181/webrev.0/

Regards
Prasanta
On 06-Nov-18 6:29 AM, Sergey Bylokhov wrote:

So shouldn't this test just be marked @headful ?

I can mark it headful if Sergey is ok with it.

This will skip the test in our nightly, but actually does not solve the existed 
bug in the test.


fails last time due to some update dialog or antivirus popup)
javax/swing/JButton/8151303/PressedIconTest.java 8198689 macosx-all*
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java

I guess there will be many more tests that will fail if we try to

run

for 100 iterations and Problemlist will swell, so I guess we should
keep only those tests in ProblemList that fail if we run

individually.

The ProblemList excludes the tests from the nightly and testing after commit,
the rest of tests(which are headless and not in this list) are quite stable.


Automated tests that are being run on a regular basis need to pass
reliably.

But we do not run each test in an batch for 100 iterations to find out

if it is reliable (should we?).

I do that, our sqe run the tests for 1000 iterations.



   I guess we just run it individually in standalone mode and if it
pass
everytime, we consider it reliable, and all these 5 tests pass if run


I guess the problem here is that these tests were added to the problem list 
without
investigation of root cause, at least It was not checked that it was a setup issue like 
wrong "Display color profile".

As a solution I suggest to check the source code of the tests, and try to find 
some issues which may affect
the stability of the tests, then run these tests in a bash loop for 100 
iterations to prove that they
really stable.

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Sergey Bylokhov]

On 07/11/2018 22:12, Shashidhara Veerabhadraiah wrote:

Hi Sergey, Probably we should stick with generic keys to go thro' java 
components like the TAB key traversals. Because on Windows, I just can't get 
focus onto the progress bar without explicitly setting the focusable to 
true(like in fix).
Ctrl+option+up/down/left/right is specific to the implementation of voice over 
on Mac and we do not have similar alternative ways for Windows(for JAWS) 
platform.


We cannot stick on some generic keys here because different a11y tools on 
different platforms uses different approaches to access the UI.
On macOS the "tab" iterates over the visible UI components, while the "special" 
shortcuts iterates over the accessible elements that implements some roles.



Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov
Sent: Thursday, November 8, 2018 12:35 AM
To: Shashidhara Veerabhadraiah ; 
awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from VoiceOver 
regarding the status of the progress bar

Hi, Shashi.

I checked it on the fresh build of jdk/client, and confirm that it is possible 
to select progress bar using ctrl+option+up/down/left.
Screenshot is attached to the bug.


On 04/11/2018 23:08, shashidhara.veerabhadra...@oracle.com wrote:

Hi Sergey, I enabled 'All controls' access in the 
'Keyboard->Shortcuts->Accessibility' but still was not able to get the focus 
unto the progress bar and even with the short cut that you mentioned it always 
skipped the progress bar. The control would move from 'edit text box' to 'Start 
loading text' button. Even the bug description says to use the tab key to do this 
operation.

Only with this fix, I was able to select the progress bar control and otherwise 
not and that is true as per the focus traversal policy used for this control 
type.

Thanks and regards,

Shashi


On 03/11/18 3:00 AM, Sergey Bylokhov wrote:

I am not sure that the focusable property should be changed to fix this issue.
because the property is ignored when a11y shortcuts are used, at
least I am able to select the progress bar using
ctr+shift+cnd+left/right/up/down. And VO reads the current value of
the progress bar, but if the demo is in progress("Start loading text"
button was pressed) the VO did not read information about the new values of the 
progress bar.

On 24/10/2018 22:31, Shashidhara Veerabhadraiah wrote:

Hi Sergey, While fixing this bug I did not verified the behavior of other 
components and how they behave with respect to the AT. Since the question about 
other components came up and did some debugging on that part. Below is the 
reason that I could find:

It is all about the focus traversal policy that is used for each component 
type. While the both the JProgressBar and JLabel derived from JComponent and 
then JComponent is also derived from Container and Component class. 
JProgressBar component goes via the DefaultFocusTraversalPolicy(.java) while 
the JLabel goes via the ContainerOrderFocusTraversalPolicy(.java) where there 
are overriding methods of accept() function. This builds different behavior for 
JLabel and JProressBar while focus traversal.

Since the both the components are derived out of Component class both are 
default to focusable to true(Component.java) but because of the way accept() 
method is overridden, JProgressBar's focusable state is considered only when 
the focus traversable is overridden(not FOCUS_TRAVERSABLE_DEFAULT). Now by 
calling setFocusable() explicitly overrides the current policy to 
FOCUS_TRAVERSABLE_SET, hence the focusable state of the JProgressBar is 
considered afterwards.

Hope this answers. Please let me know if you have any questions.

Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov
Sent: Thursday, October 25, 2018 3:11 AM
To: Shashidhara Veerabhadraiah
; awt-...@openjdk.java.net;
swing-dev@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from
VoiceOver regarding the status of the progress bar

Hi, Shashi.
Can you please provide more information about relation of focusable state and a 
VoiceOver? The simple JLabel is not focusable, but VoiceOver reads its 
contents, and it is possible to select the label using VoiceOver's shortcuts.

On 22/10/2018 00:36, shashidhara.veerabhadra...@oracle.com wrote:

Hi All, Please review a swingset fix for the below bug.

Bug: https://bugs.openjdk.java.net/browse/JDK-7124285

Fix: http://cr.openjdk.java.net/~sveerabhadra/7124285/webrev.00/

Problem: The JProgressBar component used in the swingset demo was not focusable 
and once it is turned on, now the progress status is getting narrated via the 
voice over.

Thanks and regards,
Shashi












--
Best regards, Sergey.




--
Best regards, Sergey.

Re: [12] RFR JDK-8213181:Updation of ProblemList.txt for removal of passing swing test

[Prasanta Sadhukhan]

On 08-Nov-18 11:52 AM, Sergey Bylokhov wrote:

On 07/11/2018 21:44, Prasanta Sadhukhan wrote:
I found that these tests are passing when ran for 100 iterations on 
windows

javax/swing/plaf/basic/Test6984643.java


It is necessary to check the code of the tests as well, for example 
the test above was reported in JDK-8198340.
The reason is that we have a race between shiudown of the app(caused 
by the jtreg) and initialization
of the test on EDT because the test uses invokeLater(), so the main() 
method is ended before the end of invokeLater().


And it looks like a product bug in Win32ShellFolderManager2 which 
should not throw IllegalStateException.


Others tests should be checked is a similar way.

BTW if the test is not marked as @headful it is necessary to check its 
stability in the headless environment as well.



I guess these 2 tests which I have added in last sprint because they 
fail in local machine (and not in mach5)

javax/swing/JButton/8151303/PressedIconTest.java
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java
are marked as headful and passing for 100 iterations, so I guess at 
least we should remove these 2 tests for this bugid as it does not need 
to be tested in mac5.


Rest I will look at later point as you told it might be some instability 
that might cause it.


Regards
Prasanta

[12] Review Request: 8213110 Remove the use of applets in automatic tests

[Sergey Bylokhov]

Hello.
Please review the fix for jdk 12.

Bug: https://bugs.openjdk.java.net/browse/JDK-8213110
Webrev: http://cr.openjdk.java.net/~serb/8213110/webrev.03

Description of the bug:
  A number of our tests in jdk still launch by applets via "@run applet".
Usually we drop this usage when we update the test for some reason, and
in this fix we will drop them completely for automated tests from the open repo.
I did not update the tests which are specific for Applet API, manual tests, or 
tests
which are currently under review for some other bugs.
 
Note: the "@run applet" means, that the jtreg will do these steps:

 - Creates a frame as a holder for the Applet
 - Creates an applet(which is undecorated panel) and adds it to the frame
 - Sets the size of the frame
 - Place the frame to the center of the screen
 - Make the frame visible
 - Call init() and start() methods of the Applet
 - Waits for 2 seconds
 - Call stop() and destroy() methods of the Applet
 - Dispose the frame


Description of the fix:

 - In all cases the usage of the Applet API was dropped
 - In the common case when the applet was used as launcher, this code now used 
instead:
   public static void main(final String[] args) {
  TestName app = new TestName();
  app.init();
  app.start();
   }
   Example:
   
http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.java.sdiff.html

 - In some cases it was possible to replace init()/start() by the simple main() 
method.
   Example:
   
http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.java.sdiff.html

 - Some of the tests were used the "extend Applet" w/o a reasons:
   Example:
   
http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java.sdiff.html

 - Some of the tests shows the applet window(which was unrelated to the test 
itself) in the center of the screen.
   Example:
   
http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java.sdiff.html

 - Some of the tests uses the applet as a place holder for the test components.
   In this case it was necessary to change the Applet API to the Frame API, and 
complete
   the steps which were done by the jtreg:
   Example:
   
http://cr.openjdk.java.net/~serb/8213110/webrev.03/test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java.sdiff.html


Notes:
 - To simplify the review I tried to not change the logic of the tests,
   so if the test fail before the fix, then it will fail after the fix.
   I would like to create the separate CRs for all additional(if any) cleanup 
of these tests.
 - Just a few exception from the above is additional calls to:
   "setLocationRelativeTo" to place the window to the center of the screen
   "robot.waitForIdle()"/"setUndecorated()" to make the tests more stable(when 
I compared the tests before/after the fix)


--
Best regards, Sergey.

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Shashidhara Veerabhadraiah]

Hi Alexey, Thanks for running the test on Windows. With accessibility in 
question we should reach the component using the keyboard only. Touch and mouse 
is not permitted. So the question is can it be reached via a keyboard stroke? 
If not then that component is not accessible and that's the assessment. 
I could not reach to the progress bar(thro' keyboard) without explicitly 
setting the focusability 'on' it for both Windows and Mac. Sergey found a way 
to do it on Mac but I was not able to do the same. But with this fix, I see it 
working on both Windows and Mac.

Thanks and regards,
Shashi

-Original Message-
From: Alexey Ivanov 
Sent: Thursday, November 8, 2018 1:13 AM
To: Shashidhara Veerabhadraiah ; Krishna 
Addepalli 
Cc: awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:   [12] JDK-7124285: Nothing heard from 
VoiceOver regarding the status of the progress bar

Hi Shashi,

I ran a test with a native dialog-based Windows app with two progress bars. I 
used the built-in Narrator as the accessibility tool in Windows 10.

When using Tab key to navigate between controls on a dialog box, the progress 
bar without WS_TABSTOP style cannot be focused; the one with WS_TABSTOP style 
can be focused with Tab. When it's focused, Narrator reads its value, the range 
as well as its label in static control preceding the progress bar. Narrator 
also reads new value when the progress is updated.

At the same time, the non-focusable progress bar can be selected with touch. 
It's read by Narrator in this case.
I didn't find a way to select it with mouse though.

When the progress bar is focused, it has no focus indicators. I believe this is 
because progress bar controls aren't focusable by default as they don't support 
any user input.

So the current behaviour in Java coincides with that of Windows native controls.


Narrator does not work with Java apps: it sees only the top-level window 
of SwingSet2.

Regards,
Alexey

On 24/10/2018 16:19, Alexey Ivanov wrote:
> Hi Shashi,
>
> I see, setting setFocusable dynamically is not an option then. At the 
> very least it will be confusing for the user: in some cases progress 
> bar is skipped when traversing focus and in other cases, it's not.
>
> Progress bar embedded in a toolbar button is another case.
>
> Is progress bar focusable in native apps?
> Usually it's not because this control only displays the progress and 
> does not accept any user input: neither from keyboard nor from mouse.
>
> Perhaps there's an additional accessibility property to make it be 
> read by AT.
>
> What about JLabels? They're also non-focusable because labels do not 
> accept any user input. Are labels also required to be made focusable 
> to be read by AT?
>
>
> Making a progress bar focusable is acceptable as the workaround for 
> SwingSet. But I don't think it's a good idea to make JProgressBar 
> focusable by default. The control does not accept any user input, so I 
> think it should not become focus owner. Therefore there's no need to 
> add visual focus cues.
>
> Regards,
> Alexey
>
> On 24/10/2018 06:14, Shashidhara Veerabhadraiah wrote:
>> Hi Alexey, Yes, their value is read by the AT. Though I could not 
>> find any focusability on them though. AT can be enabled on the fly 
>> like Command + F5 on mac and it varies platform to platform.
>>
>> In certain cases the progress bars are embedded within the button 
>> like in the 'show downloads' button on the Safari browser/Mozilla 
>> browser. I tried with an native windows progress bar demo application 
>> and found that they are not focused. But ideally certain visual cue 
>> is required to see where the cursor is highlighting else it seem lost.
>>
>> Thanks and regards,
>> Shashi
>>
>> -Original Message-
>> From: Alexey Ivanov
>> Sent: Wednesday, October 24, 2018 12:16 AM
>> To: Shashidhara Veerabhadraiah 
>> ; Krishna Addepalli 
>> 
>> Cc: awt-...@openjdk.java.net; swing-dev@openjdk.java.net
>> Subject: Re:   [12] JDK-7124285: Nothing heard 
>> from VoiceOver regarding the status of the progress bar
>>
>> Hi Krishna, Shashi,
>>
>> I wonder how native progress bars behave. Is their value read by 
>> assistive technologies? Are they focusable? Are they focusable if no 
>> assistive technology enabled?
>>
>> JLabel is not focusable. It does not accept user input directly. Are 
>> JLabels also skipped by assistive technologies?
>> If setLabelFor(Component) is called, the label is associated with a 
>> component. Is label read when the associated component is focused?
>>
>> Regards,
>> Alexey
>>
>> On 23/10/2018 11:49, Shashidhara Veerabhadraiah wrote:
>>> Hi Krishna, Thanks for your review.
>>>
>>> That was really a good observation and as you rightly said, some 
>>> visual cue needs to be there around the progress bar, else it does 
>>> look lost.
>>>
>>> Thanks and regards,
>>> Shashi
>>>
>>> -Original Message-
>>> From: Krishna Addepalli
>>> Sent: Tuesday, October 23, 2018 1:54 PM
>>> To: 

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Sergey Bylokhov]

On 07/11/2018 11:42, Alexey Ivanov wrote:

Narrator does not work with Java apps: it sees only the top-level window of 
SwingSet2.


It is still unsupported =(, we need to check the jaws first using their 
shortcuts:
https://www.freedomscientific.com/Content/Documents/Manuals/JAWS/Keystrokes.txt

And we need to compare jaws for native apps and swing.

--
Best regards, Sergey.

Re: [12] JDK-7124285: Nothing heard from VoiceOver regarding the status of the progress bar

[Shashidhara Veerabhadraiah]

Hi Sergey, If that's the case, then the solution should work considering all 
the variations in the a11y tool set across the different platforms. Isn't it?
So considering that, the proposed solution works for all the different tool 
set(TAB and Ctrl+Option) across the platforms and without it, it does not work 
on the windows platform!! 
>From the usability perspective of a disabled person, I don't think one would 
>know use the Ctrl+option+shift kind of traversal and they would definitely 
>prefer to be same across the platforms. i.e., TAB key traversals(just the 
>important visible UI element traversals). So considering that, the solution 
>should at least work in the usability scenarios across the platforms!!

Thanks and regards,
Shashi

-Original Message-
From: Sergey Bylokhov 
Sent: Thursday, November 8, 2018 12:14 PM
To: Shashidhara Veerabhadraiah ; 
awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re:  [12] JDK-7124285: Nothing heard from VoiceOver 
regarding the status of the progress bar

On 07/11/2018 22:12, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, Probably we should stick with generic keys to go thro' java 
> components like the TAB key traversals. Because on Windows, I just can't get 
> focus onto the progress bar without explicitly setting the focusable to 
> true(like in fix).
> Ctrl+option+up/down/left/right is specific to the implementation of voice 
> over on Mac and we do not have similar alternative ways for Windows(for JAWS) 
> platform.

We cannot stick on some generic keys here because different a11y tools on 
different platforms uses different approaches to access the UI.
On macOS the "tab" iterates over the visible UI components, while the "special" 
shortcuts iterates over the accessible elements that implements some roles.

> 
> Thanks and regards,
> Shashi
> 
> -Original Message-
> From: Sergey Bylokhov
> Sent: Thursday, November 8, 2018 12:35 AM
> To: Shashidhara Veerabhadraiah 
> ; awt-...@openjdk.java.net; 
> swing-dev@openjdk.java.net
> Subject: Re:  [12] JDK-7124285: Nothing heard from 
> VoiceOver regarding the status of the progress bar
> 
> Hi, Shashi.
> 
> I checked it on the fresh build of jdk/client, and confirm that it is 
> possible to select progress bar using ctrl+option+up/down/left.
> Screenshot is attached to the bug.
> 
> 
> On 04/11/2018 23:08, shashidhara.veerabhadra...@oracle.com wrote:
>> Hi Sergey, I enabled 'All controls' access in the 
>> 'Keyboard->Shortcuts->Accessibility' but still was not able to get the focus 
>> unto the progress bar and even with the short cut that you mentioned it 
>> always skipped the progress bar. The control would move from 'edit text box' 
>> to 'Start loading text' button. Even the bug description says to use the tab 
>> key to do this operation.
>>
>> Only with this fix, I was able to select the progress bar control and 
>> otherwise not and that is true as per the focus traversal policy used for 
>> this control type.
>>
>> Thanks and regards,
>>
>> Shashi
>>
>>
>> On 03/11/18 3:00 AM, Sergey Bylokhov wrote:
>>> I am not sure that the focusable property should be changed to fix this 
>>> issue.
>>> because the property is ignored when a11y shortcuts are used, at 
>>> least I am able to select the progress bar using
>>> ctr+shift+cnd+left/right/up/down. And VO reads the current value of
>>> the progress bar, but if the demo is in progress("Start loading text"
>>> button was pressed) the VO did not read information about the new values of 
>>> the progress bar.
>>>
>>> On 24/10/2018 22:31, Shashidhara Veerabhadraiah wrote:
 Hi Sergey, While fixing this bug I did not verified the behavior of other 
 components and how they behave with respect to the AT. Since the question 
 about other components came up and did some debugging on that part. Below 
 is the reason that I could find:

 It is all about the focus traversal policy that is used for each component 
 type. While the both the JProgressBar and JLabel derived from JComponent 
 and then JComponent is also derived from Container and Component class. 
 JProgressBar component goes via the DefaultFocusTraversalPolicy(.java) 
 while the JLabel goes via the ContainerOrderFocusTraversalPolicy(.java) 
 where there are overriding methods of accept() function. This builds 
 different behavior for JLabel and JProressBar while focus traversal.

 Since the both the components are derived out of Component class both are 
 default to focusable to true(Component.java) but because of the way 
 accept() method is overridden, JProgressBar's focusable state is 
 considered only when the focus traversable is overridden(not 
 FOCUS_TRAVERSABLE_DEFAULT). Now by calling setFocusable() explicitly 
 overrides the current policy to FOCUS_TRAVERSABLE_SET, hence the focusable 
 state of the JProgressBar is considered afterwards.

 Hope this answers. Please let me know if you 

Re: [12] RFR JDK-8213181:Updation of ProblemList.txt for removal of passing swing test

[Prasanta Sadhukhan]

On 08-Nov-18 11:59 AM, Prasanta Sadhukhan wrote:



On 08-Nov-18 11:52 AM, Sergey Bylokhov wrote:

On 07/11/2018 21:44, Prasanta Sadhukhan wrote:
I found that these tests are passing when ran for 100 iterations on 
windows

javax/swing/plaf/basic/Test6984643.java


It is necessary to check the code of the tests as well, for example 
the test above was reported in JDK-8198340.
The reason is that we have a race between shiudown of the app(caused 
by the jtreg) and initialization
of the test on EDT because the test uses invokeLater(), so the main() 
method is ended before the end of invokeLater().


And it looks like a product bug in Win32ShellFolderManager2 which 
should not throw IllegalStateException.


Others tests should be checked is a similar way.

BTW if the test is not marked as @headful it is necessary to check 
its stability in the headless environment as well.



I guess these 2 tests which I have added in last sprint because they 
fail in local machine (and not in mach5)

javax/swing/JButton/8151303/PressedIconTest.java
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java 

are marked as headful and passing for 100 iterations, so I guess at 
least we should remove these 2 tests for this bugid as it does not 
need to be tested in mac5.


Rest I will look at later point as you told it might be some 
instability that might cause it.



javax/swing/JComboBox/6607130/bug6607130.java
- Could not find anything wrong with test. Sometimes, if mouse is moved 
while test is running, then we can get the same problem as mentioned in 
the bug JDK-8196091 and this is headful so no need to test on mach5.

Can we remove this from problemlist?

javax/swing/JPopupMenu/6675802/bug6675802.java
- Could not find anything wrong with test. No exception is found in 
windows7 and windows10 (as mentioned in bugreport JDK-8196097) and test 
passed. It was failing locally and now passing in our windows7,10.

Not marked as headful so willl not remove from problemlist

javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java
- as per JDK-8196098, failing with wrong jtextfield height. But it 
passed for us in windows7,10. probably some font issue that might have 
existed in Phil's machine. Marked as headful so no issue with mach5.

Can we remove this from problemlist?

javax/swing/plaf/basic/Test6984643.java
- As stated above. will not remove from problemlist

javax/swing/text/JTextComponent/5074573/bug5074573.java
sun.awt.SunToolkit$InfiniteLoop
at java.desktop/sun.awt.SunToolkit.realSync(SunToolkit.java:1474)
at java.desktop/sun.awt.SunToolkit.realSync(SunToolkit.java:1402)
at java.desktop/java.awt.Robot.waitForIdle(Robot.java:692)
where realSync() in Robot.java was added as per JDK-8076178 

Although it pass for 100 iterations, I will not remove this from 
Problemlist as not sure why it failed last time as the realsync call is 
still present in same location in Robot.java


javax/swing/SwingWorker/6493680/bug6493680.java
- mach5 instablity. will not remove from problem list

javax/swing/UIDefaults/8149879/InternalResourceBundle.java
- mach5 instablity. will not remove from problem list

javax/swing/PopupFactory/8048506/bug8048506.java
- test fails to dispose frame and hides popup. although it has worked 
for 100 iterations, it might cause some issue sometime due to 
non-disposal. will not remove from problemlist.


In light of above comments, I think we can safely remove these below 4 
tests from problemlist


javax/swing/JButton/8151303/PressedIconTest.java
javax/swing/JWindow/ShapedAndTranslucentWindows/ShapedPerPixelTranslucentGradient.java 



javax/swing/JComboBox/6607130/bug6607130.java
javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java

Regards
Prasanta


Regards
Prasanta

Re: [12] RFR JDK-8198334: java/awt/FileDialog/8003399/bug8003399.java fails in headless mode

[Prasanta Sadhukhan]

Hi Sergey,

Actually, I was more concerned about the swing test failure 
com/sun/java/swing/plaf/windows/Test8173145 which I guess is failing with 
HeadlessException. I can create a separate bug for this test alone and handle 
this tag addition in the test case w.r.t that bug.
Will that be fine?

For the 1st 2 awt tests, it seems to throw ClassCastEzxception which I will 
leave alone. I was handling it only because it was mixed with this swing test.

Regards
Prasanta
- Original Message -
From: sergey.bylok...@oracle.com
To: prasanta.sadhuk...@oracle.com, swing-dev@openjdk.java.net, 
awt-...@openjdk.java.net
Sent: Wednesday, November 7, 2018 3:08:00 AM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re:  [12] RFR JDK-8198334: 
java/awt/FileDialog/8003399/bug8003399.java fails in headless mode

Hi, Prasanta.

An exception which was occurred in these tests are not HeadlessException but 
ClassCastException
which is think is a product bug.

On 05/11/2018 02:16, Prasanta Sadhukhan wrote:
> Hi All,
> 
> Please review a fix for an issue where some tests are found to be failing 
> with HeadlessException in mach5 systems.
> Proposed fix is to mark those tests as headful.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198334
> webrev: http://cr.openjdk.java.net/~psadhukhan/8198334/webrev.0/
> 
> Regards
> Prasanta


-- 
Best regards, Sergey.