On Wed, 16 Oct 2024 18:37:23 GMT, Manukumar V S wrote:
> This issue can be fixed by setting the preferred scrollable viewport size of
> the two tables using
> JTable table = new JTable(data, columnNames);
> + table.setPreferredScrollableViewportSize(table.getP
On Mon, 21 Oct 2024 15:44:54 GMT, Manukumar V S wrote:
>> This issue can be fixed by setting the preferred scrollable viewport size of
>> the two tables using
>> JTable table = new JTable(data, columnNames);
>> + table.setPreferredScrollableViewportSiz
ified manually in my
> local system
> Screenshots of before and after the fix are attached in the bug.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed : Removed the extra blank line
-
Changes:
- a
On Mon, 21 Oct 2024 10:25:26 GMT, Abhishek Kumar wrote:
> > The test initially failed on my local mac machine running Sonoma 14.6 also,
> > but when I changed the colour profile to sRGB, it started passing,
> > @kumarabhi006 can you please check the colour profile on your machine?.
>
> I don't
ified manually in my
> local system
> Screenshots of before and after the fix are attached in the bug.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed : Copyright year added, re-arranged imports, removed
author t
On Fri, 18 Oct 2024 15:54:24 GMT, Naveen Narayanan wrote:
>> This testcase checks for the following:
>>
>> 1. An image is drawn on the screen and a portion of it is captured using a
>> Robot. It is tested by comparing whether the captured image is same as the
>> source image.
>>
>> Testing:
On Mon, 21 Oct 2024 04:44:19 GMT, Abhishek Kumar wrote:
> @Naveenam-Oracle Test failed on my local mac machine running `Sonoma 14.5`.
The test initially failed on my local mac machine running Sonoma 14.6 also, but
when I changed the colour profile to sRGB, it started passing, @kumarabhi006
can
On Thu, 17 Oct 2024 18:53:53 GMT, Phil Race wrote:
>> This issue can be fixed by setting the preferred scrollable viewport size of
>> the two tables using
>> JTable table = new JTable(data, columnNames);
>> + table.setPreferredScrollableViewportSize(table.getPreferredSize());
>>
ified manually in my
> local system
> Screenshots of before and after the fix are attached in the bug.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed : Spelling correction, added
setPreferredScro
This issue can be fixed by setting the preferred scrollable viewport size of
the two tables using
JTable table = new JTable(data, columnNames);
+ table.setPreferredScrollableViewportSize(table.getPreferredSize());
JTable secondTable = new JTable(data, columnNames);
+
sec
On Tue, 15 Oct 2024 12:48:30 GMT, Naveen Narayanan wrote:
> This testcase checks for the following:
>
> 1. An image is drawn on the screen and a portion of it is captured using a
> Robot. It is tested by comparing whether the captured image is same as the
> source image.
>
> Testing:
> Teste
On Tue, 1 Oct 2024 17:00:55 GMT, Manukumar V S wrote:
> javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java fails
> sometimes in macos.
> This could be because of a synchronisation issue in the test.
>
> Fix: I have refactored the test to have a CountDownLatch
es 20%, it will be triggered. I have also
> removed the ProgressMonitor update logic execution from EDT as it would block
> the EDT sometimes. Also added a proper frame disposal mechanism.
>
> Testing:
> This is properly tested multiple times in all available platforms in mach5.
Manukumar
javax/swing/ProgressMonitor/ProgressMonitorEscapeKeyPress.java fails sometimes
in macos.
This could be because of a synchronisation issue in the test.
Fix: I have refactored the test to have a CountDownLatch to monitor the
ProgressMonitor and when it reaches 20%, it will be triggered. I have als
On Wed, 11 Sep 2024 14:37:12 GMT, Manukumar V S wrote:
> Stabilized the test by disposing the frame at the end, adding an auto delay,
> called panel.getLocationOnScreen() in invokeAndWait(), formatting changes, etc
> And for better debugging, added captureScreen() for fail
On Thu, 12 Sep 2024 16:38:03 GMT, Alexander Zvegintsev
wrote:
>> Manukumar V S has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments fixed : Creating frame in EDT, adding robot.delay() and
>> r
able platforms and attached the link in bug as
> a comment.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed : Minor formatting changes
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20951
On Thu, 12 Sep 2024 05:16:52 GMT, Alexander Zvegintsev
wrote:
> My other comments are minor, because this changeset doesn't seem to help, if
> we increase the JTREG=REPEAT_COUNT from 10 to 100 it can still timeout on
> Windows.
With the new changes, I have run it 900 times(JTREG=REPEAT_COUNT=
able platforms and attached the link in bug as
> a comment.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed : Creating frame in EDT, adding robot.delay() and
robot.waitForIdle(), formatting changes, etc
-
Stabilized the test by disposing the frame at the end, adding an auto delay,
called panel.getLocationOnScreen() in invokeAndWait(), formatting changes, etc
And for better debugging, added captureScreen() for failure cases.
Testing:
Tested using mach5 in all available platforms and attached the l
On Thu, 29 Aug 2024 19:07:29 GMT, Manukumar V S wrote:
> This is a highly intermittent failure, and it failed only once in CI on a
> particular windows machine and passed on all other runs.
>
> Failure reason:
> When the button was displayed for the first time, the focus rectan
On Wed, 4 Sep 2024 07:25:59 GMT, Tejesh R wrote:
>> I don't see a chance for that as the frame is initialized in createGUI() and
>> there are lot of code which directly access frame object there itself, so if
>> it was null, it would have thrown the Nullpointer even before. Anyway, I had
>> th
een(failure images attached in the bug).
>
> Fix:
> To stabilize the test, I have added a line -> button.setFocusPainted(false),
> so that the focus rectangle will not be painted
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revis
On Wed, 4 Sep 2024 07:05:57 GMT, Tejesh R wrote:
>>> null check might be required here.
>>
>> But we are not setting it as null anywhere in the code.
>
> What if its not initialized at first place? To handle this scenario most of
> the test has this condition.
I don't see a chance for that as
On Wed, 4 Sep 2024 06:57:56 GMT, Tejesh R wrote:
> null check might be required here.
But we are not setting it as null anywhere in the code.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20777#discussion_r1743182238
On Tue, 3 Sep 2024 18:13:13 GMT, Harshitha Onkar wrote:
> LGTM now. Does CI testing look good with the updated changes?
Yes, I have attached the results in the bug comment.
-
PR Comment: https://git.openjdk.org/jdk/pull/20777#issuecomment-2327139798
On Tue, 3 Sep 2024 18:02:33 GMT, Harshitha Onkar wrote:
> > Individual robot.delay() can be added after UI creation and when frame
> > state is changed to stabilize the test.
>
> You are still missing some delays. Please check the diff lines in the
> following code snippet.
>
> ```
> @@ -124,
een(failure images attached in the bug).
>
> Fix:
> To stabilize the test, I have added a line -> button.setFocusPainted(false),
> so that the focus rectangle will not be painted
Manukumar V S has updated the pull request incrementally with one additional
commit since the last r
On Tue, 3 Sep 2024 16:41:26 GMT, Harshitha Onkar wrote:
> ```
> frame.setExtendedState(JFrame.MAXIMIZED_BOTH);
> System.out.println("Frame is maximized");
> robot.waitForIdle();
> ```
>
> You missed adding delays after frame state changes, in the a
een(failure images attached in the bug).
>
> Fix:
> To stabilize the test, I have added a line -> button.setFocusPainted(false),
> so that the focus rectangle will not be painted
Manukumar V S has updated the pull request incrementally with one additional
commit since the last r
On Thu, 29 Aug 2024 19:07:29 GMT, Manukumar V S wrote:
> This is a highly intermittent failure, and it failed only once in CI on a
> particular windows machine and passed on all other runs.
>
> Failure reason:
> When the button was displayed for the first time, the focus rectan
On Sat, 31 Aug 2024 00:30:50 GMT, Harshitha Onkar wrote:
> Since the following are on unchanged lines, I'm including it as a
> consolidated note:
>
> 1. robot.setAutoWaitForIdle(true);
>robot.setAutoDelay(200);
>doesn't change anything as there are no robot mouse or key events so it
>
een(failure images attached in the bug).
>
> Fix:
> To stabilize the test, I have added a line -> button.setFocusPainted(false),
> so that the focus rectangle will not be painted
Manukumar V S has updated the pull request incrementally with one additional
commit since the last r
This is a highly intermittent failure, it failed only once in CI on a
particular windows machine and passed on all other runs.
Failure reason:
When the button was displayed for the first time, the focus rectangle drawn on
the button text(Button A) was not seen(failure images attached in the bug
On Fri, 9 Aug 2024 18:45:18 GMT, Manukumar V S wrote:
> This PR creates a new test by stabilising and open sourcing a closed test.
> This test verifies that the OpenGL pipeline does not create artifacts with
> swing components after window is zoomed to maximum size and then resized b
On Wed, 28 Aug 2024 09:39:13 GMT, Abhishek Kumar wrote:
>> Ohh you are talking about the BufferedImage object, yes it is needed as the
>> screen capture is inside a try block.
>
> I meant to say -- Can we return the captured screen like..
>
> `return robot.createScreenCapture(new Rectangle(butt
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
On Wed, 28 Aug 2024 09:19:51 GMT, Manukumar V S wrote:
>> test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 187:
>>
>>> 185: Point buttonLoc = buttonLocRef.get();
>>> 186: System.out.println("Button loc: " +
On Wed, 28 Aug 2024 09:06:23 GMT, Abhishek Kumar wrote:
>> Manukumar V S has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments fixed : Sorted imports, formatting changes, saving images
>> on
On Wed, 28 Aug 2024 09:02:42 GMT, Abhishek Kumar wrote:
>> test/jdk/javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java line 133:
>>
>>> 131: } else {
>>> 132: System.out.println("Button focus not gained...");
>>> 133: throw new RuntimeException("
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
On Wed, 28 Aug 2024 04:50:29 GMT, Abhishek Kumar wrote:
>> Manukumar V S has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comment fixed : Added different @test tags for different platforms
>
>
On Tue, 27 Aug 2024 16:51:51 GMT, Phil Race wrote:
>> Looks like it failed on Linux with the default pipeline, which should be
>> xrender. That's a bit surprising.
>> You should verify this and if necessary file a bug and exclude that failing
>> combination from testing.
>
> Also, I see you ad
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
On Tue, 27 Aug 2024 16:51:51 GMT, Phil Race wrote:
>> Looks like it failed on Linux with the default pipeline, which should be
>> xrender. That's a bit surprising.
>> You should verify this and if necessary file a bug and exclude that failing
>> combination from testing.
>
> Also, I see you ad
On Tue, 27 Aug 2024 05:58:30 GMT, Phil Race wrote:
>> @prrace I’m not sure I understand what you meant by 'testing this with
>> additional pipelines on specific platforms.' Are you suggesting that we
>> should test this not only with -Dsun.java2d.opengl=True
>> -Dsun.java2d.opengl.fbobject=fal
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
On Fri, 23 Aug 2024 18:36:40 GMT, Phil Race wrote:
>> Manukumar V S has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comment fixed : Changed the position of line comments
>
>
On Fri, 23 Aug 2024 18:36:40 GMT, Phil Race wrote:
>> Manukumar V S has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comment fixed : Changed the position of line comments
>
>
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
and without the flags "-Dsun.java2d.opengl=True
> -Dsun.java2d.opengl.fbobject=false" .
>
> This is tested(15 times per platform) in all the available mach5 headful
> platforms and found to be stable.
Manukumar V S has updated the pull request incrementally with one addit
On Mon, 19 Aug 2024 09:51:55 GMT, Tejesh R wrote:
> > > > @TejeshR13 , no, it just compares the Button renderings only, nothing
> > > > else. `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x,
> > > > buttonLoc.y, button.getWidth(), button.getHeight()));`
> > >
> > >
> > > Which i
On Mon, 19 Aug 2024 09:29:12 GMT, Tejesh R wrote:
> > @TejeshR13 , no, it just compares the Button renderings only, nothing else.
> > `bimage = robot.createScreenCapture(new Rectangle(buttonLoc.x, buttonLoc.y,
> > button.getWidth(), button.getHeight()));`
>
> Which is exactly in the image righ
On Mon, 19 Aug 2024 09:20:06 GMT, Tejesh R wrote:
>>> The test is failing on my windows machine with an error -
>>> _java.lang.RuntimeException: Button renderings are different after window
>>> resize, num of Diff Pixels=1576_ Images are uploaded for reference.
>>>
>>> .
> Tested manually in OEL 8 and 9(both x64 and aarch64) and it works fine there
> also.
Manukumar V S has updated the pull request incremen
On Wed, 14 Aug 2024 21:49:05 GMT, Damon Nguyen wrote:
> Is this due to anti-aliasing or something similar? And any idea why it's only
> Oracle Linux? Change itself looks simple enough, but odd that it's only for
> this scenario.
@DamonGuy I don't think this has any relationship with anti-alias
On Fri, 16 Aug 2024 01:39:38 GMT, Alisen Chung wrote:
>> java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight
>> color difference in the background color. This is currently reproduced only
>> for Oracle Linux.
>>
>> The Color object I'm getting for each of these Point obje
This PR creates a new test by stabilising and open sourcing a closed test.
This test verifies that the OpenGL pipeline does not create artifacts with
swing components after window is zoomed to maximum size and then resized back
to normal.
This test is run twice, with and without the flags "-Dsun.
java/awt/Frame/MaximizeUndecoratedTest.java fails in OEL due to a slight color
difference in the background color. This is currently reproduced only for
Oracle Linux.
The Color object I'm getting for each of these Point objects:
new Point(maxBounds.x + OFFSET, maxBounds.y + OFFSET) -->
java.aw
On Wed, 15 Feb 2023 12:50:42 GMT, Ravi Gupta wrote:
> Main aim of this testcase is to test the behavior of various events under
> stress.
>
> This testcase verifies the following assertions
> a. This TestCase performs various mouse and key operations on components and
> checks whether all the
On Wed, 18 Jan 2023 07:41:01 GMT, Manukumar V S wrote:
> Create a automated regression test for JComboBox titled border
> issues([JDK-8300269](https://bugs.openjdk.org/browse/JDK-8300269)).
>
> This test passes in JDK-20-ea+15 and fails in JDK-20-ea+16 and above.
This pull requ
On Wed, 8 Feb 2023 01:33:18 GMT, Sergey Bylokhov wrote:
> If this test will be merged to another PR please close this PR.
Yes, I will close this
-
PR: https://git.openjdk.org/jdk/pull/12061
Create a automated regression test for JComboBox titled border
issues([JDK-8300269](https://bugs.openjdk.org/browse/JDK-8300269)).
This test passes in JDK-20-ea+16 and fails in JDK-20-ea+16 and above.
-
Commit messages:
- 8300409: Create an automated regression test for JComboBox t
On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S wrote:
> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
> adding some stability improvements fixes the issue. It intermittently f
On Tue, 10 Jan 2023 21:35:25 GMT, Alexey Ivanov wrote:
>> Replaced robot.waitForIdle with robot.delay(200). I will check the
>> possibility of raising a new bug.
>
> Since no one expected for `robot.waitForIdle` to make the test so slow here,
> I suggest submitting a bug for evaluation. You hav
mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some
> prints for better debugging.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed: Refactoring, formatting
On Fri, 6 Jan 2023 07:21:12 GMT, Manukumar V S wrote:
>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
>> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
>> adding some stability improvements fixes the issue. It inter
On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S wrote:
> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
> adding some stability improvements fixes the issue. It intermittently f
On Tue, 3 Jan 2023 16:45:52 GMT, Alexey Ivanov wrote:
> I also suggest removing the second asterisk at line 43, so that jtreg tags
> don't result javadoc warnings.
>
> If you also remove `throws Exception` clause from `openPopup`, the test will
> become warning-free.
Fixed the review comments
On Tue, 3 Jan 2023 16:30:43 GMT, Alexey Ivanov wrote:
>> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 133:
>>
>>> 131: robot.mousePress(InputEvent.BUTTON3_DOWN_MASK);
>>> 132: robot.mouseRelease(InputEvent.BUTTON3_DOWN_MASK);
>>> 133: robot.waitForIdle();
>>
>
mach5 and got full PASS.
> Also updated the screen capture code, made frame undecorated, added some
> prints for better debugging.
Manukumar V S has updated the pull request incrementally with one additional
commit since the last revision:
Review comments fixed: Replaced one robo
On Fri, 18 Nov 2022 08:06:48 GMT, Naveen Narayanan wrote:
>> This testcase will
>> 1) Verify setAccelerator method of JMenuitem.
>> 2) Check that the selection of a menu item in the menu bar will generate
>> action by a key combination of META+M.
>>
>> Testing:
>> Tested using Mach5(20 times pe
On Fri, 11 Nov 2022 08:20:55 GMT, ravi gupta wrote:
>> This testcase Verify the content changes of a TextArea for the following
>> assertions.
>>
>> a. TextListener get invoked when the content of a TextArea gets changed.
>> b. TextListener not get invoked during text selection or when Special
On Thu, 10 Nov 2022 05:14:36 GMT, Naveen Narayanan wrote:
>> This testcase will
>> 1) Verify setAccelerator method of JMenuitem.
>> 2) Check that the selection of a menu item in the menu bar will generate
>> action by a key combination of META+M.
>>
>> Testing:
>> Tested using Mach5(20 times pe
On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote:
>> This testcase Verify the content changes of a TextArea for the following
>> assertions.
>>
>> a. TextListener get invoked when the content of a TextArea gets changed.
>> b. TextListener not get invoked during text selection or when Special
On Thu, 10 Nov 2022 14:13:08 GMT, ravi gupta wrote:
>> This testcase Verify the content changes of a TextArea for the following
>> assertions.
>>
>> a. TextListener get invoked when the content of a TextArea gets changed.
>> b. TextListener not get invoked during text selection or when Special
On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote:
>> This testcase Verify the content changes of a TextArea for the following
>> assertions.
>>
>> a. TextListener get invoked when the content of a TextArea gets changed.
>> b. TextListener not get invoked during text selection or when Special
On Thu, 10 Nov 2022 04:29:36 GMT, ravi gupta wrote:
>> This testcase Verify the content changes of a TextArea for the following
>> assertions.
>>
>> a. TextListener get invoked when the content of a TextArea gets changed.
>> b. TextListener not get invoked during text selection or when Special
On Wed, 9 Nov 2022 04:29:35 GMT, ravi gupta wrote:
> This testcase Verify the content changes of a TextArea for the following
> assertions.
>
> a. TextListener get invoked when the content of a TextArea gets changed.
> b. TextListener not get invoked during text selection or when Special keys
On Tue, 8 Nov 2022 08:57:54 GMT, Naveen Narayanan wrote:
> Colocate JMenuItemSetAcceleratorTest to a regression test.
>
> This testcase will
> 1) Verify setAccelerator method of JMenuitem.
> 2) Check that the selection of a menu item in the menu bar will generate
> action by a key combination o
On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S wrote:
> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
> adding some stability improvements fixes the issue. It intermittently f
On Thu, 20 Oct 2022 08:59:20 GMT, Srinivas Mandalika
wrote:
> 8295707: Create a regression test for JDK-7184401
>
> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144
> Above bug got introduced due to a fix for
> [JDK-7162144](https://bugs.openjdk.java.net/browse/JD
On Tue, 11 Oct 2022 14:17:42 GMT, Manukumar V S wrote:
> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
> adding some stability improvements fixes the issue. It intermittently f
On Tue, 11 Oct 2022 19:56:49 GMT, SWinxy wrote:
> So, what's the difference between this and #9187 and #10606? And did one of
> them have git issues?
No, #9187 got closed automatically by bot after being inactive for 8 weeks. And
difference between #9187 and #10606 are,
1. Improved the screen
java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
adding some stability improvements fixes the issue. It intermittently fails in
CI causing some noise. This test was already problem listed in windo
On Fri, 7 Oct 2022 13:36:17 GMT, Manukumar V S wrote:
> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
> adding some stability improvements fixes the issue. It intermittently f
On Mon, 10 Oct 2022 17:59:23 GMT, Sergey Bylokhov wrote:
>> But, is there any way we can capture the current screen where the frame is
>> displayed?
>
> You can pass coordinates/bounds of that screen to the createScreenCapture.
Will do that in a new PR as something went wrong with this and some
On Tue, 11 Oct 2022 13:48:34 GMT, Alexey Ivanov wrote:
> You did something wrong, now there are 40 commits and 126 files changed. It
> doesn't look right.
>
> Merging master should result in one commit only even though it brings
> multiple commits into the history.
Yea, I have seen that. I tr
y problem listed in windows due
> to an umbrella bug JDK-8238720. This fix doesn't cover the Windows issue, so
> the problem listing in windows will remain same.
>
> Fix:
> Some stability improvements have been done and the test has been run 100
> times per platform in
On Fri, 7 Oct 2022 21:15:02 GMT, Sergey Bylokhov wrote:
>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
>> machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
>> adding some stability improvements fixes the issue. It intermittently fails
>> i
java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS
machines, especially in MacOSX 12 & 13 machines. It seems to be a testbug as
adding some stability improvements fixes the issue. It intermittently fails in
CI causing some noise. This test was already problem listed in windo
On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S wrote:
> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS
> machines, especially in MacOSX 12 machines and it fails intermittently in CI
> causing some noise.
> It seems to be a testbug as adding so
1 - 100 of 113 matches
Mail list logo
