JDK-8290469: Add new positioning options to PassFailJFrame test framework #9525

honkar-jdk · 2022-07-16T01:00:43Z

Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.

In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.

Additionally getInstructionFrameBounds() is added to obtain the position and dimensions of test instruction frame.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8290469: Add new positioning options to PassFailJFrame test framework

Reviewers

Phil Race (@prrace - Reviewer) ⚠️ Review applies to 7d4f4c86
Alexey Ivanov (@aivanov-jdk - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525
$ git checkout pull/9525

Update a local copy of the PR:
$ git checkout pull/9525
$ git pull https://git.openjdk.org/jdk pull/9525/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 9525

View PR using the GUI difftool:
$ git pr show -t 9525

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/9525.diff

bridgekeeper · 2022-07-16T01:01:49Z

👋 Welcome back honkar! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-07-16T01:06:06Z

@honkar-jdk The following label will be automatically applied to this pull request:

client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-07-16T01:10:34Z

Webrevs

prrace · 2022-07-19T22:58:02Z

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

     */
    public static void positionTestWindow(Window testWindow, Position position) {
        Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
+


In this method we "randomly" use getX(), or getLocation().x and getY() or and getLocation().y
Why can't we be consistent and pick one style ? Seems like getX() and getY() would fit best here.

prrace · 2022-07-19T23:02:04Z

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

+     *                  VERTICAL - both test instruction frame and test window
+     *                  as arranged up and down.
+     *                  TOP_LEFT_CORNER - test instruction frame positioned at
+     *                  top left corner with main test window beside it.


All of these descriptions are lacking in explaining what goes where
eg
HORIZONTAL should say the instruction window will be placed so that the right edge is to the left of the screen's horizontal centre and the test window will be placed just to the right of it.

TOP_LEFT_CORNER should say the instruction window will be placed so that its top left corner is at the top left corner of the screen and the test window will be placed just to the right of the instruction window.

@prrace I have slightly changed the description as per your suggestion. Please let me know if any changes are required.

HORIZONTAL - the test instruction frame is positioned such that its right edge aligns with screen's vertical center and the test window is placed to the right of the instruction frame.

VERTICAL - the test instruction frame is positioned such that its bottom edge aligns with the screen's horizontal center and the test window is placed below the instruction frame.

TOP_LEFT_CORNER - the test instruction frame is positioned such that its top left corner is at the top left corner of the screen and the test window is placed to the right of the instruction frame. (Taskbar placed at the top of the screen in this example)

prrace · 2022-07-19T23:10:37Z

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

        } else if (position.equals(Position.VERTICAL)) {
            int newY = ((screenSize.height / 2) - frame.getHeight());
            frame.setLocation(frame.getX(), newY);

            testWindow.setLocation(frame.getX(),
                    (frame.getLocation().y + frame.getHeight() + 5));
        }
+        else if (position.equals(Position.TOP_LEFT_CORNER)) {
+            frame.setLocation(0,0);


I am very sceptical of this. With a toolbar on the left and a menu bar on the top of the screen I bet you
are neither at x=0 or y=0.
And this code is not allowing the desktop to reposition it and report the updated REAL position back to you
The result will be overlapping windows.
I'm actually dubious of the existing code for much the same reason but it just likely hasn't been seen as a problem there because positioning in the middle of the screen usually gets you where you asked for.

@prrace Thank you for reviewing. I do see your point - when taskbars and menu bars are located on top or left side of the screen, they would overlap the test instruction frame.

Two possible solutions:

Going with a fixed amount of offset on where to position the top-left corner of the instruction frame window. Probably this would not be ideal considering different screen settings and platforms.

The other approach would be to use GraphicsEnvironment.getMaximumWindowBounds() to get the displayable window size and position the instruction frame accordingly ?

More than that - this code needs to call setlocation, and do "whatever" to make sure that is actually pushed to the "window manager" and the REAL location of the window come back. The way the code is written it sets a couple of vars and then reads back its own values .. no chance of finding the REAL location

In the recent update the following points are addressed:

Screen insets are used to account of taskbar position and the placement of the instruction frame at top-left corner

Position option description update

Changes regarding pushing the latest position to window manager are still being evaluated and in progress.

Following is a proposed solution to push the latest position changes to the window manager.

The get and setLocation calls are wrapped in invokeLater(). Robot.waitForIdle() are added between setLocation() and the subsequent getLocation() calls. The waitForIdle() calls ensures that any pending location updates are pushed to the window manager before the new location of the frame is in turn used to position the testWindow.

In multiple test window cases ONLY the test instruction frame and the main/root test window are positioned using positionTestWindow(), the rest of the windows are positioned within EDT at test-level.

Impact of the proposed fix:
With this change positionTestWindow() can no longer be called on EDT at test-level, hence any existing manual tests calling this method on EDT requires changes.

For example: In this particular test, the following line PassFailJFrame.positionTestWindow(frame,PassFailJFrame.Position.HORIZONTAL) should be called after createAndShowGUI()

jdk/test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java

Line 75 in d333df8

PassFailJFrame.positionTestWindow(frame,

public static void positionTestWindow(Window testWindow, Position position) throws AWTException { if (isEventDispatchThread()) { throw new Exception("positionTestWindow() should not be called on EDT"); } robot = new Robot(); Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize(); if (position.equals(Position.HORIZONTAL)) { SwingUtilities.invokeAndWait(() -> { int newX = ((screenSize.width / 2) - frame.getWidth()); frame.setLocation(newX, frame.getY()); }); // waits until the queue is flushed robot.waitForIdle(); robot.delay(300); SwingUtilities.invokeAndWait(() -> testWindow.setLocation((frame.getX() + frame.getWidth() + 5), frame.getY())); } else if (position.equals(Position.VERTICAL)) { SwingUtilities.invokeAndWait(() -> { int newY = ((screenSize.height / 2) - frame.getHeight()); frame.setLocation(frame.getX(), newY); }); robot.waitForIdle(); robot.delay(300); SwingUtilities.invokeAndWait(() -> testWindow.setLocation(frame.getX(), (frame.getY() + frame.getHeight() + 5))); } else if (position.equals(Position.TOP_LEFT_CORNER)) { SwingUtilities.invokeAndWait(() -> { GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment() .getDefaultScreenDevice().getDefaultConfiguration(); Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc); frame.setLocation(screenInsets.left, screenInsets.top); }); robot.waitForIdle(); robot.delay(300); SwingUtilities.invokeAndWait(() -> testWindow.setLocation((frame.getX() + frame.getWidth() + 5), frame.getY())); } }

We should discuss that impact.
This method is useful to simplify the logic of individual tests but is it now becoming awkward to use ?
Or is it something that we should have required from the beginning ?
And why invokeLater and not invokeAndWait ? I'd have expected Later to not work for this case ..

The interleaving does seem to make the code more complex. And at test-level, it causes some confusion as few methods need to be called within EDT and few out of EDT.

Initially there were just two positions - HORIZONTAL, VERTICAL and the issue wasn't evident probably, but with multiple frames scenario and TOP_LEFT corner positioning this issue became more evident.

I chose invokeLater earlier because waitForIdle is called after it and it waits until the queue is empty. But I think invokeAndWait would be a better option here. In the above code snippet (proposed fix) invokeLater() is now replaced with invokeAndWait().

Additionally, I want check if anyone has a simpler and much cleaner approach. At this stage evaluating and rewriting the framework (if required) is manageable. In future, as more and more manual test cases happen to use this framework, the amount of rework needed might be more.

Another possible approach - Use of JSPLITPANE , details added below.

@prrace Updated the PR - added Toolkit.sync and Thread.sleep. Additionally, added few more changes as mentioned here - #9525 (comment) & #9525 (comment)

honkar-jdk · 2022-07-28T17:48:55Z

Another approach would be to use a JSplitPane to have the instruction frame and the main test frame as one window. Left half/top as instruction frame and Right half/ bottom as the main test window and this also provides HORIZONTAL_SPLIT or VERTICAL_SPLIT orientation equivalent to HORIZONTAL and VERTICAL positioning of PassFailJFrame.

Advantage of this approach:

No need to manually position the instruction frame and then the test window, as it will be one window - JSplitPane
Entire window (test + instruction frame) need to be positioned only once.
With this change, we might no longer need positionTestWindow() method, additionally the framework code will be simple and straightforward.

prrace · 2022-07-29T20:12:47Z

I can confirm that on Linux / Gnome with menu bar at the top and
toolbar on the left, that the requested location of 0,0 is not where
the window is placed but if called immediately both getLocation()
and getLocationOnScreen() may report back (0,0) leading to incorrect
positioning of the 2nd window.

Calling Toolkit.sync() isn't enough to ensure it is always correct.
In two runs of the same test code (my code below but without a sleep call) in one
case it then reports (0,0) and in another (74,27) - the actual location.

Calling isVisible() or isShowing() don't help.

The simplest thing that works every time for me is to add a short sleep()
to give time for everything to be processed. I didn't need the Robot.
It works both off and on the EDT.
Not 100% satisfactory as there really ought to be a better way but it seems
much more reliable than what we had and it keeps it easy to use.
I only tried this on Ubuntu 22.04 .. you'll need to test some other platforms
So just give that a try but do KEEP the insets calculations for the safest results.
import java.awt.*;

public class F {

public static void main(String[] args) throws Exception {
//doit();
EventQueue.invokeAndWait(F::doit);
}

public static void doit() {

Frame f1 = new Frame("Frame 1");
f1.setSize(300,200);
f1.setLocation(0,0);
f1.show();

Toolkit.getDefaultToolkit().sync();
try { Thread.sleep(500); } catch (InterruptedException e) {}
System.out.println("screen location ="+f1.getLocationOnScreen());
System.out.println("frame location ="+f1.getLocation());
System.out.println("frame size ="+f1.getSize());

int f2x = f1.getLocation().x+f1.getWidth();
int f2y = f1.getY();
System.out.println("desired frame 2 location = " + f2x + ", "+ f2y);
Frame f2 = new Frame("Frame 2");
f2.setSize(200,300);
f2.setLocation(f2x, f2y);
f2.show();
System.out.println("frame 2 location = " + f2.getLocation());

}
}

honkar-jdk · 2022-07-29T21:04:52Z

I can confirm that on Linux / Gnome with menu bar at the top and
toolbar on the left, that the requested location of 0,0 is not where
the window is placed but if called immediately both getLocation()

@prrace Thank you for checking it on Linux. Adding a delay would be the best option to get the updated location values in this scenario then.

Another approach that I had in mind was to change PassFailJFrame to use a JSplitPane (single window) for instructions and test window. This way there is no hassle of managing the positioning of 2 windows as described above #9525 (comment)

Please let me know your suggestions on JSplitPane approach.

prrace · 2022-07-29T21:10:39Z

Please let me know your suggestions on JSplitPane approach.

I think it very unlikely a JSplitPane would satisfy all test requirements.

honkar-jdk · 2022-07-29T21:19:46Z

Please let me know your suggestions on JSplitPane approach.

I think it very unlikely a JSplitPane would satisfy all test requirements.

@prrace Do you mean - a multiple frame test scenario or any other scenario in particular? We could readjust the splits (divider location) based on different test requirements and make the test window optional (if required).
Currently for the multiple frame scenario - we have a instruction window and a root test frame , the rest of the frames are arranged at test-level.

prrace · 2022-07-29T22:01:44Z

Well .. there surely must be test scenarios where a Frame is required. Perhaps the test moves it, iconifies, needs
a specific size .. expects focus to move in a certain order between components in the frame .. wants to use
heavyweight AWT components .. .in some of these I expect the extra instruction part doesn't matter but you only have to find ONE case where it matters .. then there's the fact you'd have to rewrite all the existing tests. And why a JSplitPane, anyway ? Odd choice.

I can imagine that it might be interesting to add a new version that works with a JPanel as the container for the test and let a test author decide if they want to use that for future tests.

honkar-jdk · 2022-07-29T23:51:30Z

@prrace I see your point and the broader range of testing requirements that might need to be supported by the test framework in future such as iconifying/ minimizing test frames.

Earlier when I suggested JSplitPane, I was looking it from ease of positioning, disposing and that most of the manual tests had more or less - one instruction frame and one test window which could be achieved using the JSplitPane. I probably missed analyzing the part about broader support of framework for future test cases.

Another approach would be to use a JSplitPane to have the instruction frame and the main test frame as one window. Left half/top as instruction frame and Right half/ bottom as the main test window and this also provides HORIZONTAL_SPLIT or VERTICAL_SPLIT orientation equivalent to HORIZONTAL and VERTICAL positioning of PassFailJFrame.

Advantage of this approach:

No need to manually position the instruction frame and then the test window, as it will be one window - JSplitPane

Entire window (test + instruction frame) need to be positioned only once.

With this change, we might no longer need positionTestWindow() method, additionally the framework code will be simple and straightforward.

aivanov-jdk · 2022-08-02T20:07:04Z

I don't think JSplitPane is a bad idea, rather the opposite: it's a good idea. It encapsulates a JPanel as a container for test UI. If a test doesn't add UI to that area (via a callback, or lambda or method reference, or any other way), the instructions UI could be left as the sole content of the frame. Otherwise, JSplitPane will separate the parts in the frame and will allow changing the size of the panes. It also mimics the original positioning strategy: vertical/horizontal.

In some tests, the test UI consists of a single button only. I think a single window for such test UI would work better than two separate and independent frames. One frame is easier to manage.

I was thinking about merging instructions and test UI from the start. Yet using two frames / windows seemed easier to implement.

Some test cases may not fit into either pattern. There's always the option to create test UI as needed. Yet positioning of the instruction frame may be an issue. If test creates windows / dialogs owned by the instruction frame, AWT ensures the test UI windows / dialogs are above the instruction frame; however, if test UI is large enough, it could completely overlap the instructions.

I guess some test cases may even be easier to implement and maintain with its own custom UI. Too many options in PassFailJFrame could make it harder to use.

honkar-jdk · 2022-08-03T19:42:43Z

After evaluating possible alternative solutions as well as suggestions provided by @prrace & @aivanov-jdk, I think introducing small delay (Thread.sleep) would be the best option - for syncing the updated position to window manager and keeping in mind the broader range of testing requirement that the framework needs to support for now.

honkar-jdk · 2022-08-05T00:41:04Z

The recent commit has the following changes -

Toolkit sync and Thread.sleep added to push the frame's updated location to window manager
Position of setVisible for instruction frame moved from createUI to positionTestWindow. Before this change the frame was initially visible for sometime in its initial location for a few seconds before moving to its final position set in positionTestWindow.
For the same reason as above, the setVisible for testWindow is called after positionTestWindow() at test-level. The switch from the initial to the final position is more evident due to Thread.sleep hence the position of setVisible is changed in tests and PassFailJFrame.

honkar-jdk · 2022-08-05T17:37:30Z

Added null check for testWindow in positionWindow as the following line testWindow.setLocation(.....); will produce NPE if positionWindow is called with testWindow = null.

In some tests testWindow is not required, for example TrayIconScalingTest.java in which case we can call PassFailJFrame.positionTestWindow(null,PassFailJFrame.Position.HORIZONTAL);

aivanov-jdk · 2022-08-05T19:13:18Z

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

    public static void positionTestWindow(Window testWindow, Position position) {
        Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
+
+        // to get the screen insets inorder to position the frame by taking into
+        // account the location of taskbar/menubars on screen
+        GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment()
+                .getDefaultScreenDevice().getDefaultConfiguration();
+        Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
+


I suggest separating the logic to calculate coordinates into a separate function, or save them into a local variable.

Then call sync and sleep. Or this sequence could be extracted into its own helper method to avoid code duplication, it's repeated at least twice.

Shall this method call window.setVisible(true) automatically?

@aivanov-jdk As suggested, separating the common code into a helper method would make the code look cleaner.

Earlier I did think about having the setVisible for both the testWindow and instruction frame within the positionWindow but usually at the test-level, the user would be in the habit of creating the testWindow and setting its visibility to true when creating test UI. Hence left it to be set at test-level. I can change it, if this approach is better.

Either way we need to make minor changes to existing manual tests - remove (in case we add testWindow.setVisible(true) to PassFailJFrame) or reposition (in case we retain it at test-level) setVisible() call.

Toolkit.sync + Thread.sleep extracted to a separate helper method.

Earlier I did think about having the setVisible for both the testWindow and instruction frame within the positionWindow but usually at the test-level, the user would be in the habit of creating the testWindow and setting its visibility to true when creating test UI. Hence left it to be set at test-level. I can change it, if this approach is better.

Either way we need to make minor changes to existing manual tests - remove (in case we add testWindow.setVisible(true) to PassFailJFrame) or reposition (in case we retain it at test-level) setVisible() call.

@aivanov-jdk I have retained setVisible() for testWindow on test side (where test UI is created) for reasons as described above. Please let me know in case it is better to have it within positionWindow().

aivanov-jdk · 2022-08-05T19:18:21Z

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

+            Toolkit.getDefaultToolkit().sync();
+            try {
+                Thread.sleep(500);
+            } catch (InterruptedException e) {
+                e.printStackTrace();
+            }


Is it safe to call on EDT?

If positionTestWindow is not to be called on EDT, should it be enforced?

The intention is that it can be called either way - on or off.

Is that possible? Toolkit thread is not EDT, therefore native events are processed, it's probably enough to update the frame coordinates while EDT is blocked and doesn't handle events.

Can you expand on what you mean ?
What's the problem with native events being processed ? We want that.
And this obviously isn't being called on the toolkit thread.

This change isn't doing anything to that method that might change threading reqts or rules of use.
Any problems already existed. What is being changed (apart from adding the new API) is just to make it more robust.

The intention is that it can be called either way - on or off.

@aivanov-jdk As @prrace mentioned, the main reason for opting - Toolkit.sync + Thread.sleep approach instead of robot.waitForIdle() was to give the test user the flexibility to call positionTestWindow on or off EDT. (since test cases can contain either AWT or Swing components). #9525 (comment)

With waitForIdle() approach we had to wrap parts of the code within EDT and part of it out of EDT, this was confusing and complex.

@prrace I'm just trying to understand how it works and whether it changes threading requirements. Thread.sleep blocks the EDT, no events are handled. If processing native events is enough to update the frame coordinates, that's good.

Thank you both for clarifying.

honkar-jdk · 2022-08-22T22:33:15Z

Based on this discussion #9525 (comment), Added the term "approximately positions" to positionTestWindow() javadoc.

honkar-jdk · 2022-08-22T22:36:31Z

/integrate

openjdk · 2022-08-22T22:38:33Z

@honkar-jdk
Your change (at version 2c72bc3) is now ready to be sponsored by a Committer.

honkar-jdk · 2022-08-22T22:49:48Z

Adding a button 'Screen capture' ( Screen shot ) in test instruction frame when user clicks to fail button to capture the failure scenario will be good idea. Screen shot to capture both test instruction frame as well as Test frame. This will help every one to know the following

Test scenario that user is testing

What exactly user is seeing on the screen ( test frame ) along with failure reason that user is entering now.

Another thing do later in a follow on RFE. It is a stretch to add that to a fix that adds a new positioning option.

The above suggestion was meant to be added by @lawrence-andrew as part of the test framework redesign discussion #9525 (comment)

prsadhuk · 2022-08-23T05:21:48Z

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

+     * window as specified by the {@code position} parameter. If testWindow
+     * is null, only the instruction frame is positioned according to
+     * {@code position} parameter. This method should be called before making
+     * the test window visible.


Since this condition is documented, should we also implement check to handle it by calling isShowing() and throw some warning/exception if its visible.
We do the opposite for getLocationOnScreen() where we throw exception if the compoment is not showing.

Since this condition is documented, should we also implement check to handle it by calling isShowing() and throw some warning/exception if its visible. We do the opposite for getLocationOnScreen() where we throw exception if the compoment is not showing.

It's more like a recommendation rather than a requirement. It is to avoid flickering when the window gets displayed for a very short period of time at its default position before being moved to its final position.

The same had happened to the instruction frame before Harshitha moved setVisible(true).

Yes, as described by @aivanov-jdk ,this was added to avoid flickering (happens when windows move from the initial to the final position).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java

aivanov-jdk · 2022-08-23T18:52:56Z

Adding a button 'Screen capture' ( Screen shot ) in test instruction frame when user clicks to fail button to capture the failure scenario will be good idea. Screen shot to capture both test instruction frame as well as Test frame.

Capturing the entire screen is a better option. The test may create other windows, the image of the entire screen would be more useful.

honkar-jdk · 2022-08-24T16:13:51Z

/integrate

openjdk · 2022-08-24T16:16:15Z

@honkar-jdk
Your change (at version 2db5b8a) is now ready to be sponsored by a Committer.

aivanov-jdk · 2022-08-24T16:21:04Z

/sponsor

openjdk · 2022-08-24T16:23:38Z

Going to push as commit 568be58.
Since your change was applied there have been 32 commits pushed to the master branch:

69448f9: 8292679: Simplify thread creation in gtest and port 2 tests to new way
3c2289d: 8215916: The failure reason of an optional JAAS LoginModule is not logged
71ab5c9: 8292816: GPL Classpath exception missing from assemblyprefix.h
c062397: 8292713: Unsafe.allocateInstance should be intrinsified without UseUnalignedAccesses
a45a4b9: 8292194: G1 nmethod entry barrier disarm value wraps around too early
d3fed12: 8292864: Remove resourceHash.hpp from header files
b653b9c: 8291969: Convert LoaderConstraintsTable to ResourceHashtable
0813a47: 8282729: Serial: Move BOT implementation to collector specific directory
fa5cc4c: 8291878: NMT: Malloc limits
ad2e0c4: 8292778: EncodingSupport_md.c convertUtf8ToPlatformString wrong placing of free
... and 22 more: https://git.openjdk.org/jdk/compare/aa9b8f04bf74d5fa00f2b27895e7369abea3a930...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-08-24T16:23:57Z

@aivanov-jdk @honkar-jdk Pushed as commit 568be58.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

PassFailJFrame changes for multiple frame scenarios

fb35ce2

openjdk bot added the rfr Pull request is ready for review label Jul 16, 2022

openjdk bot added the client client-libs-dev@openjdk.org label Jul 16, 2022

honkar-jdk marked this pull request as draft July 18, 2022 06:13

openjdk bot removed the rfr Pull request is ready for review label Jul 18, 2022

honkar-jdk changed the title ~~JDK-8289075: Change manual tests to use PassFailJFrame test framework~~ JDK-8289075: PassFailJFrame and manual test changes Jul 18, 2022

honkar-jdk changed the title ~~JDK-8289075: PassFailJFrame and manual test changes~~ JDK-8290469: Add new positioning options to PassFailJFrame test framework Jul 18, 2022

Top left positon added

230ca0b

honkar-jdk marked this pull request as ready for review July 18, 2022 21:00

openjdk bot added the rfr Pull request is ready for review label Jul 18, 2022

window positioning changes

bb981d4

prrace suggested changes Jul 19, 2022

View reviewed changes

added screen insets to account for taskbar position, doc changes

994888b

added Thread.sleep and changed the location of setVisible

195002d

added null check in positionWindow

96629ad

aivanov-jdk reviewed Aug 5, 2022

View reviewed changes

openjdk bot added ready Pull request is ready to be integrated and removed ready Pull request is ready to be integrated labels Aug 22, 2022

minor change to positionTestWindow javadoc

2c72bc3

openjdk bot added the sponsor Pull request is ready to be sponsored label Aug 22, 2022

prsadhuk reviewed Aug 23, 2022

View reviewed changes

aivanov-jdk suggested changes Aug 23, 2022

View reviewed changes

honkar-jdk and others added 2 commits August 23, 2022 11:19

Updated javadoc as per the review comments

9d62d41

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

Updated javadoc as per the review comments

3a52e6d

Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk@users.noreply.github.com>

openjdk bot removed the sponsor Pull request is ready to be sponsored label Aug 23, 2022

aivanov-jdk suggested changes Aug 23, 2022

View reviewed changes

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java Outdated Show resolved Hide resolved

javadoc changes

2db5b8a

aivanov-jdk approved these changes Aug 23, 2022

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Aug 24, 2022

openjdk bot added the integrated Pull request has been integrated label Aug 24, 2022

openjdk bot closed this Aug 24, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Aug 24, 2022

aivanov-jdk mentioned this pull request Sep 15, 2022

8293811: Provide a reason for PassFailJFrame.forceFail #10269

Closed

3 tasks

azvegint mentioned this pull request Dec 16, 2022

8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display openjdk/jdk20#46

Closed

3 tasks

JDK-8290469: Add new positioning options to PassFailJFrame test framework #9525

JDK-8290469: Add new positioning options to PassFailJFrame test framework #9525

Conversation

honkar-jdk commented Jul 16, 2022 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jul 16, 2022

openjdk bot commented Jul 16, 2022

mlbridge bot commented Jul 16, 2022 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk Jul 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk Jul 21, 2022 • edited Loading

Choose a reason for hiding this comment

honkar-jdk Jul 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk Jul 22, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk commented Jul 28, 2022 • edited Loading

prrace commented Jul 29, 2022

honkar-jdk commented Jul 29, 2022

prrace commented Jul 29, 2022

honkar-jdk commented Jul 29, 2022 • edited Loading

prrace commented Jul 29, 2022

honkar-jdk commented Jul 29, 2022 • edited Loading

aivanov-jdk commented Aug 2, 2022 • edited Loading

honkar-jdk commented Aug 3, 2022

honkar-jdk commented Aug 5, 2022 • edited Loading

honkar-jdk commented Aug 5, 2022 • edited Loading

Choose a reason for hiding this comment

honkar-jdk Aug 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk Aug 8, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk Aug 5, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk commented Aug 22, 2022 • edited Loading

honkar-jdk commented Aug 22, 2022

openjdk bot commented Aug 22, 2022

honkar-jdk commented Aug 22, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk Aug 23, 2022 • edited Loading

Choose a reason for hiding this comment

aivanov-jdk commented Aug 23, 2022

honkar-jdk commented Aug 24, 2022

openjdk bot commented Aug 24, 2022

aivanov-jdk commented Aug 24, 2022

openjdk bot commented Aug 24, 2022

openjdk bot commented Aug 24, 2022

honkar-jdk commented Jul 16, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Jul 16, 2022 •

edited

Loading

honkar-jdk Jul 21, 2022 •

edited

Loading

honkar-jdk Jul 21, 2022 •

edited

Loading

honkar-jdk Jul 21, 2022 •

edited

Loading

honkar-jdk Jul 22, 2022 •

edited

Loading

honkar-jdk commented Jul 28, 2022 •

edited

Loading

honkar-jdk commented Jul 29, 2022 •

edited

Loading

honkar-jdk commented Jul 29, 2022 •

edited

Loading

aivanov-jdk commented Aug 2, 2022 •

edited

Loading

honkar-jdk commented Aug 5, 2022 •

edited

Loading

honkar-jdk commented Aug 5, 2022 •

edited

Loading

honkar-jdk Aug 5, 2022 •

edited

Loading

honkar-jdk Aug 8, 2022 •

edited

Loading

honkar-jdk Aug 5, 2022 •

edited

Loading

honkar-jdk commented Aug 22, 2022 •

edited

Loading

honkar-jdk commented Aug 22, 2022 •

edited

Loading

honkar-jdk Aug 23, 2022 •

edited

Loading