Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]
On Tue, 13 Apr 2021 01:34:17 GMT, Alexander Zvegintsev wrote: >> This fix simply removes tests mentioned in the bug with for unsupported >> scenarios(applets in browser). > > Alexander Zvegintsev has updated the pull request incrementally with one > additional commit since the last revision: > > TestApplet.java removed Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3441
Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]
On Tue, 13 Apr 2021 01:03:49 GMT, Sergey Bylokhov wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> TestApplet.java removed > > test/jdk/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java > line 1: > >> 1: /* > > The "TestApplet.java" near this file is part of the test and can be removed > as well. Fixed. - PR: https://git.openjdk.java.net/jdk/pull/3441
Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked. [v2]
> This fix simply removes tests mentioned in the bug with for unsupported > scenarios(applets in browser). Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: TestApplet.java removed - Changes: - all: https://git.openjdk.java.net/jdk/pull/3441/files - new: https://git.openjdk.java.net/jdk/pull/3441/files/8f39e2f8..133f0806 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3441=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3441=00-01 Stats: 67 lines in 1 file changed: 0 ins; 67 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3441/head:pull/3441 PR: https://git.openjdk.java.net/jdk/pull/3441
Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.
On Mon, 12 Apr 2021 18:48:06 GMT, Alexander Zvegintsev wrote: > This fix simply removes tests mentioned in the bug with for unsupported > scenarios(applets in browser). test/jdk/java/awt/event/KeyEvent/KeyReleasedInAppletTest/KeyReleasedInAppletTest.java line 1: > 1: /* The "TestApplet.java" near this file is part of the test and can be removed as well. - PR: https://git.openjdk.java.net/jdk/pull/3441
Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.
On Mon, 12 Apr 2021 20:23:39 GMT, Sergey Bylokhov wrote: > Please confirm that none of them are in the problem list. I do confirm that. - PR: https://git.openjdk.java.net/jdk/pull/3441
Re: RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.
On Mon, 12 Apr 2021 18:48:06 GMT, Alexander Zvegintsev wrote: > This fix simply removes tests mentioned in the bug with for unsupported > scenarios(applets in browser). Please confirm that none of them are in the problem list. - PR: https://git.openjdk.java.net/jdk/pull/3441
RFR: 8039261: [TEST_BUG]: There is not a minimal security level in Java Preferences and the TestApplet.html is blocked.
This fix simply removes tests mentioned in the bug with for unsupported scenarios(applets in browser). - Commit messages: - initial Changes: https://git.openjdk.java.net/jdk/pull/3441/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3441=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8039261 Stats: 525 lines in 8 files changed: 0 ins; 525 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3441.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3441/head:pull/3441 PR: https://git.openjdk.java.net/jdk/pull/3441
Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application
On Sat, 10 Apr 2021 23:22:06 GMT, Philip Race wrote: > The system dialog UI talks of "documents" which might tell us something about > the mindset of the folks who designed it. Yes, that was my thinking. This seems like a setting meant for applications whose windows are a set of "documents", and where grouping the individual document windows into a single window as set of tabs make sense. It doesn't really fit for applications that have different top level windows that aren't documents that can be grouped together naturally into a single window with tabs. > I can imagine it would take some time to properly go through all of these and > I think we should schedule that rather than just disabling this and in all > likelihood forgetting about this. Do we have a go-with-the disabling RFE to > support it ? That seems a good approach to me: make this an opt-in feature that applications could decide to use. And if you go that route, filing the RFE now is a good idea. In any case, I'll file an RFE for JavaFX as well. - PR: https://git.openjdk.java.net/jdk/pull/3407
Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application
On Sat, 10 Apr 2021 23:22:06 GMT, Philip Race wrote: > The system dialog UI talks of "documents" which might tell us something about > the mindset of the folks who designed it. Yes, that was my thinking. This seems like a setting meant for applications whose windows are a set of "documents", and where grouping the individual document windows into a single window as set of tabs make sense. It doesn't really fit for applications that have different top level windows that aren't documents that can be grouped together naturally into a single window with tabs. > I can imagine it would take some time to properly go through all of these and > I think we should schedule that rather than just disabling this and in all > likelihood forgetting about this. Do we have a go-with-the disabling RFE to > support it ? That seems a good approach to me: make this an opt-in feature that applications could decide to use. And if you go that route, filing the RFE now is a good idea. In any case, I'll file an RFE for JavaFX as well. - PR: https://git.openjdk.java.net/jdk/pull/3407
Integrated: 8258788: incorrect response to change in window insets [lanai]
On Wed, 7 Apr 2021 23:04:04 GMT, Alexey Ushakov wrote: > Perform replaceSurfaceData on insets change This pull request has now been integrated. Changeset: 714ae54f Author:Alexey Ushakov Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/714ae54f Stats: 165 lines in 2 files changed: 164 ins; 0 del; 1 mod 8258788: incorrect response to change in window insets [lanai] Reviewed-by: serb, jdv - PR: https://git.openjdk.java.net/jdk/pull/3390
Integrated: 8233567: [TESTBUG] FocusSubRequestTest.java fails on macos
On Mon, 12 Apr 2021 04:37:31 GMT, Prasanta Sadhukhan wrote: > This test was problemlisted during nightly testing of jdk on macos which > seems to be caused by the fact that proper waiting was not done to make sure > frame is visible before commencing the test, which can be problematic in some > of the slower CI macos system. > Modified the wait-till-frame-is-visible code to make it more in sync with > what other similar test use. > Several iterations of the test works fine in all platforms after this > modification. This pull request has now been integrated. Changeset: b90ad76d Author:Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/b90ad76d Stats: 13 lines in 2 files changed: 3 ins; 2 del; 8 mod 8233567: [TESTBUG] FocusSubRequestTest.java fails on macos Reviewed-by: azvegint, pbansal - PR: https://git.openjdk.java.net/jdk/pull/3430
Re: RFR: 8233567: [TESTBUG] FocusSubRequestTest.java fails on macos
On Mon, 12 Apr 2021 04:37:31 GMT, Prasanta Sadhukhan wrote: > This test was problemlisted during nightly testing of jdk on macos which > seems to be caused by the fact that proper waiting was not done to make sure > frame is visible before commencing the test, which can be problematic in some > of the slower CI macos system. > Modified the wait-till-frame-is-visible code to make it more in sync with > what other similar test use. > Several iterations of the test works fine in all platforms after this > modification. Marked as reviewed by pbansal (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3430
Re: RFR: 8233567: [TESTBUG] FocusSubRequestTest.java fails on macos
On Mon, 12 Apr 2021 04:37:31 GMT, Prasanta Sadhukhan wrote: > This test was problemlisted during nightly testing of jdk on macos which > seems to be caused by the fact that proper waiting was not done to make sure > frame is visible before commencing the test, which can be problematic in some > of the slower CI macos system. > Modified the wait-till-frame-is-visible code to make it more in sync with > what other similar test use. > Several iterations of the test works fine in all platforms after this > modification. Marked as reviewed by azvegint (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3430
Re: RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application
On Sat, 10 Apr 2021 23:22:06 GMT, Philip Race wrote: > The system dialog UI talks of "documents" which might tell us something about > the mindset of the folks who designed it. Yes, that was my thinking. This seems like a setting meant for applications whose windows are a set of "documents", and where grouping the individual document windows into a single window as set of tabs make sense. It doesn't really fit for applications that have different top level windows that aren't documents that can be grouped together naturally into a single window with tabs. > I can imagine it would take some time to properly go through all of these and > I think we should schedule that rather than just disabling this and in all > likelihood forgetting about this. Do we have a go-with-the disabling RFE to > support it ? That seems a good approach to me: make this an opt-in feature that applications could decide to use. And if you go that route, filing the RFE now is a good idea. In any case, I'll file an RFE for JavaFX as well. - PR: https://git.openjdk.java.net/jdk/pull/3407
Re: RFR: 8258788: incorrect response to change in window insets [lanai] [v3]
On Fri, 9 Apr 2021 22:41:37 GMT, Sergey Bylokhov wrote: >> Yes, it's IEC61966-2.1 > > Ok, found the issue on my side, by default the test uses the OGL, not a metal. Good news! @mrserb Could you sponsor this pull request? - PR: https://git.openjdk.java.net/jdk/pull/3390