Re: [OpenJDK 2D-Dev] [12] Review Request: 8213110 Remove the use of applets in automatic tests

[Sergey Bylokhov]

The "ProblemList.txt" is updated in the new version:
http://cr.openjdk.java.net/~serb/8213110/webrev.04

On 08/11/2018 10:57, Sergey Bylokhov wrote:

Note that for some of the tests I'll need to update the problem list and 
replace the .html by the .java.
But since we actively updates the problem lists right now I postponed this task 
for a weekend.

On 07/11/2018 15:47, Sergey Bylokhov wrote:

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]RFR: JDK-8213048: Invalid use of HTML5 in java.awt files

[Sergey Bylokhov]

Hi, Krishna.


I added the closing "" tag, since it wouldn't hurt and the tool was 
reporting it.


But this tag is unused in our code, is not required by html5 and it was not 
reported in the bug report.
So I suggest to do not add them.


As for the style spec, thanks for your suggestion, I have moved it to the style 
block in the head section.


Can we to drop them completely? are these custom styles really necessary?

--
Best regards, Sergey.

RFR: 8214298 Add non interactive test case for JDK-8211267

[Ichiroh Takiguchi]

Hello.
Could you review the fix ?

Issue:
JDK-8211267 requires non interactive test case

Bug:https://bugs.openjdk.java.net/browse/JDK-8214298
Change: https://cr.openjdk.java.net/~itakiguchi/8214298/webrev.00/

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

RFR: X11 default visual support for IM status window on VNC

[Ichiroh Takiguchi]

Hello.

Could you review the fix ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212677
Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/

Screen shots are in JDK-8212677.

I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-06-21 21:58, Ichiroh Takiguchi wrote:

Hello Phil.

I'm sorry, I forgot to put my comment against your question.

Is this changing the default visual  for all WIndows, not just the IM 
status window?
I think we need to understand the implications before this can be 
accepted.

I put following debug code:
===
diff -r e1b3def12624
src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
--- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
 Wed Jun 13 06:35:04 2018 +0200
+++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
 Thu Jun 21 21:23:11 2018 +0900
@@ -667,6 +667,7 @@
 InputOutput,
 adata->awt_visInfo.visual,
 attribmask, );
+fprintf(stderr, "status window id = 0x%X\n", status);
 XSelectInput(dpy, status,
  ExposureMask | StructureNotifyMask | EnterWindowMask 
|

  LeaveWindowMask | VisibilityChangeMask);
@@ -680,6 +681,21 @@
 statusWindow->fontset = XCreateFontSet(dpy,

"-*-*-medium-r-normal-*-*-120-*-*-*-*",
, , );
+{
+int cntFonts;
+for(cntFonts = 0; cntFonts < mccr; cntFonts++) {
+fprintf(stderr, "[M][%d] %s\n", cntFonts, mclr[cntFonts]);
+}
+}
+{
+XFontStruct **font_struct_list;
+char **font_name_list;
+int cntFonts;
+int numFonts = XFontsOfFontSet(statusWindow->fontset,
_struct_list, _name_list);
+for(cntFonts = 0; cntFonts < numFonts; cntFonts++) {
+fprintf(stderr, "[L][%d] %s\n", cntFonts,
font_name_list[cntFonts]);
+}
+}
 /* In case we didn't find the font set, release the list of
missing characters */
 if (mccr > 0) {
 XFreeStringList(mclr);
===

I tested it on RHEL7.
I thought since window id was assigned, but it was gone on current 
code.

===
$ java -jar Notepad.jar
status window id = 0x455
...
$ xwininfo -id 0x455
X Error: 9: Bad Drawable: 0x455
  Request Major code: 14
  Request serial number: 3
xwininfo: error: No such window with id 0x455.
===

===
$ java -jar Notepad.jar
status window id = 0x4CA
...
$ xwininfo -id 0x4CA

xwininfo: Window id: 0x4ca (has no name)

  Absolute upper-left X:  0
  Absolute upper-left Y:  600
  Relative upper-left X:  0
  Relative upper-left Y:  600
  Width: 80
  Height: 22
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: yes
  Corners:  +0+600  -944+600  -944-146  +0-146
  -geometry 80x22+0+600
===

According to main window: (Left side: without fix, right side: with 
fix)

===
xwininfo: Window id: 0x409 " (failure   |   xwininfo: Window id:
0x460007e " (failure

  Absolute upper-left X:  4   Absolute upper-left 
X:  4
  Absolute upper-left Y:  25  Absolute upper-left 
Y:  25
  Relative upper-left X:  0   Relative upper-left 
X:  0
  Relative upper-left Y:  0   Relative upper-left 
Y:  0

  Width: 492  Width: 492
  Height: 571 Height: 571
  Depth: 24   Depth: 24
  Visual: 0x169 | Visual: 0x21
  Visual Class: TrueColor Visual Class: 
TrueColor

  Border width: 0 Border width: 0
  Class: InputOutput  Class: InputOutput
  Colormap: 0x408 (not installed)   | Colormap: 0x20 
(installed)

  Bit Gravity State: NorthWestGravity Bit Gravity State:
NorthWestGravity
  Window Gravity State: NorthWestGravity  Window Gravity
State: NorthWestGravity
  Backing Store State: NotUseful  Backing Store State: 
NotUseful

  Save Under State: noSave Under State: no
  Map State: IsViewable   Map State: IsViewable
  Override Redirect State: no Override Redirect 
State: no

  Corners:  +4+25  -528+25  -528-172  +4-1Corners:  +4+25
-528+25  -528-172  +4-1
  -geometry 492x571+0+0   -geometry 492x571+0+0
===

So main window's visual also changed by this fix.


Similarly for the fontset change .. this might change what others get.
The fontset spec. there seems very loose to me ..


Without fix
===
$ java 

RFR: 8212676 AIX's CDE/MWM support

[Ichiroh Takiguchi]

Hello.

Could you review the fix ?

Bug:https://bugs.openjdk.java.net/browse/JDK-8212676
Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/

Test instructions and screen shots are in JDK-8212676.

GUI environment for AIX platform still needs CDE support.
This fix is required to avoid unexpected working behavior on AIX 
platform.


I'd like to obtain a sponsor for this issue.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2018-06-18 18:57, Ichiroh Takiguchi wrote:

Hello.

This fix is really required for AIX's GUI.
System color setting and window manager's working behavior are very 
important.


I appreciate any feedback, and how I would go about obtaining a
sponsor and contributor ?

On 2018-05-25 11:02, Ichiroh Takiguchi wrote:

Hello Phil.

webrev file was extracted.
Please see
  http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/

On 2018-05-19 02:48, Ichiroh Takiguchi wrote:

Hello Phil.

Webrev.zip file is stored into
  http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip

Test programs are also stored:
No testcase is available for FontUtilities.java and 
XDecoratedPeer.java.


MotifColorUtilities.java
  http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java
Run SystemColorTest2, system colors should be displayed
AIX sample is
  http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt

XWM.java
  http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java
On AIX CDE, isMotif and isCDE were true.
On AIX MWM, every entry is false.

XWindowPeer.java
  http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java
On AIX CDE, click inside of "Non-Focusable" window (not window 
frame).
Window focus should not be changed because of "click on focus" 
feature.

But input focus is moved to "Non-Focusable" window.


On 2018-05-18 01:00, Phil Race wrote:

I think we'd need to see the actual proposed changes and understand
the implications
for ongoing support as we no longer support any platform which has a
CDE desktop.
Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out
such support rather
than adding to it.

-phil.

On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote:

Hello,
IBM would like to contribute AIX's CDE (Common Desktop Environment) 
DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support 
to OpenJDK project.


I'd like contribute following 5 files:

M src/java.desktop/share/classes/sun/font/FontUtilities.java
(Add isAIX flag to determine AIX platform for GUI environment)
M 
src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java
(Add High Color support on CDE, OpenJDK just supports Medium Color) 
[1]

M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
(Avoid miss calculation for window position under DTWM/MWM by 
XMapRaised/XMapWindow)

M src/java.desktop/unix/classes/sun/awt/X11/XWM.java
(Detect MWM on AIX platform)
M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java
(Add non-focusable window support on DTWM/MWM for AIX, because 
DTWM/MWM does not have enough features for ICCCM)


I appreciate any feedback please, and how I would go about 
obtaining a sponsor and contributor ?


Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

[1] 
https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html

Re: [12] RFR 8213583: Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files

[Krishna Addepalli]

Hi Dmitry,

 

Thanks for fixing this issue. The change looks fine.

 

Thanks,

Krishna

 

From: Dmitry Markov 
Sent: Monday, November 26, 2018 4:09 PM
To: awt-dev@openjdk.java.net
Subject:  [12] RFR 8213583: Error while opening the JFileChooser when 
desktop contains shortcuts pointing to deleted files

 

Hello,

Could you review a fix for jdk12, please?

bug: https://bugs.openjdk.java.net/browse/JDK-8213583

webrev: http://cr.openjdk.java.net/~dmarkov/8213583/webrev.00/

 

Problem description:

On Windows when a SecurityManager is defined and JFileChooser is opened for the 
folder which contains a broken shortcut the system popup message is displayed. 
The current implementation of ShellFolder for Windows calls 
IShellLinkW::Resolve without any flags. So the appearance of the dialog with 
system message for the broken shortcut is quite expected, see 
https://docs.microsoft.com/en-us/windows/desktop/api/shobjidl_core/nf-shobjidl_core-ishelllinkw-resolve

 

Fix:

It is necessary to use SLR_NO_UI flag to suppress any system dialogs during 
IShellLinkW::Resolve invocation.

 

Thanks,

Dmitry 

[12] RFR 8213583: Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files

[Dmitry Markov]

Hello,

Could you review a fix for jdk12, please?

bug: https://bugs.openjdk.java.net/browse/JDK-8213583 

webrev: http://cr.openjdk.java.net/~dmarkov/8213583/webrev.00/ 


Problem description:
On Windows when a SecurityManager is defined and JFileChooser is opened for the 
folder which contains a broken shortcut the system popup message is displayed. 
The current implementation of ShellFolder for Windows calls 
IShellLinkW::Resolve without any flags. So the appearance of the dialog with 
system message for the broken shortcut is quite expected, see 
https://docs.microsoft.com/en-us/windows/desktop/api/shobjidl_core/nf-shobjidl_core-ishelllinkw-resolve
 


Fix:
It is necessary to use SLR_NO_UI flag to suppress any system dialogs during 
IShellLinkW::Resolve invocation.

Thanks,
Dmitry 

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

[Shashidhara Veerabhadraiah]

Thank you Alexey for the detailed reply below. The issue is closed as non-issue 
now.

Thanks and regards,
Shashi

-Original Message-
From: Alexey Ivanov 
Sent: Saturday, November 24, 2018 12:10 AM
To: Shashidhara Veerabhadraiah ; Sergey 
Bylokhov ; Krishna Addepalli 

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

Hi Shashi,

On 23/11/2018 06:04, shashidhara.veerabhadra...@oracle.com wrote:
> Hi Alexey, The accessible information is already set for the component 
> in question and that is the reason it works with the accessibility 
> short cut(without this fix).

Then there's no bug.
Hence there's nothing to fix.

> Now the question is that my fix works across platforms and for tab key 
> based focus traversal. So even without this fix, it works with 
> accessibility short cut only on mac. My understanding is that 
> accessibility short cut is specific to mac and there is nothing that 
> we can do as those are handled at the OS level. Tab key is used on 
> java for traversal and it works for other component's accessible 
> information being voiced over but not for this component(which was 
> fixed under this bug for all platform).

I don't agree to making JProgressBar focusable because it's not supposed to be 
focusable.

Yes, that accessibility shortcut is specific to macOS, more precisely it's 
specific to VoiceOver.

If VoiceOver reads the value of the progress bar when it's selected using 
VoiceOver navigation keys, then it works as expected, doesn't it?

Tab key is universally used to navigate between *interactive* components such 
as text fields and buttons.
No, Tab key does not work for other unfocusable components such as JLabel and, 
as Sergey pointed out [1][2], for disabled components.

So Tab key is used for a different purpose. It was already discussed in this 
thread [3].

Other platforms have other accessibility tools with their own specific shortcut 
keys to navigate between components. You would use the shortcuts specific to 
your accessibility tool. If it does not work — you cannot navigate to the 
progress bar or its state is not read when you navigate to it — then it's a bug.


To sum up:
JDK-7124285 [4] is not a bug. So you will close it as Not an Issue. In a 
comment you will explain what keys are used to select the progress bar. 
Here's the quote from Sergey's message [5] on November 7:

> I … confirm that it is possible to select progress bar using
> ctrl+option+up/down/left.
> Screenshot is attached to the bug.

If a similar issue exists on other platforms, you will file a bug to address 
that issue. If unsure, you can file a bug to investigate whether the progress 
bar is accessible or not.

Does it sound reasonable?

--
Regards,
Alexey

[1] http://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014695.html
[2] http://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014700.html
[3] http://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014715.html
[4] https://bugs.openjdk.java.net/browse/JDK-7124285
[5] http://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014636.html