From kcr at openjdk.org Tue Aug 1 00:30:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 1 Aug 2023 00:30:53 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 08:16:12 GMT, Jay Bhaskar wrote: >> Issue: Some web worker tests fail to finish. >> Root Cause: >> sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Add test case for worker timeout The fix and test both look good. I confirm that it fixes the problem and that the new test fails without the fix and passes with the fix. I left a couple minor comments on the test, but I'll approve it anyway. If you choose to fix them, I'll reapprove. modules/javafx.web/src/test/java/test/javafx/scene/web/WebWorkerTest.java line 50: > 48: @After > 49: public void after() { > 50: } Minor: you don't need this empty method. modules/javafx.web/src/test/java/test/javafx/scene/web/WebWorkerTest.java line 64: > 62: } catch (InterruptedException e) { > 63: // Handle the exception if the thread is interrupted while sleeping > 64: } Minor: if you add `throws InterruptedException` to the test method you don't need a try/catch here. modules/javafx.web/src/test/java/test/javafx/scene/web/WebWorkerTest.java line 69: > 67: WebView view = getView(); > 68: String res = (String) view.getEngine().executeScript("document.getElementById('result').innerText;"); > 69: assertEquals("4",res); Minor: space after the `,` ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1191#pullrequestreview-1555894189 PR Review Comment: https://git.openjdk.org/jfx/pull/1191#discussion_r1279944478 PR Review Comment: https://git.openjdk.org/jfx/pull/1191#discussion_r1280000329 PR Review Comment: https://git.openjdk.org/jfx/pull/1191#discussion_r1280000445 From nlisker at openjdk.org Tue Aug 1 00:49:53 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 1 Aug 2023 00:49:53 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v2] In-Reply-To: References: Message-ID: <4A3rujaDJaBiA1ujI_e9l75i-lZ44KRlHsnJXCNA8z4=.156ed1b3-91c4-48dd-9956-8d000a699275@github.com> On Mon, 31 Jul 2023 11:51:24 GMT, John Hendrikx wrote: >> Incorporates documentation review comments from #1069. >> >> This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use @implSpec tag > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/subscriptions-doc-improvements > - Documentation improvements I think that the documentation on `Subscription` still needs to be improved beyond a single sentence. It should include how to use the interface and give use cases. I'll need to think about a good first paragraph. For the use cases, maybe the ones you outlines in https://github.com/openjdk/jfx/pull/1069/files#r1263857263. I also think that a short review of the methods it offers is useful: Subscriptions can also be combined using {@link #combine} and {@link #and}, which allows for multiple subscriptions to be unsubscribed together. This is useful when they share the same lifecycle, for example, when performing cleanup for the same object. Then there is the question of what to do with regards to its use in JavaFX. The previous description I gave in https://github.com/openjdk/jfx/pull/1069#discussion_r1261873147 is centered around `Observable/ObservableValue`. I think that it's still better to include this description somewhere rather than repeat a part of it in every method. Maybe it fits better in `Observable/ObservableValue`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1177#issuecomment-1659401020 From psadhukhan at openjdk.org Tue Aug 1 04:48:52 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 1 Aug 2023 04:48:52 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> Message-ID: On Sat, 29 Jul 2023 15:11:34 GMT, Kevin Rushforth wrote: > @prsadhuk @hjohn I'll take a closer look early next week, but I think the best way forward might be for Prasanta to evaluate #1189 and, if the modified fix in that PR is what we want to use, update _this_ PR to include the change that adds the call to `updateSceneState()` and removes the explicit call to `Stage::setRenderScale[XY]`. Then add John as a contributor to this PR using `/contributor add`. I have tested both JDK-8222209 and JDK-8274932 with #1189 fix and it works fine. Only question I have is, should `updateSceneState` be called in `QuantumToolkit.runWithRenderLock` synchronization? And also should we move `updateSceneState` to `GlassScene.entireSceneNeedsRepaint` as that changes the scene, so scene state needs to be updated!! > We can then close [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) as a duplicate of [JDK-8274932](https://bugs.openjdk.org/browse/JDK-8274932). I think JDK-8274932 is about scale correction and JDK-8222209 is about content refresh in different-scaled configuration so I dont think one is duplicate of another. I can add #1189 change to this PR and do /contributor add but I think we should do "/issue add JDK-8222209" instead of closing that as duplicate. [Another possibility is we can have this PR only contain swing-interop change and let #1189 having only non swing-interop updateSceneState change and assign JDK-8222209 to @hjohn] ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1659559774 From jvos at openjdk.org Tue Aug 1 07:02:55 2023 From: jvos at openjdk.org (Johan Vos) Date: Tue, 1 Aug 2023 07:02:55 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 16:52:00 GMT, Andy Goryachev wrote: >> This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. >> >> This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. >> >> No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. >> >> I've tested successfully such scenario on Linux, Mac and Windows. > > modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java line 311: > >> 309: FileLock fileLock = fileChannel.lock()) { >> 310: try { >> 311: if (!Files.exists(path)) { > > This code would fail if the target file exists but has a 0 length, or any length other that the actual resource length, or with the right length but wrong content. > Do we want to address these scenarios? This is a different type of a problem, that imho should be addressed as well, but in a separate issue which also contains a test strategy. This is something that requires a hash-based solution, but it is something that needs to be done with great care, so I personally wouldn't rush this into this PR (as it might cause criticial regression if not done correctly). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1280187329 From duke at openjdk.org Tue Aug 1 07:23:54 2023 From: duke at openjdk.org (duke) Date: Tue, 1 Aug 2023 07:23:54 GMT Subject: Withdrawn: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0 In-Reply-To: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com> Message-ID: <9V8RHtb02AhgNOP4Ho1NzFdEYtPLg6kLniLMaLLpFzU=.c838e47b-1272-4115-a320-c8a90f15b455@github.com> On Wed, 22 Feb 2023 01:11:55 GMT, Thiago Milczarek Sayao wrote: > Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero. > > Here's whats happening: > > We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN). > > When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0. > > The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1044 From hmeda at openjdk.org Tue Aug 1 07:56:46 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 1 Aug 2023 07:56:46 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 08:16:12 GMT, Jay Bhaskar wrote: >> Issue: Some web worker tests fail to finish. >> Root Cause: >> sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Add test case for worker timeout Verified the changes and internal testing looks fine. No issue observed. ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1191#pullrequestreview-1556374190 From mhanl at openjdk.org Tue Aug 1 09:33:49 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 1 Aug 2023 09:33:49 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 16:49:36 GMT, Andy Goryachev wrote: >> This PR adds a file lock to the cache directory, allowing access from multiple processes (that is, from more than one JVM) to that directory. >> >> This helps solving the issue where the cache is empty or doesn't exist yet, and two JavaFX applications start at the same time, and both try to copy the same native libraries to the same cache. >> >> No tests have been added to the PR though, since this requires a complex scenario: building the SDK and publishing to local Maven repository, creating two simple JavaFX applications that use those artifacts, using a temporary folder for cache (via `javafx.cachedir`, and launching in parallel both applications. >> >> I've tested successfully such scenario on Linux, Mac and Windows. > > modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java line 312: > >> 310: try { >> 311: if (!Files.exists(path)) { >> 312: Files.copy(is, path); > > I noticed `is` is not closed (also in the original code). > Would that be a problem? Probably something to evaluate, but in a separate ticket ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1280355284 From jbhaskar at openjdk.org Tue Aug 1 09:54:03 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 1 Aug 2023 09:54:03 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v3] In-Reply-To: References: Message-ID: <0Y9wFORoe_lOT2mbmE2iF5RhCkqX9b17vj7hDWrymOI=.1a76e4df-3ce5-481d-b7b0-49fd5b8443a3@github.com> > Issue: Some web worker tests fail to finish. > Root Cause: > sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: clean up according to review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1191/files - new: https://git.openjdk.org/jfx/pull/1191/files/06d46695..cc27cadd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1191&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1191&range=01-02 Stats: 13 lines in 1 file changed: 0 ins; 10 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1191.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1191/head:pull/1191 PR: https://git.openjdk.org/jfx/pull/1191 From jbhaskar at openjdk.org Tue Aug 1 09:54:05 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 1 Aug 2023 09:54:05 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 22:26:48 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case for worker timeout > > modules/javafx.web/src/test/java/test/javafx/scene/web/WebWorkerTest.java line 50: > >> 48: @After >> 49: public void after() { >> 50: } > > Minor: you don't need this empty method. done > modules/javafx.web/src/test/java/test/javafx/scene/web/WebWorkerTest.java line 64: > >> 62: } catch (InterruptedException e) { >> 63: // Handle the exception if the thread is interrupted while sleeping >> 64: } > > Minor: if you add `throws InterruptedException` to the test method you don't need a try/catch here. ok > modules/javafx.web/src/test/java/test/javafx/scene/web/WebWorkerTest.java line 69: > >> 67: WebView view = getView(); >> 68: String res = (String) view.getEngine().executeScript("document.getElementById('result').innerText;"); >> 69: assertEquals("4",res); > > Minor: space after the `,` done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1191#discussion_r1280380670 PR Review Comment: https://git.openjdk.org/jfx/pull/1191#discussion_r1280380041 PR Review Comment: https://git.openjdk.org/jfx/pull/1191#discussion_r1280380297 From aghaisas at openjdk.org Tue Aug 1 10:09:52 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 1 Aug 2023 10:09:52 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 13:34:28 GMT, Guillaume T?che wrote: >> This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. >> Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. > > Guillaume T?che has updated the pull request incrementally with one additional commit since the last revision: > > Empty commit Overall the fix and tests look fine. I have a couple of comments on the fix. modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1101: > 1099: loadListener.readInternalAttribute(localName, value); > 1100: } > 1101: final ResourceBundle loaderResources = FXMLLoader.this.resources; Why to have this local temporary `loaderResources`? We can simply use `this.resources` for readability. modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1106: > 1104: } else { > 1105: final ClassLoader cl = loaderResources.getClass().getClassLoader(); > 1106: resources = cl == null ? Add a bracket around `cl == null` ------------- Changes requested by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1158#pullrequestreview-1556626578 PR Review Comment: https://git.openjdk.org/jfx/pull/1158#discussion_r1280399572 PR Review Comment: https://git.openjdk.org/jfx/pull/1158#discussion_r1280400336 From jhendrikx at openjdk.org Tue Aug 1 10:27:50 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 10:27:50 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> Message-ID: <8u8_v_5fsTY6FxZQaxNbWI5kgrOaOjhCbf79ZKWe_Gg=.e5a0bb11-f6cf-48d1-a68b-36f7419b2984@github.com> On Tue, 1 Aug 2023 04:46:31 GMT, Prasanta Sadhukhan wrote: > > @prsadhuk @hjohn I'll take a closer look early next week, but I think the best way forward might be for Prasanta to evaluate #1189 and, if the modified fix in that PR is what we want to use, update _this_ PR to include the change that adds the call to `updateSceneState()` and removes the explicit call to `Stage::setRenderScale[XY]`. Then add John as a contributor to this PR using `/contributor add`. > > I have tested both JDK-8222209 and JDK-8274932 with #1189 fix and it works fine. Only question I have is, should `updateSceneState` be called in `QuantumToolkit.runWithRenderLock` synchronization? And also should we move `updateSceneState` to `GlassScene.entireSceneNeedsRepaint` as that changes the scene, so scene state needs to be updated!! I'm not sure, we'd have to look into that further still (is the lock also required for calling `entireSceneNeedsRepaint`?) It's possible the lock is there because that `WindowEvent` is received on a non-FX thread. > > We can then close [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) as a duplicate of [JDK-8274932](https://bugs.openjdk.org/browse/JDK-8274932). > > I think JDK-8274932 is about scale correction and JDK-8222209 is about content refresh in different-scaled configuration so I dont think one is duplicate of another. I can add #1189 change to this PR and do /contributor add but I think we should do "/issue add JDK-8222209" instead of closing that as duplicate. [Another possibility is we can have this PR only contain swing-interop change and let #1189 having only non swing-interop updateSceneState change and assign JDK-8222209 to @hjohn] My primary concern is that #1171 is doing `Platform.runLater` calls that I think are undesired and unnecessary if you add `updateSceneState`. In other words, the fix in #1189 might fix both problems without needing to call `Platform.runLater`, but I haven't tested that. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1660027992 From jhendrikx at openjdk.org Tue Aug 1 10:52:51 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 10:52:51 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 18:29:19 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinition.java line 54: >> >>> 52: */ >>> 53: public TransitionDefinition(String propertyName, Duration duration, >>> 54: Duration delay, Interpolator interpolator) { >> >> I think you should not repeat the parameters here, just use: >> >> Suggestion: >> >> public TransitionDefinition { >> >> >> I would also move the "@throws" documentation tags to the record class definition > > The constructor ensures that any spelling of "ALL" is converted to the interned constant "all", which is important as we would otherwise need a more computationally expensive case-insensitive string comparison in `Node.Transitions.find()`. > Removing the constructor would mean that some unrelated piece of code would need to do this conversion. > > The `@throws` tag is not allowed at the class level. I meant that you can use the short form of the constructor (without repeating the parameters): public record TransitionDefinition(String propertyName, Duration duration, Duration delay, Interpolator interpolator) { public TransitionDefinition { // no parameters necessary (short form constructor) // do checks and assignments here } } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280452828 From kcr at openjdk.org Tue Aug 1 10:57:46 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 1 Aug 2023 10:57:46 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v3] In-Reply-To: <0Y9wFORoe_lOT2mbmE2iF5RhCkqX9b17vj7hDWrymOI=.1a76e4df-3ce5-481d-b7b0-49fd5b8443a3@github.com> References: <0Y9wFORoe_lOT2mbmE2iF5RhCkqX9b17vj7hDWrymOI=.1a76e4df-3ce5-481d-b7b0-49fd5b8443a3@github.com> Message-ID: On Tue, 1 Aug 2023 09:54:03 GMT, Jay Bhaskar wrote: >> Issue: Some web worker tests fail to finish. >> Root Cause: >> sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > clean up according to review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1191#pullrequestreview-1556720341 From jpereda at openjdk.org Tue Aug 1 11:28:49 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 1 Aug 2023 11:28:49 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 09:31:15 GMT, Marius Hanl wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java line 312: >> >>> 310: try { >>> 311: if (!Files.exists(path)) { >>> 312: Files.copy(is, path); >> >> I noticed `is` is not closed (also in the original code). >> Would that be a problem? > > Probably something to evaluate, but in a separate ticket I agree, this should probably be considered as well, as part of a separate ticket. Note that, when the file already exists in the cache, the initial InputStream object is used by the DigestInputStream, and it is manually closed and reread again, so special care should be taken here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1280488134 From jpereda at openjdk.org Tue Aug 1 11:32:48 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 1 Aug 2023 11:32:48 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: <6TaKPIybVt4XGj6tMhw7aW7CHP0Jw-K1a8a4ESZfeRM=.69e73f19-3525-40f8-99c3-a2ee3d722d7f@github.com> On Tue, 1 Aug 2023 06:59:59 GMT, Johan Vos wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java line 311: >> >>> 309: FileLock fileLock = fileChannel.lock()) { >>> 310: try { >>> 311: if (!Files.exists(path)) { >> >> This code would fail if the target file exists but has a 0 length, or any length other that the actual resource length, or with the right length but wrong content. >> Do we want to address these scenarios? > > This is a different type of a problem, that imho should be addressed as well, but in a separate issue which also contains a test strategy. This is something that requires a hash-based solution, but it is something that needs to be done with great care, so I personally wouldn't rush this into this PR (as it might cause criticial regression if not done correctly). Agree to do it separately, but in any case, if there was already a file at the cache directory, its checksum is verified, and in case it is not the same, the file is removed from the cache, before it is copied again. Does this cover the possible scenarios you are referring to? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1280492135 From hmeda at openjdk.org Tue Aug 1 12:14:48 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 1 Aug 2023 12:14:48 GMT Subject: RFR: 8313177: Web Workers timeout with Webkit 616.1 [v3] In-Reply-To: <0Y9wFORoe_lOT2mbmE2iF5RhCkqX9b17vj7hDWrymOI=.1a76e4df-3ce5-481d-b7b0-49fd5b8443a3@github.com> References: <0Y9wFORoe_lOT2mbmE2iF5RhCkqX9b17vj7hDWrymOI=.1a76e4df-3ce5-481d-b7b0-49fd5b8443a3@github.com> Message-ID: On Tue, 1 Aug 2023 09:54:03 GMT, Jay Bhaskar wrote: >> Issue: Some web worker tests fail to finish. >> Root Cause: >> sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > clean up according to review comments Marked as reviewed by hmeda (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1191#pullrequestreview-1556846727 From jbhaskar at openjdk.org Tue Aug 1 12:18:49 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Tue, 1 Aug 2023 12:18:49 GMT Subject: Integrated: 8313177: Web Workers timeout with Webkit 616.1 In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 06:03:58 GMT, Jay Bhaskar wrote: > Issue: Some web worker tests fail to finish. > Root Cause: > sharedTimerFiredInternal function from ThreadTimers class does not require an isMainThread check, The check was introduced during the initial webkit stabilization. This pull request has now been integrated. Changeset: 5f5e54fe Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/5f5e54feb2e816dcb351a28862c798117c3f81e8 Stats: 117 lines in 4 files changed: 110 ins; 7 del; 0 mod 8313177: Web Workers timeout with Webkit 616.1 Reviewed-by: kcr, hmeda ------------- PR: https://git.openjdk.org/jfx/pull/1191 From jhendrikx at openjdk.org Tue Aug 1 13:50:01 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 13:50:01 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 18:07:52 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionDefinitionCssMetaData.java line 63: >> >>> 61: private static final Duration[] DURATION_ZERO = new Duration[] { Duration.ZERO }; >>> 62: >>> 63: private static final Interpolator[] INTERPOLATOR_EASE = new Interpolator[] { InterpolatorConverter.CSS_EASE }; >> >> Careful, the array contents could still be modified > > That's true. However, `CssParser` is built around array-based sequences (see `StringConverter.SequenceConverter`), and changing these arrays to lists would seem out of place for this part of the codebase. What do you think? It depends on how much you want guarantees that they're not changed. I suppose it's not that big of an issue. Changing to `List` is likely impossible (I think that part of the API is public in places), only other option than is to recreate the arrays if you want 100% certainty :) >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/TransitionTimer.java line 126: >> >>> 124: * @param forceStop if {@code true}, the timer is stopped unconditionally >>> 125: * @return {@code true} if the timer was cancelled or {@code timer} is {@code null}, >>> 126: * {@code false} otherwise >> >> minor: >> Suggestion: >> >> * @return {@code true} if the timer was cancelled, or {@code timer} is {@code null}, >> * otherwise {@code false} > > I don't see any real difference here, but then again I'm not a native speaker. I'll defer to public opinion. I'm not a native either, but it flows a bit better IMHO. I checked `String` class, they do it like that there as well. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280672359 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280673889 From jhendrikx at openjdk.org Tue Aug 1 13:53:56 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 13:53:56 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Mon, 31 Jul 2023 18:01:31 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/scenario/animation/StepInterpolator.java line 73: >> >>> 71: } >>> 72: >>> 73: if (t >= 0 && step < 0) { >> >> `t >= 0` always holds, perhaps the original `t` was meant here? The `t` parameter is re-assigned, which may be confusing. > > This algorithm is implemented as [specified](https://www.w3.org/TR/css-easing-1/#step-easing-algo), which accounts for the possibility that the interpolator is used for a back-filling animation (`t < 0`). While this is not possible in JavaFX (but may be possible in the future), I think it makes sense to keep the algorithm as is, because it ensures that its results are always correct, even though negative values for `t` are currently out of spec. Yeah, I figured as much. I just don't like code that you can't get covered in a unit test, or that contradicts itself. As you can see, I was confused, is it a bug or a feature? Perhaps a comment then to indicate that it's intentional. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280678762 From jhendrikx at openjdk.org Tue Aug 1 13:59:57 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 13:59:57 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: <35UYdTAmgs9j3-F_283cQBco8IdaGTm608n0e7IEYVY=.e4edd814-003e-4755-8fd7-79ff59db20be@github.com> References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> <35UYdTAmgs9j3-F_283cQBco8IdaGTm608n0e7IEYVY=.e4edd814-003e-4755-8fd7-79ff59db20be@github.com> Message-ID: On Mon, 31 Jul 2023 18:16:19 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/css/TransitionEvent.java line 88: >> >>> 86: * @param eventType the event type >>> 87: * @param property the {@code StyleableProperty} that is targeted by the transition >>> 88: * @param elapsedTime the time that has elapsed since the transition has entered its active period >> >> Can property be `null`? Any restrictions on `elapsedTime`? > > Added a `@throws` tag. > Interestingly, `Event` doesn't specify or assert that its `eventType` parameter is non-null. Maybe we should investigate this further. `eventType` is not used for a lot of things, aside from deciding which list of handlers to pick. In theory, you could have a `null` `EventType`, and register an event handler on the `null` type; except that most `addEventHandler` methods don't allow this -- they check that the event type is not `null`. It probably would be good to reject `null` when creating an `Event`, but that's not for this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280688688 From jhendrikx at openjdk.org Tue Aug 1 14:19:59 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 14:19:59 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: <78AJMe4TuBJq2wX3Ndg9LYr-k4UA50fX8mJrxtALeXk=.61331be4-de39-4605-9de9-a4ee60b10b19@github.com> On Mon, 31 Jul 2023 18:20:34 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8968: >> >>> 8966: >>> 8967: for (TransitionTimer timer : transitionTimers) { >>> 8968: if (timer.getProperty() == property) { >> >> minor: this probably works, but I'd still use `equals` here > > Why would this be a sensible thing to do? I'm quite explicitly comparing the identity of `property`, since I'm interested in finding the one property that I'm looking for, not potentially any property that is in some way "equal" to the property. > > For (hopefully) all property implementations, `equals` trivially works because it is not an overridden method and therefore falls back to an identity comparison. What would it even mean for a property to be equal, but not identical to another property? It's up to you, but this is really standard Java practice: you use `equals` which may defer to identity checks, unless there is a very specific reason that you **must** have an identity check. This leaves the decision of how equality works firmly in the hands of the class author. For styleable properties there may not be an issue, although it is an interface that can have 3rd party implementations. In general though, you never know when something might be a proxy, wrapper or adapter that may not be the exact same instance, but are considered equal for most purposes. So if you think it must be an identity check, and you want to avoid others thinking this is a mistake, could you add a comment with the reasoning? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280716181 From david.smith at dms489.com Tue Aug 1 15:05:43 2023 From: david.smith at dms489.com (dms489) Date: Tue, 01 Aug 2023 11:05:43 -0400 Subject: cancel Message-ID: I have changed resouces. DMS -- David Smith david.smith at dms489.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Tue Aug 1 16:46:54 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 1 Aug 2023 16:46:54 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Tue, 1 Aug 2023 13:47:19 GMT, John Hendrikx wrote: >> I don't see any real difference here, but then again I'm not a native speaker. I'll defer to public opinion. > > I'm not a native either, but it flows a bit better IMHO. I checked `String` class, they do it like that there as well. In the `String` class, I find 10 usages of `{@code false} otherwise`, and 2 usages of `otherwise {@code false}`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280900868 From mstrauss at openjdk.org Tue Aug 1 16:54:53 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 1 Aug 2023 16:54:53 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Tue, 1 Aug 2023 13:46:15 GMT, John Hendrikx wrote: >> That's true. However, `CssParser` is built around array-based sequences (see `StringConverter.SequenceConverter`), and changing these arrays to lists would seem out of place for this part of the codebase. What do you think? > > It depends on how much you want guarantees that they're not changed. I suppose it's not that big of an issue. Changing to `List` is likely impossible (I think that part of the API is public in places), only other option than is to recreate the arrays if you want 100% certainty :) I think the risk is quite low, as the only way this could be changed is by acquiring the initial value of the `CssMetaData`, and then overwriting the array element. This shouldn't happen by accident. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280908761 From mstrauss at openjdk.org Tue Aug 1 17:11:55 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 1 Aug 2023 17:11:55 GMT Subject: RFR: 8311895: CSS Transitions [v6] In-Reply-To: References: Message-ID: > Implementation of [CSS Transitions](https://gist.github.com/mstr2/c72f8c9faa87de14926978f517a6018a). > > ### Example > > .button { > -fx-background-color: dodgerblue; > } > > .button:hover { > -fx-background-color: red; > -fx-scale-x: 1.1; > -fx-scale-y: 1.1; > > transition: -fx-background-color 0.5s ease, > -fx-scale-x 0.5s ease, > -fx-scale-y 0.5s ease; > } > > > > ### Limitations > This implementation supports both shorthand and longhand notations for the `transition` property. However, due to limitations of JavaFX CSS, mixing both notations doesn't work: > > .button { > transition: -fx-background-color 1s; > transition-easing-function: linear; > } > > This issue should be addressed in a follow-up enhancement. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Review changes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/870/files - new: https://git.openjdk.org/jfx/pull/870/files/deb65ea3..da61e64c Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=870&range=04-05 Stats: 14 lines in 4 files changed: 6 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/870.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/870/head:pull/870 PR: https://git.openjdk.org/jfx/pull/870 From mstrauss at openjdk.org Tue Aug 1 17:11:56 2023 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 1 Aug 2023 17:11:56 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Tue, 1 Aug 2023 10:49:42 GMT, John Hendrikx wrote: >> The constructor ensures that any spelling of "ALL" is converted to the interned constant "all", which is important as we would otherwise need a more computationally expensive case-insensitive string comparison in `Node.Transitions.find()`. >> Removing the constructor would mean that some unrelated piece of code would need to do this conversion. >> >> The `@throws` tag is not allowed at the class level. > > I meant that you can use the short form of the constructor (without repeating the parameters): > > public record TransitionDefinition(String propertyName, Duration duration, > Duration delay, Interpolator interpolator) { > public TransitionDefinition { // no parameters necessary (short form constructor) > // do checks and assignments here > } > } Done. >> This algorithm is implemented as [specified](https://www.w3.org/TR/css-easing-1/#step-easing-algo), which accounts for the possibility that the interpolator is used for a back-filling animation (`t < 0`). While this is not possible in JavaFX (but may be possible in the future), I think it makes sense to keep the algorithm as is, because it ensures that its results are always correct, even though negative values for `t` are currently out of spec. > > Yeah, I figured as much. I just don't like code that you can't get covered in a unit test, or that contradicts itself. As you can see, I was confused, is it a bug or a feature? Perhaps a comment then to indicate that it's intentional. This is covered in `StepInterpolatorTest.testStart`: the test will assert that for t<0, the step interpolator produces the expected value. I also added a comment that this is intended. >> Added a `@throws` tag. >> Interestingly, `Event` doesn't specify or assert that its `eventType` parameter is non-null. Maybe we should investigate this further. > > `eventType` is not used for a lot of things, aside from deciding which list of handlers to pick. In theory, you could have a `null` `EventType`, and register an event handler on the `null` type; except that most `addEventHandler` methods don't allow this -- they check that the event type is not `null`. > > It probably would be good to reject `null` when creating an `Event`, but that's not for this PR. I added a null check for `eventType` on the `TransitionEvent` class. >> Why would this be a sensible thing to do? I'm quite explicitly comparing the identity of `property`, since I'm interested in finding the one property that I'm looking for, not potentially any property that is in some way "equal" to the property. >> >> For (hopefully) all property implementations, `equals` trivially works because it is not an overridden method and therefore falls back to an identity comparison. What would it even mean for a property to be equal, but not identical to another property? > > It's up to you, but this is really standard Java practice: you use `equals` which may defer to identity checks, unless there is a very specific reason that you **must** have an identity check. This leaves the decision of how equality works firmly in the hands of the class author. > > For styleable properties there may not be an issue, although it is an interface that can have 3rd party implementations. In general though, you never know when something might be a proxy, wrapper or adapter that may not be the exact same instance, but are considered equal for most purposes. > > So if you think it must be an identity check, and you want to avoid others thinking this is a mistake, could you add a comment with the reasoning? Added a comment. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280922738 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280919648 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280921115 PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1280921286 From jhendrikx at openjdk.org Tue Aug 1 18:40:55 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 18:40:55 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: On Tue, 1 Aug 2023 16:44:08 GMT, Michael Strau? wrote: >> I'm not a native either, but it flows a bit better IMHO. I checked `String` class, they do it like that there as well. > > In the `String` class, I find 10 usages of `{@code false} otherwise`, and 2 usages of `otherwise {@code false}`. Well, okay, I checked the two public boolean methods (isEmpty, isBlank) :-) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1281008684 From jhendrikx at openjdk.org Tue Aug 1 18:49:59 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Aug 2023 18:49:59 GMT Subject: RFR: 8311895: CSS Transitions [v2] In-Reply-To: References: <9wIHl0UBccE8_BCf3SnbnrsssJacg0Lbsa4jBxF0Rxg=.4d1e651c-50da-4a98-8d22-d0b2c8bc90dd@github.com> Message-ID: <1JuvEFVJvFVOFmH0FQ3HCfFw9E7_m2v4h9lRonFKUBs=.389ae993-bf06-4f09-9030-4870ef9f4a88@github.com> On Tue, 1 Aug 2023 17:02:33 GMT, Michael Strau? wrote: >> Yeah, I figured as much. I just don't like code that you can't get covered in a unit test, or that contradicts itself. As you can see, I was confused, is it a bug or a feature? Perhaps a comment then to indicate that it's intentional. > > This is covered in `StepInterpolatorTest.testStart`: the test will assert that for t<0, the step interpolator produces the expected value. I also added a comment that this is intended. Thanks for adding the comment, it's fine as is, but I expressed myself unclearly. What I meant is that you can't get full (branch) coverage on the code in the `if`s -- it can't ever happen in its current form -- I didn't mean to imply there was no test for it at all, sorry. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/870#discussion_r1281017545 From psadhukhan at openjdk.org Wed Aug 2 04:27:13 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 2 Aug 2023 04:27:13 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v7] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <-KQ6gJImPO1KYH8yePZPikoYNUNNJD_TfArkvttkyrE=.93547a8d-d181-497a-9e55-ada42d6e0d3e@github.com> > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Fix JDK-8222209 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/fb91ede0..16e83a1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=05-06 Stats: 21 lines in 2 files changed: 1 ins; 16 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From psadhukhan at openjdk.org Wed Aug 2 04:27:31 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Wed, 2 Aug 2023 04:27:31 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: <8u8_v_5fsTY6FxZQaxNbWI5kgrOaOjhCbf79ZKWe_Gg=.e5a0bb11-f6cf-48d1-a68b-36f7419b2984@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> <8u8_v_5fsTY6FxZQaxNbWI5kgrOaOjhCbf79ZKWe_Gg=.e5a0bb11-f6cf-48d1-a68b-36f7419b2984@github.com> Message-ID: <5Zcjv0muI9y9Y3HlokREw-oG8x9ll3ecG7kYbuwQL-4=.85ad0f48-2d4b-4c28-96ad-e6c117fc0a78@github.com> On Tue, 1 Aug 2023 10:25:33 GMT, John Hendrikx wrote: > @prsadhuk @hjohn I'll take a closer look early next week, but I think the best way forward might be for Prasanta to evaluate #1189 and, if the modified fix in that PR is what we want to use, update _this_ PR to include the change that adds the call to `updateSceneState()` and removes the explicit call to `Stage::setRenderScale[XY]`. Then add John as a contributor to this PR using `/contributor add`. I have tested both JDK-8222209 and JDK-8274932 with #1189 fix and it works fine. Only question I have is, should `updateSceneState` be called in `QuantumToolkit.runWithRenderLock` synchronization? And also should we move `updateSceneState` to `GlassScene.entireSceneNeedsRepaint` as that changes the scene, so scene state needs to be updated!! > We can then close [JDK-8222209](https://bugs.openjdk.org/browse/JDK-8222209) as a duplicate of [JDK-8274932](https://bugs.openjdk.org/browse/JDK-8274932). I think JDK-8274932 is about scale correction and JDK-8222209 is about content refresh in different-scaled configuration so I dont think one is duplicate of another. I can add #1189 change to this PR and do /contributor add but I think we should do "/issue add JDK-8222209" instead of closing that as duplicate. [Another possibility is we can have this PR only contain swing-interop change and let #1189 having only non swing-interop updateSceneState change and assign JDK-8222209 to @hjohn] > > > @prsadhuk @hjohn I'll take a closer look early next week, but I think the best way forward might be for Prasanta to evaluate #1189 and, if the modified fix in that PR is what we want to use, update _this_ PR to include the change that adds the call to `updateSceneState()` and removes the explicit call to `Stage::setRenderScale[XY]`. Then add John as a contributor to this PR using `/contributor add`. > > > > > > I have tested both JDK-8222209 and JDK-8274932 with #1189 fix and it works fine. Only question I have is, should `updateSceneState` be called in `QuantumToolkit.runWithRenderLock` synchronization? And also should we move `updateSceneState` to `GlassScene.entireSceneNeedsRepaint` as that changes the scene, so scene state needs to be updated!! > > I'm not sure, we'd have to look into that further still (is the lock also required for calling `entireSceneNeedsRepaint`?) > > It's possible the lock is there because that `WindowEvent` is received on a non-FX thread. I will let windows-toolkit person to comment on the requirement of lock..I think it might be needed... > My primary concern is that https://github.com/openjdk/jfx/pull/1171 is doing Platform.runLater calls that I think are undesired and unnecessary if you add updateSceneState. In other words, the fix in https://github.com/openjdk/jfx/pull/1189 might fix both problems without needing to call Platform.runLater, but I haven't tested that. That anyway I would have deleted when #1189 would have been approved...anyway, I have merged that PR in this... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1661469846 From jhendrikx at openjdk.org Wed Aug 2 07:51:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 2 Aug 2023 07:51:49 GMT Subject: Withdrawn: JDK-8222209: Repaint properly when JFXPanel moves to another screen In-Reply-To: References: Message-ID: <7lnymsiMHVmsmyFfNEIb-AE1qWCMWJxIXWIKmqI_F2o=.5eaf6997-073e-4e57-a039-145d04be875f@github.com> On Fri, 28 Jul 2023 09:26:35 GMT, John Hendrikx wrote: > Alternative fix for JFXPanel issues. > > I added an extra line to **really** trigger the repainting in `EmbeddedScene`. This was inspired by this code in `GlassWindowEventHandler` which reacts to `WindowEvent.RESCALE`. It not only calls `entireSceneNeedsRepaint` but also `updateSceneState`. Snippet: > > case WindowEvent.RESCALE: { > float outScaleX = window.getOutputScaleX(); > float outScaleY = window.getOutputScaleY(); > stage.stageListener.changedScale(outScaleX, outScaleY); > // We need to sync the new scales for painting > QuantumToolkit.runWithRenderLock(() -> { > GlassScene scene = stage.getScene(); > if (scene != null) { > scene.entireSceneNeedsRepaint(); > scene.updateSceneState(); > } > return null; > }); > break; > } This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1189 From duke at openjdk.org Wed Aug 2 09:47:25 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Wed, 2 Aug 2023 09:47:25 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute [v3] In-Reply-To: References: Message-ID: > This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. > Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. Guillaume T?che has updated the pull request incrementally with one additional commit since the last revision: 8260342: Resolve review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1158/files - new: https://git.openjdk.org/jfx/pull/1158/files/92da990d..0bc57bdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1158&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1158&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1158.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1158/head:pull/1158 PR: https://git.openjdk.org/jfx/pull/1158 From duke at openjdk.org Wed Aug 2 09:47:30 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Wed, 2 Aug 2023 09:47:30 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute [v2] In-Reply-To: References: Message-ID: <5Pr-ttpHmnRuU23nqYdXQlqQqzsVvVgHc2tALDNtulQ=.624626ed-6a7e-4153-9dea-907c8f693c92@github.com> On Tue, 1 Aug 2023 10:04:25 GMT, Ajit Ghaisas wrote: >> Guillaume T?che has updated the pull request incrementally with one additional commit since the last revision: >> >> Empty commit > > modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1101: > >> 1099: loadListener.readInternalAttribute(localName, value); >> 1100: } >> 1101: final ResourceBundle loaderResources = FXMLLoader.this.resources; > > Why to have this local temporary `loaderResources`? > We can simply use `this.resources` for readability. Done. > modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1106: > >> 1104: } else { >> 1105: final ClassLoader cl = loaderResources.getClass().getClassLoader(); >> 1106: resources = cl == null ? > > Add a bracket around `cl == null` Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1158#discussion_r1281664467 PR Review Comment: https://git.openjdk.org/jfx/pull/1158#discussion_r1281664578 From jbhaskar at openjdk.org Wed Aug 2 12:33:10 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 2 Aug 2023 12:33:10 GMT Subject: [jfx21u] Integrated: 8313177: Web Workers timeout with Webkit 616.1 Message-ID: clean backport for jfx21u. The fix is for the js web worker timeout ( some tests fail to finish) ------------- Commit messages: - Backport 5f5e54feb2e816dcb351a28862c798117c3f81e8 Changes: https://git.openjdk.org/jfx21u/pull/5/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=5&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313177 Stats: 117 lines in 4 files changed: 110 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jfx21u/pull/5.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/5/head:pull/5 PR: https://git.openjdk.org/jfx21u/pull/5 From jbhaskar at openjdk.org Wed Aug 2 12:33:10 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Wed, 2 Aug 2023 12:33:10 GMT Subject: [jfx21u] Integrated: 8313177: Web Workers timeout with Webkit 616.1 In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 12:23:04 GMT, Jay Bhaskar wrote: > clean backport for jfx21u. The fix is for the js web worker timeout ( some tests fail to finish) This pull request has now been integrated. Changeset: a9161e83 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx21u/commit/a9161e83bede3cde1c8a3de686b4f6773d9005a9 Stats: 117 lines in 4 files changed: 110 ins; 7 del; 0 mod 8313177: Web Workers timeout with Webkit 616.1 Backport-of: 5f5e54feb2e816dcb351a28862c798117c3f81e8 ------------- PR: https://git.openjdk.org/jfx21u/pull/5 From kcr at openjdk.org Wed Aug 2 15:27:53 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Aug 2023 15:27:53 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: <5Zcjv0muI9y9Y3HlokREw-oG8x9ll3ecG7kYbuwQL-4=.85ad0f48-2d4b-4c28-96ad-e6c117fc0a78@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> <8u8_v_5fsTY6FxZQaxNbWI5kgrOaOjhCbf79ZKWe_Gg=.e5a0bb11-f6cf-48d1-a68b-36f7419b2984@github.com> <5Zcjv0muI9y9Y3HlokREw-oG8x9ll3ecG7kYbuwQL-4=.85ad0f48-2d4b-4c28-96ad-e6c117fc0a78@github.com> Message-ID: On Wed, 2 Aug 2023 04:24:37 GMT, Prasanta Sadhukhan wrote: > I think JDK-8274932 is about scale correction and JDK-8222209 is about content refresh in different-scaled configuration so I dont think one is duplicate of another. OK, thanks for doing the `/issue add` then. Don't forget do the `/contributor add` to add @hjohn as a contributor of this fix. I'll take a look at this today, and specifically the question about the render lock. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1662414711 From mhanl at openjdk.org Wed Aug 2 16:44:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 2 Aug 2023 16:44:55 GMT Subject: RFR: JDK-8313628: Column drag header, overlay and line are not correctly aligned Message-ID: When a table has padding or the `layoutChildren` method inside the table skin is overridden (and x/y are modified), the drag drag header, column overlay and column line are not correctly aligned. The reason is that the positions were calculated incorrectly. - **Column overlay and column line** Always calculate in the x and y from the table. The x and y variables contain the snapped insets (padding) and possible modifications from subclasses. - **Drag header** Calculate the drag x offset local bounds from the parent header (which is either the parent column header or the root header) Before, the local bounds were calculated from the table, which will wrongly calculate in the padding. We do not want to know the local bounds based of the whole table but of our header we are in. ------------- Commit messages: - JDK-8313628: Column drag header, overlay and line are not correctly aligned Changes: https://git.openjdk.org/jfx/pull/1193/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1193&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313628 Stats: 371 lines in 5 files changed: 336 ins; 7 del; 28 mod Patch: https://git.openjdk.org/jfx/pull/1193.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1193/head:pull/1193 PR: https://git.openjdk.org/jfx/pull/1193 From mhanl at openjdk.org Wed Aug 2 16:44:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 2 Aug 2023 16:44:55 GMT Subject: RFR: JDK-8313628: Column drag header, overlay and line are not correctly aligned In-Reply-To: References: Message-ID: <5HEgA-DadlO-bgfiJCSDLPlTkBKW58sUzsk091pB99Y=.1b49728b-9645-46dd-bde3-26a3886ce70c@github.com> On Wed, 2 Aug 2023 16:36:47 GMT, Marius Hanl wrote: > When a table has padding or the `layoutChildren` method inside the table skin is overridden (and x/y are modified), the drag drag header, column overlay and column line are not correctly aligned. > > The reason is that the positions were calculated incorrectly. > - **Column overlay and column line** > Always calculate in the x and y from the table. The x and y variables contain the snapped insets (padding) and possible modifications from subclasses. > - **Drag header** > Calculate the drag x offset local bounds from the parent header (which is either the parent column header or the root header) > Before, the local bounds were calculated from the table, which will wrongly calculate in the padding. > We do not want to know the local bounds based of the whole table but of our header we are in. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewSkinTest.java line 69: > 67: scene.getStylesheets().add(TableViewSkinTest.class.getResource("TableViewSkinTest.css").toExternalForm()); > 68: > 69: stageLoader = new StageLoader(scene); Note: I just cleaned up this test to also use the more safe `stageLoader` approach. Unfortunately the diff looks a bit weird... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1193#discussion_r1282168787 From mhanl at openjdk.org Wed Aug 2 22:27:11 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 2 Aug 2023 22:27:11 GMT Subject: RFR: JDK-8311983: ListView sometimes throws an IndexOutOfBoundsException Message-ID: An IOOBE was thrown when scrolling up via the trough (-> `VirtualScrollBar#adjustValue`). This happened only when it has bigger cells than the viewport. If the the uppermost cell with the index 0 is only visible (although not completely scrolled to the top) and then an attempt is made to scroll up again, the `VirtualFlow` will try to scroll to the next cell, subtracting index 0 by 1, resulting in -1 -> IOOBE. The code now guards against any under or overflow. This is technically a regression from https://bugs.openjdk.org/browse/JDK-8173321 Note: While testing with very big cells, I found out that scrolling via the trough may not work after the first time. This is because the `VirtualFlow` still creates 2 cells, although only one can be visible at a time (and `VirtualScrollBar` does this check, which will never be true then: `firstVisibleCell == lastVisibleCell`). This is unrelated to this fix. I can create a ticket when I have more information. ------------- Commit messages: - JDK-8311983: ListView sometimes throws an IndexOutOfBoundsException Changes: https://git.openjdk.org/jfx/pull/1194/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311983 Stats: 39 lines in 3 files changed: 30 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1194.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1194/head:pull/1194 PR: https://git.openjdk.org/jfx/pull/1194 From kcr at openjdk.org Wed Aug 2 23:04:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Aug 2023 23:04:15 GMT Subject: RFR: 8301302: Platform preferences API [v4] In-Reply-To: <1wpQh3sviOLynWRd_lEAZ27iManns5ojKnDagHWua4A=.d2660433-6ad2-48fa-9999-ec63f08e514a@github.com> References: <11sPJpB3Ow0xkB3OKw9Fx-_D9nrD78SEMQW0j-RiSHA=.729a7078-6a02-476a-9fa7-234b7ddbc70e@github.com> <1wpQh3sviOLynWRd_lEAZ27iManns5ojKnDagHWua4A=.d2660433-6ad2-48fa-9999-ec63f08e514a@github.com> Message-ID: On Mon, 24 Jul 2023 17:45:31 GMT, Michael Strau? wrote: >> Please read [this document](https://gist.github.com/mstr2/9f46f92c98d3c86aa6a0b4224a9a6548) for an introduction to the Platform Preferences API, and how it interacts with the proposed style theme and stage appearance features. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Added test > - doc changes > - Ensure that ColorProperty changes are atomic when observed > - removed unused code > - Move Appearance enum to javafx.application > - doc changes > - Removed platform-independent preference keys > - documentation > - Platform preferences implementation I'm not sure why the Skara bot went into a loop adding the same comment nearly a 100 times in the space of less than 15 minutes, but we'll investigate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1014#issuecomment-1656756670 From kcr at openjdk.org Wed Aug 2 23:28:24 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 2 Aug 2023 23:28:24 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v6] In-Reply-To: <5Zcjv0muI9y9Y3HlokREw-oG8x9ll3ecG7kYbuwQL-4=.85ad0f48-2d4b-4c28-96ad-e6c117fc0a78@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <7Ncyp0c3-e4p7THnFlZ5yOAJ8YrVaYGigiaw4PiCAmE=.649a959c-870f-412f-88e0-af24a566926c@github.com> <8u8_v_5fsTY6FxZQaxNbWI5kgrOaOjhCbf79ZKWe_Gg=.e5a0bb11-f6cf-48d1-a68b-36f7419b2984@github.com> <5Zcjv0muI9y9Y3HlokREw-oG8x9ll3ecG7kYbuwQL-4=.85ad0f48-2d4b-4c28-96ad-e6c117fc0a78@github.com> Message-ID: <5-cOqaFKDuI6WM8ShBR9uopxtVcFfagyH5CgtNYCFJM=.87907fb0-ee75-4ced-b8d5-54b9580708f9@github.com> On Wed, 2 Aug 2023 04:24:37 GMT, Prasanta Sadhukhan wrote: > Only question I have is, should updateSceneState be called in QuantumToolkit.runWithRenderLock synchronization? We probably do need to acquire the lock. All but one call to that method is done with the `renderLock` held. A bigger concern with the fix, though, is the fact that `updateSceneState` must be called on the FX Application thread. Given that `setPixelScaleFactors` can be called either on the EDT or on the FX Application thread, you will either need a different place to call `updateSceneState`, or else will need use a `runLater` to call it. > And also should we move updateSceneState to GlassScene.entireSceneNeedsRepaint as that changes the scene, so scene state needs to be updated!! No, definitely not. GlassScene.entireSceneNeedsRepaint is called far more often than updateSceneState (and not always from the FX app thread(. There are plenty of reasons to need to paint the entire scene without needing to update the scene state at the time you mark the scene as needing update. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1663091978 From psadhukhan at openjdk.org Thu Aug 3 04:06:04 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Thu, 3 Aug 2023 04:06:04 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Call updateSceneState with lock and in FX thread ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/16e83a1a..b303422a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=06-07 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From aghaisas at openjdk.org Thu Aug 3 10:32:41 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Thu, 3 Aug 2023 10:32:41 GMT Subject: RFR: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute [v3] In-Reply-To: References: Message-ID: <9uQFKR0c1i5dsH8-ZdUl1x2AJazbGo0tVcHOpOrKOf0=.29fa12ea-524b-4793-8b4e-3ad01de43082@github.com> On Wed, 2 Aug 2023 09:47:25 GMT, Guillaume T?che wrote: >> This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. >> Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. > > Guillaume T?che has updated the pull request incrementally with one additional commit since the last revision: > > 8260342: Resolve review comments Fix looks good! ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1158#pullrequestreview-1560790673 From kcr at openjdk.org Thu Aug 3 11:24:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Aug 2023 11:24:40 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 3 Aug 2023 04:06:04 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Call updateSceneState with lock and in FX thread This looks good now. I'll do some testing and then finish my review. ------------- PR Review: https://git.openjdk.org/jfx/pull/1171#pullrequestreview-1560873358 From kcr at openjdk.org Thu Aug 3 11:45:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Aug 2023 11:45:38 GMT Subject: RFR: JDK-8311983: ListView sometimes throws an IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 22:21:20 GMT, Marius Hanl wrote: > An IOOBE was thrown when scrolling up via the trough (-> `VirtualScrollBar#adjustValue`). > This happened only when it has bigger cells than the viewport. > If the the uppermost cell with the index 0 is only visible (although not completely scrolled to the top) and then an attempt is made to scroll up again, the `VirtualFlow` will try to scroll to the next cell, subtracting index 0 by 1, resulting in -1 -> IOOBE. > > The code now guards against any under or overflow. > > This is technically a regression from https://bugs.openjdk.org/browse/JDK-8173321 > > Note: While testing with very big cells, I found out that scrolling via the trough may not work after the first time. > This is because the `VirtualFlow` still creates 2 cells, although only one can be visible at a time (and `VirtualScrollBar` does this check, which will never be true then: `firstVisibleCell == lastVisibleCell`). This is unrelated to this fix. I can create a ticket when I have more information. I'll let others who are more familiar with VirtualFlow formally review it, but I left a comment on the fix and test. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 144: > 142: index = Math.max(0, index - 1); > 143: } else { > 144: index = Math.max(flow.getCellCount(), index + 1); Shouldn't this be Math.min? modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java line 37: > 35: import static org.junit.Assert.assertTrue; > 36: import static org.junit.Assert.fail; > 37: import static org.junit.jupiter.api.Assertions.assertDoesNotThrow; We do not want to mix JUnit 4 and JUnit 5 calls in the same test class. Since converting this class to use JUnit 5 would be out of scope for a bug fix such as this, please rewrite it using JUnit 4 API calls only (which probably means a try/catch with a "fail" if you don't get the expected exception. ------------- PR Review: https://git.openjdk.org/jfx/pull/1194#pullrequestreview-1560899072 PR Review Comment: https://git.openjdk.org/jfx/pull/1194#discussion_r1283076891 PR Review Comment: https://git.openjdk.org/jfx/pull/1194#discussion_r1283074296 From kcr at openjdk.org Thu Aug 3 11:51:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Aug 2023 11:51:39 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: <6TaKPIybVt4XGj6tMhw7aW7CHP0Jw-K1a8a4ESZfeRM=.69e73f19-3525-40f8-99c3-a2ee3d722d7f@github.com> References: <6TaKPIybVt4XGj6tMhw7aW7CHP0Jw-K1a8a4ESZfeRM=.69e73f19-3525-40f8-99c3-a2ee3d722d7f@github.com> Message-ID: <_c5rcfqvOJB1ohEnGcA6zmllDKjHqbh5qobT5kdUuVE=.30ce65d4-a550-4c8f-9350-0152a1b6cf68@github.com> On Tue, 1 Aug 2023 11:29:55 GMT, Jose Pereda wrote: >> This is a different type of a problem, that imho should be addressed as well, but in a separate issue which also contains a test strategy. This is something that requires a hash-based solution, but it is something that needs to be done with great care, so I personally wouldn't rush this into this PR (as it might cause criticial regression if not done correctly). > > Agree to do it separately, but in any case, if there was already a file at the cache directory, its checksum is verified, and in case it is not the same, the file is removed from the cache, before it is copied again. > Does this cover the possible scenarios you are referring to? I agree with Johan and Jose: This should be fixed in a separate issue. @jperedadnr can you file a follow-up bug to investigate? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1283084195 From kcr at openjdk.org Thu Aug 3 11:51:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Aug 2023 11:51:40 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: References: Message-ID: On Tue, 1 Aug 2023 11:25:49 GMT, Jose Pereda wrote: >> Probably something to evaluate, but in a separate ticket > > I agree, this should probably be considered as well, as part of a separate ticket. > > Note that, when the file already exists in the cache, the initial InputStream object is used by the DigestInputStream, and it is manually closed and reread again, so special care should be taken here. Unless we suspect a problem, I don't see a need to do anything differently. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1283083999 From mhanl at openjdk.org Thu Aug 3 11:55:42 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Aug 2023 11:55:42 GMT Subject: RFR: JDK-8311983: ListView sometimes throws an IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 11:41:30 GMT, Kevin Rushforth wrote: >> An IOOBE was thrown when scrolling up via the trough (-> `VirtualScrollBar#adjustValue`). >> This happened only when it has bigger cells than the viewport. >> If the the uppermost cell with the index 0 is only visible (although not completely scrolled to the top) and then an attempt is made to scroll up again, the `VirtualFlow` will try to scroll to the next cell, subtracting index 0 by 1, resulting in -1 -> IOOBE. >> >> The code now guards against any under or overflow. >> >> This is technically a regression from https://bugs.openjdk.org/browse/JDK-8173321 >> >> Note: While testing with very big cells, I found out that scrolling via the trough may not work after the first time. >> This is because the `VirtualFlow` still creates 2 cells, although only one can be visible at a time (and `VirtualScrollBar` does this check, which will never be true then: `firstVisibleCell == lastVisibleCell`). This is unrelated to this fix. I can create a ticket when I have more information. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/VirtualScrollBar.java line 144: > >> 142: index = Math.max(0, index - 1); >> 143: } else { >> 144: index = Math.max(flow.getCellCount(), index + 1); > > Shouldn't this be Math.min? Yes indeed, leftover from testing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1194#discussion_r1283094443 From jpereda at openjdk.org Thu Aug 3 12:25:36 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 3 Aug 2023 12:25:36 GMT Subject: RFR: 8307536: FileAlreadyExistsException from NativeLibLoader when running concurrent applications with empty cache In-Reply-To: <_c5rcfqvOJB1ohEnGcA6zmllDKjHqbh5qobT5kdUuVE=.30ce65d4-a550-4c8f-9350-0152a1b6cf68@github.com> References: <6TaKPIybVt4XGj6tMhw7aW7CHP0Jw-K1a8a4ESZfeRM=.69e73f19-3525-40f8-99c3-a2ee3d722d7f@github.com> <_c5rcfqvOJB1ohEnGcA6zmllDKjHqbh5qobT5kdUuVE=.30ce65d4-a550-4c8f-9350-0152a1b6cf68@github.com> Message-ID: On Thu, 3 Aug 2023 11:48:49 GMT, Kevin Rushforth wrote: >> Agree to do it separately, but in any case, if there was already a file at the cache directory, its checksum is verified, and in case it is not the same, the file is removed from the cache, before it is copied again. >> Does this cover the possible scenarios you are referring to? > > I agree with Johan and Jose: This should be fixed in a separate issue. @jperedadnr can you file a follow-up bug to investigate? Sure, I've filed: https://bugs.openjdk.org/browse/JDK-8313688 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1188#discussion_r1283126446 From duke at openjdk.org Thu Aug 3 15:02:43 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Thu, 3 Aug 2023 15:02:43 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene Message-ID: `setHeight()` / `setWidth()` were ignored if called after `sizeToScene()` and before `show()`. Now the `sizeToScene` flag is unset in these methods to ensure the right values are set when the window is shown. ------------- Commit messages: - 8310885: Width/height of window is not set after calling sizeToScene Changes: https://git.openjdk.org/jfx/pull/1195/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310885 Stats: 68 lines in 2 files changed: 62 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1195.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1195/head:pull/1195 PR: https://git.openjdk.org/jfx/pull/1195 From mhanl at openjdk.org Thu Aug 3 15:13:09 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Aug 2023 15:13:09 GMT Subject: RFR: JDK-8311983: ListView sometimes throws an IndexOutOfBoundsException [v2] In-Reply-To: References: Message-ID: > An IOOBE was thrown when scrolling up via the trough (-> `VirtualScrollBar#adjustValue`). > This happened only when it has bigger cells than the viewport. > If the the uppermost cell with the index 0 is only visible (although not completely scrolled to the top) and then an attempt is made to scroll up again, the `VirtualFlow` will try to scroll to the next cell, subtracting index 0 by 1, resulting in -1 -> IOOBE. > > The code now guards against any under or overflow. > > This is technically a regression from https://bugs.openjdk.org/browse/JDK-8173321 > > Note: While testing with very big cells, I found out that scrolling via the trough may not work after the first time. > This is because the `VirtualFlow` still creates 2 cells, although only one can be visible at a time (and `VirtualScrollBar` does this check, which will never be true then: `firstVisibleCell == lastVisibleCell`). This is unrelated to this fix. I can create a ticket when I have more information. Marius Hanl has updated the pull request incrementally with three additional commits since the last revision: - JDK-8311983: remove JUnit5 import - JDK-8311983: improve exception handling - JDK-8311983: More tests ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1194/files - new: https://git.openjdk.org/jfx/pull/1194/files/63531d7f..0de3f7a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1194&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1194&range=00-01 Stats: 49 lines in 2 files changed: 45 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1194.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1194/head:pull/1194 PR: https://git.openjdk.org/jfx/pull/1194 From kcr at openjdk.org Thu Aug 3 15:16:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Aug 2023 15:16:39 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 14:57:50 GMT, Guillaume T?che wrote: > `setHeight()` / `setWidth()` were ignored if called after `sizeToScene()` and before `show()`. > Now the `sizeToScene` flag is unset in these methods to ensure the right values are set when the window is shown. The fix looks reasonable at first glance. @arapte can you be the primary reviewer? @lukostyra you might also want to take a look. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1195#issuecomment-1664172211 From mhanl at openjdk.org Thu Aug 3 15:18:49 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Aug 2023 15:18:49 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 263: > 261: > 262: > 263: /** {@inheritDoc} */ Isn't this still needed? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283355800 From jhendrikx at openjdk.org Thu Aug 3 15:27:53 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 3 Aug 2023 15:27:53 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 15:15:57 GMT, Marius Hanl wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 263: > >> 261: >> 262: >> 263: /** {@inheritDoc} */ > > Isn't this still needed? There is an `@Override` annotation, javadoc will do the right thing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283359580 From mhanl at openjdk.org Thu Aug 3 15:27:54 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Aug 2023 15:27:54 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 15:18:51 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 263: >> >>> 261: >>> 262: >>> 263: /** {@inheritDoc} */ >> >> Isn't this still needed? > > There is an `@Override` annotation, javadoc will do the right thing. So it is only needed when we want to add something to the javadoc coming from the superclass? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283367177 From mhanl at openjdk.org Thu Aug 3 15:27:57 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 3 Aug 2023 15:27:57 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Fri, 9 Jun 2023 12:45:02 GMT, John Hendrikx wrote: >> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`. >> >> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking. >> >> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`. >> >> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set` or `Set` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well. >> >> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified. >> >> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details. >> >> Although the test case above was extreme, this change should have positive effects for most applications. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate > - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/immutable-pseudoclassstate > - Fix another edge case in BitSet equals > > When arrays are not the same size, but there are no set bits in the ones > the other set doesn't have, two bit sets can still be considered equal > - Take element type into account for BitSet.equals() > - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray > > - Removed faulty toArray implementations in PseudoClassState and > StyleClassSet > - Added test that verifies equals/hashCode for PseudoClassState respect > Set contract now > - Made getBits package private so it can't be inherited > - Remove unused code > - Ensure Match doesn't allow modification > - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy > - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 582: > 580: } > 581: > 582: if (count == depth) { Can you explain why we can return here? modules/javafx.graphics/src/test/java/test/com/sun/javafx/css/ImmutablePseudoClassSetsCacheTest.java line 41: > 39: assertNotEquals(set4, set5); > 40: > 41: assertTrue(set1 == set2); you can actually use `assertSame` here. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283364589 PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283362317 From angorya at openjdk.org Thu Aug 3 18:07:42 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Aug 2023 18:07:42 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 3 Aug 2023 04:06:04 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Call updateSceneState with lock and in FX thread modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 826: > 824: } > 825: double newScaleFactorX = config.getDefaultTransform().getScaleX(); > 826: double newScaleFactorY = config.getDefaultTransform().getScaleY(); minor suggestion: create a method get[Current]Transform() to avoid code duplication (here and line 621) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1171#discussion_r1283538380 From hmeda at openjdk.org Thu Aug 3 18:12:49 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Thu, 3 Aug 2023 18:12:49 GMT Subject: RFR: 8313711: Cherry-pick webkitgtk-2.40.5 stabilzation fixes Message-ID: Cherry-picked commits from webkitgtk-2.40.5. Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen ------------- Commit messages: - white space correction - cherry-pick webkit-2.40.5 Changes: https://git.openjdk.org/jfx/pull/1196/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313711 Stats: 636 lines in 88 files changed: 320 ins; 150 del; 166 mod Patch: https://git.openjdk.org/jfx/pull/1196.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1196/head:pull/1196 PR: https://git.openjdk.org/jfx/pull/1196 From kcr at openjdk.org Thu Aug 3 18:34:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 3 Aug 2023 18:34:38 GMT Subject: RFR: 8313711: Cherry-pick webkitgtk-2.40.5 stabilzation fixes In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 17:54:48 GMT, Hima Bindu Meda wrote: > Cherry-picked commits from webkitgtk-2.40.5. > Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen I changed the JBS title to match the pattern that we use for cherry-picking stabilization fixes. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1196#issuecomment-1664445924 From duke at openjdk.org Thu Aug 3 19:04:39 2023 From: duke at openjdk.org (Martin Fox) Date: Thu, 3 Aug 2023 19:04:39 GMT Subject: RFR: 8308644: [Linux] Missing mappings for dead keys + Alt Gr [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 11:45:30 GMT, Thiago Milczarek Sayao wrote: >> This PR adds missing key mappings for dead keys and fixes "Alt Gr" for some systems. > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - Minimize changes > - Merge branch 'master' into gdk_to_glass_key_map > - Forgot test code > - Back to hash > - Revert key lock change because it has different behaviour > - Revert modifier change + Remove F13 -> F24 > - Remove print statement > - Use GDK instead of X calls (to ease in a future wayland implementation) > - Avoid sending unknown key event > - GDK_META_MASK is not ALT > - ... and 6 more: https://git.openjdk.org/jfx/compare/1b8f7d64...aad021a6 I'm surprised no customer ever noticed this. On Linux the current JavaFX behavior is that the real AltGr key (the one that appears on European and UK keyboards) is assigned KeyCode.UNDEFINED. On layouts like US English the right Alt key is just an Alt key but we sill assign it KeyCode.ALT_GRAPH. So, yeah, we should be adding ISO_Level3_Shift to the map. The Robot digs through the hash map to do a reverse lookup from KeyCode to keysym. I'll add AltGr to my keyboard test app and sort out how this affects the Robot. I'm not too worried about making matters worse, as it stands the Robot can't send an ALT_GRAPH key event on layouts that actually use AltGr. The dead key additions are harmless and make the system look more professional but those codes only show up on RELEASED KeyEvents so I suspect they will be ignored. Windows doesn't even generate RELEASED events for dead keys. The Mac does but the codes are wrong. But, again, I don't see any downside to adding them. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1143#issuecomment-1664483379 From angorya at openjdk.org Thu Aug 3 19:30:40 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Aug 2023 19:30:40 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v4] In-Reply-To: References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com> Message-ID: On Wed, 5 Jul 2023 19:30:21 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale) (I think). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - whitespace > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - review comments > - review comments > - whitespace > - removed obsolete tester > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - cleanup > - new algorithm @kevinrushforth please take a look. thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-1664515679 From angorya at openjdk.org Thu Aug 3 23:07:38 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 3 Aug 2023 23:07:38 GMT Subject: RFR: JDK-8313628: Column drag header, overlay and line are not correctly aligned In-Reply-To: References: Message-ID: On Wed, 2 Aug 2023 16:36:47 GMT, Marius Hanl wrote: > When a table has padding or the `layoutChildren` method inside the table skin is overridden (and x/y are modified), the drag drag header, column overlay and column line are not correctly aligned. > > The reason is that the positions were calculated incorrectly. > - **Column overlay and column line** > Always calculate in the x and y from the table. The x and y variables contain the snapped insets (padding) and possible modifications from subclasses. > - **Drag header** > Calculate the drag x offset local bounds from the parent header (which is either the parent column header or the root header) > Before, the local bounds were calculated from the table, which will wrongly calculate in the padding. > We do not want to know the local bounds based of the whole table but of our header we are in. Looks good on macOS with 2 monitors (scales 100% and 200%), and on Windows 11 at different scales, incl. fractional: 100% and 225% modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewSkinTest.java line 79: > 77: @Test > 78: void testInitialColumnResizeNodePositions() { > 79: TableView tableView = new TableView<>(); question: would it make sense to test with scene scale(s) other than 100%? just to see if there is no failures with fractional scales? (the asserts would need to use non-0 tolerance) modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewSkinTest.java line 129: > 127: Toolkit.getToolkit().firePulse(); > 128: > 129: assertEquals(5, columnResizeLine.getLayoutX()); comparing doubles with 0 tolerance: this is probably ok, since we expect to see whole numbers. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1193#pullrequestreview-1561961550 PR Review Comment: https://git.openjdk.org/jfx/pull/1193#discussion_r1283798454 PR Review Comment: https://git.openjdk.org/jfx/pull/1193#discussion_r1283797210 From jhendrikx at openjdk.org Fri Aug 4 04:42:52 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 4 Aug 2023 04:42:52 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 15:22:39 GMT, Marius Hanl wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Merge remote-tracking branch 'upstream/master' into feature/immutable-pseudoclassstate >> - Avoid using Lambda in ImmutablePseudoClassSetsCache.of() >> - Merge branch 'master' of https://git.openjdk.org/jfx into >> feature/immutable-pseudoclassstate >> - Fix another edge case in BitSet equals >> >> When arrays are not the same size, but there are no set bits in the ones >> the other set doesn't have, two bit sets can still be considered equal >> - Take element type into account for BitSet.equals() >> - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray >> >> - Removed faulty toArray implementations in PseudoClassState and >> StyleClassSet >> - Added test that verifies equals/hashCode for PseudoClassState respect >> Set contract now >> - Made getBits package private so it can't be inherited >> - Remove unused code >> - Ensure Match doesn't allow modification >> - Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy >> - ... and 6 more: https://git.openjdk.org/jfx/compare/9ad0e908...7975ae99 > > modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 582: > >> 580: } >> 581: >> 582: if (count == depth) { > > Can you explain why we can return here? Yes, we want to return a `Set[]` which has pseudo class state information for each nesting level of `Node`, as each entry in the array represents a nesting level (0 = `Node`, 1 = parent, 2 = parent.parent, etc.). We allocate the array with the maximum possible nesting level (`depth`). The loop then runs to fill in each level. It's possible however that a level is unused, and in that case the array would be too long, so it must be trimmed. If however all levels were used, there's no need to reallocate the array and we can return early. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283972056 From jhendrikx at openjdk.org Fri Aug 4 04:56:49 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 4 Aug 2023 04:56:49 GMT Subject: RFR: JDK-8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet [v8] In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 15:24:40 GMT, Marius Hanl wrote: >> There is an `@Override` annotation, javadoc will do the right thing. > > So it is only needed when we want to add something to the javadoc coming from the superclass? Yes, that's correct. `@inheritDoc` is only needed when you want to add your own documentation, and you can then choose where to have the original docs "inserted". See last part of this quote from the standard doclet documentation (at https://docs.oracle.com/en/java/javase/20/docs/specs/javadoc/doc-comment-spec.html): ## Comment Inheritance ### Class and Interface Inheritance Comment inheritance occurs in all possible cases of inheritance from classes and interfaces: - When a method in a class overrides a method in a superclass - When a method in an interface overrides a method in a superinterface - When a method in a class implements a method in an interface In the first two cases, the standard doclet generates the subheading "Overrides" in the documentation for the overriding method. A link to the method being overridden is included, whether or not the comment is inherited. In the third case, when a method in a specified class implements a method in an interface, the standard doclet generates the subheading "Specified by" in the documentation for the overriding method. A link to the method being implemented is included, whether or not the comment is inherited. ### Method Comment Inheritance The standard doclet allows method comment inheritance in classes and interfaces to fill in missing text or to explicitly inherit method comments. Constructors, fields, and nested classes do not inherit documentation comments. Note: The source file for an inherited method must be on the path specified by the -sourcepath option for the documentation comment to be available to copy. Neither the class nor its package needs to be passed in on the command line. ### Fill in Missing Text When a main description, or @return, @param, or @throws tag is missing from a method comment, the information is copied from the method it overrides or implements (if any). When an @param tag for a particular parameter is missing, the comment for that parameter is copied from the method further up the inheritance hierarchy. When an @throws tag for a particular exception is missing, the @throws tag is copied only when that exception is declared. ### Explicit Inheritance Insert the {@inheritDoc} inline tag in a method main description or @return, @param, or @throws tag comment. The corresponding inherited main description or tag comment is copied into that spot. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1283979152 From angorya at openjdk.org Fri Aug 4 05:49:37 2023 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 4 Aug 2023 05:49:37 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 3 Aug 2023 04:06:04 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Call updateSceneState with lock and in FX thread The good: - image on both monitors (macOS) appear with no gaps - text on both monitors looks good, anti-aliasing works as expected The bad: - both windows (using EmbeddedFrameBug class listed earlier) shows O100% for primary retina screen (should be 200%). What's more, moving from one screen to another does not trigger the `renderScaleXProperty` change event, using this code: scene.windowProperty().addListener((ob, oldWindow, newWindow) -> { newWindow.renderScaleXProperty().addListener((obs, oldValue, newValue) -> updateText(label, newValue)); updateText(label, newWindow.getRenderScaleX()); newWindow.renderScaleXProperty().addListener((s,p,c) -> { System.out.println("w=" + newWindow + " scale=" + c); }); }); Is this a problem? Screenshot 2023-08-03 at 10 56 56 should be 200% ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1664410463 PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1664412446 From psadhukhan at openjdk.org Fri Aug 4 05:49:38 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Aug 2023 05:49:38 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <5wt7P9euaaxQYbG5PVAued5cjpChVz4ZtnEUeS9M4gI=.9614f577-5528-4968-826d-43d5d74be10f@github.com> On Thu, 3 Aug 2023 18:04:23 GMT, Andy Goryachev wrote: > The good: > > * image on both monitors (macOS) appear with no gaps > > * text on both monitors looks good, anti-aliasing works as expected > > > The bad: > > * both windows (using EmbeddedFrameBug class listed earlier) shows O100% for primary retina screen (should be 200%). What's more, moving from one screen to another does not trigger the `renderScaleXProperty` change event, using this code: > > > ``` > scene.windowProperty().addListener((ob, oldWindow, newWindow) -> { > newWindow.renderScaleXProperty().addListener((obs, oldValue, newValue) -> updateText(label, newValue)); > updateText(label, newWindow.getRenderScaleX()); > newWindow.renderScaleXProperty().addListener((s,p,c) -> { > System.out.println("w=" + newWindow + " scale=" + c); > }); > }); > ``` > > Is this a problem? I do not have mac setup for FX so cannot comment immediately. it worked for windows where it showed correct scale for secondary monitor...swing-interop does not have platform-dependant code so not sure why it will behave that way in mac.. Was that not working before when you first approved? or does it stop working after updateSceneState integration? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1665045386 From psadhukhan at openjdk.org Fri Aug 4 06:21:55 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Aug 2023 06:21:55 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v9] In-Reply-To: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: > When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. > Fix is made to update scales to EmbeddedWindow Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Duplicate code removal ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1171/files - new: https://git.openjdk.org/jfx/pull/1171/files/b303422a..c715f14f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1171&range=07-08 Stats: 23 lines in 1 file changed: 9 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1171.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1171/head:pull/1171 PR: https://git.openjdk.org/jfx/pull/1171 From psadhukhan at openjdk.org Fri Aug 4 06:21:55 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Fri, 4 Aug 2023 06:21:55 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: <-85-RQJkVBKEw6Jgy7kABNscQily9C_kEUIPxvRmRl4=.255f707d-8ac0-410c-a16b-a949b1d0b3ce@github.com> On Thu, 3 Aug 2023 17:55:14 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Call updateSceneState with lock and in FX thread > > modules/javafx.swing/src/main/java/javafx/embed/swing/JFXPanel.java line 826: > >> 824: } >> 825: double newScaleFactorX = config.getDefaultTransform().getScaleX(); >> 826: double newScaleFactorY = config.getDefaultTransform().getScaleY(); > > minor suggestion: create a method get[Current]Transform() to avoid code duplication (here and line 621) done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1171#discussion_r1284026118 From mhanl at openjdk.org Fri Aug 4 07:38:42 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 4 Aug 2023 07:38:42 GMT Subject: RFR: JDK-8313628: Column drag header, overlay and line are not correctly aligned In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 23:02:29 GMT, Andy Goryachev wrote: >> When a table has padding or the `layoutChildren` method inside the table skin is overridden (and x/y are modified), the drag drag header, column overlay and column line are not correctly aligned. >> >> The reason is that the positions were calculated incorrectly. >> - **Column overlay and column line** >> Always calculate in the x and y from the table. The x and y variables contain the snapped insets (padding) and possible modifications from subclasses. >> - **Drag header** >> Calculate the drag x offset local bounds from the parent header (which is either the parent column header or the root header) >> Before, the local bounds were calculated from the table, which will wrongly calculate in the padding. >> We do not want to know the local bounds based of the whole table but of our header we are in. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableViewSkinTest.java line 79: > >> 77: @Test >> 78: void testInitialColumnResizeNodePositions() { >> 79: TableView tableView = new TableView<>(); > > question: would it make sense to test with scene scale(s) other than 100%? just to see if there is no failures with fractional scales? > (the asserts would need to use non-0 tolerance) It probably won't hurt. But since the mismatch is visible even at a normal scale, I didn't bothered to do so. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1193#discussion_r1284088011 From kcr at openjdk.org Fri Aug 4 11:31:41 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Aug 2023 11:31:41 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 17:54:48 GMT, Hima Bindu Meda wrote: > Cherry-picked commits from webkitgtk-2.40.5. > Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen Note that this also contains cherry-picked commits from webkitgtk-2.40.4, since the WebKit 616.1 update was synced up through webkitgtk-2.40.3. Reviewers: @kevinrushforth + @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1196#issuecomment-1665458687 From kcr at openjdk.org Fri Aug 4 11:42:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Aug 2023 11:42:38 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol [v2] In-Reply-To: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> References: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> Message-ID: On Mon, 24 Jul 2023 18:34:22 GMT, Alexander Zuev wrote: >> also >> 8309629: Create implementation of NSAccessibilityRadioButton protocol >> >> Create implementation of NSAccessibilityCheckBox and NSAccessibilityRadioButton protocols >> Add workaround for the wrong focus owner announcement with radio buttons >> Add workaround for wrong magnifier text on buttons > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at the end of the header files. Reviewers @arapte @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1184#issuecomment-1665471584 From duke at openjdk.org Fri Aug 4 11:47:43 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Fri, 4 Aug 2023 11:47:43 GMT Subject: Integrated: 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 10:43:39 GMT, Guillaume T?che wrote: > This fixes ResourceBundle loading by calling `ResourceBundle.getBundle(value, Locale.getDefault())` when the loader resources are null or their classloader is null. > Apparently the original author of the bug report said they would submit a pull request, but it seems like it never happened. This pull request has now been integrated. Changeset: d649a5ea Author: Guillaume T?che Committer: Ajit Ghaisas URL: https://git.openjdk.org/jfx/commit/d649a5ea6b6d85ff33a28c48fd0b9fa920637fa5 Stats: 207 lines in 8 files changed: 204 ins; 0 del; 3 mod 8260342: FXMLLoader fails to load a sub layout using fx:include with the resources attribute Reviewed-by: aghaisas ------------- PR: https://git.openjdk.org/jfx/pull/1158 From kcr at openjdk.org Fri Aug 4 13:30:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Aug 2023 13:30:38 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol [v2] In-Reply-To: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> References: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> Message-ID: On Mon, 24 Jul 2023 18:34:22 GMT, Alexander Zuev wrote: >> also >> 8309629: Create implementation of NSAccessibilityRadioButton protocol >> >> Create implementation of NSAccessibilityCheckBox and NSAccessibilityRadioButton protocols >> Add workaround for the wrong focus owner announcement with radio buttons >> Add workaround for wrong magnifier text on buttons > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at the end of the header files. Code changes look good. I tested it on macOS 13.3.1 and VoiceOver output was as expected. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1184#pullrequestreview-1562875555 From kcr at openjdk.org Fri Aug 4 13:39:42 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Aug 2023 13:39:42 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 17:54:48 GMT, Hima Bindu Meda wrote: > Cherry-picked commits from webkitgtk-2.40.5. > Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen Looks good. Testing is green. modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3DuplicateTails.cpp line 89: > 87: > 88: if (canCopyBlock) > 89: candidates.add(block); The indentation looks off here. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1196#pullrequestreview-1562884809 PR Review Comment: https://git.openjdk.org/jfx/pull/1196#discussion_r1284432329 From kcr at openjdk.org Fri Aug 4 13:39:44 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 4 Aug 2023 13:39:44 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 13:33:17 GMT, Kevin Rushforth wrote: >> Cherry-picked commits from webkitgtk-2.40.5. >> Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen > > modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3DuplicateTails.cpp line 89: > >> 87: >> 88: if (canCopyBlock) >> 89: candidates.add(block); > > The indentation looks off here. I'll reapprove if you choose to fix this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1196#discussion_r1284436576 From mhanl at openjdk.org Fri Aug 4 18:01:59 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 4 Aug 2023 18:01:59 GMT Subject: RFR: 8091153: Customize the Table Button Menu [v5] In-Reply-To: References: Message-ID: On Wed, 24 May 2023 16:55:11 GMT, Marius Hanl wrote: >> This PR implements a way to override the table column menu. >> When the `cornerRegion` is pressed, it will now call the `showColumnMenu` method. This new method is protected and therefore can be overidden by developers. If not overridden, the known default column 'ContextMenu' is created and shown. >> >> This PR also resolves [JDK-8091419 ](https://bugs.openjdk.org/browse/JDK-8091419) (The method `showColumnMenu` can be overridden and made public now) >> >> This PR also helps with [JDK-8092148](https://bugs.openjdk.org/browse/JDK-8092148), but does not address all the points mentioned in the ticket. >> Now that everyone can provide their own implementation, we can think of treating the current implementation of the table column menu as an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) and any other requested feature/idea should be fulfilled by providing your own implementaion of the menu. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8091153: Replace @link with @code (Note: I decided to keep the tag as `@implNote`. I had a look on some examples in the jdk and decided that `@implNote` looks a bit better here IMO. Still the `@apiNote` would be a good fit as well) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1135#issuecomment-1566108067 From mhanl at openjdk.org Fri Aug 4 18:02:06 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 4 Aug 2023 18:02:06 GMT Subject: RFR: 8276056: Control.skin.setSkin(Skin) fails to call dispose() on discarded Skin In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 13:35:15 GMT, Marius Hanl wrote: > For some reason the `skinProperty` did not allow to set a new skin which is the same class as the previous one. > This leads to multiple issues: > 1. When creating a new skin (same class as previous), the skin will likely install some children and listener but is then rejected when setting it due to the `skinProperty` class constraint > -> Control is in a weird state as the current skin was not disposed since it is still set, although we already created and 'set' a new skin > 2. A skin of the same class can behave differently, so it is not really valid to reject a skin just because it is the same class as the previous > -> Just imagine we have the following skin class > > class MyCustomButtonSkin extends ButtonSkin { > public MyCustomButtonSkin(Button button, boolean someFlag) { super(button); ... } > } > > Now if we would change the skin of the Button two times like this: > > button.setSkin(new MyCustomButtonSkin(button, true)); > button.setSkin(new MyCustomButtonSkin(button, false)); > > The second time the skin will be rejected as it is the same class, although I may changed the skin behaviour, in this case demonstrated by a boolean flag for showing purposes. I used the tests you wrote in comments of the ticket. Thanks! ------------- PR Comment: https://git.openjdk.org/jfx/pull/806#issuecomment-1169999580 From mhanl at openjdk.org Fri Aug 4 18:18:55 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 4 Aug 2023 18:18:55 GMT Subject: RFR: JDK-8187314: All Cells: must show backing data always Message-ID: Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`. This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise). We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value. Changed and added tests for all 4 cells. ------------- Commit messages: - JDK-8187314: All Cells: must show backing data always Changes: https://git.openjdk.org/jfx/pull/1197/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8187314 Stats: 110 lines in 8 files changed: 94 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1197.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1197/head:pull/1197 PR: https://git.openjdk.org/jfx/pull/1197 From kevin.rushforth at oracle.com Fri Aug 4 20:49:54 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 4 Aug 2023 13:49:54 -0700 Subject: JavaFX 21 is in Rampdown Phase Two (RDP2) Message-ID: To: JavaFX Developers As a reminder, JavaFX 21 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bug fixes, and test or doc fixes of any priority, can be fixed during RDP2. Explicit approval is needed for all bug fixes and enhancements (except for doc and test fixes) to go in to the jfx21 branch [2]. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in JavaFX 21. We need to be extremely careful about including anything that introduces risk. We will use the same rules for RDP2 that the JDK uses [3], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 21 release. As an obvious choice, derived from the JBS fix version, we will use "jfx21-fix-request", "jfx21-fix-yes", "jfx21-fix-no" and "jfx21-fix-nmi", "jfx21-enhancement-request", "jfx21-enhancement-yes", "jfx21-enhancement-no" and "jfx21-enhancement-nmi" as corresponding labels. REMINDER: In contrast to past practice, in this release we will integrate almost all stabilization changes via backports from the master branch [4]. ? * Almost all fixes intended for the jfx21 stabilization branch will also be applicable to the master branch. Integrate such a change into the master branch first. Then, after you have obtained any required approvals, backport it to the stabilization branch using the Skara `/backport` command or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash.? (The JDK Developers? Guide contains more information on working with backports [5].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 22 as of today). This is usually what we want. A backport PR should be targeted to `jfx21` if, and only if, it is intended for JavaFX 21 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx21`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 22 (or withdrawn if it is a backport of a fix already in `master`). Reviewers also need to be extra careful when reviewing PRs targeted to jfx21 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. This should be less of a problem for this release, since almost all PRs for jfx21 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2023-April/039630.html [2] https://github.com/openjdk/jfx/tree/jfx21 [3] http://openjdk.org/jeps/3 [4] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [5] https://openjdk.org/guide/#working-with-backports-in-jbs From mhanl at openjdk.org Fri Aug 4 22:18:53 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 4 Aug 2023 22:18:53 GMT Subject: RFR: JDK-8313799: Remove lockItemOnEdit flag from (Tree)TableCell Message-ID: The `lockItemOnEdit` only exists inside `TreeTableCell` and `TableCell` for the sake of testing. It is only changed by some JUnit tests to remove the need of setting up the whole table framework. This PR shifts this flag from those two classes to the shim classes, which are not inside the final JavaFX product, only used for testing. ------------- Commit messages: - JDK-8313799: Remove lockItemOnEdit flag from (Tree)TableCell Changes: https://git.openjdk.org/jfx/pull/1198/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313799 Stats: 90 lines in 8 files changed: 50 ins; 21 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1198.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1198/head:pull/1198 PR: https://git.openjdk.org/jfx/pull/1198 From mhanl at openjdk.org Sat Aug 5 13:05:59 2023 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 5 Aug 2023 13:05:59 GMT Subject: RFR: JDK-8283401: ArrayIndexOutOfBoundsException when disconnecting screen(s) Message-ID: When the `D3DPipeline` is reinitialized, the adapter ordinal of all the `Screen`s are outdated. As a consequence, when a `D3DResourceFactory` is created for a `Screen` (adapter ordinal), the code may fail with an `ArrayIndexOutOfBoundsException` as the ordinal is higher than what we would expect it to be. Example: We have 3 screens. Adapter ordinal 0, 1, 2. If we now disconnect 2 screens, we only have one screen left. The `D3DPipeline` is reinitialized as a [D3DERR_DEVICEREMOVED](https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3derr) is reported from Direct3d9. Now the remaining screen may have the adapter ordinal 1 (from before). But since we only have 1 screen left, it should have the adapter ordinal 0. Direct3d9 will also return 0 as adapter ordinal if you call it. And that is what we do to update the `Screen` and fix this problem. See also the ticket for information how to reproduce this problem (Windows only). ------------- Commit messages: - JDK-8283401: ArrayIndexOutOfBoundsException when disconnecting screen(s) Changes: https://git.openjdk.org/jfx/pull/1200/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1200&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8283401 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1200.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1200/head:pull/1200 PR: https://git.openjdk.org/jfx/pull/1200 From kcr at openjdk.org Sat Aug 5 13:25:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 5 Aug 2023 13:25:39 GMT Subject: RFR: JDK-8283401: ArrayIndexOutOfBoundsException when disconnecting screen(s) In-Reply-To: References: Message-ID: On Sat, 5 Aug 2023 13:00:36 GMT, Marius Hanl wrote: > When the `D3DPipeline` is reinitialized, the adapter ordinal of all the `Screen`s are outdated. > As a consequence, when a `D3DResourceFactory` is created for a `Screen` (adapter ordinal), the code may fail with an `ArrayIndexOutOfBoundsException` as the ordinal is higher than what we would expect it to be. > > Example: > We have 3 screens. Adapter ordinal 0, 1, 2. > If we now disconnect 2 screens, we only have one screen left. > The `D3DPipeline` is reinitialized as a [D3DERR_DEVICEREMOVED](https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3derr) is reported from Direct3d9. > Now the remaining screen may have the adapter ordinal 1 (from before). But since we only have 1 screen left, it should have the adapter ordinal 0. > > Direct3d9 will also return 0 as adapter ordinal if you call it. And that is what we do to update the `Screen` and fix this problem. > > See also the ticket for information how to reproduce this problem (Windows only). Thanks for tracking this down. I'll review and do some testing of this next week. Reviewers: @kevinrushforth @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1200#issuecomment-1666505287 From kcr at openjdk.org Sat Aug 5 13:42:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 5 Aug 2023 13:42:34 GMT Subject: RFR: JDK-8313799: Remove lockItemOnEdit flag from (Tree)TableCell In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 22:12:55 GMT, Marius Hanl wrote: > The `lockItemOnEdit` only exists inside `TreeTableCell` and `TableCell` for the sake of testing. > It is only changed by some JUnit tests to remove the need of setting up the whole table framework. > This PR shifts this flag from those two classes to the shim classes, which are not inside the final JavaFX product, only used for testing. Where possible, avoiding injection of test flags into production code is better, so this seems like a reasonable cleanup. @aghaisas can you review this? It probably doesn't need a second reviewer, but you can decide. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1198#issuecomment-1666509050 From kcr at openjdk.org Sat Aug 5 13:46:34 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 5 Aug 2023 13:46:34 GMT Subject: RFR: JDK-8187314: All Cells: must show backing data always In-Reply-To: References: Message-ID: <6XwepnN3ZnhUe6xzETnLyuVC1GD9sr7PH5-K5G9KYtI=.a4e37b19-68b2-40f2-a894-48a83557b2d0@github.com> On Fri, 4 Aug 2023 18:13:34 GMT, Marius Hanl wrote: > Before, the `updateItem` method was called with the new value that was committed via `commitEdit()`. > This is problematic as developers may setup a commit handler via `setOnEditCommit`, which may reject the edit (or change the value otherwise). > We therefore do call the `updateItem(-1)` which will also call `updateItem` but with the real underlying value. > > Changed and added tests for all 4 cells. This seems reasonable. @aghaisas can you review it. It will need a second reviewer as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1197#issuecomment-1666510080 From jhendrikx at openjdk.org Sun Aug 6 08:29:43 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Aug 2023 08:29:43 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v9] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Fri, 4 Aug 2023 06:21:55 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Duplicate code removal Marked as reviewed by jhendrikx (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1171#pullrequestreview-1564097438 From jhendrikx at openjdk.org Sun Aug 6 09:16:32 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Aug 2023 09:16:32 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v3] In-Reply-To: References: Message-ID: <2N-ckTVlGQEFlufGrQF9u-OcETrxDy9fN4a3l12hGSE=.808d4bff-44bd-4913-97c5-42cd3c11b970@github.com> > Incorporates documentation review comments from #1069. > > This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Improve Subscription javadoc ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1177/files - new: https://git.openjdk.org/jfx/pull/1177/files/7382af03..b943340f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1177&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1177&range=01-02 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1177.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1177/head:pull/1177 PR: https://git.openjdk.org/jfx/pull/1177 From jhendrikx at openjdk.org Sun Aug 6 09:16:37 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Sun, 6 Aug 2023 09:16:37 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v2] In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 11:51:24 GMT, John Hendrikx wrote: >> Incorporates documentation review comments from #1069. >> >> This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Use @implSpec tag > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/subscriptions-doc-improvements > - Documentation improvements > I think that the documentation on `Subscription` still needs to be improved beyond a single sentence. It should include how to use the interface and give use cases. I'll need to think about a good first paragraph. For the use cases, maybe the ones you outlines in https://github.com/openjdk/jfx/pull/1069/files#r1263857263. I also think that a short review of the methods it offers is useful: > > ``` > Subscriptions can also be combined using {@link #combine} and {@link #and}, which allows for > multiple subscriptions to be unsubscribed together. This is useful when they share the same > lifecycle, for example, when performing cleanup for the same object. > ``` > > Then there is the question of what to do with regards to its use in JavaFX. The previous description I gave in [#1069 (comment)](https://github.com/openjdk/jfx/pull/1069#discussion_r1261873147) is centered around `Observable/ObservableValue`. I think that it's still better to include this description somewhere rather than repeat a part of it in every method. Maybe it fits better in `Observable/ObservableValue`. I took a stab at creating a good first paragraph, and used your suggestion as the second paragraph. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1177#issuecomment-1666785026 From jbhaskar at openjdk.org Sun Aug 6 11:51:52 2023 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 6 Aug 2023 11:51:52 GMT Subject: RFR: 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element Message-ID: Issue : Enabling modern media controls on webkit 616.1 does not load button images on HTML5 Video Element Solution: Add resources and correct MediaControl Stylesheet ------------- Commit messages: - use smart pointer to avoid memory leak - Adding simple tool based on python to generate base64 code for images - 8313181:Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element Changes: https://git.openjdk.org/jfx/pull/1201/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313181 Stats: 281 lines in 12 files changed: 275 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1201.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1201/head:pull/1201 PR: https://git.openjdk.org/jfx/pull/1201 From arapte at openjdk.org Sun Aug 6 13:37:40 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Sun, 6 Aug 2023 13:37:40 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol [v2] In-Reply-To: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> References: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> Message-ID: On Mon, 24 Jul 2023 18:34:22 GMT, Alexander Zuev wrote: >> also >> 8309629: Create implementation of NSAccessibilityRadioButton protocol >> >> Create implementation of NSAccessibilityCheckBox and NSAccessibilityRadioButton protocols >> Add workaround for the wrong focus owner announcement with radio buttons >> Add workaround for wrong magnifier text on buttons > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at the end of the header files. Providing a minor comment for a warning. Also noticed that, with this change tab are read as radio button. [ Tested with ensemble ] Screenshot 2023-08-06 at 3 23 35 PM modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 174: > 172: jobject jresult = NULL; > 173: GET_MAIN_JENV; > 174: if (env == NULL) return NULL; This generates a warning: `warning: incompatible pointer to integer conversion returning 'void *' from a function with result type 'BOOL' (aka 'signed char') [-Wint-conversion]` ------------- Changes requested by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1184#pullrequestreview-1564090685 PR Review Comment: https://git.openjdk.org/jfx/pull/1184#discussion_r1285169799 From nlisker at openjdk.org Sun Aug 6 22:41:36 2023 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 6 Aug 2023 22:41:36 GMT Subject: RFR: JDK-8312058: Documentation improvements for subscription based listeners [v3] In-Reply-To: <2N-ckTVlGQEFlufGrQF9u-OcETrxDy9fN4a3l12hGSE=.808d4bff-44bd-4913-97c5-42cd3c11b970@github.com> References: <2N-ckTVlGQEFlufGrQF9u-OcETrxDy9fN4a3l12hGSE=.808d4bff-44bd-4913-97c5-42cd3c11b970@github.com> Message-ID: On Sun, 6 Aug 2023 09:16:32 GMT, John Hendrikx wrote: >> Incorporates documentation review comments from #1069. >> >> This PR should be kept minimal so it can be backported to JFX21; it should only contain documentation changes. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Improve Subscription javadoc modules/javafx.base/src/main/java/javafx/util/Subscription.java line 33: > 31: /** > 32: * A {@code Subscription} represents the encapsulation of the result of an action > 33: * that can be cancelled. Subscriptions can be obtained, for example, as a result The first sentence is a bit cryptic to me. I'm looking at `Runnable` that is basically a less fancy version of `Subscription` (in a way, `Subscription` could extend `Runnable`). Maybe something like "Represents a cancel/cleanup operation for an action that can be cancelled/allocates resources". You can also choose either. I would also add a general example after the first paragraph, maybe like this: class Person { public Subscription subscribeToNewspaper(Newspaper paper) { register(paper); return () -> unregister(paper); } ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1177#discussion_r1285270811 From hmeda at openjdk.org Mon Aug 7 04:18:31 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 7 Aug 2023 04:18:31 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes [v2] In-Reply-To: References: Message-ID: <1JT4PBgOIhyG7UCkRsXSJZArjfWD4u_y1mXSDveV36E=.4dc36415-dae3-49e8-bb43-7dd95d028660@github.com> > Cherry-picked commits from webkitgtk-2.40.5. > Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Correct indentation ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1196/files - new: https://git.openjdk.org/jfx/pull/1196/files/f53e0dd7..036c9601 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1196&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1196&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1196.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1196/head:pull/1196 PR: https://git.openjdk.org/jfx/pull/1196 From jdv at openjdk.org Mon Aug 7 05:00:42 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 7 Aug 2023 05:00:42 GMT Subject: RFR: 8313856: Replace VLA with malloc in pango Message-ID: We should not use stack for array memory allocations in JNI. Updated pango.c to use malloc for arrays and release them at appropriate places. ------------- Commit messages: - 8313856: Replace VLA with malloc in pango Changes: https://git.openjdk.org/jfx/pull/1202/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313856 Stats: 26 lines in 1 file changed: 22 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1202.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1202/head:pull/1202 PR: https://git.openjdk.org/jfx/pull/1202 From arapte at openjdk.org Mon Aug 7 06:32:35 2023 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 7 Aug 2023 06:32:35 GMT Subject: RFR: 8313856: Replace VLA with malloc in pango In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 04:55:23 GMT, Jayathirth D V wrote: > We should not use stack for array memory allocations in JNI. > Updated pango.c to use malloc for arrays and release them at appropriate places. LGTM ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1202#pullrequestreview-1564630432 From psadhukhan at openjdk.org Mon Aug 7 06:51:43 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 7 Aug 2023 06:51:43 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: <5wt7P9euaaxQYbG5PVAued5cjpChVz4ZtnEUeS9M4gI=.9614f577-5528-4968-826d-43d5d74be10f@github.com> References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> <5wt7P9euaaxQYbG5PVAued5cjpChVz4ZtnEUeS9M4gI=.9614f577-5528-4968-826d-43d5d74be10f@github.com> Message-ID: On Fri, 4 Aug 2023 05:46:35 GMT, Prasanta Sadhukhan wrote: > both windows (using EmbeddedFrameBug class listed earlier) shows O100% for primary retina screen (should be 200%). @hjohn Seems like @andy-goryachev-oracle is telling it regressed after `updateSceneState` integration as previously he mentioned https://github.com/openjdk/jfx/pull/1171#pullrequestreview-1522452579 > getting the scales right on both monitors now (macOS) > the image is rendered with no gaps. > LGTM So, it seems scaling swing-interop fix with` stage.setRenderScaleX/Y `was solving JDK-8274932 but not JDK-8222209 whereas your fix is solving both in windows but not solving JDK-8274932 in mac.. Since this seems to be about windows-toolkit `updateSceneState` , probably it's best to take it out from this PR and let it have only swing-interop change with ` stage.setRenderScaleX/Y ` and remove JDK-8222209 from this PR.. What you both suggest? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667283749 From psadhukhan at openjdk.org Mon Aug 7 07:17:36 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 7 Aug 2023 07:17:36 GMT Subject: RFR: 8090267: JFXPanel Input Problem In-Reply-To: References: Message-ID: <1BwI-hSW0Grj8leuKEXj1DVjxBVNKAeTPUQqCgr9T84=.d5ba10b3-f8a4-404c-9a48-fa91398a156a@github.com> On Thu, 27 Jul 2023 16:59:59 GMT, Andy Goryachev wrote: > I would love to review this, but for some reason, I could not get Japanese IME to work on my windows 11... Does it work now? or Can anyone else review this please? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1169#issuecomment-1667315939 From jhendrikx at openjdk.org Mon Aug 7 07:59:44 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 7 Aug 2023 07:59:44 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v9] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Fri, 4 Aug 2023 06:21:55 GMT, Prasanta Sadhukhan wrote: >> When the JavaFX scene is set before it is really shown, then the scale factors are not properly propagated to the EmbeddedWindow, resulting in showing wrong scales. >> Fix is made to update scales to EmbeddedWindow > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Duplicate code removal > > both windows (using EmbeddedFrameBug class listed earlier) shows O100% for primary retina screen (should be 200%). > > @hjohn Seems like @andy-goryachev-oracle is telling it regressed after `updateSceneState` integration as previously he mentioned > > [#1171 (review)](https://github.com/openjdk/jfx/pull/1171#pullrequestreview-1522452579) > > > getting the scales right on both monitors now (macOS) > > the image is rendered with no gaps. > > LGTM > > So, it seems scaling swing-interop fix with`stage.setRenderScaleX/Y`was solving JDK-8274932 but not JDK-8222209 whereas your fix is solving both in windows but not solving JDK-8274932 in mac.. Since this seems to be about windows-toolkit `updateSceneState` , probably it's best to take it out from this PR and let it have only swing-interop change with `stage.setRenderScaleX/Y` and remove JDK-8222209 from this PR.. What you both suggest? IMHO, calling `setRenderScaleX/Y` should never be done by JavaFX, unless it is in response to a change in the ouput scale properties -- render scale is for the user to change the render size. Calling them from JFXPanel is fixing a symptom of the problem, not the actual problem. The ouput scales should be correct as well (in fact, in 99% of the cases they will be the same as the render scale, unless the user overrides the render scale). So, JavaFX should be ensuring that the output scale is correct (which will then be copied to the render scale). This is why I was looking further, and why I recommended calling `updateSceneState`, as in that way the output scales get changed, and, consequently, the render scales are updated. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667377118 From psadhukhan at openjdk.org Mon Aug 7 08:26:47 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 7 Aug 2023 08:26:47 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v9] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Mon, 7 Aug 2023 07:56:27 GMT, John Hendrikx wrote: > > > both windows (using EmbeddedFrameBug class listed earlier) shows O100% for primary retina screen (should be 200%). > > > > > > @hjohn Seems like @andy-goryachev-oracle is telling it regressed after `updateSceneState` integration as previously he mentioned > > [#1171 (review)](https://github.com/openjdk/jfx/pull/1171#pullrequestreview-1522452579) > > > getting the scales right on both monitors now (macOS) > > > the image is rendered with no gaps. > > > LGTM > > > > > > So, it seems scaling swing-interop fix with`stage.setRenderScaleX/Y`was solving JDK-8274932 but not JDK-8222209 whereas your fix is solving both in windows but not solving JDK-8274932 in mac.. Since this seems to be about windows-toolkit `updateSceneState` , probably it's best to take it out from this PR and let it have only swing-interop change with `stage.setRenderScaleX/Y` and remove JDK-8222209 from this PR.. What you both suggest? > > IMHO, calling `setRenderScaleX/Y` should never be done by JavaFX, unless it is in response to a change in the ouput scale properties -- render scale is for the user to change the render size. Calling them from JFXPanel is fixing a symptom of the problem, not the actual problem. The ouput scales should be correct as well (in fact, in 99% of the cases they will be the same as the render scale, unless the user overrides the render scale). > > So, JavaFX should be ensuring that the output scale is correct (which will then be copied to the render scale). > > This is why I was looking further, and why I recommended calling `updateSceneState`, as in that way the output scales get changed, and, consequently, the render scales are updated. Any idea then why it would not work in macos? Did you test it there? Probably windows-toolkit has a native component where it needs some updation? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667417424 From jhendrikx at openjdk.org Mon Aug 7 08:54:41 2023 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 7 Aug 2023 08:54:41 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v9] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Mon, 7 Aug 2023 08:23:35 GMT, Prasanta Sadhukhan wrote: > > > > both windows (using EmbeddedFrameBug class listed earlier) shows O100% for primary retina screen (should be 200%). > > > > > > > > > @hjohn Seems like @andy-goryachev-oracle is telling it regressed after `updateSceneState` integration as previously he mentioned > > > [#1171 (review)](https://github.com/openjdk/jfx/pull/1171#pullrequestreview-1522452579) > > > > getting the scales right on both monitors now (macOS) > > > > the image is rendered with no gaps. > > > > LGTM > > > > > > > > > So, it seems scaling swing-interop fix with`stage.setRenderScaleX/Y`was solving JDK-8274932 but not JDK-8222209 whereas your fix is solving both in windows but not solving JDK-8274932 in mac.. Since this seems to be about windows-toolkit `updateSceneState` , probably it's best to take it out from this PR and let it have only swing-interop change with `stage.setRenderScaleX/Y` and remove JDK-8222209 from this PR.. What you both suggest? > > > > > > IMHO, calling `setRenderScaleX/Y` should never be done by JavaFX, unless it is in response to a change in the ouput scale properties -- render scale is for the user to change the render size. Calling them from JFXPanel is fixing a symptom of the problem, not the actual problem. The ouput scales should be correct as well (in fact, in 99% of the cases they will be the same as the render scale, unless the user overrides the render scale). > > So, JavaFX should be ensuring that the output scale is correct (which will then be copied to the render scale). > > This is why I was looking further, and why I recommended calling `updateSceneState`, as in that way the output scales get changed, and, consequently, the render scales are updated. > > Any idea then why it would not work in macos? Did you test it there? Probably windows-toolkit has a native component where it needs some updation? Sorry, no, I don't have macos. I'm only pointing out that the original fix was not correct, as you are updating render scale directly but that would leave output scale wrong -- it should be updating the output scale. I've debugged this for the move window to another screen case, but didn't try debugging the initial window showing case. Are you sure it works correctly on Windows now? In other words, both output and render scale are set correctly? If that still bugs on macos, there may be a 3rd problem that is mac specific. Judging from the build failure, it does seem to work everywhere except mac, which would point to a deeper underlying problem. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667460350 From psadhukhan at openjdk.org Mon Aug 7 08:57:41 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 7 Aug 2023 08:57:41 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v9] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Mon, 7 Aug 2023 08:52:01 GMT, John Hendrikx wrote: > Are you sure it works correctly on Windows now? I have tested EmbeddedFrameBug in windows10 with primary scale 1.25 and secondary scale 1.75 and it worked for me.. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667464406 From sykora at openjdk.org Mon Aug 7 09:17:38 2023 From: sykora at openjdk.org (Joeri Sykora) Date: Mon, 7 Aug 2023 09:17:38 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes [v2] In-Reply-To: <1JT4PBgOIhyG7UCkRsXSJZArjfWD4u_y1mXSDveV36E=.4dc36415-dae3-49e8-bb43-7dd95d028660@github.com> References: <1JT4PBgOIhyG7UCkRsXSJZArjfWD4u_y1mXSDveV36E=.4dc36415-dae3-49e8-bb43-7dd95d028660@github.com> Message-ID: On Mon, 7 Aug 2023 04:18:31 GMT, Hima Bindu Meda wrote: >> Cherry-picked commits from webkitgtk-2.40.5. >> Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Correct indentation All tests ran fine here too. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1196#pullrequestreview-1564901998 From psadhukhan at openjdk.org Mon Aug 7 09:33:47 2023 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 7 Aug 2023 09:33:47 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Thu, 3 Aug 2023 18:05:52 GMT, Andy Goryachev wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Call updateSceneState with lock and in FX thread > > Screenshot 2023-08-03 at 10 56 56 > > should be 200% @andy-goryachev-oracle @kevinrushforth Since this PR solves issue 2 issues in windows and has not regressed anything in mac (behaves same before and after fix), can we commit this and raise a windows-toolkit JBS issue for mac to see why render scale is not updated for `updateSceneState` call? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667519017 From hmeda at openjdk.org Mon Aug 7 09:40:37 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 7 Aug 2023 09:40:37 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes [v2] In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 13:37:10 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/native/Source/JavaScriptCore/b3/B3DuplicateTails.cpp line 89: >> >>> 87: >>> 88: if (canCopyBlock) >>> 89: candidates.add(block); >> >> The indentation looks off here. > > I'll reapprove if you choose to fix this. Indentation corrected ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1196#discussion_r1285626830 From lkostyra at openjdk.org Mon Aug 7 10:06:38 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 7 Aug 2023 10:06:38 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 14:57:50 GMT, Guillaume T?che wrote: > `setHeight()` / `setWidth()` were ignored if called after `sizeToScene()` and before `show()`. > Now the `sizeToScene` flag is unset in these methods to ensure the right values are set when the window is shown. Don't see any issues with this one. I'll run the tests and share the final review then. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1195#issuecomment-1667568096 From jpereda at openjdk.org Mon Aug 7 10:59:45 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 7 Aug 2023 10:59:45 GMT Subject: RFR: 8313709: Wrong layout of a FlowPane in a BorderPane in a ScrollPane, if padding is too big Message-ID: So far, BorderPane does the calculation for the children min/pref width/height taken into account only the margin applied to them, if any, but not the total padding that could be applied as well to the BorderPane itself. However, this padding needs to be taken into account as well, and this PR modifies BorderPane to subtract its insets from its size while doing the children min/pref width/height calculations. A parameterized test has been included. It is a simplified version of the test case attached to https://bugs.openjdk.org/browse/JDK-8313709, but still shows how without this patch, two of the cases (padding with or without margin) fail, while pass with it. ------------- Commit messages: - modify test - Subtract borderPane insets from size for children min/pref calculations, including test Changes: https://git.openjdk.org/jfx/pull/1203/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1203&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313709 Stats: 74 lines in 2 files changed: 67 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1203.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1203/head:pull/1203 PR: https://git.openjdk.org/jfx/pull/1203 From kcr at openjdk.org Mon Aug 7 12:30:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 12:30:38 GMT Subject: RFR: 8313711: Cherry-pick WebKit 616.1 stabilization fixes [v2] In-Reply-To: <1JT4PBgOIhyG7UCkRsXSJZArjfWD4u_y1mXSDveV36E=.4dc36415-dae3-49e8-bb43-7dd95d028660@github.com> References: <1JT4PBgOIhyG7UCkRsXSJZArjfWD4u_y1mXSDveV36E=.4dc36415-dae3-49e8-bb43-7dd95d028660@github.com> Message-ID: On Mon, 7 Aug 2023 04:18:31 GMT, Hima Bindu Meda wrote: >> Cherry-picked commits from webkitgtk-2.40.5. >> Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Correct indentation Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1196#pullrequestreview-1565215770 From hmeda at openjdk.org Mon Aug 7 12:35:38 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 7 Aug 2023 12:35:38 GMT Subject: Integrated: 8313711: Cherry-pick WebKit 616.1 stabilization fixes In-Reply-To: References: Message-ID: <2LId1JGrzTYQNtOBDDYLgX3k2qm3xsSDsD57nKkEz1M=.21264313-82f4-4f31-b819-8d5452a14b91@github.com> On Thu, 3 Aug 2023 17:54:48 GMT, Hima Bindu Meda wrote: > Cherry-picked commits from webkitgtk-2.40.5. > Verified build on windows, mac and linux. Sanity testing looks fine. No issues seen This pull request has now been integrated. Changeset: af8950e7 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/af8950e7ebfa1f0705cc9ef5ab50ce25571c00d4 Stats: 637 lines in 88 files changed: 320 ins; 150 del; 167 mod 8313711: Cherry-pick WebKit 616.1 stabilization fixes Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1196 From kcr at openjdk.org Mon Aug 7 12:37:36 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 12:37:36 GMT Subject: RFR: 8313856: Replace VLA with malloc in pango In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 04:55:23 GMT, Jayathirth D V wrote: > We should not use stack for array memory allocations in JNI. > Updated pango.c to use malloc for arrays and release them at appropriate places. Looks good. One slight clarification: > We should not use stack for array memory allocations in JNI. To be more precise, we shouldn't use stack allocation for _variable length_ arrays. It's OK to use stack memory for relatively small, fixed-length arrays. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1202#pullrequestreview-1565226650 From kcr at openjdk.org Mon Aug 7 12:58:47 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 12:58:47 GMT Subject: RFR: 8274932: Render scales in EmbeddedWindow are not properly updated [v8] In-Reply-To: References: <0IyisyFVWJdKWHCIZRSG1TlvThD8ljlTQR8swkbOAXY=.f180f4f7-9158-4f79-b198-733d5e4a7e98@github.com> Message-ID: On Mon, 7 Aug 2023 09:30:47 GMT, Prasanta Sadhukhan wrote: > Since this PR solves issue 2 issues in windows and has not regressed anything in mac (behaves same before and after fix), can we commit this and raise a windows-toolkit JBS issue for mac to see why render scale is not updated for updateSceneState call? I'll take a look. HiDPI scaling for retina displays on Mac is somewhat different than on Windows, so it wouldn't surprise me if there was a Mac-specific problem in addition to the platform-independent problems solved by this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1171#issuecomment-1667808162 From kcr at openjdk.org Mon Aug 7 14:13:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 14:13:38 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol [v2] In-Reply-To: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> References: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> Message-ID: On Mon, 24 Jul 2023 18:34:22 GMT, Alexander Zuev wrote: >> also >> 8309629: Create implementation of NSAccessibilityRadioButton protocol >> >> Create implementation of NSAccessibilityCheckBox and NSAccessibilityRadioButton protocols >> Add workaround for the wrong focus owner announcement with radio buttons >> Add workaround for wrong magnifier text on buttons > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add newline at the end of the header files. > Also noticed that, with this change tab are read as radio button. [ Tested with ensemble ] That seems like a bug. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1184#pullrequestreview-1565416527 From kcr at openjdk.org Mon Aug 7 14:13:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 14:13:40 GMT Subject: RFR: 8309558: Create implementation of NSAccessibilityCheckBox protocol [v2] In-Reply-To: References: <50NfIpDHgD4IX_GIe1Wk7jt0pi-WTOc0i-Ab46kIdQs=.78abcef5-3350-4029-af53-a82905089a45@github.com> Message-ID: On Sun, 6 Aug 2023 07:45:54 GMT, Ambarish Rapte wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add newline at the end of the header files. > > modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 174: > >> 172: jobject jresult = NULL; >> 173: GET_MAIN_JENV; >> 174: if (env == NULL) return NULL; > > This generates a warning: > `warning: incompatible pointer to integer conversion returning 'void *' from a function with result type 'BOOL' (aka 'signed char') [-Wint-conversion]` Good catch. This should probably be changed to: `return NO;` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1184#discussion_r1285921001 From lkostyra at openjdk.org Mon Aug 7 14:15:38 2023 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 7 Aug 2023 14:15:38 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene In-Reply-To: References: Message-ID: On Thu, 3 Aug 2023 14:57:50 GMT, Guillaume T?che wrote: > `setHeight()` / `setWidth()` were ignored if called after `sizeToScene()` and before `show()`. > Now the `sizeToScene` flag is unset in these methods to ensure the right values are set when the window is shown. Overall LGTM, tests pass on Windows and macOS. Left out a minor comment, but it's not a deal-breaker. modules/javafx.graphics/src/test/java/test/javafx/stage/WindowTest.java line 85: > 83: } > 84: > 85: @Test Minor - I think it would be best to keep old code untouched to not mix up the file history in Git, should we ever need it. ------------- PR Review: https://git.openjdk.org/jfx/pull/1195#pullrequestreview-1565359901 PR Review Comment: https://git.openjdk.org/jfx/pull/1195#discussion_r1285920644 From hmeda at openjdk.org Mon Aug 7 14:33:04 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 7 Aug 2023 14:33:04 GMT Subject: [jfx21u] Integrated: 8313711: Cherry-pick WebKit 616.1 stabilization fixes Message-ID: Clean backport ------------- Commit messages: - Backport af8950e7ebfa1f0705cc9ef5ab50ce25571c00d4 Changes: https://git.openjdk.org/jfx21u/pull/6/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=6&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313711 Stats: 637 lines in 88 files changed: 320 ins; 150 del; 167 mod Patch: https://git.openjdk.org/jfx21u/pull/6.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/6/head:pull/6 PR: https://git.openjdk.org/jfx21u/pull/6 From hmeda at openjdk.org Mon Aug 7 14:33:05 2023 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 7 Aug 2023 14:33:05 GMT Subject: [jfx21u] Integrated: 8313711: Cherry-pick WebKit 616.1 stabilization fixes In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 14:23:50 GMT, Hima Bindu Meda wrote: > Clean backport This pull request has now been integrated. Changeset: bb6cbae9 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx21u/commit/bb6cbae996a529cd8d8bf30bf7b1c35fa920112e Stats: 637 lines in 88 files changed: 320 ins; 150 del; 167 mod 8313711: Cherry-pick WebKit 616.1 stabilization fixes Backport-of: af8950e7ebfa1f0705cc9ef5ab50ce25571c00d4 ------------- PR: https://git.openjdk.org/jfx21u/pull/6 From kcr at openjdk.org Mon Aug 7 15:21:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 15:21:39 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene In-Reply-To: References: Message-ID: <80JLfgO7qxOHrxlSMZdX6kKACmOPYvHn4qTk1y8NafI=.54806177-d5b5-4e90-ae5e-33bf223e776d@github.com> On Mon, 7 Aug 2023 14:09:51 GMT, Lukasz Kostyra wrote: >> `setHeight()` / `setWidth()` were ignored if called after `sizeToScene()` and before `show()`. >> Now the `sizeToScene` flag is unset in these methods to ensure the right values are set when the window is shown. > > modules/javafx.graphics/src/test/java/test/javafx/stage/WindowTest.java line 85: > >> 83: } >> 84: >> 85: @Test > > Minor - I think it would be best to keep old code untouched to not mix up the file history in Git, should we ever need it. Good suggestion. The following sentence from the [code style section of the CONTRIBUTING guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#coding-style-and-testing-guidelines) provides this advice: * Avoid making changes that are unrelated to the bug you are fixing. This includes fixing minor errors such as warnings, spacing / indentation, spelling errors, etc, in code that you aren't otherwise modifying as part of your fix. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1195#discussion_r1286031638 From kcr at openjdk.org Mon Aug 7 23:13:41 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 7 Aug 2023 23:13:41 GMT Subject: RFR: 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element In-Reply-To: References: Message-ID: On Sun, 6 Aug 2023 11:46:32 GMT, Jay Bhaskar wrote: > Issue : Enabling modern media controls on webkit 616.1 does not load button images on HTML5 Video Element > Solution: Add resources and correct MediaControl Stylesheet Reviewers: @kevinrushforth @HimaBinduMeda ------------- PR Comment: https://git.openjdk.org/jfx/pull/1201#issuecomment-1668688049 From almatvee at openjdk.org Mon Aug 7 23:39:44 2023 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 7 Aug 2023 23:39:44 GMT Subject: RFR: 8313900: Possible NULL pointer access in NativeAudioSpectrum and NativeVideoBuffer Message-ID: - Fixed by checking for `NULL` pointer after memory allocation. - In `NativeVideoBuffer` `std::nothrow` was added when allocating `jint` array, so `new` will return `NULL` instead of throwing exception. This done for consistency and also it is not clear how well JNI handles C++ exceptions in this case and what value will Java code get if exception is thrown. ------------- Commit messages: - 8313900: Possible NULL pointer access in NativeAudioSpectrum and NativeVideoBuffer Changes: https://git.openjdk.org/jfx/pull/1204/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313900 Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1204.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1204/head:pull/1204 PR: https://git.openjdk.org/jfx/pull/1204 From duke at openjdk.org Tue Aug 8 04:05:44 2023 From: duke at openjdk.org (duke) Date: Tue, 8 Aug 2023 04:05:44 GMT Subject: Withdrawn: 8278924: [Linux] Robot key test can fail if multiple keyboard layouts are installed In-Reply-To: <5SPjvG13-ikrrvdyb0M7KJNSmvRIM-bWEXTxLNka8Jg=.49267d9e-a893-4251-88ce-667da5567405@github.com> References: <5SPjvG13-ikrrvdyb0M7KJNSmvRIM-bWEXTxLNka8Jg=.49267d9e-a893-4251-88ce-667da5567405@github.com> Message-ID: On Mon, 17 Jan 2022 20:25:08 GMT, Martin Fox wrote: > The Robot implementation on Linux did not consult the current layout when mapping from a KeyCode to a hardware code. Internally it retrieved results for all the layouts but just picked the first one it saw leading to random effects. Though not part of the original bug report, the code also ignored the shift level when choosing which result to pick. On a French layout the dollar sign is on two keys (AltGr 4 is the second one) and the code could choose either one. Same is true for pound. > > This PR consults the current layout and only on shift level 0 which is the same level used in get_glass_key to figure out which KeyCode to assign when generating a KeyEvent. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/718 From duke at openjdk.org Tue Aug 8 09:02:07 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Tue, 8 Aug 2023 09:02:07 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene [v2] In-Reply-To: References: Message-ID: > `setHeight()` / `setWidth()` were ignored if called after `sizeToScene()` and before `show()`. > Now the `sizeToScene` flag is unset in these methods to ensure the right values are set when the window is shown. Guillaume T?che has updated the pull request incrementally with one additional commit since the last revision: 8310885: Fixes review comment ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1195/files - new: https://git.openjdk.org/jfx/pull/1195/files/b06049aa..fd3fb463 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1195&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1195&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1195.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1195/head:pull/1195 PR: https://git.openjdk.org/jfx/pull/1195 From duke at openjdk.org Tue Aug 8 09:02:07 2023 From: duke at openjdk.org (Guillaume =?UTF-8?B?VMOiY2hl?=) Date: Tue, 8 Aug 2023 09:02:07 GMT Subject: RFR: 8310885: Width/height of window is not set after calling sizeToScene [v2] In-Reply-To: <80JLfgO7qxOHrxlSMZdX6kKACmOPYvHn4qTk1y8NafI=.54806177-d5b5-4e90-ae5e-33bf223e776d@github.com> References: <80JLfgO7qxOHrxlSMZdX6kKACmOPYvHn4qTk1y8NafI=.54806177-d5b5-4e90-ae5e-33bf223e776d@github.com> Message-ID: On Mon, 7 Aug 2023 15:18:48 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/test/java/test/javafx/stage/WindowTest.java line 85: >> >>> 83: } >>> 84: >>> 85: @Test >> >> Minor - I think it would be best to keep old code untouched to not mix up the file history in Git, should we ever need it. > > Good suggestion. The following sentence from the [code style section of the CONTRIBUTING guidelines](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#coding-style-and-testing-guidelines) provides this advice: > > * Avoid making changes that are unrelated to the bug you are fixing. This includes fixing minor errors such as warnings, spacing / indentation, spelling errors, etc, in code that you aren't otherwise modifying as part of your fix. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1195#discussion_r1286821171 From kcr at openjdk.org Tue Aug 8 11:33:36 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Aug 2023 11:33:36 GMT Subject: RFR: 8313900: Possible NULL pointer access in NativeAudioSpectrum and NativeVideoBuffer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 23:33:37 GMT, Alexander Matveev wrote: > - Fixed by checking for `NULL` pointer after memory allocation. > - In `NativeVideoBuffer` `std::nothrow` was added when allocating `jint` array, so `new` will return `NULL` instead of throwing exception. This done for consistency and also it is not clear how well JNI handles C++ exceptions in this case and what value will Java code get if exception is thrown. Reviewers: @kevinrushforth @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1204#issuecomment-1669440655 From aghaisas at openjdk.org Tue Aug 8 11:36:38 2023 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Tue, 8 Aug 2023 11:36:38 GMT Subject: RFR: JDK-8313799: Remove lockItemOnEdit flag from (Tree)TableCell In-Reply-To: References: Message-ID: On Fri, 4 Aug 2023 22:12:55 GMT, Marius Hanl wrote: > The `lockItemOnEdit` only exists inside `TreeTableCell` and `TableCell` for the sake of testing. > It is only changed by some JUnit tests to remove the need of setting up the whole table framework. > This PR shifts this flag from those two classes to the shim classes, which are not inside the final JavaFX product, only used for testing. Thanks for fixing it. This is a good cleanup! ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1198#pullrequestreview-1567094257 From kcr at openjdk.org Tue Aug 8 11:36:39 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Aug 2023 11:36:39 GMT Subject: RFR: 8313900: Possible NULL pointer access in NativeAudioSpectrum and NativeVideoBuffer In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 23:33:37 GMT, Alexander Matveev wrote: > - Fixed by checking for `NULL` pointer after memory allocation. > - In `NativeVideoBuffer` `std::nothrow` was added when allocating `jint` array, so `new` will return `NULL` instead of throwing exception. This done for consistency and also it is not clear how well JNI handles C++ exceptions in this case and what value will Java code get if exception is thrown. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1204#pullrequestreview-1567094779 From jdv at openjdk.org Tue Aug 8 12:16:45 2023 From: jdv at openjdk.org (Jayathirth D V) Date: Tue, 8 Aug 2023 12:16:45 GMT Subject: Integrated: 8313856: Replace VLA with malloc in pango In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 04:55:23 GMT, Jayathirth D V wrote: > We should not use stack for array memory allocations in JNI. > Updated pango.c to use malloc for arrays and release them at appropriate places. This pull request has now been integrated. Changeset: 1752b623 Author: Jayathirth D V Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1752b62320f9e42f6d0d2c1f8278cf2ab205a8f4 Stats: 26 lines in 1 file changed: 22 ins; 0 del; 4 mod 8313856: Replace VLA with malloc in pango Reviewed-by: arapte, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1202 From kcr at openjdk.org Tue Aug 8 12:33:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Aug 2023 12:33:40 GMT Subject: RFR: 8313709: Wrong layout of a FlowPane in a BorderPane in a ScrollPane, if padding is too big In-Reply-To: References: Message-ID: <3gSxD51qN6wJHzQUqu5dqnMwwehf-Ovw3CBov58pUo0=.00a952af-643f-40cb-8d6d-f931dddc125d@github.com> On Mon, 7 Aug 2023 10:53:06 GMT, Jose Pereda wrote: > So far, BorderPane does the calculation for the children min/pref width/height taken into account only the margin applied to them, if any, but not the total padding that could be applied as well to the BorderPane itself. > > However, this padding needs to be taken into account as well, and this PR modifies BorderPane to subtract its insets from its size while doing the children min/pref width/height calculations. > > A parameterized test has been included. > > It is a simplified version of the test case attached to https://bugs.openjdk.org/browse/JDK-8313709, but still shows how without this patch, two of the cases (padding with or without margin) fail, while pass with it. @arapte Can you review this? I left one comment on the test about not mixing JUnit4 and JUnit5. modules/javafx.graphics/src/test/java/test/javafx/scene/layout/BorderPaneTest.java line 40: > 38: import org.junit.Test; > 39: import org.junit.jupiter.params.ParameterizedTest; > 40: import org.junit.jupiter.params.provider.CsvSource; We don't want to mix JUnit4 and JUnit5 API calls in the same test class file. ------------- PR Review: https://git.openjdk.org/jfx/pull/1203#pullrequestreview-1567178577 PR Review Comment: https://git.openjdk.org/jfx/pull/1203#discussion_r1287042901 From jpereda at openjdk.org Tue Aug 8 13:27:40 2023 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 8 Aug 2023 13:27:40 GMT Subject: RFR: 8313709: Wrong layout of a FlowPane in a BorderPane in a ScrollPane, if padding is too big In-Reply-To: References: Message-ID: On Mon, 7 Aug 2023 10:53:06 GMT, Jose Pereda wrote: > So far, BorderPane does the calculation for the children min/pref width/height taken into account only the margin applied to them, if any, but not the total padding that could be applied as well to the BorderPane itself. > > However, this padding needs to be taken into account as well, and this PR modifies BorderPane to subtract its insets from its size while doing the children min/pref width/height calculations. > > A parameterized test has been included. > > It is a simplified version of the test case attached to https://bugs.openjdk.org/browse/JDK-8313709, but still shows how without this patch, two of the cases (padding with or without margin) fail, while pass with it. Okay, makes sense. Should I port the test back to JUnit 4, then? Or convert the existing test class to JUnit 5? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1203#issuecomment-1669611738 From kpk at openjdk.org Tue Aug 8 13:57:31 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 8 Aug 2023 13:57:31 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v5] In-Reply-To: References: Message-ID: > The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. > > Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. > > Added tests to validate the changes. Karthik P K has updated the pull request incrementally with one additional commit since the last revision: Fix character index calculation issue when Text node content is wrapped ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1157/files - new: https://git.openjdk.org/jfx/pull/1157/files/1ea7365c..1a5e23fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1157&range=03-04 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1157.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1157/head:pull/1157 PR: https://git.openjdk.org/jfx/pull/1157 From kpk at openjdk.org Tue Aug 8 13:58:40 2023 From: kpk at openjdk.org (Karthik P K) Date: Tue, 8 Aug 2023 13:58:40 GMT Subject: RFR: 8306083: Text.hitTest is incorrect when Text node is present in TextFlow [v4] In-Reply-To: References: Message-ID: On Fri, 30 Jun 2023 14:40:14 GMT, Karthik P K wrote: >> The text run selected in `PrismTextLayout::getHitInfo()` method for character index calculation was not correct when Text node was embedded in TextFlow. Hence wrong character index value was calculated for the same. >> >> Since only x, y coordinates were available in the above mentioned method, sending the text as a parameter to this method is necessary so as to know if the text run selected for character index calculation is correct. Along with this change modified the `PrismTextLayout::getHitInfo()` method to calculate the correct character index. >> >> Added tests to validate the changes. > > Karthik P K has updated the pull request incrementally with one additional commit since the last revision: > > Fix character index calculation issue The x coordinate value returned from mouse event is correct and it is not a bug as the x coordinate value is relative to the Text node bounds and not relative to the start of the first character. Hence fixed the character index calculation issue as part of this PR. Made changes in text as well to wrap Text node content. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1157#issuecomment-1669671252 From kcr at openjdk.org Tue Aug 8 14:08:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 8 Aug 2023 14:08:48 GMT Subject: RFR: 8313181: Enabling modern media controls on webkit 616.1 does not load button images on HTML5 video Element In-Reply-To: References: Message-ID: On Sun, 6 Aug 2023 11:46:32 GMT, Jay Bhaskar wrote: > Issue : Enabling modern media controls on webkit 616.1 does not load button images on HTML5 Video Element > Solution: Add resources and correct MediaControl Stylesheet I tested this on Windows and confirm that the media controls are visible and active now. I left a few inline comments on the test and the utility script. modules/javafx.web/src/main/native/Source/WebCore/platform/java/ModernMediaControlResource.cpp line 26: > 24: */ > 25: > 26: Minor: extra blank line (only one is needed). modules/javafx.web/src/main/native/Source/WebCore/platform/java/generate_icon_resource.py line 1: > 1: #!/usr/bin/env python3 Do we need this tool in our repo? If so, I recommend moving it somewhere under `src/main/native/Tools` modules/javafx.web/src/main/native/Source/WebCore/platform/java/generate_icon_resource.py line 30: > 28: ''' > 29: ''' > 30: Tool to generate base64 code There is a trailing space on this line. We don't currently enforce whitespace rules for `.py` files, but might in the future. tests/manual/web/HTML5VideoControlTest.java line 39: > 37: webView.getEngine().loadContent( > 38: "