From fastegal at openjdk.java.net Mon Nov 1 12:53:43 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 1 Nov 2021 12:53:43 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v3] In-Reply-To: References: Message-ID: <0WKI-_WhGrbPik3SGTIkHUaaThXP5DmYIQ1KtxKgl1M=.1b17b93c-e1ee-47ba-bb59-914a71f8eb2b@github.com> > Cleanup of Tree-/TableRowSkin to support switching skins > > The misbehavior/s > - memory leaks due to manually registered listeners that were not removed > - side-effects due to listeners still active on old skin (like NPEs) > > Fix > - use skin api for all listener registration (for automatic removal in dispose) > - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745)) > > Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. > > Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: removed unused code, fixed doc of test methods ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/632/files - new: https://git.openjdk.java.net/jfx/pull/632/files/5402e1fb..fc71c931 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=01-02 Stats: 6 lines in 2 files changed: 1 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/632.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/632/head:pull/632 PR: https://git.openjdk.java.net/jfx/pull/632 From fastegal at openjdk.java.net Mon Nov 1 12:57:12 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 1 Nov 2021 12:57:12 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: <8ZHb9oNuP9ws90xV_5LUV3kDDjPluqZy4FFwnIZCj5U=.b55bd50b-5fdf-4097-9c68-1225263f3111@github.com> On Sun, 31 Oct 2021 18:07:27 GMT, Marius Hanl wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> re-added forgotten code comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 365: > >> 363: // Fix for RT-27782: Need to set isDirty to true, rather than the >> 364: // cheaper updateCells, as otherwise the text indentation will not >> 365: // be recalculated in TreeTableCellSkin.leftLabelPadding() > > Actually this comment is not correct anymore since my PR got merged (https://github.com/openjdk/jfx/pull/568). > Instead, it should be `TreeTableCellSkin.calculateIndentation()`. well .. that would be a merge conflict, had you updated the code comment in your PR ?? As noted in my comments to Ajit's review, the listener registration is simply moved (including the code comment .. belatedly :) Not sure how to handle it from here - following the rules, we might need a follow-up issue to the issue fixed in your PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From mhanl at openjdk.java.net Mon Nov 1 13:02:15 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 1 Nov 2021 13:02:15 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v2] In-Reply-To: <8ZHb9oNuP9ws90xV_5LUV3kDDjPluqZy4FFwnIZCj5U=.b55bd50b-5fdf-4097-9c68-1225263f3111@github.com> References: <8ZHb9oNuP9ws90xV_5LUV3kDDjPluqZy4FFwnIZCj5U=.b55bd50b-5fdf-4097-9c68-1225263f3111@github.com> Message-ID: On Mon, 1 Nov 2021 12:54:12 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 365: >> >>> 363: // Fix for RT-27782: Need to set isDirty to true, rather than the >>> 364: // cheaper updateCells, as otherwise the text indentation will not >>> 365: // be recalculated in TreeTableCellSkin.leftLabelPadding() >> >> Actually this comment is not correct anymore since my PR got merged (https://github.com/openjdk/jfx/pull/568). >> Instead, it should be `TreeTableCellSkin.calculateIndentation()`. > > well .. that would be a merge conflict, had you updated the code comment in your PR ?? As noted in my comments to Ajit's review, the listener registration is simply moved (including the code comment .. belatedly :) > > Not sure how to handle it from here - following the rules, we might need a follow-up issue to the issue fixed in your PR? My PR is already merged, so this is not a problem. :) I dont know, but since this is only fixing a (also before) wrong comment it might be okay as it is very minor? :) ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From fastegal at openjdk.java.net Mon Nov 1 13:17:12 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 1 Nov 2021 13:17:12 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v2] In-Reply-To: References: Message-ID: <3Y-twTtl8Lb0pOFeqThaV8qYtbbHSQFwRp3Ww9PJcxw=.994d4efd-4d71-4d9b-a4f3-ef9a8ff89e66@github.com> On Sun, 31 Oct 2021 17:05:52 GMT, Michael Strau? wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> re-added forgotten code comments > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 299: > >> 297: @Override protected ObjectProperty graphicProperty() { >> 298: TreeTableRow treeTableRow = getSkinnable(); >> 299: // FIXME: illegal access if skinnable is null > > What is the purpose of removing the null check, but leaving getSkinnable() in there? > Given the signature of the method, it seems that it shouldn't ever return `null` in any case. none except me having been sloppy ;) - removed both the access and the left-over code comment from my dev version). And yeah, true: guarding against null skinnable is always an indication of something being wrong (skinnable can be null only after dispose - after that, its methods must not be used) For fun, here's the evolution of `graphicProperty()` (which was `getGraphic()` early on): Initially the treeItem is accessed directly from the skinnable: the null guard already is wrong (and might hide problems elsewhere), but doesn't look so @Override protected Node getGraphic() { TreeTableRow treeTableRow = getSkinnable(); if (treeTableRow == null) return null; TreeItem treeItem = treeTableRow.getTreeItem(); if (treeItem == null) return null; return treeItem.getGraphic(); } At some time ([JDK-8124119](https://bugs.openjdk.java.net/browse/JDK-8124119) was RT-28098) the direct access was replaced by keeping an alias to the treeItem. Now the skinnable is not needed, and the null guard still is wrong :) @Override protected Node getGraphic() { TreeTableRow treeTableRow = getSkinnable(); if (treeTableRow == null) return null; if (treeItem == null) return null; return treeItem.getGraphic(); } ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From tsayao at openjdk.java.net Mon Nov 1 13:25:12 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 1 Nov 2021 13:25:12 GMT Subject: RFR: WIP: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v5] In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 22:35:47 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Still not correct The problem occurs because `WindowStage.activeWindows` gets out of order, because of focus events. So when "Focus Disabled" happens it brings up the wrong window. Probably because "Focus Stealing" situation which is mentioned on: https://docs.gtk.org/gtk3/method.Window.present_with_time.html I'm working on the fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Mon Nov 1 16:41:43 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 1 Nov 2021 16:41:43 GMT Subject: RFR: WIP: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v6] In-Reply-To: References: Message-ID: <3S0zYtJQWFUbpmlN5c4ElDhOOGcc74YqkT5QULDuHQY=.b45a0990-d06c-4a3e-8d82-37defe4ff180@github.com> > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes de problem ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/c54a5413..d51988c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=04-05 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Mon Nov 1 16:46:34 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 1 Nov 2021 16:46:34 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7] In-Reply-To: References: Message-ID: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> > Found the problem thru this path: > > **WindowStage.java** > > final void handleFocusDisabled() { > if (activeWindows.isEmpty()) { > return; > } > WindowStage window = activeWindows.get(activeWindows.size() - 1); > window.setIconified(false); > window.requestToFront(); > window.requestFocus(); > } > > > **glass_window.cpp** > > void WindowContextBase::process_focus(GdkEventFocus* event) { > ... > > if (jwindow) { > if (!event->in || isEnabled()) { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, > event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); > CHECK_JNI_EXCEPTION(mainEnv) > } else { > mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); > CHECK_JNI_EXCEPTION(mainEnv) > } > } > } > > > So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). > > The docs states: > > /** > * Enables or disables the window. > * > * A disabled window is unfocusable by definition. > * Also, key or mouse events aren't generated for disabled windows. > * > * When a user tries to activate a disabled window, or the window gets > * accidentally brought to the top of the stacking order, the window > * generates the FOCUS_DISABLED window event. A Glass client should react > * to this event and bring the currently active modal blocker of the > * disabled window to top by calling blocker's minimize(false), toFront(), > * and requestFocus() methods. It may also 'blink' the blocker window to > * further attract user's attention. > * > ..... > > > So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. > > The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Minimize changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/598/files - new: https://git.openjdk.java.net/jfx/pull/598/files/d51988c8..196cecfe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=05-06 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/598.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598 PR: https://git.openjdk.java.net/jfx/pull/598 From tsayao at openjdk.java.net Mon Nov 1 16:53:20 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Mon, 1 Nov 2021 16:53:20 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7] In-Reply-To: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> References: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> Message-ID: <4i7fxWX3_Zv1oxGvdvEnkxXfurJ_iv6fqWCaOgSJ-6Q=.15d47497-8b9d-461e-836d-0c8656f792c5@github.com> On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Minimize changes The ideal fix would be to know the original event and save it's X11 serial event number to pass to `gtk_window_present_with_time` so "focus stealing" would not happen. But I don't think it's possible because it should save the "event serial number" on the original mouse click to open a window (for example). As you have thought, many "original event" combinations are possible. The fix just reorders the `WindowStage.activeWindows` by calling `FOCUS_GAINED`. So when `FOCUS_DISABLED` happens it focuses the correct window. Please not that with this fix there are extra calls to FOCUS events and reorder of `WindowStage.activeWindows` (although they are not expensive). ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From fkirmaier at openjdk.java.net Tue Nov 2 07:57:36 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 07:57:36 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v2] In-Reply-To: References: Message-ID: > This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. > To fix it, I've made the Value of the WeakHashMap also weak. > We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. > > > I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. > > It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. > > Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8274022 fixed some whitesapce formatting issues ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/659/files - new: https://git.openjdk.java.net/jfx/pull/659/files/324188f1..402fcd27 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/659/head:pull/659 PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Tue Nov 2 08:16:41 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 08:16:41 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: > This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. > To fix it, I've made the Value of the WeakHashMap also weak. > We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. > > > I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. > > It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. > > Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8274022 Simplified code related to WeakHashMaps ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/659/files - new: https://git.openjdk.java.net/jfx/pull/659/files/402fcd27..bbc39f24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=01-02 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/659/head:pull/659 PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Tue Nov 2 08:16:47 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 08:16:47 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: <3p_YGwquSWGyNp7W3OK-EvP704Fs7ErlRQGkBGHFfBo=.53e2bdb4-1339-442b-bbc9-86038c803dfe@github.com> On Sun, 31 Oct 2021 16:32:49 GMT, Michael Strau? wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274022 >> Simplified code related to WeakHashMaps > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 88: > >> 86: // Remove previously added listener if any >> 87: if (sceneChangeListenerMap.containsKey(anchor)) { >> 88: ChangeListener listener = sceneChangeListenerMap.get(anchor).get(); > > It seems unusual to check for the existence of a weak key (containsKey), and then just assume it still exists (get). You should probably get() the value directly without checking containsKey() first, and then check whether the returned value is null. Yes, you are right. This issue also existed in the previous version. It can't cause problems, because the key is held as a parameter in the method, and the keys equal method is implemented by comparing references. But that's an unnecessarily complicated argument. It's way easier to just make one call without any timing issue. > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 254: > >> 252: // at the time of installing the accelerators. >> 253: if (sceneChangeListenerMap.containsKey(anchor)) { >> 254: ChangeListener listener = sceneChangeListenerMap.get(anchor).get(); > > It seems unusual to check for the existence of a weak key (containsKey), and then just assume it still exists (get). You should probably get() the value directly without checking containsKey() first, and then check whether the returned value is null. The conversation is below in the other reviewed code. ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From mstrauss at openjdk.java.net Tue Nov 2 09:44:13 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 2 Nov 2021 09:44:13 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 08:16:41 GMT, Florian Kirmaier wrote: >> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. >> To fix it, I've made the Value of the WeakHashMap also weak. >> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. >> >> >> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. >> >> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. >> >> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8274022 > Simplified code related to WeakHashMaps Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Tue Nov 2 10:15:41 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 10:15:41 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v3] In-Reply-To: References: Message-ID: > After thinking about this issue for some time, I've now got a solution. > I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. > This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8269907 We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/584/files - new: https://git.openjdk.java.net/jfx/pull/584/files/c603d2b1..28b793b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=584&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/584.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/584/head:pull/584 PR: https://git.openjdk.java.net/jfx/pull/584 From fkirmaier at openjdk.java.net Tue Nov 2 10:27:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 10:27:11 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v3] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 10:15:41 GMT, Florian Kirmaier wrote: >> After thinking about this issue for some time, I've now got a solution. >> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. >> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8269907 > We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. Thank you for your feedback! To solidify my understanding - the "RenderScenegraph" is only allowed to be changed when the render lock is held. This scene graph is represented by all these NG classes, correct? I've now updated my PR. I found some code for snapshot, which solves the same problem about aquiring the render lock. I've moved it into an own method and used it for my fix. The regular sync, and the new sync shouldn't happen in the same pulse - because the regular sync checks whether the Window is closed by `if (peer != null)`. At least it shouldn't require the lock. If it would for some reason aquire the lock, then it should basically be a noop - so i don't really see why this would be an issue. Performance wise aquiring an additional lock can cause a very minor slowdown, but because it only happens once per closed window, it is realy minor. ------------- PR: https://git.openjdk.java.net/jfx/pull/584 From mstrauss at openjdk.java.net Tue Nov 2 10:55:27 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 2 Nov 2021 10:55:27 GMT Subject: RFR: 8276313: ScrollPane scroll delta incorrectly depends on content height Message-ID: <5mrsHfVHvv_niJZmPBwKg-DBt7lINRLDwykrAUGdGW8=.5ec0595a-4593-438e-9337-9b60e381b161@github.com> This PR fixes an issue where the scroll delta of ScrollPane incorrectly depends on the size of its content. This leads to extremely slow scrolling when the content is only slightly larger than the ScrollPane. ------------- Commit messages: - Fixed scrolling speed for ScrollPaneSkin - failing test Changes: https://git.openjdk.java.net/jfx/pull/660/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=660&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276313 Stats: 52 lines in 2 files changed: 49 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/660.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/660/head:pull/660 PR: https://git.openjdk.java.net/jfx/pull/660 From fkirmaier at openjdk.java.net Tue Nov 2 10:58:13 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 10:58:13 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v7] In-Reply-To: References: Message-ID: On Sat, 30 Oct 2021 13:35:39 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8273485 >> Fixing toggle fullscreen! > > modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1345: > >> 1343: if (self->nativeFullScreenModeWindow) >> 1344: { >> 1345: [[self->nsView window] toggleFullScreen:self]; > > I see you added the call to `toggleFullScreen` back in, but you now pass `self` to the method, where the previous code passed `nil`. Unless there is a compelling reason why you need to change it, I recommend to restore _exactly_ the former code, such that there are no diffs: > > > [self->nativeFullScreenModeWindow performSelector:@selector(toggleFullScreen:) withObject:nil]; With the previous version, I get a "beep" sound when closing a window. But with the changed line, it works for me and I don't get any issues. The beep sound also was the original reason, why I've removed the line. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From fkirmaier at openjdk.java.net Tue Nov 2 11:06:12 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 11:06:12 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v7] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > Fixing toggle fullscreen! I've been using macOS 11.6. It is also not so easy for me to test another version. I guess the exception can easily be "fixed" by checking whether the application is null, in the `Screen.initScreens` method. Should I change it this way? ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From fkirmaier at openjdk.java.net Tue Nov 2 12:12:09 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Tue, 2 Nov 2021 12:12:09 GMT Subject: Integrated: 8276179 PrismFontFile.isInstalledFont is dead code and should be removed In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com> References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com> Message-ID: On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier wrote: > removing dead code. > When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup. This pull request has now been integrated. Changeset: cde72c8e Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/cde72c8e2988f267230625d976fff85576858766 Stats: 34 lines in 2 files changed: 0 ins; 34 del; 0 mod 8276179: PrismFontFile.isInstalledFont is dead code and should be removed Reviewed-by: prr, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/658 From kcr at openjdk.java.net Tue Nov 2 13:56:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 2 Nov 2021 13:56:17 GMT Subject: RFR: 8274854: Mnemonics for menu containing numeric text not working [v4] In-Reply-To: References: Message-ID: On Sat, 30 Oct 2021 20:40:12 GMT, Michael Strau? wrote: >> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace. > > Michael Strau? has updated the pull request incrementally with four additional commits since the last revision: > > - revert rename > - revert rename > - test for KeyCombination > - renamed TextBinding to MnemonicParser, refactored tests The latest version looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/647 From fastegal at openjdk.java.net Tue Nov 2 14:13:15 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 2 Nov 2021 14:13:15 GMT Subject: RFR: Draft - 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v3] In-Reply-To: <0WKI-_WhGrbPik3SGTIkHUaaThXP5DmYIQ1KtxKgl1M=.1b17b93c-e1ee-47ba-bb59-914a71f8eb2b@github.com> References: <0WKI-_WhGrbPik3SGTIkHUaaThXP5DmYIQ1KtxKgl1M=.1b17b93c-e1ee-47ba-bb59-914a71f8eb2b@github.com> Message-ID: On Mon, 1 Nov 2021 12:53:43 GMT, Jeanette Winzenburg wrote: >> Cleanup of Tree-/TableRowSkin to support switching skins >> >> The misbehavior/s >> - memory leaks due to manually registered listeners that were not removed >> - side-effects due to listeners still active on old skin (like NPEs) >> >> Fix >> - use skin api for all listener registration (for automatic removal in dispose) >> - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745)) >> >> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. >> >> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > removed unused code, fixed doc of test methods Changed to draft because just noted an issue with initial horizontal scrollBar for many columns and fixedCellSize which I don't quite understand yet. ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From bae at openjdk.java.net Tue Nov 2 18:21:38 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Tue, 2 Nov 2021 18:21:38 GMT Subject: RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc Message-ID: GlassRunnable uses jni environment (jEnv) associated with the main application thread both for run() and dealloc() methods. Both these methods are supposed to be scheduled for execution on the main thread: if (jEnv != NULL) { GlassRunnable *runnable = [[GlassRunnable alloc] initWithRunnable:(*env)->NewGlobalRef(env, jRunnable)]; [runnable performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:NO]; } However, it appears that on macOS 12 only the run() method is executed the main thread, whereas the dealloc() method is executed on the InvokeLaterDispatcher thread, that leads to usage of the main thread jni env in the context of another thread. This problem is more visible on aarch64, where the thread check is triggered by the W^X machinery, but the problem is present on x64 as well. Proposed fix just encapsulates all jni-related work in the run() method, reducing risks to misuse the jni environment of the main thread. ------------- Commit messages: - 8275723: Crash on macOS 12 in GlassRunnable::dealloc Changes: https://git.openjdk.java.net/jfx/pull/661/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=661&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275723 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/661.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/661/head:pull/661 PR: https://git.openjdk.java.net/jfx/pull/661 From mstrauss at openjdk.java.net Wed Nov 3 00:38:49 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 3 Nov 2021 00:38:49 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value [v2] In-Reply-To: References: Message-ID: > The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. > > The following program shows the problem for HBox: > > Region r1 = new Region(); > Region r2 = new Region(); > Region r3 = new Region(); > Region r4 = new Region(); > Region r5 = new Region(); > Region r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); > hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox1.setPrefHeight(40); > > r1 = new Region(); > r2 = new Region(); > r3 = new Region(); > r4 = new Region(); > r5 = new Region(); > r6 = new Region(); > r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); > r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); > r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); > r1.setPrefWidth(25.3); > r2.setPrefWidth(25.3); > r3.setPrefWidth(25.4); > r4.setPrefWidth(25.3); > r5.setPrefWidth(25.3); > r6.setPrefWidth(25.4); > r1.setMaxHeight(30); > r2.setMaxHeight(30); > r3.setMaxHeight(30); > r4.setMaxHeight(30); > r5.setMaxHeight(30); > r6.setMaxHeight(30); > HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); > hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); > hbox2.setPrefHeight(40); > hbox2.setPrefWidth(152); > > VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); > root.setSpacing(20); > Scene scene = new Scene(root, 500, 250); > > primaryStage.setScene(scene); > primaryStage.show(); > > > Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. > ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) > > I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. Michael Strau? 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 four additional commits since the last revision: - added documentation, improved method names - Merge branch 'master' into fixes/box-snap-to-pixel - Fix pixel-snapping glitches in VBox/HBox - Failing test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/445/files - new: https://git.openjdk.java.net/jfx/pull/445/files/c218b809..744f19f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=445&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=445&range=00-01 Stats: 449813 lines in 8109 files changed: 251439 ins; 126257 del; 72117 mod Patch: https://git.openjdk.java.net/jfx/pull/445.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/445/head:pull/445 PR: https://git.openjdk.java.net/jfx/pull/445 From mstrauss at openjdk.java.net Wed Nov 3 01:04:09 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 3 Nov 2021 01:04:09 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 18:48:13 GMT, Marius Hanl wrote: > I had a look at the PR. But it took quite a while to fully understand the changes (also the current implementation ??). I think it make sense to improve it a bit e.g. by adding javadoc to the new methods, maybe also the existing? Other ideas are also welcome. With that said maybe more people will review it then. I will have a full look soon as well. :) I've added a bit of documentation. ------------- PR: https://git.openjdk.java.net/jfx/pull/445 From kcr at openjdk.java.net Wed Nov 3 12:16:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 12:16:10 GMT Subject: RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 18:11:38 GMT, Andrew Brygin wrote: > GlassRunnable uses jni environment (jEnv) associated with the main application thread both for run() and dealloc() methods. Both these methods are supposed to be scheduled for execution on the main thread: > > if (jEnv != NULL) > { > GlassRunnable *runnable = [[GlassRunnable alloc] initWithRunnable:(*env)->NewGlobalRef(env, jRunnable)]; > [runnable performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:NO]; > } > > > However, it appears that on macOS 12 only the run() method is executed the main thread, whereas the dealloc() method is executed on the InvokeLaterDispatcher thread, that leads to usage of the main thread jni env in the context of another thread. This problem is more visible on aarch64, where the thread check is triggered by the W^X machinery, but the problem is present on x64 as well. > > Proposed fix just encapsulates all jni-related work in the run() method, reducing risks to misuse the jni environment of the main thread. The fix looks good. All my testing so far looks good. I'll finish my testing today. ------------- PR: https://git.openjdk.java.net/jfx/pull/661 From jvos at openjdk.java.net Wed Nov 3 12:33:17 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 3 Nov 2021 12:33:17 GMT Subject: RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 12:13:35 GMT, Kevin Rushforth wrote: > The fix looks good. All my testing so far looks good. I'll finish my testing today. same here. ------------- PR: https://git.openjdk.java.net/jfx/pull/661 From erikj at openjdk.java.net Wed Nov 3 13:15:14 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 3 Nov 2021 13:15:14 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > Michael Strau? 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 two additional commits since the last revision: > > - Merge branch 'master' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows @drmarmac The issue with accepting the TOU should now have been fixed, so if you click the agree box again, your review comment should be restored. ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From duke at openjdk.java.net Wed Nov 3 13:41:23 2021 From: duke at openjdk.java.net (drmarmac) Date: Wed, 3 Nov 2021 13:41:23 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Wed, 3 Nov 2021 13:12:14 GMT, Erik Joelsson wrote: >> Michael Strau? 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 two additional commits since the last revision: >> >> - Merge branch 'master' into fixes/JDK-8267059 >> - Use cmd /s option when building on Windows > > @drmarmac The issue with accepting the TOU should now have been fixed, so if you click the agree box again, your review comment should be restored. @erikj79 thanks, doesn't seem to have worked though. ------------- PR: https://git.openjdk.java.net/jfx/pull/499 From duke at openjdk.java.net Wed Nov 3 13:54:15 2021 From: duke at openjdk.java.net (drmarmac) Date: Wed, 3 Nov 2021 13:54:15 GMT Subject: RFR: 8267059: Gradle :clean and :apps tasks fail on Windows if ANT_HOME contains spaces [v2] In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 05:04:17 GMT, Michael Strau? wrote: >> This PR fixes an issue when building OpenJFX on Windows and command-line arguments contain paths with spaces. >> >> The problem is that on Windows, `ant` is invoked via `cmd`, which leads to quotes being interpreted twice. This can be fixed with the option `cmd /s`, which prevents interpreting quotes on the rest of the command line. The result is as if the rest of the command line had been typed verbatim at the command prompt. > > Michael Strau? 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 two additional commits since the last revision: > > - Merge branch 'master' into fixes/JDK-8267059 > - Use cmd /s option when building on Windows Tested this on Windows, seems to fix the issue. ------------- Marked as reviewed by drmarmac at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jfx/pull/499 From kcr at openjdk.java.net Wed Nov 3 14:24:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 14:24:22 GMT Subject: RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 18:11:38 GMT, Andrew Brygin wrote: > GlassRunnable uses jni environment (jEnv) associated with the main application thread both for run() and dealloc() methods. Both these methods are supposed to be scheduled for execution on the main thread: > > if (jEnv != NULL) > { > GlassRunnable *runnable = [[GlassRunnable alloc] initWithRunnable:(*env)->NewGlobalRef(env, jRunnable)]; > [runnable performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:NO]; > } > > > However, it appears that on macOS 12 only the run() method is executed the main thread, whereas the dealloc() method is executed on the InvokeLaterDispatcher thread, that leads to usage of the main thread jni env in the context of another thread. This problem is more visible on aarch64, where the thread check is triggered by the W^X machinery, but the problem is present on x64 as well. > > Proposed fix just encapsulates all jni-related work in the run() method, reducing risks to misuse the jni environment of the main thread. Testing completed. I ran tests on three different macOS systems: M1 running macOS 12.0.1 beta Intel x64 system running macOS 12.0.1 beta Intel x64 system (MacBook Pro) running 10.15.7 ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/661 From jvos at openjdk.java.net Wed Nov 3 14:45:23 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 3 Nov 2021 14:45:23 GMT Subject: RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 18:11:38 GMT, Andrew Brygin wrote: > GlassRunnable uses jni environment (jEnv) associated with the main application thread both for run() and dealloc() methods. Both these methods are supposed to be scheduled for execution on the main thread: > > if (jEnv != NULL) > { > GlassRunnable *runnable = [[GlassRunnable alloc] initWithRunnable:(*env)->NewGlobalRef(env, jRunnable)]; > [runnable performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:NO]; > } > > > However, it appears that on macOS 12 only the run() method is executed the main thread, whereas the dealloc() method is executed on the InvokeLaterDispatcher thread, that leads to usage of the main thread jni env in the context of another thread. This problem is more visible on aarch64, where the thread check is triggered by the W^X machinery, but the problem is present on x64 as well. > > Proposed fix just encapsulates all jni-related work in the run() method, reducing risks to misuse the jni environment of the main thread. This indeed fixes the issue, and doesn't cause regression. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/661 From kcr at openjdk.java.net Wed Nov 3 14:55:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 14:55:13 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 07:51:20 GMT, Alexander Matveev wrote: > - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev This adds an additional supported encoding type, so we will need a CSR for this. The specification can be the changes to the docs in `javafx/scene/media/package.html` Sorry for the delay in looking at this. I get this failure on Ubuntu 20.04 Linux running the oow2010-2.mp4 sample media file: ** (java:72365): WARNING **: 07:18:02.597: Failed to load plugin '.../build/sdk/lib/libavplugin-ffmpeg-58.so': libswscale.so.5: cannot open shared object file: No such file or directory Regarding the additional runtime dependencies: > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 The added dependency on Linux on `libswscale5` is a problem, at least as implemented in the current version of the PR. It's OK to require additional dependencies at runtime in order to play H.265 media files, but we need to continue to be able to play media that doesn't use H.265 without any additional requirements. This means that the loading of `libswscale5.so` needs to be optional; we can't link with it at build time, but need to dynamically load it at runtime, and only use it, or fail if not present, when decoding media formats that require it. Similarly, it is fine to make the playing of H.265 videos dependent on macOS 10.13 High Sierra or later, but unless we bump our current minimum platform across the board, we need to be able to play videos that don't use H.265 on macOS 10.12 Sierra. The same thing applies to Windows, where we need to be able to play non-H.265 media without the HEVC Video Extensions. ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From mstrauss at openjdk.java.net Wed Nov 3 15:04:30 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 3 Nov 2021 15:04:30 GMT Subject: RFR: 8268642: Improve property system to facilitate correct usage Message-ID: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> Based on previous discussions, this PR attempts to improve the JavaFX property system by enforcing correct API usage in several cases that are outlined below. It also streamlines the API by deprecating untyped APIs in favor of typed APIs that better express intent. ### 1. Behavioral changes for regular bindings var target = new SimpleObjectProperty(bean, "target"); var source = new SimpleObjectProperty(bean, "source"); target.bind(source); target.bindBidirectional(source); _Before:_ `RuntimeException` --> "bean.target: A bound value cannot be set." _After:_ `IllegalStateException` --> "bean.target: Bidirectional binding cannot target a bound property." var target = new SimpleObjectProperty(bean, "target"); var source = new SimpleObjectProperty(bean, "source"); var other = new SimpleObjectProperty(bean, "other"); source.bind(other); target.bindBidirectional(source); _Before:_ no error _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional binding cannot target a bound property." var target = new SimpleObjectProperty(bean, "target"); var source = new SimpleObjectProperty(bean, "source"); target.bindBidirectional(source); target.bind(source); _Before:_ no error _After:_ `IllegalStateException` --> "bean.target: Cannot bind a property that is targeted by a bidirectional binding." ### 2. Behavioral changes for content bindings var target = new SimpleListProperty(bean, "target"); var source = new SimpleListProperty(bean, "source"); target.bindContent(source); target.bindContentBidirectional(source); _Before:_ no error _After:_ `IllegalStateException` --> "bean.target: Bidirectional content binding cannot target a bound collection." var target = new SimpleListProperty(bean, "target"); var source = new SimpleListProperty(bean, "source"); var other = new SimpleListProperty(); source.bindContent(other); target.bindContentBidirectional(source); _Before:_ no error _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional content binding cannot target a bound collection." var target = new SimpleListProperty(bean, "target"); var source = new SimpleListProperty(bean, "source"); target.bindContentBidirectional(source); target.bindContent(source); _Before:_ no error _After:_ `IllegalStateException` --> "bean.target: Cannot bind a collection that is targeted by a bidirectional content binding." var target = new SimpleListProperty(bean, "target"); var source = new SimpleListProperty(bean, "source"); target.bindContent(source); target.set(FXCollections.observableArrayList()); _Before:_ no error _After:_ `IllegalStateException` --> "bean.target: Cannot set the value of a content-bound property." var target = new SimpleListProperty(bean, "target"); var source = new SimpleListProperty(bean, "source"); target.bindContent(source); target.add("foo"); _Before_: no error, but binding is broken because the lists are in an inconsistent state _After:_ `RuntimeExeption` via `Thread.UncaughtExceptionHandler` --> "Illegal list modification: Content binding was removed because the lists are out-of-sync." ### 3. Align un-binding of unidirectional content bindings with regular unidirectional bindings The API of unidirectional content bindings is aligned with regular unidirectional bindings because the semantics are similar. Like `unbind()`, `unbindContent(Object)` should not need an argument because there can only be a single content binding. For this reason, `unbindContent(Object)` will be deprecated in favor of `unbindContent()`: void bindContent(ObservableList source); + void unbindContent(); + boolean isContentBound(); + @Deprecated(since = "18", forRemoval = true) void unbindContent(Object object); ### 4. Replace untyped binding APIs with typed APIs The following untyped APIs will be marked for removal in favor of typed replacements: In `javafx.beans.binding.Bindings`: @Deprecated(since = "18", forRemoval = true) void unbindBidirectional(Object property1, Object property2) @Deprecated(since = "18", forRemoval = true) void unbindContentBidirectional(Object obj1, Object obj2) @Deprecated(since = "18", forRemoval = true) void unbindContent(Object obj1, Object obj2) In `ReadOnlyListProperty`, `ReadOnlySetProperty`, `ReadOnlyMapProperty`: @Deprecated(since = "18", forRemoval = true) void unbindContentBidirectional(Object object) ~~5. Support un-binding bidirectional conversion bindings with typed API At this moment, `StringProperty` is the only property implementation that offers bidirectional conversion bindings, where the `StringProperty` is bound to a property of another type:~~ void bindBidirectional(Property other, StringConverter converter) ~~The inherited `Property.unbindBidirectional(Property)` API cannot be used to unbind a conversion binding, because it only accepts arguments of type `Property`. `StringProperty` solves this issue by adding an untyped overload: `unbindBidirectional(Object)`.~~ ~~I propose to relax the definition of `Property.unbindBidirectional`:~~ - void unbindBidirectional(Property other); + void unbindBidirectional(Property other); ~~This allows property implementations to use the same API to un-bind regular bidirectional bindings, as well as converting bidirectional bindings. The `Property` typing is retained with a minimal impact on existing code (most _usages_ of this API will continue to compile, while classes that override `unbindBidirectional` will need to be changed to match the new API).~~ ~~As a side-effect, this allows the option of easily adding conversion bindings for other property implementations as well.~~ ------------- Commit messages: - centralized Property.toString - test error message in content binding tests - fix whitespace issues - fix things that broke - Clean up content binding API - Rework exception messages - changes - Javadoc changes - replace Object with Property - fix merge - ... and 15 more: https://git.openjdk.java.net/jfx/compare/55faac49...244b76f2 Changes: https://git.openjdk.java.net/jfx/pull/590/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=590&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268642 Stats: 4696 lines in 95 files changed: 3102 ins; 822 del; 772 mod Patch: https://git.openjdk.java.net/jfx/pull/590.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/590/head:pull/590 PR: https://git.openjdk.java.net/jfx/pull/590 From kcr at openjdk.java.net Wed Nov 3 15:04:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 15:04:31 GMT Subject: RFR: 8268642: Improve property system to facilitate correct usage In-Reply-To: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> Message-ID: On Tue, 27 Jul 2021 23:15:10 GMT, Michael Strau? wrote: > Based on previous discussions, this PR attempts to improve the JavaFX property system by enforcing correct API usage in several cases that are outlined below. It also streamlines the API by deprecating untyped APIs in favor of typed APIs that better express intent. > > ### 1. Behavioral changes for regular bindings > > var target = new SimpleObjectProperty(bean, "target"); > var source = new SimpleObjectProperty(bean, "source"); > target.bind(source); > target.bindBidirectional(source); > > _Before:_ `RuntimeException` --> "bean.target: A bound value cannot be set." > _After:_ `IllegalStateException` --> "bean.target: Bidirectional binding cannot target a bound property." > > > var target = new SimpleObjectProperty(bean, "target"); > var source = new SimpleObjectProperty(bean, "source"); > var other = new SimpleObjectProperty(bean, "other"); > source.bind(other); > target.bindBidirectional(source); > > _Before:_ no error > _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional binding cannot target a bound property." > > > var target = new SimpleObjectProperty(bean, "target"); > var source = new SimpleObjectProperty(bean, "source"); > target.bindBidirectional(source); > target.bind(source); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Cannot bind a property that is targeted by a bidirectional binding." > > > ### 2. Behavioral changes for content bindings > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContent(source); > target.bindContentBidirectional(source); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Bidirectional content binding cannot target a bound collection." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > var other = new SimpleListProperty(); > source.bindContent(other); > target.bindContentBidirectional(source); > > _Before:_ no error > _After:_ `IllegalArgumentException` --> "bean.source: Bidirectional content binding cannot target a bound collection." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContentBidirectional(source); > target.bindContent(source); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Cannot bind a collection that is targeted by a bidirectional content binding." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContent(source); > target.set(FXCollections.observableArrayList()); > > _Before:_ no error > _After:_ `IllegalStateException` --> "bean.target: Cannot set the value of a content-bound property." > > > var target = new SimpleListProperty(bean, "target"); > var source = new SimpleListProperty(bean, "source"); > target.bindContent(source); > target.add("foo"); > > _Before_: no error, but binding is broken because the lists are in an inconsistent state > _After:_ `RuntimeExeption` via `Thread.UncaughtExceptionHandler` --> "Illegal list modification: Content binding was removed because the lists are out-of-sync." > > > ### 3. Align un-binding of unidirectional content bindings with regular unidirectional bindings > The API of unidirectional content bindings is aligned with regular unidirectional bindings because the semantics are similar. Like `unbind()`, `unbindContent(Object)` should not need an argument because there can only be a single content binding. For this reason, `unbindContent(Object)` will be deprecated in favor of `unbindContent()`: > > void bindContent(ObservableList source); > + void unbindContent(); > + boolean isContentBound(); > > + @Deprecated(since = "18", forRemoval = true) > void unbindContent(Object object); > > > ### 4. Replace untyped binding APIs with typed APIs > The following untyped APIs will be marked for removal in favor of typed replacements: > In `javafx.beans.binding.Bindings`: > > @Deprecated(since = "18", forRemoval = true) > void unbindBidirectional(Object property1, Object property2) > > @Deprecated(since = "18", forRemoval = true) > void unbindContentBidirectional(Object obj1, Object obj2) > > @Deprecated(since = "18", forRemoval = true) > void unbindContent(Object obj1, Object obj2) > > > In `ReadOnlyListProperty`, `ReadOnlySetProperty`, `ReadOnlyMapProperty`: > > @Deprecated(since = "18", forRemoval = true) > void unbindContentBidirectional(Object object) > > > ~~5. Support un-binding bidirectional conversion bindings with typed API > At this moment, `StringProperty` is the only property implementation that offers bidirectional conversion bindings, where the `StringProperty` is bound to a property of another type:~~ > > void bindBidirectional(Property other, StringConverter converter) > > ~~The inherited `Property.unbindBidirectional(Property)` API cannot be used to unbind a conversion binding, because it only accepts arguments of type `Property`. > `StringProperty` solves this issue by adding an untyped overload: `unbindBidirectional(Object)`.~~ > > ~~I propose to relax the definition of `Property.unbindBidirectional`:~~ > > - void unbindBidirectional(Property other); > + void unbindBidirectional(Property other); > > ~~This allows property implementations to use the same API to un-bind regular bidirectional bindings, as well as converting bidirectional bindings. The `Property` typing is retained with a minimal impact on existing code (most _usages_ of this API will continue to compile, while classes that override `unbindBidirectional` will need to be changed to match the new API).~~ > > ~~As a side-effect, this allows the option of easily adding conversion bindings for other property implementations as well.~~ Moving to Draft until the discussion surrounding the API issues is resolved. When they are, this will need a CSR and two reviewers. ------------- PR: https://git.openjdk.java.net/jfx/pull/590 From kcr at openjdk.java.net Wed Nov 3 15:11:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 15:11:21 GMT Subject: RFR: 8268642: Improve property system to facilitate correct usage In-Reply-To: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> Message-ID: On Tue, 27 Jul 2021 23:15:10 GMT, Michael Strau? wrote: > 4. Replace untyped binding APIs with typed APIs We have not yet finished the discussion on this. As currently proposed, I am not in favor of this. It will take me some time to go through it in enough detail to reply. ------------- Changes requested by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/590 From kcr at openjdk.java.net Wed Nov 3 15:17:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 15:17:16 GMT Subject: RFR: 8268642: Improve property system to facilitate correct usage In-Reply-To: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> References: <6wNqOyLEuepHxTUhZ7WNSrv37hXf_zVctzAhbZphBKA=.a1a5b5ef-9c51-464b-9621-952d316024b0@github.com> Message-ID: <0VFx47JIgBu3JLv_720nISKaD31TZNYU7l-gh292Abo=.326cc369-f9c6-4df6-8d38-f8c35c369aaf@github.com> On Tue, 27 Jul 2021 23:15:10 GMT, Michael Strau? wrote: > 3. Align un-binding of unidirectional content bindings with regular unidirectional bindings Same comment as for item 4. We need to finish the discussion of whether and how to do this. ------------- PR: https://git.openjdk.java.net/jfx/pull/590 From mstrauss at openjdk.java.net Wed Nov 3 19:20:23 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 3 Nov 2021 19:20:23 GMT Subject: RFR: 8089589: [ListView] ScrollBar content moves toward-backward during scrolling. [v4] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:45:18 GMT, Johan Vos wrote: >> This PR introduces a refactory for VirtualFlow, fixing a number of issues reported about inconsistent scrolling speed (see https://bugs.openjdk.java.net/browse/JDK-8089589) >> The problem mentioned in the JBS issue (and in related issues) is that the VirtualFlow implementation depends on cell index and cell count, instead of on pixel count. The latter is unknown when the VirtualFlow is created, and pre-calculating the size of a large set of items would be very expensive. >> Therefore, this PR uses a combination of a gradual calculation of the total size in pixels (estimatedSize) and a smoothing part that prevents the scrollback to scroll in the reverse direction as the requested change. >> This PR currently breaks a number of tests that hard-coded depend on a number of evaluations. This is inherit to the approach of this PR: if we want to estimate the total size, we need to do some additional calculations. In this PR, I try to balance between consistent behavior and performance. > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Process reviewer comments, uncomment commented test, remove stderr modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 926: > 924: // the absolute offset is changed accordingly. > 925: adjustAbsoluteOffset(); > 926: } This seems to violate the invariant `setPosition(...)` ? `positionProperty().set(...)`. Your comment indicates that this is by design, but how do you prevent people from invoking `positionProperty().set(...)` and getting a different behavior? ------------- PR: https://git.openjdk.java.net/jfx/pull/398 From kcr at openjdk.java.net Wed Nov 3 22:44:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 3 Nov 2021 22:44:13 GMT Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v3] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 10:15:41 GMT, Florian Kirmaier wrote: >> After thinking about this issue for some time, I've now got a solution. >> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. >> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8269907 > We now require the rendering lock when cleaning up dirty nodes. To do so, we moved some code required for snapshot into a reusable method. > To solidify my understanding - the "RenderScenegraph" is only allowed to be changed when the render lock is held. This scene graph is represented by all these NG classes, correct? Correct. When the renderLock is not held, the renderer thread is free to render it and can be sure it won't change. I'll take a look at the updated fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/584 From kcr at openjdk.java.net Thu Nov 4 10:59:27 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Nov 2021 10:59:27 GMT Subject: [jfx17u] RFR: 8274413: FX: Update copyright year in docs, readme files to 2022 Message-ID: <8zvjRDurtoAbvvG-NqczqYhVfkGmjFAxPql6hHlkZNQ=.4c14f7ef-1c2f-416a-b7fa-75ac2bb4b477@github.com> Clean backport to jfx17u ------------- Commit messages: - 8274413: FX: Update copyright year in docs, readme files to 2022 Changes: https://git.openjdk.java.net/jfx17u/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=16&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274413 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx17u/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/16/head:pull/16 PR: https://git.openjdk.java.net/jfx17u/pull/16 From kcr at openjdk.java.net Thu Nov 4 11:00:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Nov 2021 11:00:35 GMT Subject: [jfx17u] RFR: 8275138: WebView: UserAgent string is empty for first request Message-ID: Clean backport to jfx17u ------------- Commit messages: - 8275138: WebView: UserAgent string is empty for first request Changes: https://git.openjdk.java.net/jfx17u/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275138 Stats: 51 lines in 4 files changed: 33 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jfx17u/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/17/head:pull/17 PR: https://git.openjdk.java.net/jfx17u/pull/17 From kcr at openjdk.java.net Thu Nov 4 11:13:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Nov 2021 11:13:13 GMT Subject: [jfx17u] Integrated: 8274413: FX: Update copyright year in docs, readme files to 2022 In-Reply-To: <8zvjRDurtoAbvvG-NqczqYhVfkGmjFAxPql6hHlkZNQ=.4c14f7ef-1c2f-416a-b7fa-75ac2bb4b477@github.com> References: <8zvjRDurtoAbvvG-NqczqYhVfkGmjFAxPql6hHlkZNQ=.4c14f7ef-1c2f-416a-b7fa-75ac2bb4b477@github.com> Message-ID: On Thu, 4 Nov 2021 10:53:28 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u This pull request has now been integrated. Changeset: 7b9e7eec Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/7b9e7eecb88e33716605c481e02d769a01e6e926 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8274413: FX: Update copyright year in docs, readme files to 2022 Backport-of: 7be0abb9aa5e86e953b13d4ad1d88000e652029c ------------- PR: https://git.openjdk.java.net/jfx17u/pull/16 From kcr at openjdk.java.net Thu Nov 4 11:21:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Nov 2021 11:21:18 GMT Subject: [jfx17u] Integrated: 8275138: WebView: UserAgent string is empty for first request In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 10:54:12 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u This pull request has now been integrated. Changeset: 75a2f444 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/75a2f4443e0c6fe44c583d72bac8f1fd51c347b5 Stats: 51 lines in 4 files changed: 33 ins; 0 del; 18 mod 8275138: WebView: UserAgent string is empty for first request Backport-of: d6f78e27a698925f029126b8d62a3e88d4d6f868 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/17 From jvos at openjdk.java.net Thu Nov 4 12:54:13 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 4 Nov 2021 12:54:13 GMT Subject: RFR: 8275911: Keyboard doesn't show when tapping inside an iOS text input control In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 11:07:50 GMT, Jose Pereda wrote: > After [JDK-8245053](https://bugs.openjdk.java.net/browse/JDK-8245053) for Android, this PR applies the same approach on iOS: tapping on a text input control on iOS shows the keyboard, which hides after the control loses the focus. > > Now, both platforms have the same behaviour. > > Tested on an iOS device. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/653 From jvos at openjdk.java.net Thu Nov 4 13:04:10 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 4 Nov 2021 13:04:10 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers [v2] In-Reply-To: <29RU2DRp0ngvHRRdan_6M3HOxFpUi7XHRKbhol-uzU8=.afab9cba-a44d-4352-8209-edf3b833ea09@github.com> References: <29RU2DRp0ngvHRRdan_6M3HOxFpUi7XHRKbhol-uzU8=.afab9cba-a44d-4352-8209-edf3b833ea09@github.com> Message-ID: On Wed, 27 Oct 2021 15:52:38 GMT, Nir Lisker wrote: > @johanvos Can you comment on `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView`? That is unused and can safely be deleted. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From jvos at openjdk.java.net Thu Nov 4 13:08:13 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 4 Nov 2021 13:08:13 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers [v2] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker wrote: >> Replacements of more immutable collections. >> >> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused imports If you want to remove the idMap field in the android/.../WebView.java, that's fine. If not, that's fine too. All other changes look reasonable to me. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/627 From jpereda at openjdk.java.net Thu Nov 4 13:35:11 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 4 Nov 2021 13:35:11 GMT Subject: Integrated: 8275911: Keyboard doesn't show when tapping inside an iOS text input control In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 11:07:50 GMT, Jose Pereda wrote: > After [JDK-8245053](https://bugs.openjdk.java.net/browse/JDK-8245053) for Android, this PR applies the same approach on iOS: tapping on a text input control on iOS shows the keyboard, which hides after the control loses the focus. > > Now, both platforms have the same behaviour. > > Tested on an iOS device. This pull request has now been integrated. Changeset: 7d6493bf Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/7d6493bf8219d8f57b4da07ca2bfe2d3422dd827 Stats: 90 lines in 2 files changed: 60 ins; 2 del; 28 mod 8275911: Keyboard doesn't show when tapping inside an iOS text input control Reviewed-by: jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/653 From nlisker at openjdk.java.net Thu Nov 4 17:15:45 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 4 Nov 2021 17:15:45 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers [v3] In-Reply-To: References: Message-ID: > Replacements of more immutable collections. > > One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Removed unused field ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/627/files - new: https://git.openjdk.java.net/jfx/pull/627/files/79606579..fc72e5dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=627&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=627&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/627.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/627/head:pull/627 PR: https://git.openjdk.java.net/jfx/pull/627 From nlisker at openjdk.java.net Thu Nov 4 17:15:48 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 4 Nov 2021 17:15:48 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers [v2] In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker wrote: >> Replacements of more immutable collections. >> >> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused imports I removed the field. Needs a quick re-review. ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From kcr at openjdk.java.net Thu Nov 4 17:19:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 4 Nov 2021 17:19:17 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers [v3] In-Reply-To: References: Message-ID: <-QvlmFgu9N3sjuNPfdtwBlcmWkVvRYeYE_1r1Oc0j2c=.14c810b7-3bd0-4892-848b-770a76e77393@github.com> On Thu, 4 Nov 2021 17:15:45 GMT, Nir Lisker wrote: >> Replacements of more immutable collections. >> >> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused field Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From jvos at openjdk.java.net Thu Nov 4 18:07:15 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 4 Nov 2021 18:07:15 GMT Subject: RFR: 8272808: Update constant collections to use the new immutable collections - leftovers [v3] In-Reply-To: References: Message-ID: On Thu, 4 Nov 2021 17:15:45 GMT, Nir Lisker wrote: >> Replacements of more immutable collections. >> >> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused field Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From nlisker at openjdk.java.net Thu Nov 4 20:25:12 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 4 Nov 2021 20:25:12 GMT Subject: Integrated: 8272808: Update constant collections to use the new immutable collections - leftovers In-Reply-To: References: Message-ID: On Tue, 21 Sep 2021 11:13:06 GMT, Nir Lisker wrote: > Replacements of more immutable collections. > > One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case. This pull request has now been integrated. Changeset: 5fc047ba Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/5fc047ba2300b5a285a58cd76451e41fefe6e462 Stats: 168 lines in 8 files changed: 0 ins; 34 del; 134 mod 8272808: Update constant collections to use the new immutable collections - leftovers Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/627 From michaelstrau2 at gmail.com Fri Nov 5 02:31:23 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 5 Nov 2021 03:31:23 +0100 Subject: Circling back to a new layout algorithm Message-ID: I previously proposed a new iterative layout algorithm [1] that supports baseline alignment and introduces new APIs to give developers control over the way nodes are aligned. This is a solution to the long-standing problem that JavaFX cannot reliably lay out nodes that are aligned on their baseline [2]. The new layout algorithm might also fix some issues where the scene graph layout only settles after interacting with the controls (for example, by clicking). I've created a small application that shows the new APIs and a correctly working baseline-aligned layout [3]. In addition to that, I also built SceneBuilder with both the old and new layout system, and played around with it to find out whether there were any regressions or visual differences. So far, I haven't found any. In order to move this forward, I think it would be a good idea to test the latest version of the new layout system in more real-world JavaFX applications. Any help from JavaFX application developers is greatly appreciated. It's as easy as checking out the JavaFX sources from the PR [1], building a local SDK and linking your application with the binaries. Finally, here's a high-level overview of the new algorithm: When Parent::layout() is called on a layout root (i.e. a scene root or an unmanaged node), it will lay out its children in a loop until the scene graph under the layout root is fully laid out, which means it is clean and doesn't require further layout. The totality of layout activity for a single layout root is called "layout cycle". A layout cycle will often take a few layout passes to finish (but not more than 2 in most cases). There is no limit on how often Parent::layout() will iterate to lay out its children, so in principle, this could lead to an infinite layout loop. One source of infinite layout loops are incorrectly implemented controls: class PathologicalControl extends Region { final Text text = new Text("foo"); PathologicalControl() { getChildren().add(text); } @Override protected void layoutChildren() { text.relocate(0, text.getLayoutY() + 10); } } In this example, each call to layoutChildren() moves down the text node another 10 pixels from where it was, which causes the layout algorithm to schedule yet another layout pass. It's an infinite loop. The layout system detects this by tracking how often a node invalidates the scene graph in a single layout cycle. If a node exceeds a threshold of 100 invalidations, it will be suspended from layout and can no longer invalidate the scene graph in the current layout cycle. A warning will be logged to notify developers of that fact. [1] https://github.com/openjdk/jfx/pull/433 [2] https://bugs.openjdk.java.net/browse/JDK-8090261 [3] https://github.com/mstr2/jfx-layout-sample From bae at openjdk.java.net Fri Nov 5 08:06:11 2021 From: bae at openjdk.java.net (Andrew Brygin) Date: Fri, 5 Nov 2021 08:06:11 GMT Subject: Integrated: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 18:11:38 GMT, Andrew Brygin wrote: > GlassRunnable uses jni environment (jEnv) associated with the main application thread both for run() and dealloc() methods. Both these methods are supposed to be scheduled for execution on the main thread: > > if (jEnv != NULL) > { > GlassRunnable *runnable = [[GlassRunnable alloc] initWithRunnable:(*env)->NewGlobalRef(env, jRunnable)]; > [runnable performSelectorOnMainThread:@selector(run) withObject:nil waitUntilDone:NO]; > } > > > However, it appears that on macOS 12 only the run() method is executed the main thread, whereas the dealloc() method is executed on the InvokeLaterDispatcher thread, that leads to usage of the main thread jni env in the context of another thread. This problem is more visible on aarch64, where the thread check is triggered by the W^X machinery, but the problem is present on x64 as well. > > Proposed fix just encapsulates all jni-related work in the run() method, reducing risks to misuse the jni environment of the main thread. This pull request has now been integrated. Changeset: 4d8e12d2 Author: Andrew Brygin Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/4d8e12d231476fe72742cf10c223d8baf5028677 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod 8275723: Crash on macOS 12 in GlassRunnable::dealloc Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/661 From alessandro.parisi406 at gmail.com Fri Nov 5 11:45:34 2021 From: alessandro.parisi406 at gmail.com (Alessandro Parisi) Date: Fri, 5 Nov 2021 12:45:34 +0100 Subject: RFR: 8267606: Style classes not always working Message-ID: Hello Kevin, I recently had time to review this issue and I created a new MRE. It's a Gradle project but it has no dependencies as requested, there are just two resources a .ttf font that has some font icons and a CSS for the custom control user agent. This time nothing works except for inline style (with setStyle()), I don't know if I'm doing something wrong or it's a bug to be honest The project is here: https://drive.google.com/file/d/1oaUawMqg0QYcMmokYyocpFkBzutPNMLR/view?usp=sharing From kcr at openjdk.java.net Fri Nov 5 13:24:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 13:24:28 GMT Subject: [jfx17u] RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc Message-ID: Clean backport. Tested on macOS 10.15.7 and 12.0.1-beta. ------------- Commit messages: - 8275723: Crash on macOS 12 in GlassRunnable::dealloc Changes: https://git.openjdk.java.net/jfx17u/pull/18/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=18&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275723 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/18/head:pull/18 PR: https://git.openjdk.java.net/jfx17u/pull/18 From kcr at openjdk.java.net Fri Nov 5 13:30:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 13:30:17 GMT Subject: [jfx17u] Integrated: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: <_yQF9zRXEvngL2chD1Ph1aB8OwhXjy2f8aL4g0hi3us=.d424ed3e-d5d6-4035-a007-469f7da973bd@github.com> On Fri, 5 Nov 2021 13:17:22 GMT, Kevin Rushforth wrote: > Clean backport. Tested on macOS 10.15.7 and 12.0.1-beta. This pull request has now been integrated. Changeset: be5793ea Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/be5793ea9bf32a98981898c1b2a8bbbe2b53bc07 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod 8275723: Crash on macOS 12 in GlassRunnable::dealloc Backport-of: 4d8e12d231476fe72742cf10c223d8baf5028677 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/18 From kcr at openjdk.java.net Fri Nov 5 15:13:29 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:13:29 GMT Subject: [jfx11u] RFR: 8275138: WebView: UserAgent string is empty for first request Message-ID: Clean backport. ------------- Commit messages: - 8275138: WebView: UserAgent string is empty for first request Changes: https://git.openjdk.java.net/jfx11u/pull/57/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=57&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275138 Stats: 51 lines in 4 files changed: 33 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jfx11u/pull/57.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/57/head:pull/57 PR: https://git.openjdk.java.net/jfx11u/pull/57 From kcr at openjdk.java.net Fri Nov 5 15:14:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:14:31 GMT Subject: [jfx11u] RFR: 8275723: Crash on macOS 12 in GlassRunnable::dealloc Message-ID: Clean backport. Tested on macOS 10.15.7 and 12.0.1-beta. ------------- Commit messages: - 8275723: Crash on macOS 12 in GlassRunnable::dealloc Changes: https://git.openjdk.java.net/jfx11u/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275723 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/59/head:pull/59 PR: https://git.openjdk.java.net/jfx11u/pull/59 From kcr at openjdk.java.net Fri Nov 5 15:16:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:16:38 GMT Subject: [jfx11u] Integrated: 8274413: FX: Update copyright year in docs, readme files to 2022 Message-ID: Clean backport. ------------- Commit messages: - 8274413: FX: Update copyright year in docs, readme files to 2022 Changes: https://git.openjdk.java.net/jfx11u/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274413 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/56/head:pull/56 PR: https://git.openjdk.java.net/jfx11u/pull/56 From kcr at openjdk.java.net Fri Nov 5 15:16:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:16:39 GMT Subject: [jfx11u] Integrated: 8274413: FX: Update copyright year in docs, readme files to 2022 In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 15:06:29 GMT, Kevin Rushforth wrote: > Clean backport. This pull request has now been integrated. Changeset: 54062a24 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/54062a2462140c1bae30a490300ee68536563a7b Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8274413: FX: Update copyright year in docs, readme files to 2022 Backport-of: 7be0abb9aa5e86e953b13d4ad1d88000e652029c ------------- PR: https://git.openjdk.java.net/jfx11u/pull/56 From kcr at openjdk.java.net Fri Nov 5 15:18:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:18:13 GMT Subject: [jfx11u] Integrated: 8275138: WebView: UserAgent string is empty for first request In-Reply-To: References: Message-ID: <8mamsnll4wzNw9tU4Dq4IqcKhBZ4mI_xnTLBZ2n38zc=.769c5526-a289-4f02-b71b-5095e6659fde@github.com> On Fri, 5 Nov 2021 15:06:54 GMT, Kevin Rushforth wrote: > Clean backport. This pull request has now been integrated. Changeset: d9c0729e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/d9c0729e483421df73f4b93303dc6badcf6382bd Stats: 51 lines in 4 files changed: 33 ins; 0 del; 18 mod 8275138: WebView: UserAgent string is empty for first request Backport-of: d6f78e27a698925f029126b8d62a3e88d4d6f868 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/57 From kcr at openjdk.java.net Fri Nov 5 15:18:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:18:36 GMT Subject: [jfx11u] Integrated: 8263807: Button types of a DialogPane are set twice, returns a wrong button Message-ID: Clean backport. ------------- Commit messages: - 8263807: Button types of a DialogPane are set twice, returns a wrong button Changes: https://git.openjdk.java.net/jfx11u/pull/58/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=58&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263807 Stats: 52 lines in 2 files changed: 45 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jfx11u/pull/58.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/58/head:pull/58 PR: https://git.openjdk.java.net/jfx11u/pull/58 From kcr at openjdk.java.net Fri Nov 5 15:18:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:18:36 GMT Subject: [jfx11u] Integrated: 8263807: Button types of a DialogPane are set twice, returns a wrong button In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 15:07:17 GMT, Kevin Rushforth wrote: > Clean backport. This pull request has now been integrated. Changeset: acab9b3e Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/acab9b3e11405202e5b0437aee5027ae1933bd44 Stats: 52 lines in 2 files changed: 45 ins; 3 del; 4 mod 8263807: Button types of a DialogPane are set twice, returns a wrong button Backport-of: 28475cb287b7af0223fb60df4134530d48441f10 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/58 From kcr at openjdk.java.net Fri Nov 5 15:20:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 5 Nov 2021 15:20:17 GMT Subject: [jfx11u] Integrated: 8275723: Crash on macOS 12 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Fri, 5 Nov 2021 15:07:34 GMT, Kevin Rushforth wrote: > Clean backport. Tested on macOS 10.15.7 and 12.0.1-beta. This pull request has now been integrated. Changeset: 5f9d9730 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/5f9d9730d6e905073ba37c63b4bb82b26e6de4b5 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod 8275723: Crash on macOS 12 in GlassRunnable::dealloc Backport-of: 4d8e12d231476fe72742cf10c223d8baf5028677 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/59 From aghaisas at openjdk.java.net Mon Nov 8 14:14:47 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 8 Nov 2021 14:14:47 GMT Subject: RFR: 8274854: Mnemonics for menu containing numeric text not working [v4] In-Reply-To: References: Message-ID: On Sat, 30 Oct 2021 20:40:12 GMT, Michael Strau? wrote: >> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace. > > Michael Strau? has updated the pull request incrementally with four additional commits since the last revision: > > - revert rename > - revert rename > - test for KeyCombination > - renamed TextBinding to MnemonicParser, refactored tests Marked as reviewed by aghaisas (Reviewer). The fix and test is fine. ------------- PR: https://git.openjdk.java.net/jfx/pull/647 From mstrauss at openjdk.java.net Mon Nov 8 20:06:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 8 Nov 2021 20:06:43 GMT Subject: Integrated: 8274854: Mnemonics for menu containing numeric text not working In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 16:54:35 GMT, Michael Strau? wrote: > This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace. This pull request has now been integrated. Changeset: 6749ab60 Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6749ab60b7673a0838d55fbd09cabf4232d5da60 Stats: 194 lines in 3 files changed: 162 ins; 22 del; 10 mod 8274854: Mnemonics for menu containing numeric text not working Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/647 From kcr at openjdk.java.net Mon Nov 8 21:05:01 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Nov 2021 21:05:01 GMT Subject: [jfx17u] RFR: 8274854: Mnemonics for menu containing numeric text not working Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8274854: Mnemonics for menu containing numeric text not working Changes: https://git.openjdk.java.net/jfx17u/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=19&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274854 Stats: 194 lines in 3 files changed: 162 ins; 22 del; 10 mod Patch: https://git.openjdk.java.net/jfx17u/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/19/head:pull/19 PR: https://git.openjdk.java.net/jfx17u/pull/19 From kcr at openjdk.java.net Mon Nov 8 22:26:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 8 Nov 2021 22:26:36 GMT Subject: [jfx17u] Integrated: 8274854: Mnemonics for menu containing numeric text not working In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 20:58:45 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: 3d556ec3 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/3d556ec34f715d153f2edb99a9890d0c95fb76b4 Stats: 194 lines in 3 files changed: 162 ins; 22 del; 10 mod 8274854: Mnemonics for menu containing numeric text not working Backport-of: 6749ab60b7673a0838d55fbd09cabf4232d5da60 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/19 From pbansal at openjdk.java.net Tue Nov 9 06:11:44 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 9 Nov 2021 06:11:44 GMT Subject: RFR: 8232812: [MacOS] Double click title bar does not restore window size In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:36:37 GMT, Martin Fox wrote: > The test case for JDK-8160241 creates a window in a zoomed state (as defined by macOS). When the OS later goes to unzoom the window it will try to shrink it down to 1 point wide. This was entered as JDK-8163137 but the fix for that bug inadvertently disabled unzooming altogether. This PR fixes 8163137 in a slightly different way. > > Access to the zoom/unzoom feature has changed with newer versions of macOS. To reproduce this you have to change `System Preferences > Dock & Menu Bar > Double-click a window's title bar` to `zoom`. Then use double-clicks in the title bar to test the feature. The green button in the title bar no longer has anything to do with zoom/unzoom. Looks good to me ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/639 From pbansal at openjdk.java.net Tue Nov 9 07:00:37 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 9 Nov 2021 07:00:37 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout In-Reply-To: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: On Tue, 28 Sep 2021 21:01:13 GMT, Martin Fox wrote: > There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. > > In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. > > I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . As you recommended in the description, could you please add the attached test as part of PR as manual test which fails before the fix and passes with the fix? ------------- PR: https://git.openjdk.java.net/jfx/pull/635 From pbansal at openjdk.java.net Tue Nov 9 09:27:40 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Tue, 9 Nov 2021 09:27:40 GMT Subject: RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox wrote: > During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing. > > This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been. > > For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms. > > As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation. There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level. Looks good to me. I tested the testcase attached in JBS on macOS BigSur and I can see the move operation is selected if cmd key is pressed after the fix. ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/651 From kcr at openjdk.java.net Tue Nov 9 17:03:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 9 Nov 2021 17:03:46 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content Message-ID: This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. ------------- Commit messages: - 8274929: Crash while reading specific clipboard content Changes: https://git.openjdk.java.net/jfx/pull/662/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274929 Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/662.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/662/head:pull/662 PR: https://git.openjdk.java.net/jfx/pull/662 From mstrauss at openjdk.java.net Tue Nov 9 23:49:34 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 9 Nov 2021 23:49:34 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 16:57:58 GMT, Kevin Rushforth wrote: > This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. > > The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 1307: > 1305: jsize bufferSize = me.size() - sizeof(UINT); > 1306: if ((pdata->cItems > 0) && > 1307: (bufferSize / pdata->cItems >= itemSize)) Instead of discarding all the data, have you considered reading `min(pdata->cItems, bufferSize / itemSize)` items? ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From kcr at openjdk.java.net Wed Nov 10 00:33:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Nov 2021 00:33:40 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 23:46:18 GMT, Michael Strau? wrote: >> This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. >> >> The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. > > modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 1307: > >> 1305: jsize bufferSize = me.size() - sizeof(UINT); >> 1306: if ((pdata->cItems > 0) && >> 1307: (bufferSize / pdata->cItems >= itemSize)) > > Instead of discarding all the data, have you considered reading `min(pdata->cItems, bufferSize / itemSize)` items? I thought about it, but since failing this test means that `cItems` is invalid, there is no reason to believe that the data that follows it is any less invalid. ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From mstrauss at openjdk.java.net Wed Nov 10 00:56:36 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 10 Nov 2021 00:56:36 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 00:31:05 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 1307: >> >>> 1305: jsize bufferSize = me.size() - sizeof(UINT); >>> 1306: if ((pdata->cItems > 0) && >>> 1307: (bufferSize / pdata->cItems >= itemSize)) >> >> Instead of discarding all the data, have you considered reading `min(pdata->cItems, bufferSize / itemSize)` items? > > I thought about it, but since failing this test means that `cItems` is invalid, there is no reason to believe that the data that follows it is any less invalid. Then shouldn't we also not trust the data if `bufferSize` is larger than it needs to be? The documentation of `FILEGROUPDESCRIPTORA/W` says that `cItems` should correspond exactly to the numer of items in the array that follows. ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From kcr at openjdk.java.net Wed Nov 10 01:09:37 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Nov 2021 01:09:37 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 00:53:24 GMT, Michael Strau? wrote: > Then shouldn't we also not trust the data if bufferSize is larger than it needs to be? Yes, that's a good point. In order to avoid integer overflow, I'll probably leave the two existing tests, and add a third (or else do the test using a `jlong`). Something like this should work: jsize bufferSize = me.size() - sizeof(UINT); if ((pdata->cItems > 0) && (bufferSize / pdata->cItems >= itemSize) && (bufferSize == pdata->cItems * itemSize)) I'll update this tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From michaelstrau2 at gmail.com Wed Nov 10 05:45:46 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 10 Nov 2021 06:45:46 +0100 Subject: Bidirectional binding enhancement Message-ID: JavaFX developers routinely use programming patterns like MVC, MVP, or MVVM to separate views from their associated business logic. Bindings can be used to connect the values of UI controls (like Label or TextField) to properties on a business logic class. A typical (simplified) scenario may look like this: var valueField = new TextField(); valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); The business logic class may perform data validation or other actions on the value that was entered in the TextField. However, in many cases, it is neither necessary nor desirable for the binding to update the business-layer property on every single change (i.e. every single character that was typed by a user). For example, if a business rule verifies that the data entered by a user is formatted in a specific way, it's usually not a great experience to yield a validation error before the user has finished typing. Instead, it's often better to wait until the user has significantly interacted with a UI control before running business logic. For this reason, I propose to add a new type of binding to the javafx.beans.binding.Bindings class: void bindBidirectional(Property target, Property source, UpdateSourceTrigger trigger) UpdateSourceTrigger is an enumeration that allows developers to specify the condition on which changes of the target property will update the source property. Its values are: DEFAULT: Updates the source property on every change (this is the default behavior of bidirectional bindings). FOCUS: Updates the source property when the UI control loses input focus. ACTION: Updates the source property when the UI control loses input focus or when it receives an ActionEvent (in the case of TextField, this corresponds to the ENTER key). Note that this setting only applies to changes of the target property. When the source property is changed instead, the target property is always immediately updated. Any feedback on this proposal is appreciated. From tom.schindl at bestsolution.at Wed Nov 10 07:51:23 2021 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 10 Nov 2021 08:51:23 +0100 Subject: Bidirectional binding enhancement In-Reply-To: References: Message-ID: <36c12f2f-1f8d-7457-e191-aa34638ffecf@bestsolution.at> Hi, We had something very similar in Eclipse-Databinding so I think something like that makes a lot of sense but I wonder how you want to implement this FOCUS, ACTION. Another thing we had was a delayed-Observable where the sync only happened if there hasn't been a change with a user specified timeout which fairly nice to implement undo/redo like stuff eg in TextAreas. As you don't have access to Node in javafx.base I'm not sure how you want to implement the trigger stuff. Just in case in Eclipse-Databinding world we had stuff like this in a module (in this case OSGi-Bundle) who has access to both the core-API and the ui-API. Tom Am 10.11.21 um 06:45 schrieb Michael Strau?: > JavaFX developers routinely use programming patterns like MVC, MVP, or > MVVM to separate views from their associated business logic. Bindings > can be used to connect the values of UI controls (like Label or > TextField) to properties on a business logic class. > > A typical (simplified) scenario may look like this: > > var valueField = new TextField(); > valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); > > The business logic class may perform data validation or other actions > on the value that was entered in the TextField. However, in many > cases, it is neither necessary nor desirable for the binding to update > the business-layer property on every single change (i.e. every single > character that was typed by a user). For example, if a business rule > verifies that the data entered by a user is formatted in a specific > way, it's usually not a great experience to yield a validation error > before the user has finished typing. Instead, it's often better to > wait until the user has significantly interacted with a UI control > before running business logic. > > For this reason, I propose to add a new type of binding to the > javafx.beans.binding.Bindings class: > > void bindBidirectional(Property target, Property source, > UpdateSourceTrigger trigger) > > UpdateSourceTrigger is an enumeration that allows developers to > specify the condition on which changes of the target property will > update the source property. Its values are: > > DEFAULT: Updates the source property on every change (this is the > default behavior of bidirectional bindings). > FOCUS: Updates the source property when the UI control loses input focus. > ACTION: Updates the source property when the UI control loses input > focus or when it receives an ActionEvent (in the case of TextField, > this corresponds to the ENTER key). > > Note that this setting only applies to changes of the target property. > When the source property is changed instead, the target property is > always immediately updated. > > Any feedback on this proposal is appreciated. > -- Tom Schindl - CTO BestSolution.at EDV Systemhaus GmbH Salurner Stra?e 15, A-6020 Innsbruck Phone: ++43 (0)512 935834 http://www.BestSolution.at - http://efxclipse.org From andrea.vacondio at gmail.com Wed Nov 10 09:37:52 2021 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Wed, 10 Nov 2021 10:37:52 +0100 Subject: Bidirectional binding enhancement In-Reply-To: <36c12f2f-1f8d-7457-e191-aa34638ffecf@bestsolution.at> References: <36c12f2f-1f8d-7457-e191-aa34638ffecf@bestsolution.at> Message-ID: In my latest project I felt the need for a built in debounce which is fairly common for search fields or similar. Andrea Il giorno mer 10 nov 2021 alle ore 08:51 Tom Schindl < tom.schindl at bestsolution.at> ha scritto: > Hi, > > We had something very similar in Eclipse-Databinding so I think > something like that makes a lot of sense but I wonder how you want to > implement this FOCUS, ACTION. > > Another thing we had was a delayed-Observable where the sync only > happened if there hasn't been a change with a user specified timeout > which fairly nice to implement undo/redo like stuff eg in TextAreas. > > As you don't have access to Node in javafx.base I'm not sure how you > want to implement the trigger stuff. Just in case in Eclipse-Databinding > world we had stuff like this in a module (in this case OSGi-Bundle) who > has access to both the core-API and the ui-API. > > Tom > > Am 10.11.21 um 06:45 schrieb Michael Strau?: > > JavaFX developers routinely use programming patterns like MVC, MVP, or > > MVVM to separate views from their associated business logic. Bindings > > can be used to connect the values of UI controls (like Label or > > TextField) to properties on a business logic class. > > > > A typical (simplified) scenario may look like this: > > > > var valueField = new TextField(); > > > valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); > > > > The business logic class may perform data validation or other actions > > on the value that was entered in the TextField. However, in many > > cases, it is neither necessary nor desirable for the binding to update > > the business-layer property on every single change (i.e. every single > > character that was typed by a user). For example, if a business rule > > verifies that the data entered by a user is formatted in a specific > > way, it's usually not a great experience to yield a validation error > > before the user has finished typing. Instead, it's often better to > > wait until the user has significantly interacted with a UI control > > before running business logic. > > > > For this reason, I propose to add a new type of binding to the > > javafx.beans.binding.Bindings class: > > > > void bindBidirectional(Property target, Property source, > > UpdateSourceTrigger trigger) > > > > UpdateSourceTrigger is an enumeration that allows developers to > > specify the condition on which changes of the target property will > > update the source property. Its values are: > > > > DEFAULT: Updates the source property on every change (this is the > > default behavior of bidirectional bindings). > > FOCUS: Updates the source property when the UI control loses input focus. > > ACTION: Updates the source property when the UI control loses input > > focus or when it receives an ActionEvent (in the case of TextField, > > this corresponds to the ENTER key). > > > > Note that this setting only applies to changes of the target property. > > When the source property is changed instead, the target property is > > always immediately updated. > > > > Any feedback on this proposal is appreciated. > > > > -- > Tom Schindl - CTO > BestSolution.at EDV Systemhaus GmbH > Salurner Stra?e 15, A-6020 Innsbruck > Phone: ++43 (0)512 935834 > http://www.BestSolution.at - http://efxclipse.org > From hjohn at xs4all.nl Wed Nov 10 11:10:56 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Wed, 10 Nov 2021 12:10:56 +0100 Subject: Bidirectional binding enhancement In-Reply-To: References: Message-ID: Although I think you have a valid use case, I don't think JavaFX should facilitate this exact scenario; it is a high level concern that you want to solve in a very low level mechanism. A similar scenario also applies to uni-directional bindings, so I think it would have to apply there as well. It also really depends on how you are doing the communication between view and model. Some system use models that are always valid, some systems use a view-model that contains a direct copy of what is in the UI controls. Some views allow users to type anything and do validation on submission or focus loss; some do per character validation and mark bad input; some will not even allow you to type bad input. For a scenario like you describe, which seems to be about delayed updates of bindings, I think you really want to use something like ReactFX's EventStreams. These offer far more features, including timeouts, removal of duplicates, combining of values, conditional suspending, etc. It might work like this for example: EventStream.of(textInput.textProperty()) .conditionOn(textInput.focusedProperty().not()) .feedTo(model::valueProperty); Or with Val: Val.of(textInput.textProperty()) .conditionOn(textInput.focusedProperty().not()) .subcribe(v -> updateModel(v)); (Note: conditionOn is part of the fluent bindings proposal that Nir Lisker and me have been working on). Now, this isn't bidirectional, but I don't see how that will work in any case as there are some edge cases. For example, how would you handle a model update when the view is currently being edited? Delaying updates runs into issues where both may have changed, whereas currently bindings are resolved immediately on the FX thread. --John On 10/11/2021 06:45, Michael Strau? wrote: > JavaFX developers routinely use programming patterns like MVC, MVP, or > MVVM to separate views from their associated business logic. Bindings > can be used to connect the values of UI controls (like Label or > TextField) to properties on a business logic class. > > A typical (simplified) scenario may look like this: > > var valueField = new TextField(); > valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); > > The business logic class may perform data validation or other actions > on the value that was entered in the TextField. However, in many > cases, it is neither necessary nor desirable for the binding to update > the business-layer property on every single change (i.e. every single > character that was typed by a user). For example, if a business rule > verifies that the data entered by a user is formatted in a specific > way, it's usually not a great experience to yield a validation error > before the user has finished typing. Instead, it's often better to > wait until the user has significantly interacted with a UI control > before running business logic. > > For this reason, I propose to add a new type of binding to the > javafx.beans.binding.Bindings class: > > void bindBidirectional(Property target, Property source, > UpdateSourceTrigger trigger) > > UpdateSourceTrigger is an enumeration that allows developers to > specify the condition on which changes of the target property will > update the source property. Its values are: > > DEFAULT: Updates the source property on every change (this is the > default behavior of bidirectional bindings). > FOCUS: Updates the source property when the UI control loses input focus. > ACTION: Updates the source property when the UI control loses input > focus or when it receives an ActionEvent (in the case of TextField, > this corresponds to the ENTER key). > > Note that this setting only applies to changes of the target property. > When the source property is changed instead, the target property is > always immediately updated. > > Any feedback on this proposal is appreciated. > From kcr at openjdk.java.net Wed Nov 10 12:46:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Nov 2021 12:46:08 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: > This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. > > The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Update check to test that bufferSize is exactly the right size ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/662/files - new: https://git.openjdk.java.net/jfx/pull/662/files/abcd51c4..ff5f9c1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=662&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=662&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/662.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/662/head:pull/662 PR: https://git.openjdk.java.net/jfx/pull/662 From kcr at openjdk.java.net Wed Nov 10 12:46:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Nov 2021 12:46:10 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 01:06:40 GMT, Kevin Rushforth wrote: >> Then shouldn't we also not trust the data if `bufferSize` is larger than it needs to be? The documentation of `FILEGROUPDESCRIPTORA/W` says that `cItems` should correspond exactly to the numer of items in the array that follows. > >> Then shouldn't we also not trust the data if bufferSize is larger than it needs to be? > > Yes, that's a good point. > > In order to avoid integer overflow, I'll probably leave the two existing tests, and add a third (or else do the test using a `jlong`). Something like this should work: > > > jsize bufferSize = me.size() - sizeof(UINT); > if ((pdata->cItems > 0) && > (bufferSize / pdata->cItems >= itemSize) && > (bufferSize == pdata->cItems * itemSize)) > > > I'll update this tomorrow. Fixed. I decided it was cleaner to use `jlong` and just have the equality check. ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From mstrauss at openjdk.java.net Wed Nov 10 14:53:37 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 10 Nov 2021 14:53:37 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 12:46:08 GMT, Kevin Rushforth wrote: >> This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. >> >> The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update check to test that bufferSize is exactly the right size Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From michaelstrau2 at gmail.com Wed Nov 10 15:26:27 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 10 Nov 2021 16:26:27 +0100 Subject: Bidirectional binding enhancement In-Reply-To: References: Message-ID: On Wed, Nov 10, 2021 at 12:12 PM John Hendrikx wrote: > > Although I think you have a valid use case, I don't think JavaFX should > facilitate this exact scenario; it is a high level concern that you want > to solve in a very low level mechanism. A similar scenario also applies > to uni-directional bindings, so I think it would have to apply there as > well. I don't think it would have to apply for unidirectional bindings, as it is exceedingly rare that you would want to unidirectionally bind the value of a model-layer property to a view-layer property, but not vice versa. After all, you'd probably want your input controls to reflect the initial state of the model. In any way, it sure is a kind-of high level concern, but in my experience, it's a very common problem at least for some software architectures without a great solution. > It also really depends on how you are doing the communication between > view and model. Some system use models that are always valid, some > systems use a view-model that contains a direct copy of what is in the > UI controls. Some views allow users to type anything and do validation > on submission or focus loss; some do per character validation and mark > bad input; some will not even allow you to type bad input. > > For a scenario like you describe, which seems to be about delayed > updates of bindings, I think you really want to use something like > ReactFX's EventStreams. These offer far more features, including > timeouts, removal of duplicates, combining of values, conditional > suspending, etc. It might work like this for example: > > EventStream.of(textInput.textProperty()) > .conditionOn(textInput.focusedProperty().not()) > .feedTo(model::valueProperty); > > Or with Val: > > Val.of(textInput.textProperty()) > .conditionOn(textInput.focusedProperty().not()) > .subcribe(v -> updateModel(v)); > > (Note: conditionOn is part of the fluent bindings proposal that Nir > Lisker and me have been working on). Well, that requires you to pull in another third-party dependency, and even then you would need to roll your own bidirectional binding implementation. It might work for the focus-lost behavior, but not for the ActionEvent behavior. Of course, you can do all of that, but this doesn't seem to me like a great value proposition for solving a very common problem. > Now, this isn't bidirectional, but I don't see how that will work in any > case as there are some edge cases. For example, how would you handle a > model update when the view is currently being edited? Delaying updates > runs into issues where both may have changed, whereas currently bindings > are resolved immediately on the FX thread. There are no additional edge cases compared to vanilla bidirectional bindings. Bidirectional bindings with an UpdateSourceTrigger will have exactly the same concurrency behavior as vanilla bidirectional bindings (i.e. they don't support concurrent modification at all). I'm not sure how the FX thread relates to this, as bidirectional bindings don't know about threads in any case. Note that UpdateSourceTrigger only applies to the target->source direction. The source->target direction, which is the scenario you describe when the model is updated while the view is being edited, is exactly the same as it is for vanilla bidirectional bindings. From michaelstrau2 at gmail.com Wed Nov 10 15:47:45 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Wed, 10 Nov 2021 16:47:45 +0100 Subject: Bidirectional binding enhancement In-Reply-To: <36c12f2f-1f8d-7457-e191-aa34638ffecf@bestsolution.at> References: <36c12f2f-1f8d-7457-e191-aa34638ffecf@bestsolution.at> Message-ID: If you're interested in the implementation, please have a look at the draft PR: https://github.com/openjdk/jfx/pull/663 This feature is implemented on the FX beans level in javafx.base, so there's no need to have access to javafx.graphics. On Wed, Nov 10, 2021 at 8:52 AM Tom Schindl wrote: > > Hi, > > We had something very similar in Eclipse-Databinding so I think > something like that makes a lot of sense but I wonder how you want to > implement this FOCUS, ACTION. > > Another thing we had was a delayed-Observable where the sync only > happened if there hasn't been a change with a user specified timeout > which fairly nice to implement undo/redo like stuff eg in TextAreas. > > As you don't have access to Node in javafx.base I'm not sure how you > want to implement the trigger stuff. Just in case in Eclipse-Databinding > world we had stuff like this in a module (in this case OSGi-Bundle) who > has access to both the core-API and the ui-API. > > Tom From mstrauss at openjdk.java.net Wed Nov 10 17:43:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 10 Nov 2021 17:43:43 GMT Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value In-Reply-To: References: Message-ID: On Wed, 22 Sep 2021 18:48:13 GMT, Marius Hanl wrote: >> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa. >> >> The following program shows the problem for HBox: >> >> Region r1 = new Region(); >> Region r2 = new Region(); >> Region r3 = new Region(); >> Region r4 = new Region(); >> Region r5 = new Region(); >> Region r6 = new Region(); >> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r1.setPrefWidth(25.3); >> r2.setPrefWidth(25.3); >> r3.setPrefWidth(25.4); >> r4.setPrefWidth(25.3); >> r5.setPrefWidth(25.3); >> r6.setPrefWidth(25.4); >> r1.setMaxHeight(30); >> r2.setMaxHeight(30); >> r3.setMaxHeight(30); >> r4.setMaxHeight(30); >> r5.setMaxHeight(30); >> r6.setMaxHeight(30); >> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6); >> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); >> hbox1.setPrefHeight(40); >> >> r1 = new Region(); >> r2 = new Region(); >> r3 = new Region(); >> r4 = new Region(); >> r5 = new Region(); >> r6 = new Region(); >> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null))); >> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null))); >> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null))); >> r1.setPrefWidth(25.3); >> r2.setPrefWidth(25.3); >> r3.setPrefWidth(25.4); >> r4.setPrefWidth(25.3); >> r5.setPrefWidth(25.3); >> r6.setPrefWidth(25.4); >> r1.setMaxHeight(30); >> r2.setMaxHeight(30); >> r3.setMaxHeight(30); >> r4.setMaxHeight(30); >> r5.setMaxHeight(30); >> r6.setMaxHeight(30); >> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6); >> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null))); >> hbox2.setPrefHeight(40); >> hbox2.setPrefWidth(152); >> >> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2)); >> root.setSpacing(20); >> Scene scene = new Scene(root, 500, 250); >> >> primaryStage.setScene(scene); >> primaryStage.show(); >> >> >> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example. >> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png) >> >> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted. > > I had a look at the PR. But it took quite a while to fully understand the changes (also the current implementation ??). > I think it make sense to improve it a bit e.g. by adding javadoc to the new methods, maybe also the existing? Other ideas are also welcome. > With that said maybe more people will review it then. I will have a full look soon as well. :) @Maran23 Would you be interested in reviewing the implementation and the added documentation? ------------- PR: https://git.openjdk.java.net/jfx/pull/445 From mstrauss at openjdk.java.net Wed Nov 10 17:48:35 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 10 Nov 2021 17:48:35 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: <320PNI-3MULDZOUpCr5SqY5vD4PI8oWLQgC12-tcvGs=.78d56839-9046-43ab-80b6-60dc84e23e02@github.com> Message-ID: On Thu, 9 Sep 2021 09:51:33 GMT, Jeanette Winzenburg wrote: >>> Just curious: with this in place, would it be possible to use for supporting [JDK-8087926](https://bugs.openjdk.java.net/browse/JDK-8087926) (it's a bit vague, though, at least for me)? >> >> Yes, `:focus-within` can be used to select an ancestor of the currently-focused node. > >> >> >> > Just curious: with this in place, would it be possible to use for supporting [JDK-8087926](https://bugs.openjdk.java.net/browse/JDK-8087926) (it's a bit vague, though, at least for me)? >> >> Yes, `:focus-within` can be used to select an ancestor of the currently-focused node. > > cool - thanks :) @kleopatra Can you be a reviewer on this PR? ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From jpereda at openjdk.java.net Wed Nov 10 18:24:47 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 10 Nov 2021 18:24:47 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Message-ID: This PR enables intersection observer support for WebKit, and includes a system test. ------------- Commit messages: - Include html file - Enable intersection observer support, including system test Changes: https://git.openjdk.java.net/jfx/pull/664/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=664&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276847 Stats: 183 lines in 3 files changed: 180 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/664.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/664/head:pull/664 PR: https://git.openjdk.java.net/jfx/pull/664 From kcr at openjdk.java.net Wed Nov 10 18:33:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Nov 2021 18:33:36 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. This looks like a reasonable thing to do. ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From duke at openjdk.java.net Wed Nov 10 18:37:59 2021 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 10 Nov 2021 18:37:59 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: > There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. > > In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. > > I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . Martin Fox has updated the pull request incrementally with two additional commits since the last revision: - Add manual test for KeyCharacterCombination - Handle same character appearing on multiple keys ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/635/files - new: https://git.openjdk.java.net/jfx/pull/635/files/cce46016..2e8510bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=00-01 Stats: 169 lines in 2 files changed: 167 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/635/head:pull/635 PR: https://git.openjdk.java.net/jfx/pull/635 From duke at openjdk.java.net Wed Nov 10 18:48:04 2021 From: duke at openjdk.java.net (Martin Fox) Date: Wed, 10 Nov 2021 18:48:04 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v3] In-Reply-To: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> References: <34JAQYedjNtwzb-HyVlczGg-WQp2fzL1DwzB-FHSkHw=.7850793e-4a7f-46c6-951d-bb557f52ca24@github.com> Message-ID: > There was a mismatch between the way `get_glass_key` generated the Java key code for a given key press and how `getKeyCodeForChar` determined the key code for the matching character. For example, when pressing the plus sign on a US keyboard `get_glass_key` correctly generated `KeyCode.EQUALS` but `getKeyCodeForChar("+")` generated `KeyCode.PLUS`. > > In this PR `getKeyCodeForChar` mirrors the behavior of `get_glass_key`; it determines which key the character lies on and generates a key code based on the unshifted character on the same key. > > I'm working on a more comprehensive test case that allows you to press any key on the keyboard and test whether a KeyCharacterCombination for that character will succeed or not. I've attached it to this thread. It might be worth submitting as a manual test case > [CharComboTest.txt](https://github.com/openjdk/jfx/files/7247265/CharComboTest.txt) > . Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Remove extraneous whitespace ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/635/files - new: https://git.openjdk.java.net/jfx/pull/635/files/2e8510bf..69d46c2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=635&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/635.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/635/head:pull/635 PR: https://git.openjdk.java.net/jfx/pull/635 From kcr at openjdk.java.net Wed Nov 10 23:41:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 10 Nov 2021 23:41:39 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Readd junit declaration in allprojects and set junit version to 4.13.2 All tasks needed to get third-party approval are now completed. You can move this PR back to ready and the review can proceed. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Thu Nov 11 08:47:38 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 11 Nov 2021 08:47:38 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v2] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:50:51 GMT, John Hendrikx wrote: >> gradle/verification-metadata.xml line 121: >> >>> 119: >>> 120: >>> 121: >> >> Why the dependency on junit 4.13.2? > > The vintage engine pulls this in, so I think we may be forced to upgrade from 4.8.2 JUnit 4 to 4.13.2 JUnit 4 as well, although the current setup seems to work (I remember some Rules being deprecated in later JUnit 4, specifically rules for catching exceptions which could require rewriting those tests to use `assertThrows`). Assuming this is okay now as approvals have been received. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From arapte at openjdk.java.net Thu Nov 11 08:56:34 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 11 Nov 2021 08:56:34 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: <7i_b3WRMclD0_7iFh0fwB-_WOthYS3YZ-4BllMtF-0c=.f07f9bd9-d7a4-434d-8b42-fc062463e718@github.com> On Wed, 10 Nov 2021 12:46:08 GMT, Kevin Rushforth wrote: >> This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. >> >> The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update check to test that bufferSize is exactly the right size Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From jpereda at openjdk.java.net Thu Nov 11 10:03:52 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 11 Nov 2021 10:03:52 GMT Subject: RFR: 8276915: Crash on iOS 15.1 in GlassRunnable::dealloc Message-ID: After https://bugs.openjdk.java.net/browse/JDK-8275723 and the fix applied to `GlassApplication.m` for macOS, this PR is a follow-up and applies the same fix to `GlassApplication.m` on iOS to prevent the crash. I've only tested on iOS 15.0 building from macOS 11.6, but it should fix the crash when building from macOS 12. ------------- Commit messages: - Avoid crash on iOS Changes: https://git.openjdk.java.net/jfx/pull/665/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=665&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276915 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/665.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/665/head:pull/665 PR: https://git.openjdk.java.net/jfx/pull/665 From jvos at openjdk.java.net Thu Nov 11 10:16:40 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 11 Nov 2021 10:16:40 GMT Subject: RFR: 8276915: Crash on iOS 15.1 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 09:57:21 GMT, Jose Pereda wrote: > After https://bugs.openjdk.java.net/browse/JDK-8275723 and the fix applied to `GlassApplication.m` for macOS, this PR is a follow-up and applies the same fix to `GlassApplication.m` on iOS to prevent the crash. > > I've only tested on iOS 15.0 building from macOS 11.6, but it should fix the crash when building from macOS 12. This is the same fix as is done in JDK-8275723 which is working well. Only iOS specific code is impacted, so this is a safe patch. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/665 From pbansal at openjdk.java.net Thu Nov 11 10:45:36 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 11 Nov 2021 10:45:36 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 12:46:08 GMT, Kevin Rushforth wrote: >> This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. >> >> The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update check to test that bufferSize is exactly the right size The changes look fine to me ------------- Marked as reviewed by pbansal (Committer). PR: https://git.openjdk.java.net/jfx/pull/662 From pbansal at openjdk.java.net Thu Nov 11 10:49:39 2021 From: pbansal at openjdk.java.net (Pankaj Bansal) Date: Thu, 11 Nov 2021 10:49:39 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 12:46:08 GMT, Kevin Rushforth wrote: >> This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. >> >> The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Update check to test that bufferSize is exactly the right size tests/system/src/test/java/test/javafx/scene/input/ClipboardTest.java line 47: > 45: import sun.awt.datatransfer.SunClipboard; > 46: > 47: import static org.junit.Assert.*; I am not sure about how strict we are about using wildcard imports in tests in JavaFX. You can change this or keep it as it is, depending upon the answer to the first statement. ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From duke at openjdk.java.net Thu Nov 11 10:51:53 2021 From: duke at openjdk.java.net (Andreas Heger) Date: Thu, 11 Nov 2021 10:51:53 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics Message-ID: By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? ------------- Commit messages: - Merge branch 'openjdk:master' into fix-8276174 - 8276174: Use "arm64" as clang arch parameter if target is aarch64 Changes: https://git.openjdk.java.net/jfx/pull/666/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=666&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276174 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/666.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/666/head:pull/666 PR: https://git.openjdk.java.net/jfx/pull/666 From fastegal at openjdk.java.net Thu Nov 11 11:26:36 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 11 Nov 2021 11:26:36 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: <320PNI-3MULDZOUpCr5SqY5vD4PI8oWLQgC12-tcvGs=.78d56839-9046-43ab-80b6-60dc84e23e02@github.com> Message-ID: On Wed, 10 Nov 2021 17:45:32 GMT, Michael Strau? wrote: > > > @kleopatra Can you be a reviewer on this PR? css is not my turf, sry ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From kcr at openjdk.java.net Thu Nov 11 13:31:40 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 13:31:40 GMT Subject: RFR: 8276915: Crash on iOS 15.1 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 09:57:21 GMT, Jose Pereda wrote: > After https://bugs.openjdk.java.net/browse/JDK-8275723 and the fix applied to `GlassApplication.m` for macOS, this PR is a follow-up and applies the same fix to `GlassApplication.m` on iOS to prevent the crash. > > I've only tested on iOS 15.0 building from macOS 11.6, but it should fix the crash when building from macOS 12. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/665 From kcr at openjdk.java.net Thu Nov 11 13:40:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 13:40:36 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 10:46:26 GMT, Andreas Heger wrote: > By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? Did you build WebKit and media with this fix? This might be an OK stop gap, but a more permanent solution would probably be to automatically set `TARGET_ARCH` to `arm64` when `OS_ARCH` is set to `aarch64`. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Thu Nov 11 13:43:45 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 13:43:45 GMT Subject: RFR: 8274929: Crash while reading specific clipboard content [v2] In-Reply-To: References: Message-ID: <-y3Ka2MexXjtBofJm5dIECnPcjoRa8yzzNmbGKsAc1A=.fd489541-b1a7-492c-a43b-555d7c5d751b@github.com> On Thu, 11 Nov 2021 10:46:13 GMT, Pankaj Bansal wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Update check to test that bufferSize is exactly the right size > > tests/system/src/test/java/test/javafx/scene/input/ClipboardTest.java line 47: > >> 45: import sun.awt.datatransfer.SunClipboard; >> 46: >> 47: import static org.junit.Assert.*; > > I am not sure about how strict we are about using wildcard imports in tests in JavaFX. You can change this or keep it as it is, depending upon the answer to the first statement. In general wildcard imports are discouraged; static imports (e.g., `Assert.*`) are an exception used in many of our tests. ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From kcr at openjdk.java.net Thu Nov 11 13:51:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 13:51:38 GMT Subject: Integrated: 8274929: Crash while reading specific clipboard content In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 16:57:58 GMT, Kevin Rushforth wrote: > This bug is caused by not sanity checking the data returned by a call to the Windows Clipboard `IDataObject::GetData` method. When requesting a file descriptor with a format of either `CFSTR_FILEDESCRIPTORA` or `CFSTR_FILEDESCRIPTORW`, which returns a list of file names, the first word of the returned data buffer is supposed to be the number of items that follow. Applications can put data on the clipboard in such a way that it will respond to a request to return the list of files from the clipboard with data that isn't formatted correctly, so we can't assume that the first word is a valid count. > > The fix is to check the returned buffer size against the item count. I added a regression test that fails before and passes after the fix. This pull request has now been integrated. Changeset: effcc866 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/effcc86667f0ed7cf2899384fbc5fd97b8c9f7b5 Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod 8274929: Crash while reading specific clipboard content Reviewed-by: mstrauss, arapte, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/662 From jpereda at openjdk.java.net Thu Nov 11 15:08:38 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 11 Nov 2021 15:08:38 GMT Subject: Integrated: 8276915: Crash on iOS 15.1 in GlassRunnable::dealloc In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 09:57:21 GMT, Jose Pereda wrote: > After https://bugs.openjdk.java.net/browse/JDK-8275723 and the fix applied to `GlassApplication.m` for macOS, this PR is a follow-up and applies the same fix to `GlassApplication.m` on iOS to prevent the crash. > > I've only tested on iOS 15.0 building from macOS 11.6, but it should fix the crash when building from macOS 12. This pull request has now been integrated. Changeset: d122ed00 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/d122ed00557eeeb823a42e0c5503ab55f754e921 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod 8276915: Crash on iOS 15.1 in GlassRunnable::dealloc Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/665 From kcr at openjdk.java.net Thu Nov 11 15:21:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 15:21:42 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: References: Message-ID: <6mfgYW4q_uDYhKtYuus3_zL0wUWRU80903mAnO-RJcM=.3c17f520-98f4-4f5d-a54d-bc1d6d6b0ff1@github.com> On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Readd junit declaration in allprojects and set junit version to 4.13.2 I left a few comments on the dependencies. Will review / test the PR later. One comment about adding new JUnit 5 tests and migrating existing tests. I think there could be value in organizing the tests such that all of the JUnit 5 tests are grouped, rather than mixing tests in the same directory such that some use JUnit 5 and others use JUnit 4. What do you (or others) think? We could either do this with a new JUnit 5 source set in each project, or by using a package naming convention for JUnit 5 tests like we do for robot tests. Maybe `test5.some.pkg`. This needs more thought. build.gradle line 1953: > 1951: testRuntimeOnly(group: "org.junit.vintage", name: "junit-vintage-engine", version: "5.8.1") { > 1952: exclude(group: "org.apiguardian", module: "apiguardian-api") > 1953: } As it turns out, `apiguardian` no longer needs to be blocked, so you can restore it if it is easier. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Thu Nov 11 15:21:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 15:21:42 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v2] In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 08:44:54 GMT, John Hendrikx wrote: >> The vintage engine pulls this in, so I think we may be forced to upgrade from 4.8.2 JUnit 4 to 4.13.2 JUnit 4 as well, although the current setup seems to work (I remember some Rules being deprecated in later JUnit 4, specifically rules for catching exceptions which could require rewriting those tests to use `assertThrows`). > > Assuming this is okay now as approvals have been received. Yes, this is fine. >> Will try block > > I couldn't block opentest4j. Apparently this is a project that harmonizes the exceptions thrown by various test frameworks (not just JUnit 5) and JUnit 5 depends on it for the exceptions it uses to signal test failures and other error conditions. It is a fairly small project (6 classes only) licensed under the Apache 2.0 license: https://github.com/ota4j-team/opentest4j Since we only use JUnit for build / test, and don't directly depend on `opentest4j`, this is not a problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Thu Nov 11 15:21:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 15:21:43 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 21:17:14 GMT, John Hendrikx wrote: >> I will try block this and get back to you. > > Hamcrest could be blocked, tests still run. As it turns out, `hamcrest` does not need to be blocked, so you can restore it if it is easier. I'll leave it up to you. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Thu Nov 11 15:23:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 11 Nov 2021 15:23:41 GMT Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS pseudoclasses [v7] In-Reply-To: References: Message-ID: On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strau? wrote: >> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fixed undeterministic test failures @aghaisas and I will review it. ------------- PR: https://git.openjdk.java.net/jfx/pull/475 From ebresie at gmail.com Fri Nov 12 12:49:23 2021 From: ebresie at gmail.com (Eric Bresie) Date: Fri, 12 Nov 2021 06:49:23 -0600 Subject: Bidirectional binding enhancement In-Reply-To: CAJEpuXTUZ95MG_xF_viUg=zpTa_vK=xAj4P4fBP2F4uv2b2vRQ@mail.gmail.com Message-ID: <15c55108-d5d5-4d8b-99dc-5afe8c1812b8@iPad> Regarding the enumeration? As was touched on separately, would a ?TIMER? or ?TIME? based case be worth considering? For the FOCUS/ACTION?with ACTION It does FOCUS + Event, should there be one that is just ?Event? (I.e. not accounting for loss of focus)? Would it need to account for ?multiple Enums? being applied at one time (combination of types)? Eric Bresie Ebresie at gmail.com > On November 9, 2021 at 11:45:46 PM CST, Michael Strau? wrote:. > > For this reason, I propose to add a new type of binding to the > javafx.beans.binding.Bindings class: > > void bindBidirectional(Property target, Property source, > UpdateSourceTrigger trigger) > > UpdateSourceTrigger is an enumeration that allows developers to > specify the condition on which changes of the target property will > update the source property. Its values are: > > DEFAULT: Updates the source property on every change (this is the > default behavior of bidirectional bindings). > FOCUS: Updates the source property when the UI control loses input focus. > ACTION: Updates the source property when the UI control loses input > focus or when it receives an ActionEvent (in the case of TextField, > this corresponds to the ENTER key). > > Note that this setting only applies to changes of the target property. > When the source property is changed instead, the target property is > always immediately updated. > > Any feedback on this proposal is appreciated. From duke at openjdk.java.net Fri Nov 12 13:41:56 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 12 Nov 2021 13:41:56 GMT Subject: RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Message-ID: PathElements were skipped in AreaChart if the data point were outside axis bounds and had duplicate value for either x or y. This is now fixed with this PR. ------------- Commit messages: - Remove trailing whitespace - Remove unwanted import - Update tests - 8276490: Incorrect path is drawn if visible area of the chart is smaller than actual size Changes: https://git.openjdk.java.net/jfx/pull/667/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=667&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276490 Stats: 63 lines in 2 files changed: 58 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/667.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/667/head:pull/667 PR: https://git.openjdk.java.net/jfx/pull/667 From kcr at openjdk.java.net Fri Nov 12 16:48:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Nov 2021 16:48:54 GMT Subject: [jfx17u] Integrated: 8274929: Crash while reading specific clipboard content Message-ID: Clean backport to `jfx17u`. ------------- Commit messages: - 8274929: Crash while reading specific clipboard content Changes: https://git.openjdk.java.net/jfx17u/pull/20/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=20&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274929 Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx17u/pull/20.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/20/head:pull/20 PR: https://git.openjdk.java.net/jfx17u/pull/20 From kcr at openjdk.java.net Fri Nov 12 16:48:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Nov 2021 16:48:57 GMT Subject: [jfx11u] Integrated: 8274929: Crash while reading specific clipboard content Message-ID: <24PAonCBXTfmiCt5GJLs80eiVY4NS5PO8w4TrfP-7wA=.e0a03dc9-3db1-40e8-bb17-80ff7d3cdd0d@github.com> Clean backport to `jfx11u`. ------------- Commit messages: - 8274929: Crash while reading specific clipboard content Changes: https://git.openjdk.java.net/jfx11u/pull/60/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=60&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274929 Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx11u/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/60/head:pull/60 PR: https://git.openjdk.java.net/jfx11u/pull/60 From kcr at openjdk.java.net Fri Nov 12 16:48:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Nov 2021 16:48:54 GMT Subject: [jfx17u] Integrated: 8274929: Crash while reading specific clipboard content In-Reply-To: References: Message-ID: <7wg3OiSFBpbCIDaZ24dKAOxUPeC3i3ZuC_wDya9yV74=.fa1d4d42-e63c-4c06-b3c4-fb08134bd9c9@github.com> On Fri, 12 Nov 2021 16:39:00 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: aa9772e7 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/aa9772e7d21a9e953bf8317142bf3b43d3cad085 Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod 8274929: Crash while reading specific clipboard content Backport-of: effcc86667f0ed7cf2899384fbc5fd97b8c9f7b5 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/20 From kcr at openjdk.java.net Fri Nov 12 16:48:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Nov 2021 16:48:57 GMT Subject: [jfx11u] Integrated: 8274929: Crash while reading specific clipboard content In-Reply-To: <24PAonCBXTfmiCt5GJLs80eiVY4NS5PO8w4TrfP-7wA=.e0a03dc9-3db1-40e8-bb17-80ff7d3cdd0d@github.com> References: <24PAonCBXTfmiCt5GJLs80eiVY4NS5PO8w4TrfP-7wA=.e0a03dc9-3db1-40e8-bb17-80ff7d3cdd0d@github.com> Message-ID: On Fri, 12 Nov 2021 16:39:15 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: 99d138d0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/99d138d0a78e2246e3a01bf797059c3535c261fc Stats: 115 lines in 3 files changed: 111 ins; 0 del; 4 mod 8274929: Crash while reading specific clipboard content Backport-of: effcc86667f0ed7cf2899384fbc5fd97b8c9f7b5 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/60 From kcr at openjdk.java.net Fri Nov 12 23:48:34 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 12 Nov 2021 23:48:34 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 08:16:41 GMT, Florian Kirmaier wrote: >> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. >> To fix it, I've made the Value of the WeakHashMap also weak. >> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. >> >> >> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. >> >> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. >> >> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8274022 > Simplified code related to WeakHashMaps The fix looks good, although I left one question inline (also there is an unused import). The test looks good. I verified that it fails without your fix and passes with your fix. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 31: > 29: import javafx.beans.property.ReadOnlyObjectProperty; > 30: import javafx.beans.value.ChangeListener; > 31: import javafx.beans.value.WeakChangeListener; Unused import. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 291: > 289: WeakReference> listenerW = changeListenerMap.get(menuitem); > 290: ChangeListener listener = listenerW == null ? null : listenerW.get(); > 291: if (listener != null) { This will fail to remove a weak reference to a listener that has been collected. It is a `WeakHashMap`, so the `WeakReference` to the listener will be reclaimed as soon as the `menuItem` is no longer reachable, but if you used the same logic as you did for the scene listener (e.g., on lines 254-261), it would be removed sooner. I don't know whether it matters in this case. ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From kcr at openjdk.java.net Sat Nov 13 00:30:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 13 Nov 2021 00:30:38 GMT Subject: RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox wrote: > During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing. > > This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been. > > For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms. > > As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation. There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level. The fix looks good to me, too. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/651 From kevin.rushforth at oracle.com Sat Nov 13 00:31:43 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Nov 2021 16:31:43 -0800 Subject: Bidirectional binding enhancement In-Reply-To: References: Message-ID: <1dfb4e01-4089-383a-69c3-c48457d9025c@oracle.com> In addition to the points John raises, I also agree with the comment Tom added to the Draft PR: I don't think the object bindings in javafx.base should have UI concepts like Action or Focus, even if you abstract them a bit. -- Kevin On 11/10/2021 3:10 AM, John Hendrikx wrote: > Although I think you have a valid use case, I don't think JavaFX > should facilitate this exact scenario; it is a high level concern that > you want to solve in a very low level mechanism. A similar scenario > also applies to uni-directional bindings, so I think it would have to > apply there as well. > > It also really depends on how you are doing the communication between > view and model. Some system use models that are always valid, some > systems use a view-model that contains a direct copy of what is in the > UI controls. Some views allow users to type anything and do validation > on submission or focus loss; some do per character validation and mark > bad input; some will not even allow you to type bad input. > > For a scenario like you describe, which seems to be about delayed > updates of bindings, I think you really want to use something like > ReactFX's EventStreams.? These offer far more features, including > timeouts, removal of duplicates, combining of values, conditional > suspending, etc.? It might work like this for example: > > ??? EventStream.of(textInput.textProperty()) > ??????? .conditionOn(textInput.focusedProperty().not()) > ??????? .feedTo(model::valueProperty); > > Or with Val: > > ??? Val.of(textInput.textProperty()) > ??????? .conditionOn(textInput.focusedProperty().not()) > ??????? .subcribe(v -> updateModel(v)); > > (Note: conditionOn is part of the fluent bindings proposal that Nir > Lisker and me have been working on). > > Now, this isn't bidirectional, but I don't see how that will work in > any case as there are some edge cases. For example, how would you > handle a model update when the view is currently being edited? > Delaying updates runs into issues where both may have changed, whereas > currently bindings are resolved immediately on the FX thread. > > --John > > On 10/11/2021 06:45, Michael Strau? wrote: >> JavaFX developers routinely use programming patterns like MVC, MVP, or >> MVVM to separate views from their associated business logic. Bindings >> can be used to connect the values of UI controls (like Label or >> TextField) to properties on a business logic class. >> >> A typical (simplified) scenario may look like this: >> >> var valueField = new TextField(); >> valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); >> >> >> The business logic class may perform data validation or other actions >> on the value that was entered in the TextField. However, in many >> cases, it is neither necessary nor desirable for the binding to update >> the business-layer property on every single change (i.e. every single >> character that was typed by a user). For example, if a business rule >> verifies that the data entered by a user is formatted in a specific >> way, it's usually not a great experience to yield a validation error >> before the user has finished typing. Instead, it's often better to >> wait until the user has significantly interacted with a UI control >> before running business logic. >> >> For this reason, I propose to add a new type of binding to the >> javafx.beans.binding.Bindings class: >> >> void bindBidirectional(Property target, Property source, >> UpdateSourceTrigger trigger) >> >> UpdateSourceTrigger is an enumeration that allows developers to >> specify the condition on which changes of the target property will >> update the source property. Its values are: >> >> DEFAULT: Updates the source property on every change (this is the >> default behavior of bidirectional bindings). >> FOCUS: Updates the source property when the UI control loses input >> focus. >> ACTION: Updates the source property when the UI control loses input >> focus or when it receives an ActionEvent (in the case of TextField, >> this corresponds to the ENTER key). >> >> Note that this setting only applies to changes of the target property. >> When the source property is changed instead, the target property is >> always immediately updated. >> >> Any feedback on this proposal is appreciated. >> From kevin.rushforth at oracle.com Sat Nov 13 00:48:00 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Nov 2021 16:48:00 -0800 Subject: Circling back to a new layout algorithm In-Reply-To: References: Message-ID: <39311e22-5be9-20d2-d419-a9f753ca84bd@oracle.com> I think this will be a good improvement to implement to the JavaFX layout algorithm. I see that you filed JDK-8276671 [1] to track this enhancement. As noted, the main concern will be making sure we don't break existing applications, so testing this will be key. One other issue that will need to be addressed is what a good the threshold would be for the maximum number of iterations, such that if it doesn't converge we will stop anyway (and log a warning). This is a trade-off between performance and accuracy, although as noted in the JBS issue, if the layout doesn't converge it's a bug. The value we ultimately choose can be discussed during the review and testing. Regardless of what the threshold is, I recommend a system property (named something like "com.sun.javafx.scene.layout.threshold"). This will be helpful during testing. What do other developers think? Would this be a useful problem to solve in layout? -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8276671 On 11/4/2021 7:31 PM, Michael Strau? wrote: > I previously proposed a new iterative layout algorithm [1] that > supports baseline alignment and introduces new APIs to give developers > control over the way nodes are aligned. This is a solution to the > long-standing problem that JavaFX cannot reliably lay out nodes that > are aligned on their baseline [2]. The new layout algorithm might also > fix some issues where the scene graph layout only settles after > interacting with the controls (for example, by clicking). > > I've created a small application that shows the new APIs and a > correctly working baseline-aligned layout [3]. In addition to that, I > also built SceneBuilder with both the old and new layout system, and > played around with it to find out whether there were any regressions > or visual differences. So far, I haven't found any. > > In order to move this forward, I think it would be a good idea to test > the latest version of the new layout system in more real-world JavaFX > applications. Any help from JavaFX application developers is greatly > appreciated. It's as easy as checking out the JavaFX sources from the > PR [1], building a local SDK and linking your application with the > binaries. > > > Finally, here's a high-level overview of the new algorithm: > > When Parent::layout() is called on a layout root (i.e. a scene root or > an unmanaged node), it will lay out its children in a loop until the > scene graph under the layout root is fully laid out, which means it is > clean and doesn't require further layout. The totality of layout > activity for a single layout root is called "layout cycle". A layout > cycle will often take a few layout passes to finish (but not more than > 2 in most cases). There is no limit on how often Parent::layout() will > iterate to lay out its children, so in principle, this could lead to > an infinite layout loop. > > One source of infinite layout loops are incorrectly implemented controls: > > class PathologicalControl extends Region { > final Text text = new Text("foo"); > > PathologicalControl() { > getChildren().add(text); > } > > @Override > protected void layoutChildren() { > text.relocate(0, text.getLayoutY() + 10); > } > } > > In this example, each call to layoutChildren() moves down the text > node another 10 pixels from where it was, which causes the layout > algorithm to schedule yet another layout pass. It's an infinite loop. > > The layout system detects this by tracking how often a node > invalidates the scene graph in a single layout cycle. If a node > exceeds a threshold of 100 invalidations, it will be suspended from > layout and can no longer invalidate the scene graph in the current > layout cycle. A warning will be logged to notify developers of that > fact. > > > [1] https://github.com/openjdk/jfx/pull/433 > [2] https://bugs.openjdk.java.net/browse/JDK-8090261 > [3] https://github.com/mstr2/jfx-layout-sample From swpalmer at gmail.com Sat Nov 13 02:28:54 2021 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 12 Nov 2021 21:28:54 -0500 Subject: Circling back to a new layout algorithm In-Reply-To: <39311e22-5be9-20d2-d419-a9f753ca84bd@oracle.com> References: <39311e22-5be9-20d2-d419-a9f753ca84bd@oracle.com> Message-ID: > On Nov 12, 2021, at 7:48 PM, Kevin Rushforth wrote: > > ?I think this will be a good improvement to implement to the JavaFX layout algorithm. I see that you filed JDK-8276671 [1] to track this enhancement. > > As noted, the main concern will be making sure we don't break existing applications, so testing this will be key. > > One other issue that will need to be addressed is what a good the threshold would be for the maximum number of iterations, such that if it doesn't converge we will stop anyway (and log a warning). This is a trade-off between performance and accuracy, although as noted in the JBS issue, if the layout doesn't converge it's a bug. The value we ultimately choose can be discussed during the review and testing. Regardless of what the threshold is, I recommend a system property (named something like "com.sun.javafx.scene.layout.threshold"). This will be helpful during testing. > > What do other developers think? Sounds good to me. I?m all for it. > Would this be a useful problem to solve in layout? Absolutely. I have dialogs that have really irritating layout issues that magically correct themselves when you interact with the controls. Scott > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8276671 > > >> On 11/4/2021 7:31 PM, Michael Strau? wrote: >> I previously proposed a new iterative layout algorithm [1] that >> supports baseline alignment and introduces new APIs to give developers >> control over the way nodes are aligned. This is a solution to the >> long-standing problem that JavaFX cannot reliably lay out nodes that >> are aligned on their baseline [2]. The new layout algorithm might also >> fix some issues where the scene graph layout only settles after >> interacting with the controls (for example, by clicking). >> >> I've created a small application that shows the new APIs and a >> correctly working baseline-aligned layout [3]. In addition to that, I >> also built SceneBuilder with both the old and new layout system, and >> played around with it to find out whether there were any regressions >> or visual differences. So far, I haven't found any. >> >> In order to move this forward, I think it would be a good idea to test >> the latest version of the new layout system in more real-world JavaFX >> applications. Any help from JavaFX application developers is greatly >> appreciated. It's as easy as checking out the JavaFX sources from the >> PR [1], building a local SDK and linking your application with the >> binaries. >> >> >> Finally, here's a high-level overview of the new algorithm: >> >> When Parent::layout() is called on a layout root (i.e. a scene root or >> an unmanaged node), it will lay out its children in a loop until the >> scene graph under the layout root is fully laid out, which means it is >> clean and doesn't require further layout. The totality of layout >> activity for a single layout root is called "layout cycle". A layout >> cycle will often take a few layout passes to finish (but not more than >> 2 in most cases). There is no limit on how often Parent::layout() will >> iterate to lay out its children, so in principle, this could lead to >> an infinite layout loop. >> >> One source of infinite layout loops are incorrectly implemented controls: >> >> class PathologicalControl extends Region { >> final Text text = new Text("foo"); >> >> PathologicalControl() { >> getChildren().add(text); >> } >> >> @Override >> protected void layoutChildren() { >> text.relocate(0, text.getLayoutY() + 10); >> } >> } >> >> In this example, each call to layoutChildren() moves down the text >> node another 10 pixels from where it was, which causes the layout >> algorithm to schedule yet another layout pass. It's an infinite loop. >> >> The layout system detects this by tracking how often a node >> invalidates the scene graph in a single layout cycle. If a node >> exceeds a threshold of 100 invalidations, it will be suspended from >> layout and can no longer invalidate the scene graph in the current >> layout cycle. A warning will be logged to notify developers of that >> fact. >> >> >> [1] https://github.com/openjdk/jfx/pull/433 >> [2] https://bugs.openjdk.java.net/browse/JDK-8090261 >> [3] https://github.com/mstr2/jfx-layout-sample > From kcr at openjdk.java.net Sat Nov 13 14:05:39 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 13 Nov 2021 14:05:39 GMT Subject: RFR: 8232812: [MacOS] Double click title bar does not restore window size In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 20:36:37 GMT, Martin Fox wrote: > The test case for JDK-8160241 creates a window in a zoomed state (as defined by macOS). When the OS later goes to unzoom the window it will try to shrink it down to 1 point wide. This was entered as JDK-8163137 but the fix for that bug inadvertently disabled unzooming altogether. This PR fixes 8163137 in a slightly different way. > > Access to the zoom/unzoom feature has changed with newer versions of macOS. To reproduce this you have to change `System Preferences > Dock & Menu Bar > Double-click a window's title bar` to `zoom`. Then use double-clicks in the title bar to test the feature. The green button in the title bar no longer has anything to do with zoom/unzoom. @beldenfox this is ready for you to integrate. ------------- PR: https://git.openjdk.java.net/jfx/pull/639 From kcr at openjdk.java.net Sat Nov 13 14:05:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 13 Nov 2021 14:05:38 GMT Subject: RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS In-Reply-To: References: Message-ID: On Sat, 23 Oct 2021 18:20:38 GMT, Martin Fox wrote: >> During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing. >> >> This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been. >> >> For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms. >> >> As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation. There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level. > > No, my changes won?t fix JDK-8264172. Anything that changes the way JavaFX interacts with external applications like Finder has to go through the Java CSR review process and I wanted to avoid that. I did look into this bug and determined there?s nothing much we can fix. > > When it comes to using the Command key to select Move I discovered that Finder doesn?t respond to Move from another app anyway. Drags from the Finder complete successfully on the drop end but the Finder just ignores the Move. I?m pretty sure this is by design since it conforms with the Apple user interface guidelines. > > You have to use the Control modifier key to select Link when dragging files from the Finder to a JavaFX app. There?s nothing we can do about that, modifier key filtering between applications is handled by the OS and it uses obsolete conventions carried over from NeXTSTEP. And unfortunately given the weird way the OS filters the modifier keys there?s no good work-around. > > By the way, Apple?s online API documentation (in NSDraggingInfo draggingSourceOperationMask) isn?t accurate, it seems to be describing how Finder works internally. There are older documents which describe the OS behavior correctly. I?ve entered a bug against the online docs which I?m sure Apple will ignore. > > Let me know if you want further details on any of this. > >> On Oct 23, 2021, at 3:56 AM, Christoph ***@***.***> wrote: >> >> >> Thanks for tackling this issue, much appreciated. I reported a similar one a while ago https://bugs.openjdk.java.net/browse/JDK-8264172 Can you confirm this will also be fixed if you drag a file? >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub , or unsubscribe . >> Triage notifications on the go with GitHub Mobile for iOS or Android . >> @beldenfox this is ready for you to integrate. ------------- PR: https://git.openjdk.java.net/jfx/pull/651 From hjohn at xs4all.nl Sat Nov 13 15:23:47 2021 From: hjohn at xs4all.nl (John Hendrikx) Date: Sat, 13 Nov 2021 16:23:47 +0100 Subject: Circling back to a new layout algorithm In-Reply-To: References: Message-ID: I haven't taken a close look, but I've done some automated layout work before. The baseline layout seems to be an interesting kind of problem where controls can influence each other, where normally they are mostly independent. An iterative approach may be the only viable one, but it does leave me thinking if there isn't a better option. My primary concern is that it is relatively easy to construct a situation that would not converge quickly. Given a fixed height control A with some text that is top aligned and which has a significant amount of padding at the bottom (maybe it has an image below the text), and another unbounded control B with its text vertically centered. Every time the algorithm tries to align the baselines of these two controls, the container grows a little bit bigger. This enlarges control B, pushing the baseline down (as it is centered), which in turn means that aligning control A on that new baseline will mean its bottom padding now extends beyond the containers size, and the container is enlarged again... Visually: +-------+ +-------+ | A | | | | | | B | | | | | +-------+ +-------+ After 1 iteration: +-------+ +-------+ | | | A | | | | | | B | | | | | +-------+ +-------+ After 2 iterations: +-------+ | | +-------+ | | | A | | B | | | | | | | | | +-------+ +-------+ In ASCII art this converges relatively fast, but it all depends on the size of control A and how large its bottom padding is. I was wondering if this can be improved upon somehow. --John On 05/11/2021 03:31, Michael Strau? wrote: > I previously proposed a new iterative layout algorithm [1] that > supports baseline alignment and introduces new APIs to give developers > control over the way nodes are aligned. This is a solution to the > long-standing problem that JavaFX cannot reliably lay out nodes that > are aligned on their baseline [2]. The new layout algorithm might also > fix some issues where the scene graph layout only settles after > interacting with the controls (for example, by clicking). > > I've created a small application that shows the new APIs and a > correctly working baseline-aligned layout [3]. In addition to that, I > also built SceneBuilder with both the old and new layout system, and > played around with it to find out whether there were any regressions > or visual differences. So far, I haven't found any. > > In order to move this forward, I think it would be a good idea to test > the latest version of the new layout system in more real-world JavaFX > applications. Any help from JavaFX application developers is greatly > appreciated. It's as easy as checking out the JavaFX sources from the > PR [1], building a local SDK and linking your application with the > binaries. > > > Finally, here's a high-level overview of the new algorithm: > > When Parent::layout() is called on a layout root (i.e. a scene root or > an unmanaged node), it will lay out its children in a loop until the > scene graph under the layout root is fully laid out, which means it is > clean and doesn't require further layout. The totality of layout > activity for a single layout root is called "layout cycle". A layout > cycle will often take a few layout passes to finish (but not more than > 2 in most cases). There is no limit on how often Parent::layout() will > iterate to lay out its children, so in principle, this could lead to > an infinite layout loop. > > One source of infinite layout loops are incorrectly implemented controls: > > class PathologicalControl extends Region { > final Text text = new Text("foo"); > > PathologicalControl() { > getChildren().add(text); > } > > @Override > protected void layoutChildren() { > text.relocate(0, text.getLayoutY() + 10); > } > } > > In this example, each call to layoutChildren() moves down the text > node another 10 pixels from where it was, which causes the layout > algorithm to schedule yet another layout pass. It's an infinite loop. > > The layout system detects this by tracking how often a node > invalidates the scene graph in a single layout cycle. If a node > exceeds a threshold of 100 invalidations, it will be suspended from > layout and can no longer invalidate the scene graph in the current > layout cycle. A warning will be logged to notify developers of that > fact. > > > [1] https://github.com/openjdk/jfx/pull/433 > [2] https://bugs.openjdk.java.net/browse/JDK-8090261 > [3] https://github.com/mstr2/jfx-layout-sample > From fkirmaier at openjdk.java.net Mon Nov 15 08:15:16 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 08:15:16 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 22:42:35 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274022 >> Simplified code related to WeakHashMaps > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 31: > >> 29: import javafx.beans.property.ReadOnlyObjectProperty; >> 30: import javafx.beans.value.ChangeListener; >> 31: import javafx.beans.value.WeakChangeListener; > > Unused import. removed! ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Mon Nov 15 08:15:11 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 08:15:11 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v4] In-Reply-To: References: Message-ID: > This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. > To fix it, I've made the Value of the WeakHashMap also weak. > We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. > > > I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. > > It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. > > Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8274022 removed an unused import ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/659/files - new: https://git.openjdk.java.net/jfx/pull/659/files/bbc39f24..d2a1c448 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/659/head:pull/659 PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Mon Nov 15 08:24:04 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 08:24:04 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v5] In-Reply-To: References: Message-ID: > This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. > To fix it, I've made the Value of the WeakHashMap also weak. > We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. > > > I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. > > It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. > > Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: 8274022 the logic to remove the keys from the map, is now more consistent ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/659/files - new: https://git.openjdk.java.net/jfx/pull/659/files/d2a1c448..873c3090 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=03-04 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/659.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/659/head:pull/659 PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Mon Nov 15 08:28:42 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 08:28:42 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 23:42:30 GMT, Kevin Rushforth wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274022 >> Simplified code related to WeakHashMaps > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 291: > >> 289: WeakReference> listenerW = changeListenerMap.get(menuitem); >> 290: ChangeListener listener = listenerW == null ? null : listenerW.get(); >> 291: if (listener != null) { > > This will fail to remove a weak reference to a listener that has been collected. It is a `WeakHashMap`, so the `WeakReference` to the listener will be reclaimed as soon as the `menuItem` is no longer reachable, but if you used the same logic as you did for the scene listener (e.g., on lines 254-261), it would be removed sooner. I don't know whether it matters in this case. Yes, you are right. I now use the same logic in all 3 places. I guess it doesn't matter because the key always references the listener - but the code is now more straight line. ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Mon Nov 15 10:05:10 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 10:05:10 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v8] In-Reply-To: References: Message-ID: > When using Swing it's possible to generate a Deadlock. > It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. > Sample Programm and Threaddump are added to the ticket. > > Removing the nested loop fixes the Problem. > I hope this doesn't have any side effect - so far i don't know of any. Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8273485 Added check for null when calling initScreens ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/622/files - new: https://git.openjdk.java.net/jfx/pull/622/files/4dcbcc22..faddeb60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=06-07 Stats: 8 lines in 1 file changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/622.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/622/head:pull/622 PR: https://git.openjdk.java.net/jfx/pull/622 From fkirmaier at openjdk.java.net Mon Nov 15 10:05:15 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 10:05:15 GMT Subject: RFR: 8273485: Deadlock when also using Swing and exiting Fullscreen on Mac [v7] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier wrote: >> When using Swing it's possible to generate a Deadlock. >> It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene. >> Sample Programm and Threaddump are added to the ticket. >> >> Removing the nested loop fixes the Problem. >> I hope this doesn't have any side effect - so far i don't know of any. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8273485 > Fixing toggle fullscreen! I've now added a check for null when calling the initScreens method. This should fix the null pointer exception. ------------- PR: https://git.openjdk.java.net/jfx/pull/622 From jpereda at openjdk.java.net Mon Nov 15 11:24:59 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 15 Nov 2021 11:24:59 GMT Subject: RFR: 8160597: IllegalArgumentException when we initiate drag on Image Message-ID: This PR fixes an exception that can happen when dragging an image from a WebView on macOS. Dragging an image that is directly included like `` works fine, without exception. However, there are (at least) two other cases when the IAE is thrown: - Dragging an image that is part of an hyperlink, like ``. - Dragging an image encoded as base64. The IAE happens only on macOS, where a native image is created in `GlassPasteboard.m` from an URL, and in those two cases the generated image has 0x0 dimensions: `` which leads to `ByteArrayFromPixels` being called with a null byte array. The included test reproduces the case by directly pushing the `MacPasteboard` content (instead of adding a more complex test with a webView and a drag and drop gesture). ------------- Commit messages: - Remove unused imports - Check if MacPasteboard contains a valid image, including test Changes: https://git.openjdk.java.net/jfx/pull/668/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=668&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8160597 Stats: 155 lines in 5 files changed: 154 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/668.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/668/head:pull/668 PR: https://git.openjdk.java.net/jfx/pull/668 From fastegal at openjdk.java.net Mon Nov 15 13:11:06 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 15 Nov 2021 13:11:06 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v4] In-Reply-To: References: Message-ID: > Cleanup of Tree-/TableRowSkin to support switching skins > > The misbehavior/s > - memory leaks due to manually registered listeners that were not removed > - side-effects due to listeners still active on old skin (like NPEs) > > Fix > - use skin api for all listener registration (for automatic removal in dispose) > - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745)) > > Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. > > Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: reverted fixedCellSize handling ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/632/files - new: https://git.openjdk.java.net/jfx/pull/632/files/fc71c931..603b08af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=02-03 Stats: 312 lines in 6 files changed: 243 ins; 50 del; 19 mod Patch: https://git.openjdk.java.net/jfx/pull/632.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/632/head:pull/632 PR: https://git.openjdk.java.net/jfx/pull/632 From duke at openjdk.java.net Mon Nov 15 13:28:36 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 15 Nov 2021 13:28:36 GMT Subject: Integrated: 8232812: [MacOS] Double click title bar does not restore window size In-Reply-To: References: Message-ID: <9YmXKs_z-4s0FyymBj-EWjruQHiqN2af6PFkzf5GXZs=.8db3fa4d-1915-4a59-9d04-e8cd050da714@github.com> On Tue, 5 Oct 2021 20:36:37 GMT, Martin Fox wrote: > The test case for JDK-8160241 creates a window in a zoomed state (as defined by macOS). When the OS later goes to unzoom the window it will try to shrink it down to 1 point wide. This was entered as JDK-8163137 but the fix for that bug inadvertently disabled unzooming altogether. This PR fixes 8163137 in a slightly different way. > > Access to the zoom/unzoom feature has changed with newer versions of macOS. To reproduce this you have to change `System Preferences > Dock & Menu Bar > Double-click a window's title bar` to `zoom`. Then use double-clicks in the title bar to test the feature. The green button in the title bar no longer has anything to do with zoom/unzoom. This pull request has now been integrated. Changeset: 7ddd6427 Author: Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/7ddd6427814877ddf191b83e371f166b326ce821 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8232812: [MacOS] Double click title bar does not restore window size Reviewed-by: kcr, pbansal ------------- PR: https://git.openjdk.java.net/jfx/pull/639 From fastegal at openjdk.java.net Mon Nov 15 13:31:41 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 15 Nov 2021 13:31:41 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v2] In-Reply-To: References: <8ZHb9oNuP9ws90xV_5LUV3kDDjPluqZy4FFwnIZCj5U=.b55bd50b-5fdf-4097-9c68-1225263f3111@github.com> Message-ID: On Mon, 1 Nov 2021 12:59:42 GMT, Marius Hanl wrote: >> well .. that would be a merge conflict, had you updated the code comment in your PR ?? As noted in my comments to Ajit's review, the listener registration is simply moved (including the code comment .. belatedly :) >> >> Not sure how to handle it from here - following the rules, we might need a follow-up issue to the issue fixed in your PR? > > My PR is already merged, so this is not a problem. :) > I dont know, but since this is only fixing a (also before) wrong comment it might be okay as it is very minor? :) FYI: now the listener registration - including the incorrect code comment (which is the same as in current master) - is back at the old location in the re-inserted setupTreeTableViewListeners. So still need input whether it's okay to correct the code comment here. ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From kcr at openjdk.java.net Mon Nov 15 14:13:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Nov 2021 14:13:38 GMT Subject: RFR: 8274022 fixing critical memory leak in the ControlAcceleratorSupport [v5] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 08:24:04 GMT, Florian Kirmaier wrote: >> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. >> To fix it, I've made the Value of the WeakHashMap also weak. >> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. >> >> >> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. >> >> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. >> >> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8274022 > the logic to remove the keys from the map, is now more consistent Looks good. Btw, you still need to change the title of this PR to match the JBS title. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Mon Nov 15 14:20:39 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 14:20:39 GMT Subject: RFR: 8274022 Additional Memory Leak in ControlAcceleratorSupport [v5] In-Reply-To: References: Message-ID: <8D4fPii-Q2PbdziXcZIgGuplyQ_kwPbmCgUILrHFIEE=.e9dbb390-e9eb-42bc-976e-cadf216eda0e@github.com> On Mon, 15 Nov 2021 08:24:04 GMT, Florian Kirmaier wrote: >> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. >> To fix it, I've made the Value of the WeakHashMap also weak. >> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. >> >> >> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. >> >> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. >> >> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8274022 > the logic to remove the keys from the map, is now more consistent Great, I've just updated the title! ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From mhanl at openjdk.java.net Mon Nov 15 14:38:59 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 15 Nov 2021 14:38:59 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout Message-ID: When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. While this is fine, it is also called when the **layoutChildren(..)** method is repositioning the divider. This makes no sense since we are currently layouting everything, so we don't need to request it again (-> We are doing it right now). After positioning the dividers the **SplitPane** content is layouted (based of the may new positioned dividers). This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). Note: I also fixed a simple typo of a private method in SplitPaneSkin: initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers ------------- Commit messages: - 8277122: SplitPane divider drag can hang the layout Changes: https://git.openjdk.java.net/jfx/pull/669/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277122 Stats: 61 lines in 2 files changed: 54 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/669.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/669/head:pull/669 PR: https://git.openjdk.java.net/jfx/pull/669 From kcr at openjdk.java.net Mon Nov 15 15:04:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Nov 2021 15:04:38 GMT Subject: RFR: 8274022 Additional Memory Leak in ControlAcceleratorSupport [v3] In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021 09:41:09 GMT, Michael Strau? wrote: >> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: >> >> 8274022 >> Simplified code related to WeakHashMaps > > Marked as reviewed by mstrauss (Author). @mstr2 can you re-review this? ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From mstrauss at openjdk.java.net Mon Nov 15 15:53:38 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 15 Nov 2021 15:53:38 GMT Subject: RFR: 8274022 Additional Memory Leak in ControlAcceleratorSupport [v5] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 08:24:04 GMT, Florian Kirmaier wrote: >> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. >> To fix it, I've made the Value of the WeakHashMap also weak. >> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. >> >> >> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. >> >> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. >> >> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. > > Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: > > 8274022 > the logic to remove the keys from the map, is now more consistent Looks good to me. ------------- Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.java.net/jfx/pull/659 From fkirmaier at openjdk.java.net Mon Nov 15 16:32:37 2021 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Mon, 15 Nov 2021 16:32:37 GMT Subject: Integrated: 8274022 Additional Memory Leak in ControlAcceleratorSupport In-Reply-To: References: Message-ID: On Sat, 30 Oct 2021 10:56:40 GMT, Florian Kirmaier wrote: > This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17. > To fix it, I've made the Value of the WeakHashMap also weak. > We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak. > > > I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug. > > It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable. > > Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe. This pull request has now been integrated. Changeset: 0d5b8f8b Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/0d5b8f8b3f71b1301a65adcc41fe0c7308d4ff01 Stats: 46 lines in 2 files changed: 33 ins; 0 del; 13 mod 8274022: Additional Memory Leak in ControlAcceleratorSupport Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/659 From duke at openjdk.java.net Mon Nov 15 16:39:36 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 15 Nov 2021 16:39:36 GMT Subject: Integrated: 8227371: Drag&Drop while holding the CMD key does not work on macOS In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox wrote: > During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing. > > This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been. > > For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms. > > As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation. There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level. This pull request has now been integrated. Changeset: f939d094 Author: Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f939d094e3f02575c77a12c3a986d5f601a65a1d Stats: 87 lines in 3 files changed: 78 ins; 1 del; 8 mod 8227371: Drag&Drop while holding the CMD key does not work on macOS Reviewed-by: pbansal, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/651 From mstrauss at openjdk.java.net Mon Nov 15 16:44:46 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 15 Nov 2021 16:44:46 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: <6mfgYW4q_uDYhKtYuus3_zL0wUWRU80903mAnO-RJcM=.3c17f520-98f4-4f5d-a54d-bc1d6d6b0ff1@github.com> References: <6mfgYW4q_uDYhKtYuus3_zL0wUWRU80903mAnO-RJcM=.3c17f520-98f4-4f5d-a54d-bc1d6d6b0ff1@github.com> Message-ID: On Thu, 11 Nov 2021 15:18:25 GMT, Kevin Rushforth wrote: > I left a few comments on the dependencies. Will review / test the PR later. > > One comment about adding new JUnit 5 tests and migrating existing tests. I think there could be value in organizing the tests such that all of the JUnit 5 tests are grouped, rather than mixing tests in the same directory such that some use JUnit 5 and others use JUnit 4. What do you (or others) think? We could either do this with a new JUnit 5 source set in each project, or by using a package naming convention for JUnit 5 tests like we do for robot tests. Maybe `test5.some.pkg`. This needs more thought. I don't like the idea of separating source sets or packages just based on the version of our unit test framework. In my opinion, sources should be organized by function, and not based on a technicality. A very common case we'll encounter will be adding a new unit test to an existing test class. What's our guidance in this case? If we continue to use JUnit4 for new unit tests, that means we'll effectively persist this version of the framework forever in the test sources. Another option would be to migrate the entire test class once it's updated with new code. However, that would be a significant amount of work required from the author of a new unit test. A third option would be to actually migrate all unit test classes as a series of refactoring PRs. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Mon Nov 15 18:32:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Nov 2021 18:32:50 GMT Subject: RFR: 8276142: Update gradle to version 7.3 Message-ID: This bumps the version of gradle used to build JavaFX to 7.3 (from the current 7.0.1). Among other things, gradle 7.3 adds support for JDK 17, so this is a prerequisite to update the boot JDK to JDK 17.x -- see [JDK-8276144](https://bugs.openjdk.java.net/browse/JDK-8276144). This will not affect the minimum version of gradle needed to build JavaFX, which remains at 6.3 (although that version requires an even older boot JDK than we currently use, so is not recommended). I included a `gradle/UPDATING.txt ` file to document the steps needed to update to a new version of gradle. NOTE: The boot JDK remains at 16.0.2 with this PR, but the intent is to update the boot JDK soon after this is integrated. To that end, I have created PR #670 as a Draft PR to bump the boot JDK to 17.0.1. It necessarily includes the fix from _this_ PR to update gradle to 7.3, otherwise the GitHub Actions build would have failed. You can look at the test results from that Draft PR to see that JDK 17.0.1 works when buliding with gradle 7.3. ------------- Commit messages: - 8276142: Update gradle to version 7.3 Changes: https://git.openjdk.java.net/jfx/pull/671/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276142 Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod Patch: https://git.openjdk.java.net/jfx/pull/671.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/671/head:pull/671 PR: https://git.openjdk.java.net/jfx/pull/671 From kcr at openjdk.java.net Mon Nov 15 18:56:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Nov 2021 18:56:54 GMT Subject: [jfx17u] Integrated: 8274022: Additional Memory Leak in ControlAcceleratorSupport Message-ID: <9M6vl3a9qXQIU7JTbYsV8h7N44e8Ky1bJhdIkUr8lUk=.068fc6b7-1f84-4ef4-bca0-7beafb3a116e@github.com> Clean backport to `jfx17u`. ------------- Commit messages: - 8274022: Additional Memory Leak in ControlAcceleratorSupport Changes: https://git.openjdk.java.net/jfx17u/pull/21/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=21&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274022 Stats: 46 lines in 2 files changed: 33 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx17u/pull/21.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/21/head:pull/21 PR: https://git.openjdk.java.net/jfx17u/pull/21 From kcr at openjdk.java.net Mon Nov 15 18:56:54 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Nov 2021 18:56:54 GMT Subject: [jfx17u] Integrated: 8274022: Additional Memory Leak in ControlAcceleratorSupport In-Reply-To: <9M6vl3a9qXQIU7JTbYsV8h7N44e8Ky1bJhdIkUr8lUk=.068fc6b7-1f84-4ef4-bca0-7beafb3a116e@github.com> References: <9M6vl3a9qXQIU7JTbYsV8h7N44e8Ky1bJhdIkUr8lUk=.068fc6b7-1f84-4ef4-bca0-7beafb3a116e@github.com> Message-ID: <5JB9XbQyU2a55n82YzfRp4XVq9TlbQhvptcRSG6Z0zw=.d0335224-0a98-4ead-8b43-b92e789db13f@github.com> On Mon, 15 Nov 2021 18:48:51 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. This pull request has now been integrated. Changeset: e3b061c9 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/e3b061c9d3667bd7ec327d9c9869d6415fd33414 Stats: 46 lines in 2 files changed: 33 ins; 0 del; 13 mod 8274022: Additional Memory Leak in ControlAcceleratorSupport Backport-of: 0d5b8f8b3f71b1301a65adcc41fe0c7308d4ff01 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/21 From duke at openjdk.java.net Mon Nov 15 20:19:54 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 15 Nov 2021 20:19:54 GMT Subject: RFR: 8274967: KeyCharacterCombinations for punctuation and symbols fail on non-US keyboards Message-ID: The code that maps from a Windows virtual key code to a Java key code in `getKeyCodeForChar` did not match the similar code in `ViewContainer::HandleViewKeyEvent`. The OEM keys are assigned to printable punctuation and symbols in way which varies across layouts and even keyboards. To determine the correct Java key code you have to query the layout to determine the character the key would generate without modifiers and map that character to the key code. `ViewContainer::HandleViewKeyEvent` did this, `getKeyCodeForChar` did not. This PR copies a few snippets of code from `ViewContainer::HandleViewKeyEvent` to make the two algorithms match. ------------- Commit messages: - getKeyCodeForChar works on non-US layouts for symbols and punctuation Changes: https://git.openjdk.java.net/jfx/pull/672/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=672&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274967 Stats: 70 lines in 1 file changed: 67 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/672.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/672/head:pull/672 PR: https://git.openjdk.java.net/jfx/pull/672 From jhendrikx at openjdk.java.net Mon Nov 15 21:50:44 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 15 Nov 2021 21:50:44 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: References: <6mfgYW4q_uDYhKtYuus3_zL0wUWRU80903mAnO-RJcM=.3c17f520-98f4-4f5d-a54d-bc1d6d6b0ff1@github.com> Message-ID: On Mon, 15 Nov 2021 16:42:04 GMT, Michael Strau? wrote: > One comment about adding new JUnit 5 tests and migrating existing tests. I think there could be value in organizing the tests such that all of the JUnit 5 tests are grouped, rather than mixing tests in the same directory such that some use JUnit 5 and others use JUnit 4. What do you (or others) think? We could either do this with a new JUnit 5 source set in each project, or by using a package naming convention for JUnit 5 tests like we do for robot tests. Maybe `test5.some.pkg`. This needs more thought. I don't think this is really needed, since the introduction of JUnit 5 I've written numerous tests in projects with the bulk of their test classes still using JUnit 4. In all cases, the new tests were just mixed with the old tests. The mixing of the tests has so far caused no confusion, and in these projects the teams involved also didn't feel any need to prioritize migrating all tests to JUnit 5. Conversion to JUnit 5 usually happens on a test by test basis when other changes are made to the test -- existing code is rewritten as needed, usually limited to introducing `assertThrows` to replace `@Test(expected = Throwable.class)` and updating all static asserts to use the `jupiter` package hierarchy instead of the `org.junit` one (just import changes). Usually this is done in a separate commit (a "chore" commit) with another commit containing the actual change and new test cases. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Mon Nov 15 21:57:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 15 Nov 2021 21:57:43 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Readd junit declaration in allprojects and set junit version to 4.13.2 These are good points regarding test migration. I withdraw the suggestion of test segregation. I would not want to see a wholesale migration of all tests to JUnit5, but I do like the idea of migrating on a test-by-test basis if new tests are being added to an existing test class where using JUnit 5 would be a benefit. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Mon Nov 15 22:00:45 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 15 Nov 2021 22:00:45 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: <6mfgYW4q_uDYhKtYuus3_zL0wUWRU80903mAnO-RJcM=.3c17f520-98f4-4f5d-a54d-bc1d6d6b0ff1@github.com> References: <6mfgYW4q_uDYhKtYuus3_zL0wUWRU80903mAnO-RJcM=.3c17f520-98f4-4f5d-a54d-bc1d6d6b0ff1@github.com> Message-ID: <2ylQO500xshjma4Km2UtDeGvE34C68seib3mENapLcU=.265a32fa-2756-47c6-819f-e1724aaf3049@github.com> On Thu, 11 Nov 2021 15:11:32 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Readd junit declaration in allprojects and set junit version to 4.13.2 > > build.gradle line 1953: > >> 1951: testRuntimeOnly(group: "org.junit.vintage", name: "junit-vintage-engine", version: "5.8.1") { >> 1952: exclude(group: "org.apiguardian", module: "apiguardian-api") >> 1953: } > > As it turns out, `apiguardian` no longer needs to be blocked, so you can restore it if it is easier. Okay, I'll remove the exclusion on apiguardian then as it would just be confusing why it was excluded in the first place. Hamcrest was already included as JUnit 5 wouldn't work without it. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Mon Nov 15 22:06:38 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 15 Nov 2021 22:06:38 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 20:45:23 GMT, Kevin Rushforth wrote: > As mentioned in JBS, any new third-party libraries require prior third-party license approval. And we will need to work with you on sponsoring this (as you can't contribute any third-party code under the OCA). > > Speaking of which, there are more libraries added to `gradle-verification.xml` than I would expect. Each one will need third-party approval, if they are required. Since this is for internal use (build / test only) and not something we redistribute, that makes it easier, although it still depends on the license for each piece. > > Finally, we have some closed tests that we need to ensure aren't impacted by this, so that's one more area we need to coordinate. > > We can take a look, but it won't be right away. Can you also start a thread on openjfx-dev? I'd like to gauge the level of interest in enabling JUnit 5 for new tests. Github is showing this as a "requested change" but I can't resolve this. @kevinrushforth anything you can do on your end? All the issues in this comment were addresses AFAIK. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Mon Nov 15 22:37:09 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 15 Nov 2021 22:37:09 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v6] In-Reply-To: References: Message-ID: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Fix white space error - Allow apiguardian as dependency ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/7d56bcd0..c5b76ee8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=04-05 Stats: 15 lines in 2 files changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From almatvee at openjdk.java.net Tue Nov 16 02:24:11 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 16 Nov 2021 02:24:11 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: > - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8273096: Add support for H.265/HEVC to JavaFX Media [v3] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/649/files - new: https://git.openjdk.java.net/jfx/pull/649/files/62ba1ec8..6cb1ac5c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=00-01 Stats: 134 lines in 6 files changed: 113 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649 From almatvee at openjdk.java.net Tue Nov 16 02:28:34 2021 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 16 Nov 2021 02:28:34 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: <88j8FUI1oOiMIO5uf8I_77EoYbqpmPv1_TnwZk0KufU=.cf82fb37-f751-4081-95b5-0f35f3c50f50@github.com> On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] Added new patch. libswscale will be loaded dynamically on Linux for H.265/HEVC 10/12-bit. Playback will not fail for other formats if it is not present. Windows should play other formats without "HEVC Video Extensions" without any issues. Same for macOS. Following MediaException will be thrown on Linux if libswscale is not present. Output is from FXMediaPlayer. onError: MediaException: PLAYBACK_ERROR : [com.sun.media.jfxmediaimpl.platform.gstreamer.GSTMediaPlayer at a88d9ab] ERROR_MISSING_LIBSWSCALE: ERROR_MISSING_LIBSWSCALE ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From sykora at openjdk.java.net Tue Nov 16 13:53:39 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Tue, 16 Nov 2021 13:53:39 GMT Subject: RFR: 8276142: Update gradle to version 7.3 In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 18:27:06 GMT, Kevin Rushforth wrote: > This bumps the version of gradle used to build JavaFX to 7.3 (from the current 7.0.1). Among other things, gradle 7.3 adds support for JDK 17, so this is a prerequisite to update the boot JDK to JDK 17.x -- see [JDK-8276144](https://bugs.openjdk.java.net/browse/JDK-8276144). This will not affect the minimum version of gradle needed to build JavaFX, which remains at 6.3 (although that version requires an even older boot JDK than we currently use, so is not recommended). > > I included a `gradle/UPDATING.txt ` file to document the steps needed to update to a new version of gradle. > > NOTE: The boot JDK remains at 16.0.2 with this PR, but the intent is to update the boot JDK soon after this is integrated. To that end, I have created PR #670 as a Draft PR to bump the boot JDK to 17.0.1. It necessarily includes the fix from _this_ PR to update gradle to 7.3, otherwise the GitHub Actions build would have failed. You can look at the test results from that Draft PR to see that JDK 17.0.1 works when buliding with gradle 7.3. Builds and tests ran without issues on linux, mac and windows. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/671 From jvos at openjdk.java.net Tue Nov 16 13:53:40 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 16 Nov 2021 13:53:40 GMT Subject: RFR: 8276142: Update gradle to version 7.3 In-Reply-To: References: Message-ID: <-T1RW9ED07zHufLQ6hBFA7Dd-uLFQtx_X3GKyj9RtBw=.a24d2f71-d04e-442f-9627-90c81ba4f922@github.com> On Mon, 15 Nov 2021 18:27:06 GMT, Kevin Rushforth wrote: > This bumps the version of gradle used to build JavaFX to 7.3 (from the current 7.0.1). Among other things, gradle 7.3 adds support for JDK 17, so this is a prerequisite to update the boot JDK to JDK 17.x -- see [JDK-8276144](https://bugs.openjdk.java.net/browse/JDK-8276144). This will not affect the minimum version of gradle needed to build JavaFX, which remains at 6.3 (although that version requires an even older boot JDK than we currently use, so is not recommended). > > I included a `gradle/UPDATING.txt ` file to document the steps needed to update to a new version of gradle. > > NOTE: The boot JDK remains at 16.0.2 with this PR, but the intent is to update the boot JDK soon after this is integrated. To that end, I have created PR #670 as a Draft PR to bump the boot JDK to 17.0.1. It necessarily includes the fix from _this_ PR to update gradle to 7.3, otherwise the GitHub Actions build would have failed. You can look at the test results from that Draft PR to see that JDK 17.0.1 works when buliding with gradle 7.3. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/671 From kcr at openjdk.java.net Tue Nov 16 15:28:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Nov 2021 15:28:42 GMT Subject: Integrated: 8276142: Update gradle to version 7.3 In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 18:27:06 GMT, Kevin Rushforth wrote: > This bumps the version of gradle used to build JavaFX to 7.3 (from the current 7.0.1). Among other things, gradle 7.3 adds support for JDK 17, so this is a prerequisite to update the boot JDK to JDK 17.x -- see [JDK-8276144](https://bugs.openjdk.java.net/browse/JDK-8276144). This will not affect the minimum version of gradle needed to build JavaFX, which remains at 6.3 (although that version requires an even older boot JDK than we currently use, so is not recommended). > > I included a `gradle/UPDATING.txt ` file to document the steps needed to update to a new version of gradle. > > NOTE: The boot JDK remains at 16.0.2 with this PR, but the intent is to update the boot JDK soon after this is integrated. To that end, I have created PR #670 as a Draft PR to bump the boot JDK to 17.0.1. It necessarily includes the fix from _this_ PR to update gradle to 7.3, otherwise the GitHub Actions build would have failed. You can look at the test results from that Draft PR to see that JDK 17.0.1 works when buliding with gradle 7.3. This pull request has now been integrated. Changeset: 13c24d22 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/13c24d22463436bc953ec5159beec7a78017019f Stats: 227 lines in 7 files changed: 102 ins; 49 del; 76 mod 8276142: Update gradle to version 7.3 Reviewed-by: sykora, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/671 From kevin.rushforth at oracle.com Tue Nov 16 15:36:08 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 Nov 2021 07:36:08 -0800 Subject: Proposed schedule for JavaFX 18 Message-ID: Here is the proposed schedule for JavaFX 18. RDP1: Jan 13, 2022 (aka ?feature freeze?) RDP2: Feb 3, 2022 Freeze: Feb 24, 2022 GA: Mar 15, 2022 We plan to fork a jfx18 stabilization branch at RDP1. The GA date is one week ahead of JDK 18, matching what we did for 17. The start of RDP1, the start of RDP2, and the code freeze will be 16:00 UTC on the respective dates. Please let Johan or me know if you have any questions. -- Kevin From kcr at openjdk.java.net Tue Nov 16 15:38:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Nov 2021 15:38:09 GMT Subject: RFR: 8276144: Update boot JDK to 17.0.1 Message-ID: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> Now that JavaFX has updated to gradle 7.3 -- see [JDK-8276142](https://bugs.openjdk.java.net/browse/JDK-8276142) / PR #671 -- we can update the boot JDK used to build JavaFX to JDK 17.0.1. I have run a smoke test on all three platforms. I will run a full set of tests in parallel with the review. ------------- Commit messages: - 8276144: Update boot JDK to 17.0.1 Changes: https://git.openjdk.java.net/jfx/pull/670/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=670&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276144 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/670.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/670/head:pull/670 PR: https://git.openjdk.java.net/jfx/pull/670 From kcr at openjdk.java.net Tue Nov 16 22:36:38 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 16 Nov 2021 22:36:38 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] The recent changes for Linux look good to me. And thanks for confirming that it already works as expected for Windows and macOS. I'll put this back on my queue to review and test. ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From duke at openjdk.java.net Wed Nov 17 08:59:54 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Wed, 17 Nov 2021 08:59:54 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow Message-ID: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs There are currently 2 manual tests for this fix. ------------- Commit messages: - Update line ending for SelectTableViewTest - Update line ending - Add manual tests - 8197991: Selecting many items in a TableView is very slow Changes: https://git.openjdk.java.net/jfx/pull/673/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 256 lines in 4 files changed: 250 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/673/head:pull/673 PR: https://git.openjdk.java.net/jfx/pull/673 From aghaisas at openjdk.java.net Wed Nov 17 10:11:41 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 17 Nov 2021 10:11:41 GMT Subject: RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 09:44:47 GMT, Abhinay Agarwal wrote: > PathElements were skipped in AreaChart if the data point were outside axis bounds and had duplicate value for either x or y. This is now fixed with this PR. modules/javafx.controls/src/test/java/test/javafx/scene/chart/AreaChartTest.java line 187: > 185: } > 186: > 187: @Test public void testPathOutsideXBoundsWithDuplicateXAndLowerY() { I wonder whether we need another set of similar tests with X and Y interchanged? Something like - testPathOutsideYBoundsWithDuplicateYAndLowerX ------------- PR: https://git.openjdk.java.net/jfx/pull/667 From duke at openjdk.java.net Wed Nov 17 16:29:41 2021 From: duke at openjdk.java.net (Christian Heilmann) Date: Wed, 17 Nov 2021 16:29:41 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: <7psvBBkKDCQo8VUJPCE3CmreXLyr_d97fy0v-j81TnM=.d1ba2101-11d7-4e46-8175-97e657e2eb25@github.com> Message-ID: On Wed, 6 Oct 2021 20:18:33 GMT, Martin Fox wrote: >> @beldenfox Can you somehow add the test you talked about in a previous comment? It always helps to have a test that fails before and succeeds after. >> Let me know if you need help with this? > > @johanvos I've attached my test app to this comment. The test I was referring to is invoked using the `A-Z Test` button down at the bottom. The test just sends KeyCodes A-Z using the Robot and verifies that the expected KeyCodes and characters come back. > > > [KeyboardTest.txt](https://github.com/openjdk/jfx/files/7296937/KeyboardTest.txt) @beldenfox @johanvos I would kindly ask for any updates on this issue? For our customers frequently used keycombinations are broken for all non us keyboards. What can we do to bring this PR to a finished state? ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Wed Nov 17 16:37:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 17 Nov 2021 16:37:50 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. This is waiting on review from me (and others). I agree that it has been waiting for too long. It will take some time to review and, test, but I need to bump it up in priority. What will help is additional reviewers / testers to ensure no regressions. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From kcr at openjdk.java.net Thu Nov 18 00:29:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 00:29:52 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v4] In-Reply-To: <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> <0nkXdOP1Qvd8C_BbziQIQutPeBI7-AeCjVEmlVN0CYU=.544819c7-3a5a-4891-a995-2d40da4fa2b4@github.com> Message-ID: <7MTv4xA7q52-XAd4dHbDf0jZGH_JwD_l5RPPC76YQRU=.411c584f-461f-4d90-8108-b919b7e8c0c2@github.com> On Mon, 12 Apr 2021 08:34:25 GMT, yosbits wrote: >> https://bugs.openjdk.java.net/browse/JDK-8197991 >> >> The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. >> >> This greatly improves the response when selecting multiple items in ListView and TableView. >> >> However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). >> >> Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) >> >> ListView >> * selectAll: 400_000-> 10_000_000 >> * selectRange: 7_000-> 70_000 >> >> TableView >> * selectAll: 8_000-> 700_000 >> * selectRange: 7_000-> 50_000 >> >> >> You can see performance improvements in the following applications: >> >> >> ``` SelectListViewTest.java >> import javafx.application.Application; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.ListView; >> import javafx.scene.control.SelectionMode; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class SelectListViewTest extends Application { >> final int ROW_COUNT = 70_000; >> // final int ROW_COUNT = 400_000; >> // final int ROW_COUNT = 10_000_000; >> // final int ROW_COUNT = 7_000; >> >> @Override >> public void start(Stage stage) { >> ListView listView = new ListView<>(); >> listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> >> >> ObservableList items = listView.getItems(); >> for(int i=0; i> String rec = String.valueOf(i); >> items.add(rec); >> } >> BorderPane root = new BorderPane(listView); >> Button selectAll = new Button("selectAll"); >> Button clearSelection = new Button("clearSelection"); >> Button selectToStart = new Button("selectToStart"); >> Button selectToEnd = new Button("selectToEnd"); >> Button selectPrevious = new Button("selectPrevious"); >> Button selectNext= new Button("selectNext"); >> >> selectAll.setFocusTraversable(true); >> clearSelection.setFocusTraversable(true); >> selectToStart.setFocusTraversable(true); >> selectToEnd.setFocusTraversable(true); >> selectPrevious.setFocusTraversable(true); >> selectNext.setFocusTraversable(true); >> >> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); >> stage.setScene(new Scene(root, 600, 600)); >> >> selectAll.setOnAction((e)->selectAll(listView)); >> clearSelection.setOnAction((e)->clearSelection(listView)); >> selectToStart.setOnAction((e)->selectToStart(listView)); >> selectToEnd.setOnAction((e)->selectToLast(listView)); >> selectPrevious.setOnAction((e)->selectPrevious(listView)); >> selectNext.setOnAction((e)->selectNext(listView)); >> >> stage.show(); >> } >> >> private void selectAll(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectAll(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void clearSelection(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().clearSelection(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToStart(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToLast(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectPrevious(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectPrevious(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectNext(ListView listView) { >> long t = System.currentTimeMillis(); >> listView.getSelectionModel().selectNext(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> public static void main(String[] args) { >> Application.launch(args); >> } >> } >> >> >> ``` SelectTableViewTest.java >> import javafx.application.Application; >> import javafx.beans.property.SimpleStringProperty; >> import javafx.collections.ObservableList; >> import javafx.scene.Scene; >> import javafx.scene.control.Button; >> import javafx.scene.control.SelectionMode; >> import javafx.scene.control.TableColumn; >> import javafx.scene.control.TableView; >> import javafx.scene.layout.BorderPane; >> import javafx.scene.layout.VBox; >> import javafx.stage.Stage; >> >> public class SelectTableViewTest extends Application { >> >> final int ROW_COUNT = 700_000; >> // final int ROW_COUNT = 80_000; >> // final int ROW_COUNT = 50_000; >> // final int ROW_COUNT = 8_000; >> final int COL_COUNT = 3; >> >> @Override >> public void start(Stage stage) { >> TableView tableView = new TableView<>(); >> tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); >> // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); >> >> final ObservableList> columns = tableView.getColumns(); >> for(int i=0; i> TableColumn column = new TableColumn<>("Col"+i); >> final int colIndex=i; >> column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); >> column.setPrefWidth(150); >> columns.add(column); >> } >> >> ObservableList items = tableView.getItems(); >> for(int i=0; i> String[] rec = new String[COL_COUNT]; >> for(int j=0; j> rec[j] = i+":"+j; >> } >> items.add(rec); >> } >> BorderPane root = new BorderPane(tableView); >> Button selectAll = new Button("selectAll"); >> Button clearSelection = new Button("clearSelection"); >> Button selectToStart = new Button("selectToStart"); >> Button selectToEnd = new Button("selectToEnd"); >> Button selectPrevious = new Button("selectPrevious"); >> Button selectNext= new Button("selectNext"); >> >> selectAll.setFocusTraversable(true); >> clearSelection.setFocusTraversable(true); >> selectToStart.setFocusTraversable(true); >> selectToEnd.setFocusTraversable(true); >> selectPrevious.setFocusTraversable(true); >> selectNext.setFocusTraversable(true); >> >> root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); >> stage.setScene(new Scene(root, 600, 600)); >> >> selectAll.setOnAction((e)->selectAll(tableView)); >> clearSelection.setOnAction((e)->clearSelection(tableView)); >> selectToStart.setOnAction((e)->selectToStart(tableView)); >> selectToEnd.setOnAction((e)->selectToLast(tableView)); >> selectPrevious.setOnAction((e)->selectPrevious(tableView)); >> selectNext.setOnAction((e)->selectNext(tableView)); >> >> stage.show(); >> } >> >> private void selectAll(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectAll(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void clearSelection(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().clearSelection(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToStart(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> private void selectToLast(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectPrevious(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectPrevious(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> private void selectNext(TableView tableView) { >> long t = System.currentTimeMillis(); >> tableView.getSelectionModel().selectNext(); >> System.out.println("time:"+ (System.currentTimeMillis() - t)); >> } >> >> public static void main(String[] args) { >> Application.launch(args); >> } >> } > > yosbits has updated the pull request incrementally. The work in this PR has been picked up by @abhinayagarwal in PR #673 so I am closing this one. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From kcr at openjdk.java.net Thu Nov 18 00:29:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 00:29:52 GMT Subject: Withdrawn: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> References: <0oBe9C3p7-nZQK5-8QlpBCzj1ojBXu2Tlkoc8SEx-qE=.b4808aeb-6fea-45a6-bdd8-6f06c36e9428@github.com> Message-ID: <7VE0xuOBVZ68sulmLFM4fxDw-gbxO6KutNy6VHCxptI=.4f69391b-ec34-4973-b0c6-bfecf49d0702@github.com> On Wed, 26 Feb 2020 07:37:06 GMT, yosbits wrote: > https://bugs.openjdk.java.net/browse/JDK-8197991 > > The performance of the selectAll and selectRange methods of the MultiSelectionModel class has been greatly improved. > > This greatly improves the response when selecting multiple items in ListView and TableView. > > However, in TreeView / TreeTableView, the improvement effect is hidden mainly due to the design problem of the cache of TreeUtil.getTreeItem (). > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > ListView > * selectAll: 400_000-> 10_000_000 > * selectRange: 7_000-> 70_000 > > TableView > * selectAll: 8_000-> 700_000 > * selectRange: 7_000-> 50_000 > > > You can see performance improvements in the following applications: > > > ``` SelectListViewTest.java > import javafx.application.Application; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.ListView; > import javafx.scene.control.SelectionMode; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; > > @Override > public void start(Stage stage) { > ListView listView = new ListView<>(); > listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > > > ObservableList items = listView.getItems(); > for(int i=0; i String rec = String.valueOf(i); > items.add(rec); > } > BorderPane root = new BorderPane(listView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(listView)); > clearSelection.setOnAction((e)->clearSelection(listView)); > selectToStart.setOnAction((e)->selectToStart(listView)); > selectToEnd.setOnAction((e)->selectToLast(listView)); > selectPrevious.setOnAction((e)->selectPrevious(listView)); > selectNext.setOnAction((e)->selectNext(listView)); > > stage.show(); > } > > private void selectAll(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(0, listView.getSelectionModel().getSelectedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectRange(listView.getSelectionModel().getSelectedIndex(), listView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(ListView listView) { > long t = System.currentTimeMillis(); > listView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > public static void main(String[] args) { > Application.launch(args); > } > } > > > ``` SelectTableViewTest.java > import javafx.application.Application; > import javafx.beans.property.SimpleStringProperty; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Button; > import javafx.scene.control.SelectionMode; > import javafx.scene.control.TableColumn; > import javafx.scene.control.TableView; > import javafx.scene.layout.BorderPane; > import javafx.scene.layout.VBox; > import javafx.stage.Stage; > > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; > > @Override > public void start(Stage stage) { > TableView tableView = new TableView<>(); > tableView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE); > // tableView.getSelectionModel().setSelectionMode(SelectionMode.SINGLE); > > final ObservableList> columns = tableView.getColumns(); > for(int i=0; i TableColumn column = new TableColumn<>("Col"+i); > final int colIndex=i; > column.setCellValueFactory((cell)->new SimpleStringProperty(cell.getValue()[colIndex])); > column.setPrefWidth(150); > columns.add(column); > } > > ObservableList items = tableView.getItems(); > for(int i=0; i String[] rec = new String[COL_COUNT]; > for(int j=0; j rec[j] = i+":"+j; > } > items.add(rec); > } > BorderPane root = new BorderPane(tableView); > Button selectAll = new Button("selectAll"); > Button clearSelection = new Button("clearSelection"); > Button selectToStart = new Button("selectToStart"); > Button selectToEnd = new Button("selectToEnd"); > Button selectPrevious = new Button("selectPrevious"); > Button selectNext= new Button("selectNext"); > > selectAll.setFocusTraversable(true); > clearSelection.setFocusTraversable(true); > selectToStart.setFocusTraversable(true); > selectToEnd.setFocusTraversable(true); > selectPrevious.setFocusTraversable(true); > selectNext.setFocusTraversable(true); > > root.setRight(new VBox(6, selectAll, selectToStart, selectToEnd, selectPrevious, selectNext, clearSelection)); > stage.setScene(new Scene(root, 600, 600)); > > selectAll.setOnAction((e)->selectAll(tableView)); > clearSelection.setOnAction((e)->clearSelection(tableView)); > selectToStart.setOnAction((e)->selectToStart(tableView)); > selectToEnd.setOnAction((e)->selectToLast(tableView)); > selectPrevious.setOnAction((e)->selectPrevious(tableView)); > selectNext.setOnAction((e)->selectNext(tableView)); > > stage.show(); > } > > private void selectAll(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectAll(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void clearSelection(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().clearSelection(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToStart(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(0, tableView.getSelectionModel().getFocusedIndex()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > private void selectToLast(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectRange(tableView.getSelectionModel().getFocusedIndex(), tableView.getItems().size()); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectPrevious(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectPrevious(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > private void selectNext(TableView tableView) { > long t = System.currentTimeMillis(); > tableView.getSelectionModel().selectNext(); > System.out.println("time:"+ (System.currentTimeMillis() - t)); > } > > public static void main(String[] args) { > Application.launch(args); > } > } This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx/pull/127 From kcr at openjdk.java.net Thu Nov 18 00:30:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 00:30:46 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. I closed #127 on which this PR is based. @abhinayagarwal Please use the `/contributor` command to add @yososs as a contributor. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From nlisker at openjdk.java.net Thu Nov 18 00:58:44 2021 From: nlisker at openjdk.java.net (Nir Lisker) Date: Thu, 18 Nov 2021 00:58:44 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java line 119: > 117: Object obj = get(i); > 118: if (o.equals(obj)) return i; > 119: } An alternative is return IntStream.range(0, size()) .filter(i -> o.equals(get(i))) .findFirst() .orElse(-1); I don't know if it helps. modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java line 193: > 191: arr[i] = get(i); > 192: } > 193: return arr; Have you tried `return stream().toArray();`? ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From mhanl at openjdk.java.net Thu Nov 18 08:55:40 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Thu, 18 Nov 2021 08:55:40 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. Just wondering, isn't it also possible to write some unit tests for the MultipleSelectionModel(Base) ? ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From tschindl at openjdk.java.net Thu Nov 18 09:08:44 2021 From: tschindl at openjdk.java.net (Tom Schindl) Date: Thu, 18 Nov 2021 09:08:44 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Thu, 18 Nov 2021 00:55:18 GMT, Nir Lisker wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java line 119: > >> 117: Object obj = get(i); >> 118: if (o.equals(obj)) return i; >> 119: } > > An alternative is > > return IntStream.range(0, size()) > .filter(i -> o.equals(get(i))) > .findFirst() > .orElse(-1); > > I don't know if it helps. the for-loop is certainly faster and would allocate less memory - i find the `for(int i = 0, max = size())`-style a bit odd ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Thu Nov 18 17:02:19 2021 From: duke at openjdk.java.net (Andreas Heger) Date: Thu, 18 Nov 2021 17:02:19 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: > By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/666/files - new: https://git.openjdk.java.net/jfx/pull/666/files/c499d948..dad95b14 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=666&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=666&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/666.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/666/head:pull/666 PR: https://git.openjdk.java.net/jfx/pull/666 From duke at openjdk.java.net Thu Nov 18 17:12:54 2021 From: duke at openjdk.java.net (Andreas Heger) Date: Thu, 18 Nov 2021 17:12:54 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 13:37:37 GMT, Kevin Rushforth wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Did you build WebKit and media with this fix? This might be an OK stop gap, but a more permanent solution would probably be to automatically set `TARGET_ARCH` to `arm64` when `OS_ARCH` is set to `aarch64`. @kevinrushforth > Did you build WebKit and media with this fix? This might be an OK stop gap, but a more permanent solution would probably be to automatically set `TARGET_ARCH` to `arm64` when `OS_ARCH` is set to `aarch64`. You are right, WebKit and media did not build with the original fix, so I now changed the build.gradle file to set the `TARGET_ARCH`to `arm64`on Macs with `OS_ARCH`== `aarch64`. All modules can be build now. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Thu Nov 18 17:15:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 17:15:46 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines Thanks for the confirmation. I'll test it, and either @johanvos or @tiainen will need to do so as well. It will be great to not have to manually set `TARGET_ARCH`. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Thu Nov 18 17:35:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 17:35:49 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines Btw, I changed the title of the JBS issue to `JavaFX build fails on macOS aarch64`. Can you change the PR title to match? ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From jhendrikx at openjdk.java.net Thu Nov 18 21:04:15 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Thu, 18 Nov 2021 21:04:15 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue Message-ID: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. **Flexible Mappings** Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. **Lazy** The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) **Null Safe** The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. Some examples: void mapProperty() { // Standard JavaFX: label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); // Fluent: much more compact, no need to handle null label.textProperty().bind(text.map(String::toUpperCase)); } void calculateCharactersLeft() { // Standard JavaFX: label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); // Fluent: slightly more compact and more clear (no negate needed) label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); } void mapNestedValue() { // Standard JavaFX: label.textProperty().bind(Bindings.createStringBinding( () -> employee.get() == null ? "" : employee.get().getCompany() == null ? "" : employee.get().getCompany().getName(), employee )); // Fluent: no need to handle nulls everywhere label.textProperty().bind( employee.map(Employee::getCompany) .map(Company::getName) .orElse("") ); } void mapNestedProperty() { // Standard JavaFX: label.textProperty().bind( Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) .then("Visible") .otherwise("Not Visible") ); // Fluent: type safe label.textProperty().bind(label.sceneProperty() .flatMap(Scene::windowProperty) .flatMap(Window::showingProperty) .orElse(false) .map(showing -> showing ? "Visible" : "Not Visible") ); } Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. ------------- Commit messages: - Initial proposal Changes: https://git.openjdk.java.net/jfx/pull/675/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=675&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274771 Stats: 1501 lines in 11 files changed: 1498 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/675.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/675/head:pull/675 PR: https://git.openjdk.java.net/jfx/pull/675 From kcr at openjdk.java.net Thu Nov 18 21:24:51 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 21:24:51 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines With this patch I am able to build without setting `TARGET_ARCH`. Everything looks like it is working except that the architecture is still coming up as "x86_64" for the WebKit binaries. This looks like a preexisting problem that might have something to do with my development environment. @johanvos Do you need to use any special flags today when you build WebKit on M1? ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Thu Nov 18 21:41:44 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 18 Nov 2021 21:41:44 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue In-Reply-To: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: On Thu, 18 Nov 2021 20:58:06 GMT, John Hendrikx wrote: > This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. > > This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. > > **Flexible Mappings** > Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. > > **Lazy** > The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) > > **Null Safe** > The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. > > Some examples: > > void mapProperty() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); > > // Fluent: much more compact, no need to handle null > label.textProperty().bind(text.map(String::toUpperCase)); > } > > void calculateCharactersLeft() { > // Standard JavaFX: > label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); > > // Fluent: slightly more compact and more clear (no negate needed) > label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); > } > > void mapNestedValue() { > // Standard JavaFX: > label.textProperty().bind(Bindings.createStringBinding( > () -> employee.get() == null ? "" > : employee.get().getCompany() == null ? "" > : employee.get().getCompany().getName(), > employee > )); > > // Fluent: no need to handle nulls everywhere > label.textProperty().bind( > employee.map(Employee::getCompany) > .map(Company::getName) > .orElse("") > ); > } > > void mapNestedProperty() { > // Standard JavaFX: > label.textProperty().bind( > Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) > .then("Visible") > .otherwise("Not Visible") > ); > > // Fluent: type safe > label.textProperty().bind(label.sceneProperty() > .flatMap(Scene::windowProperty) > .flatMap(Window::showingProperty) > .orElse(false) > .map(showing -> showing ? "Visible" : "Not Visible") > ); > } > > Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. This will need an API review followed by an implementation review. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From sykora at openjdk.java.net Fri Nov 19 09:12:50 2021 From: sykora at openjdk.java.net (Joeri Sykora) Date: Fri, 19 Nov 2021 09:12:50 GMT Subject: RFR: 8276144: Update boot JDK to 17.0.1 In-Reply-To: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> References: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> Message-ID: On Mon, 15 Nov 2021 18:26:00 GMT, Kevin Rushforth wrote: > Now that JavaFX has updated to gradle 7.3 -- see [JDK-8276142](https://bugs.openjdk.java.net/browse/JDK-8276142) / PR #671 -- we can update the boot JDK used to build JavaFX to JDK 17.0.1. > > I have run a smoke test on all three platforms. > > I will run a full set of tests in parallel with the review. All builds ran successfully. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/670 From aghaisas at openjdk.java.net Fri Nov 19 10:01:49 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 19 Nov 2021 10:01:49 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v2] In-Reply-To: References: <8ZHb9oNuP9ws90xV_5LUV3kDDjPluqZy4FFwnIZCj5U=.b55bd50b-5fdf-4097-9c68-1225263f3111@github.com> Message-ID: On Mon, 15 Nov 2021 13:28:40 GMT, Jeanette Winzenburg wrote: >> My PR is already merged, so this is not a problem. :) >> I dont know, but since this is only fixing a (also before) wrong comment it might be okay as it is very minor? :) > > FYI: now the listener registration - including the incorrect code comment (which is the same as in current master) - is back at the old location in the re-inserted setupTreeTableViewListeners. So still need input whether it's okay to correct the code comment here. I think, it is okay to fix the comment in this review itself. It is very minor to warrant a separate PR. Also, this anomaly was discovered in this review makes it a candidate to be fixed here. ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From aghaisas at openjdk.java.net Fri Nov 19 10:01:48 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 19 Nov 2021 10:01:48 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v4] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 13:11:06 GMT, Jeanette Winzenburg wrote: >> Cleanup of Tree-/TableRowSkin to support switching skins >> >> The misbehavior/s >> - memory leaks due to manually registered listeners that were not removed >> - side-effects due to listeners still active on old skin (like NPEs) >> >> Fix >> - use skin api for all listener registration (for automatic removal in dispose) >> - ~~do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))~~ not handled here, see [JDK-8277000](https://bugs.openjdk.java.net/browse/JDK-8277000) >> >> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. >> >> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > reverted fixedCellSize handling Overall the fix looks OK. I have 2 minor comments. modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableSkinShim.java line 2: > 1: /* > 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. 2021 :) ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From jvos at openjdk.java.net Fri Nov 19 10:25:49 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 19 Nov 2021 10:25:49 GMT Subject: RFR: 8276144: Update boot JDK to 17.0.1 In-Reply-To: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> References: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> Message-ID: On Mon, 15 Nov 2021 18:26:00 GMT, Kevin Rushforth wrote: > Now that JavaFX has updated to gradle 7.3 -- see [JDK-8276142](https://bugs.openjdk.java.net/browse/JDK-8276142) / PR #671 -- we can update the boot JDK used to build JavaFX to JDK 17.0.1. > > I have run a smoke test on all three platforms. > > I will run a full set of tests in parallel with the review. Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/670 From jvos at openjdk.java.net Fri Nov 19 10:41:51 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 19 Nov 2021 10:41:51 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: <1TR4rmkrAQiPdHmo0eQnh8A9ZqK4Gi2FkuysCtZiz0I=.37605026-ed1c-4622-add7-080b3fd27127@github.com> On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines We also pass -PTARGET_ARCH=arm64 when invoking gradlew. We don't have specific flags that we pass to build webkit, so having the TARGET_ARCH set to arm64 in one way or another should be sufficient. I'm not sure about the best place for this. When this was done in OpenJDK, the arch-information would be supplied to `configure.sh` and the makefiles would be generated with the correct flags. The build files don't have to be touched. In our case, we have the configuration + build logic in one file (build.gradle) which is imho a bit more confusing. Therefore, rather than doing configuration-related processing in the build.gradle file, I personally prefer to keep the configuration separately (e.g. by passing arch flags on the commandline). We also have platform-specific gradle files, but they are used for a mix of configuration and build logic either, so that won't help. I'm not really against putting this in the build.gradle file though, if that makes building easier for others. But it doesn't improve the readability of that file. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From fastegal at openjdk.java.net Fri Nov 19 11:42:16 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 19 Nov 2021 11:42:16 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v5] In-Reply-To: References: Message-ID: > Cleanup of Tree-/TableRowSkin to support switching skins > > The misbehavior/s > - memory leaks due to manually registered listeners that were not removed > - side-effects due to listeners still active on old skin (like NPEs) > > Fix > - use skin api for all listener registration (for automatic removal in dispose) > - ~~do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))~~ not handled here, see [JDK-8277000](https://bugs.openjdk.java.net/browse/JDK-8277000) > > Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. > > Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: changes as requested in review ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/632/files - new: https://git.openjdk.java.net/jfx/pull/632/files/603b08af..801182ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/632.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/632/head:pull/632 PR: https://git.openjdk.java.net/jfx/pull/632 From fastegal at openjdk.java.net Fri Nov 19 11:42:17 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 19 Nov 2021 11:42:17 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v2] In-Reply-To: References: <8ZHb9oNuP9ws90xV_5LUV3kDDjPluqZy4FFwnIZCj5U=.b55bd50b-5fdf-4097-9c68-1225263f3111@github.com> Message-ID: On Fri, 19 Nov 2021 09:45:06 GMT, Ajit Ghaisas wrote: >> FYI: now the listener registration - including the incorrect code comment (which is the same as in current master) - is back at the old location in the re-inserted setupTreeTableViewListeners. So still need input whether it's okay to correct the code comment here. > > I think, it is okay to fix the comment in this review itself. It is very minor to warrant a separate PR. Also, this anomaly was discovered in this review makes it a candidate to be fixed here. done - thanks to both of you :) ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From fastegal at openjdk.java.net Fri Nov 19 11:42:21 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 19 Nov 2021 11:42:21 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v4] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 09:24:42 GMT, Ajit Ghaisas wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: >> >> reverted fixedCellSize handling > > modules/javafx.controls/src/shims/java/javafx/scene/control/skin/TableSkinShim.java line 2: > >> 1: /* >> 2: * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > > 2021 :) lost a year to the pandemic ;) ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From jhendrikx at openjdk.java.net Fri Nov 19 11:55:53 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Fri, 19 Nov 2021 11:55:53 GMT Subject: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue In-Reply-To: References: <58kPGdpiUxl_VI2zHBeNor49Ky6Ii1X4VRX-vwc7NMI=.ba57e3f7-0e79-42b1-a2aa-4f096ff4e604@github.com> Message-ID: <3kh48MwMKNaxabNeIausDCZBCU5wjsXCVAi58IDMoes=.3f8729db-99aa-4e0a-b31e-870280681df1@github.com> On Thu, 18 Nov 2021 21:38:28 GMT, Kevin Rushforth wrote: >> This is an implementation of the proposal in https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker (@nlisker) have been working on. It's a complete implementation including good test coverage. >> >> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller API footprint. Compared to the PoC this is lacking public API for subscriptions, and does not include `orElseGet` or the `conditionOn` conditional mapping. >> >> **Flexible Mappings** >> Map the contents of a property any way you like with `map`, or map nested properties with `flatMap`. >> >> **Lazy** >> The bindings created are lazy, which means they are always _invalid_ when not themselves observed. This allows for easier garbage collection (once the last observer is removed, a chain of bindings will stop observing their parents) and less listener management when dealing with nested properties. Furthermore, this allows inclusion of such bindings in classes such as `Node` without listeners being created when the binding itself is not used (this would allow for the inclusion of a `treeShowingProperty` in `Node` without creating excessive listeners, see this fix I did in an earlier PR: https://github.com/openjdk/jfx/pull/185) >> >> **Null Safe** >> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional` when the value they would be mapping is `null`. This makes mapping nested properties with `flatMap` trivial as the `null` case does not need to be taken into account in a chain like this: `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`. Instead a default can be provided with `orElse`. >> >> Some examples: >> >> void mapProperty() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding(() -> text.getValueSafe().toUpperCase(), text)); >> >> // Fluent: much more compact, no need to handle null >> label.textProperty().bind(text.map(String::toUpperCase)); >> } >> >> void calculateCharactersLeft() { >> // Standard JavaFX: >> label.textProperty().bind(text.length().negate().add(100).asString().concat(" characters left")); >> >> // Fluent: slightly more compact and more clear (no negate needed) >> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() + " characters left")); >> } >> >> void mapNestedValue() { >> // Standard JavaFX: >> label.textProperty().bind(Bindings.createStringBinding( >> () -> employee.get() == null ? "" >> : employee.get().getCompany() == null ? "" >> : employee.get().getCompany().getName(), >> employee >> )); >> >> // Fluent: no need to handle nulls everywhere >> label.textProperty().bind( >> employee.map(Employee::getCompany) >> .map(Company::getName) >> .orElse("") >> ); >> } >> >> void mapNestedProperty() { >> // Standard JavaFX: >> label.textProperty().bind( >> Bindings.when(Bindings.selectBoolean(label.sceneProperty(), "window", "showing")) >> .then("Visible") >> .otherwise("Not Visible") >> ); >> >> // Fluent: type safe >> label.textProperty().bind(label.sceneProperty() >> .flatMap(Scene::windowProperty) >> .flatMap(Window::showingProperty) >> .orElse(false) >> .map(showing -> showing ? "Visible" : "Not Visible") >> ); >> } >> >> Note that this is based on ideas in ReactFX and my own experiments in https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion that this is much better directly integrated into JavaFX, and I'm hoping this proof of concept will be able to move such an effort forward. > > This will need an API review followed by an implementation review. @kevinrushforth I've created the CSR here: https://bugs.openjdk.java.net/browse/JDK-8277456 -- it is my first CSR, if you any feedback on it I'd appreciate it. ------------- PR: https://git.openjdk.java.net/jfx/pull/675 From aghaisas at openjdk.java.net Fri Nov 19 12:36:48 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 19 Nov 2021 12:36:48 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v5] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 11:42:16 GMT, Jeanette Winzenburg wrote: >> Cleanup of Tree-/TableRowSkin to support switching skins >> >> The misbehavior/s >> - memory leaks due to manually registered listeners that were not removed >> - side-effects due to listeners still active on old skin (like NPEs) >> >> Fix >> - use skin api for all listener registration (for automatic removal in dispose) >> - ~~do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))~~ not handled here, see [JDK-8277000](https://bugs.openjdk.java.net/browse/JDK-8277000) >> >> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. >> >> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changes as requested in review Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From aghaisas at openjdk.java.net Fri Nov 19 12:39:38 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 19 Nov 2021 12:39:38 GMT Subject: RFR: 8276144: Update boot JDK to 17.0.1 In-Reply-To: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> References: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> Message-ID: On Mon, 15 Nov 2021 18:26:00 GMT, Kevin Rushforth wrote: > Now that JavaFX has updated to gradle 7.3 -- see [JDK-8276142](https://bugs.openjdk.java.net/browse/JDK-8276142) / PR #671 -- we can update the boot JDK used to build JavaFX to JDK 17.0.1. > > I have run a smoke test on all three platforms. > > I will run a full set of tests in parallel with the review. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/670 From fastegal at openjdk.java.net Fri Nov 19 12:44:46 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 19 Nov 2021 12:44:46 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout In-Reply-To: References: Message-ID: <-oozo6iPMsvA--pocHeuxIOkGsO8f49n7msrUPewq50=.0f61fb69-e48e-4690-904a-21c36a1163a1@github.com> On Mon, 15 Nov 2021 14:34:04 GMT, Marius Hanl wrote: > When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. > While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. > > This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) > > -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. > > This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). > > Note: I also fixed a simple typo of a private method in SplitPaneSkin: > initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers interesting issue - and fix :) Verified the mis-behaviour before the fix and its working after. Wondering, though (read: I don't understand ??) - why the layout details in the splitpane hinders the visual update of a completely unrelated component (like the combo)? - why does it only happen on increasing the divider pos, not on decreasing? As to the test: would prefer to also see a test of the fixed effect (vs. the fix implementation of not re-entering layout) - might be a bit tricky, though. ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From kcr at openjdk.java.net Fri Nov 19 13:15:50 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Nov 2021 13:15:50 GMT Subject: Integrated: 8276144: Update boot JDK to 17.0.1 In-Reply-To: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> References: <1bOjG0jOxTH7Pgrx2SaZWwem7tmB9sJwSOZ_3LPIZ14=.551a2359-49cf-4f2e-81c5-787f11b0afb1@github.com> Message-ID: <3RMzkoDqnyDERjgjbmpMqoiFSOUcUkqIeAcHv2QIsJc=.fbecff55-993c-439c-957a-ccb310c2dd52@github.com> On Mon, 15 Nov 2021 18:26:00 GMT, Kevin Rushforth wrote: > Now that JavaFX has updated to gradle 7.3 -- see [JDK-8276142](https://bugs.openjdk.java.net/browse/JDK-8276142) / PR #671 -- we can update the boot JDK used to build JavaFX to JDK 17.0.1. > > I have run a smoke test on all three platforms. > > I will run a full set of tests in parallel with the review. This pull request has now been integrated. Changeset: 27dce0ad Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/27dce0adebcecaeaf5bbb44d627931bc472cc502 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod 8276144: Update boot JDK to 17.0.1 Reviewed-by: sykora, jvos, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/670 From kcr at openjdk.java.net Fri Nov 19 13:45:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Nov 2021 13:45:43 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines Marked as reviewed by kcr (Lead). Given the current build structure, it seems better to have this in `build.gradle`. For all other cases, the processor arch of the boot JDK is used as the default target architecture. For macOS it tries to do the same thing, but we need to do a mapping on macOS from aarch64 --> arm64 when passing the flag to the clang compiler since there is otherwise a mismatch. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Fri Nov 19 13:45:43 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Nov 2021 13:45:43 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: <1TR4rmkrAQiPdHmo0eQnh8A9ZqK4Gi2FkuysCtZiz0I=.37605026-ed1c-4622-add7-080b3fd27127@github.com> References: <1TR4rmkrAQiPdHmo0eQnh8A9ZqK4Gi2FkuysCtZiz0I=.37605026-ed1c-4622-add7-080b3fd27127@github.com> Message-ID: On Fri, 19 Nov 2021 10:39:05 GMT, Johan Vos wrote: > We don't have specific flags that we pass to build webkit, so having the TARGET_ARCH set to arm64 in one way or another should be sufficient. I'll check my build environment and file a follow-up issue if needed. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From jvos at openjdk.java.net Fri Nov 19 14:10:45 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 19 Nov 2021 14:10:45 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: <-3fWhC6VJJp0CvIwLi-2Sc6cAYFNb3ZW1-baxTu8_hY=.8d522ec4-c8a6-4c29-b561-6665af6ff327@github.com> On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines Approved with the comment that I don't think the TARGET_ARCH should be modified in a build script, but since this is the current setup, it is probably the most pragmatic approach. I had a look how it is done in the JDK (flags.m4) if test "x$OPENJDK_TARGET_OS" = xmacosx; then if test "x$OPENJDK_TARGET_CPU" = xaarch64; then MACHINE_FLAG="$MACHINE_FLAG -arch arm64" The TARGET_CPU is never changed, and the MACHINE_FLAG is the one being passed to the compiler. That looks cleaner to me. I would prefer to have a single value of TARGET_CPU that is the same for Linux/AArch64, macOS/AArch64 and win/AArch64, but since we already semantic overloading in build.gradle, I won't object the current change. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Fri Nov 19 14:29:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Nov 2021 14:29:49 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: <-3fWhC6VJJp0CvIwLi-2Sc6cAYFNb3ZW1-baxTu8_hY=.8d522ec4-c8a6-4c29-b561-6665af6ff327@github.com> References: <-3fWhC6VJJp0CvIwLi-2Sc6cAYFNb3ZW1-baxTu8_hY=.8d522ec4-c8a6-4c29-b561-6665af6ff327@github.com> Message-ID: On Fri, 19 Nov 2021 14:06:28 GMT, Johan Vos wrote: > The TARGET_CPU is never changed, and the MACHINE_FLAG is the one being passed to the compiler. This does seem a cleaner approach. I'll file a follow-on issue to track this (which wouldn't just be limited to macOS). ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Fri Nov 19 14:38:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 19 Nov 2021 14:38:46 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics [v2] In-Reply-To: References: Message-ID: <7xmbhIfRwgGDiCWNYDliN_uOcRRcA0xS3XG0WvR9MrM=.9844cdd7-a4d9-4147-bdc8-6754019e4b6a@github.com> On Thu, 18 Nov 2021 17:02:19 GMT, Andreas Heger wrote: >> By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? > > Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: > > 8276174: Set default TARGET_ARCH to "arm64" on apple silicon machines I filed the follow-up issue: [JDK-8277479](https://bugs.openjdk.java.net/browse/JDK-8277479): JavaFX build should define a new flag and not override TARGET_ARCH ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Sat Nov 20 14:46:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Nov 2021 14:46:07 GMT Subject: RFR: 8276174: Build failure on MacBook Air (M1) in JFX component graphics In-Reply-To: References: Message-ID: On Thu, 18 Nov 2021 17:09:47 GMT, Andreas Heger wrote: >> Did you build WebKit and media with this fix? This might be an OK stop gap, but a more permanent solution would probably be to automatically set `TARGET_ARCH` to `arm64` when `OS_ARCH` is set to `aarch64`. > > @kevinrushforth >> Did you build WebKit and media with this fix? This might be an OK stop gap, but a more permanent solution would probably be to automatically set `TARGET_ARCH` to `arm64` when `OS_ARCH` is set to `aarch64`. > > You are right, WebKit and media did not build with the original fix, so I now changed the build.gradle file to set the `TARGET_ARCH`to `arm64`on Macs with `OS_ARCH`== `aarch64`. All modules can be build now. @andreas-heger Once you fix the title of this PR to match the updated JBS title, you can `/integrate` this. Either Johan or I will sponsor it. ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Sat Nov 20 16:03:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Nov 2021 16:03:13 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v6] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 22:37:09 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Fix white space error > - Allow apiguardian as dependency I was able to do a build / test on my local build machine using locally cached jar files. In order for this to work, I needed to add an explicit list of dependencies in `build.gradle`. See comments inline. Once you make the requested updates, I'll do a CI test build. build.gradle line 1948: > 1946: dependencies { > 1947: testImplementation group: "junit", name: "junit", version: "4.13.2" > 1948: testImplementation group: "org.junit.jupiter", name: "junit-jupiter", version: "5.8.1" We need an explicit list of dependencies here, rather than relying on the maven pom files to bring them in. This is needed for our internal builds where we only host a snapshot of the jar files and not the pom files. Also, it better documents the dependencies. After adding the following to my local build, it all works now: testImplementation group: "org.junit.jupiter", name: "junit-jupiter-api", version: "5.8.1" testImplementation group: "org.hamcrest", name: "hamcrest-core", version: "1.3" testRuntimeOnly group: "org.junit.jupiter", name: "junit-jupiter-engine", version: "5.8.1" testRuntimeOnly group: "org.junit.jupiter", name: "junit-jupiter-params", version: "5.8.1" testRuntimeOnly group: "org.junit.platform", name: "junit-platform-commons", version: "1.8.1" testRuntimeOnly group: "org.junit.platform", name: "junit-platform-engine", version: "1.8.1" testRuntimeOnly group: "org.apiguardian", name: "apiguardian-api", version: "1.1.2" testRuntimeOnly group: "org.opentest4j", name: "opentest4j", version: "1.2.0" build.gradle line 1951: > 1949: testRuntimeOnly group: "org.junit.vintage", name: "junit-vintage-engine", version: "5.8.1" > 1950: > 1951: if (BUILD_CLOSED && DO_JCOV) { Minor: you added an extra space of indentation (which is why this line is showing up in the diff). build.gradle line 2041: > 2039: > 2040: dependencies { > 2041: testImplementation group: "junit", name: "junit", version: "4.13.2" This isn't needed and should be removed (rather than updating it). build.gradle line 2117: > 2115: > 2116: dependencies { > 2117: stubImplementation group: "junit", name: "junit", version: "4.13.2" This isn't needed and should be removed (rather than updating it). modules/javafx.base/src/test/java/test/JUnit5Test.java line 34: > 32: @Test > 33: void junit5ShouldWork() { > 34: System.err.println("JUnit 5 test working!"); I recommend adding a trivial assert here (e.g., `assertNotNull(this)` or similar). ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Sat Nov 20 16:08:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 20 Nov 2021 16:08:08 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v6] In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 22:37:09 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Fix white space error > - Allow apiguardian as dependency I also was able to make the (minor) changes needed to our closed build to use the `4.13.2` jar files. As a note to other committers: Given that this is a third-party update, and that I need to integrate a coordinated closed change, I will sponsor this once it is ready. Please don't sponsor it even if it appears to be waiting for a while. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From mhanl at openjdk.java.net Sat Nov 20 20:03:05 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Sat, 20 Nov 2021 20:03:05 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout In-Reply-To: <-oozo6iPMsvA--pocHeuxIOkGsO8f49n7msrUPewq50=.0f61fb69-e48e-4690-904a-21c36a1163a1@github.com> References: <-oozo6iPMsvA--pocHeuxIOkGsO8f49n7msrUPewq50=.0f61fb69-e48e-4690-904a-21c36a1163a1@github.com> Message-ID: On Fri, 19 Nov 2021 12:39:23 GMT, Jeanette Winzenburg wrote: > interesting issue - and fix :) Verified the mis-behaviour before the fix and its working after. > > Wondering, though (read: I don't understand ??) > > * why the layout details in the splitpane hinders the visual update of a completely unrelated component (like the combo)? > * why does it only happen on increasing the divider pos, not on decreasing? > > As to the test: would prefer to also see a test of the fixed effect (vs. the fix implementation of not re-entering layout) - might be a bit tricky, though. - the combobox is a children of the splitpane, so therefore it is affected by the invalid layout state of the splitpane. - it can also happen when decreasing, it might be that you need to set the min width to 0 of the left content of the splitpane. -> The bug is only happening if you drag the divider while being either as far on the left as possible or as far as possible on the right, so that a drag won't affect the divider since it is already at the min/max position. The layout code whoever will basically adjust the divider a second time since it would now be out of bounds Do you mean something like checking the combobox display text? ------------- PR: https://git.openjdk.java.net/jfx/pull/669 From jhendrikx at openjdk.java.net Sun Nov 21 21:50:36 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 21 Nov 2021 21:50:36 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v7] In-Reply-To: References: Message-ID: <8e0VJAsNb5am2TXTjixZ4VQHJUDmdFHxQJh1RFUQNCo=.c84d2e49-00bd-4f71-80b2-aa896c3848e3@github.com> > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Add trivial assert to JUnit5Test - Add explicit dependencies in build.gradle ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/c5b76ee8..d06d6570 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=05-06 Stats: 15 lines in 2 files changed: 11 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Sun Nov 21 21:50:44 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Sun, 21 Nov 2021 21:50:44 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v6] In-Reply-To: References: Message-ID: On Sat, 20 Nov 2021 15:54:06 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix white space error >> - Allow apiguardian as dependency > > build.gradle line 1948: > >> 1946: dependencies { >> 1947: testImplementation group: "junit", name: "junit", version: "4.13.2" >> 1948: testImplementation group: "org.junit.jupiter", name: "junit-jupiter", version: "5.8.1" > > We need an explicit list of dependencies here, rather than relying on the maven pom files to bring them in. This is needed for our internal builds where we only host a snapshot of the jar files and not the pom files. Also, it better documents the dependencies. After adding the following to my local build, it all works now: > > > testImplementation group: "org.junit.jupiter", name: "junit-jupiter-api", version: "5.8.1" > testImplementation group: "org.hamcrest", name: "hamcrest-core", version: "1.3" > testRuntimeOnly group: "org.junit.jupiter", name: "junit-jupiter-engine", version: "5.8.1" > testRuntimeOnly group: "org.junit.jupiter", name: "junit-jupiter-params", version: "5.8.1" > testRuntimeOnly group: "org.junit.platform", name: "junit-platform-commons", version: "1.8.1" > testRuntimeOnly group: "org.junit.platform", name: "junit-platform-engine", version: "1.8.1" > testRuntimeOnly group: "org.apiguardian", name: "apiguardian-api", version: "1.1.2" > testRuntimeOnly group: "org.opentest4j", name: "opentest4j", version: "1.2.0" I've added the dependencies you listed here. > build.gradle line 1951: > >> 1949: testRuntimeOnly group: "org.junit.vintage", name: "junit-vintage-engine", version: "5.8.1" >> 1950: >> 1951: if (BUILD_CLOSED && DO_JCOV) { > > Minor: you added an extra space of indentation (which is why this line is showing up in the diff). Fixed > build.gradle line 2041: > >> 2039: >> 2040: dependencies { >> 2041: testImplementation group: "junit", name: "junit", version: "4.13.2" > > This isn't needed and should be removed (rather than updating it). Removed this and in the other location. > modules/javafx.base/src/test/java/test/JUnit5Test.java line 34: > >> 32: @Test >> 33: void junit5ShouldWork() { >> 34: System.err.println("JUnit 5 test working!"); > > I recommend adding a trivial assert here (e.g., `assertNotNull(this)` or similar). Added ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jgneff at openjdk.java.net Mon Nov 22 06:43:30 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 22 Nov 2021 06:43:30 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v6] In-Reply-To: References: Message-ID: > This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: > > > $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) > $ bash gradlew sdk jmods javadoc > $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod > > > The three commands: > > 1. set the build timestamp to the date of the latest source code change, > 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and > 3. recreate the JMOD files with stable file modification times and ordering. > > The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. > > #### Fixes > > There are at least four sources of non-determinism in the JavaFX builds: > > 1. Build timestamp > > The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. > > 2. Modification times > > The JAR, JMOD, and ZIP archives store the modification time of each file. > > 3. File ordering > > The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. > > 4. Build path > > The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. > > This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Get build timestamp in UTC and set ZIP timestamps Create the build timestamp as a zoned date and time in UTC instead of a local date and time. If SOURCE_DATE_EPOCH is defined, set the last modification time of ZIP and JAR entries to the local date and time in UTC of the instant defined by SOURCE_DATE_EPOCH. Add a comment as a reminder to make JMOD files deterministic when the following enhancements are complete: * Enable deterministic file content ordering for Jar and Jmod https://bugs.openjdk.java.net/browse/JDK-8276764 https://github.com/openjdk/jdk/pull/6395 * Enable jar and jmod to produce deterministic timestamped content https://bugs.openjdk.java.net/browse/JDK-8276766 https://github.com/openjdk/jdk/pull/6481 - Merge branch 'master' into allow-reproducible-builds - Make build of SDK ZIP bundle reproducible - Merge branch 'master' into allow-reproducible-builds - Merge branch 'master' into allow-reproducible-builds - Include WebKit shared library for Windows Enable reproducible builds of the native WebKit shared library for Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. - Include media shared libraries for Windows Enable reproducible builds of the native media shared libraries for Windows when SOURCE_DATE_EPOCH is defined. The libraries are: fxplugins.dll glib-lite.dll gstreamer-lite.dll jfxmedia.dll - Enable reproducible builds with SOURCE_DATE_EPOCH - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH ------------- Changes: https://git.openjdk.java.net/jfx/pull/446/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=446&range=05 Stats: 149 lines in 7 files changed: 119 ins; 13 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/446.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/446/head:pull/446 PR: https://git.openjdk.java.net/jfx/pull/446 From duke at openjdk.java.net Mon Nov 22 12:16:09 2021 From: duke at openjdk.java.net (Andreas Heger) Date: Mon, 22 Nov 2021 12:16:09 GMT Subject: Integrated: 8276174: JavaFX build fails on macOS aarch64 In-Reply-To: References: Message-ID: On Thu, 11 Nov 2021 10:46:26 GMT, Andreas Heger wrote: > By changing the value for the clang -arch parameter to "arm64", the jfx project compiles on an apple silicon system. Are there any side effects which I might be missing in this simple solution? This pull request has now been integrated. Changeset: d289db94 Author: andreas-heger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d289db94d15e49ed28f797b516ffccf023fce9c9 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8276174: JavaFX build fails on macOS aarch64 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/666 From kcr at openjdk.java.net Mon Nov 22 12:56:10 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Nov 2021 12:56:10 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v7] In-Reply-To: <8e0VJAsNb5am2TXTjixZ4VQHJUDmdFHxQJh1RFUQNCo=.c84d2e49-00bd-4f71-80b2-aa896c3848e3@github.com> References: <8e0VJAsNb5am2TXTjixZ4VQHJUDmdFHxQJh1RFUQNCo=.c84d2e49-00bd-4f71-80b2-aa896c3848e3@github.com> Message-ID: On Sun, 21 Nov 2021 21:50:36 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add trivial assert to JUnit5Test > - Add explicit dependencies in build.gradle Looks good with one comment inline. modules/javafx.base/src/test/java/test/JUnit5Test.java line 28: > 26: package test; > 27: > 28: import static org.junit.Assert.assertNotNull; For JUnit 5, shouldn't this be `org.junit.jupiter.api.Assertions.assertNotNull`? ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Mon Nov 22 13:30:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Nov 2021 13:30:09 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v7] In-Reply-To: <8e0VJAsNb5am2TXTjixZ4VQHJUDmdFHxQJh1RFUQNCo=.c84d2e49-00bd-4f71-80b2-aa896c3848e3@github.com> References: <8e0VJAsNb5am2TXTjixZ4VQHJUDmdFHxQJh1RFUQNCo=.c84d2e49-00bd-4f71-80b2-aa896c3848e3@github.com> Message-ID: On Sun, 21 Nov 2021 21:50:36 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Add trivial assert to JUnit5Test > - Add explicit dependencies in build.gradle I was looking for places where JUnit 4.8.2 was still being referenced and found two more places that should be changed: 1. [`buildSrc/build.gradle`](https://github.com/openjdk/jfx/blob/d06d657007c3af86ba2ff908b546cae18e775bfb/buildSrc/build.gradle#L77) depends on JUnit 4.8.2 -- this should be changed to JUnit 4.13.2 (and you will need to add hamcrest) 2. Once the above is fixed, you should be able to remove the JUnit 4.8.2 artifacts from [`gradle/verification-metadata.xml`](https://github.com/openjdk/jfx/blob/d06d657007c3af86ba2ff908b546cae18e775bfb/gradle/verification-metadata.xml#L122) ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Mon Nov 22 13:36:40 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 22 Nov 2021 13:36:40 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v8] In-Reply-To: References: Message-ID: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix import to use jupiter annotations ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/d06d6570..f556a1ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From jhendrikx at openjdk.java.net Mon Nov 22 13:36:42 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 22 Nov 2021 13:36:42 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v7] In-Reply-To: References: <8e0VJAsNb5am2TXTjixZ4VQHJUDmdFHxQJh1RFUQNCo=.c84d2e49-00bd-4f71-80b2-aa896c3848e3@github.com> Message-ID: On Mon, 22 Nov 2021 12:52:10 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add trivial assert to JUnit5Test >> - Add explicit dependencies in build.gradle > > modules/javafx.base/src/test/java/test/JUnit5Test.java line 28: > >> 26: package test; >> 27: >> 28: import static org.junit.Assert.assertNotNull; > > For JUnit 5, shouldn't this be `org.junit.jupiter.api.Assertions.assertNotNull`? Sorry, I totally missed that. Although you can mix these without ill effect, we should move towards the `jupiter` annotations if we ever want to get to the point where JUnit 4 can be phased out. ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From duke at openjdk.java.net Mon Nov 22 13:37:43 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 22 Nov 2021 13:37:43 GMT Subject: RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound [v2] In-Reply-To: References: Message-ID: > PathElements were skipped in AreaChart if the data point were outside axis bounds and had duplicate value for either x or y. This is now fixed with this PR. Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Fix condition and add more tests ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/667/files - new: https://git.openjdk.java.net/jfx/pull/667/files/07efa203..1381aaa4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=667&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=667&range=00-01 Stats: 726 lines in 3 files changed: 534 ins; 11 del; 181 mod Patch: https://git.openjdk.java.net/jfx/pull/667.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/667/head:pull/667 PR: https://git.openjdk.java.net/jfx/pull/667 From jhendrikx at openjdk.java.net Mon Nov 22 13:43:34 2021 From: jhendrikx at openjdk.java.net (John Hendrikx) Date: Mon, 22 Nov 2021 13:43:34 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v9] In-Reply-To: References: Message-ID: > I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. > > I've updated the Eclipse project file for the base module only. John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: - Remove remaining references to old JUnit 4.8.2 - Upgrade to JUnit 4.13.2 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/633/files - new: https://git.openjdk.java.net/jfx/pull/633/files/f556a1ae..5f4f695b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=633&range=07-08 Stats: 10 lines in 2 files changed: 1 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/633.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/633/head:pull/633 PR: https://git.openjdk.java.net/jfx/pull/633 From duke at openjdk.java.net Mon Nov 22 13:58:17 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 22 Nov 2021 13:58:17 GMT Subject: RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound [v2] In-Reply-To: References: Message-ID: <-3cg2Wt_I9O7Wa8BwQ-e_Ra141NylLERqPXDOGStgn4=.9f9e9699-b557-43eb-953f-280c21f8922c@github.com> On Wed, 17 Nov 2021 10:07:37 GMT, Ajit Ghaisas wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix condition and add more tests > > modules/javafx.controls/src/test/java/test/javafx/scene/chart/AreaChartTest.java line 187: > >> 185: } >> 186: >> 187: @Test public void testPathOutsideXBoundsWithDuplicateXAndLowerY() { > > I wonder whether we need another set of similar tests with X and Y interchanged? > Something like - testPathOutsideYBoundsWithDuplicateYAndLowerX I have added a couple of additional tests ------------- PR: https://git.openjdk.java.net/jfx/pull/667 From mhanl at openjdk.java.net Mon Nov 22 14:03:56 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Mon, 22 Nov 2021 14:03:56 GMT Subject: RFR: 8277122: SplitPane divider drag can hang the layout [v2] In-Reply-To: References: Message-ID: <_grncaimIi3UGlnE44XBdS9hIQYAVlOGOpcXErtg-nA=.cce76737-295b-48fa-b8a9-17e39d7cfa70@github.com> > When a divider is moved via drag or code it will call **requestLayout()** for the **SplitPane**. > While this is fine, it is also called when the **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider. > > This makes no sense since we are currently layouting everything, so we don't need to request it again. (The divider positioning is the first part of **layoutChildren(..)**. In the second part the SplitPane content is layouted based off those positions) > > -> With this behaviour the layout may hang under some conditions (check attached source). The problem is that the **requestLayout()** will mark the **SplitPane** dirty but won't propagate to the parent since the **SplitPane** is currently doing a layout. > > This PR fixes this by not requesting layout when we are currently doing it (and thus repositioning the dividers as part of it). > > Note: I also fixed a simple typo of a private method in SplitPaneSkin: > initializeDivderEventHandlers -> initializeDiv**i**derEventHandlers Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8277122: Added test for setting a negative divider position + improved readability ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/669/files - new: https://git.openjdk.java.net/jfx/pull/669/files/919f5db8..9db28ff0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=669&range=00-01 Stats: 27 lines in 2 files changed: 14 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/669.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/669/head:pull/669 PR: https://git.openjdk.java.net/jfx/pull/669 From duke at openjdk.java.net Mon Nov 22 14:04:01 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 22 Nov 2021 14:04:01 GMT Subject: RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound [v3] In-Reply-To: References: Message-ID: > PathElements were skipped in AreaChart if the data point were outside axis bounds and had duplicate value for either x or y. This is now fixed with this PR. Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Update line ending ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/667/files - new: https://git.openjdk.java.net/jfx/pull/667/files/1381aaa4..c98cc976 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=667&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=667&range=01-02 Stats: 535 lines in 1 file changed: 0 ins; 0 del; 535 mod Patch: https://git.openjdk.java.net/jfx/pull/667.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/667/head:pull/667 PR: https://git.openjdk.java.net/jfx/pull/667 From duke at openjdk.java.net Mon Nov 22 15:58:20 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 22 Nov 2021 15:58:20 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Thu, 18 Nov 2021 09:06:08 GMT, Tom Schindl wrote: >> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java line 119: >> >>> 117: Object obj = get(i); >>> 118: if (o.equals(obj)) return i; >>> 119: } >> >> An alternative is >> >> return IntStream.range(0, size()) >> .filter(i -> o.equals(get(i))) >> .findFirst() >> .orElse(-1); >> >> I don't know if it helps. > > the for-loop is certainly faster and would allocate less memory - i find the `for(int i = 0, max = size())`-style a bit odd I could move `int max = size();` outside the loop ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Mon Nov 22 15:58:21 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 22 Nov 2021 15:58:21 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Thu, 18 Nov 2021 00:54:30 GMT, Nir Lisker wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java line 193: > >> 191: arr[i] = get(i); >> 192: } >> 193: return arr; > > Have you tried `return stream().toArray();`? I haven't measured how `stream().toArray()` compare to a for..loop, but I inherently try to avoid streams in such scenarios. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Mon Nov 22 16:10:28 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 22 Nov 2021 16:10:28 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Thu, 18 Nov 2021 08:53:07 GMT, Marius Hanl wrote: >> This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. >> >> The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > Just wondering, isn't it also possible to write some unit tests for the MultipleSelectionModel(Base) ? @Maran23 I don't know what would be an apt unit test as the PR changes implementation detail. If you have suggestions, please let me know. There are 276 unit tests in `test.javafx.scene.control.MultipleSelectionModelImplTest` and all of them still pass with the changes made to this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From mstrauss at openjdk.java.net Mon Nov 22 16:28:17 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 22 Nov 2021 16:28:17 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Mon, 22 Nov 2021 15:55:03 GMT, Abhinay Agarwal wrote: >> the for-loop is certainly faster and would allocate less memory - i find the `for(int i = 0, max = size())`-style a bit odd > > I could move `int max = size();` outside the loop But why? The initialization block of a `for` statement is exactly where you'd put loop-scoped variables. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From mstrauss at openjdk.java.net Mon Nov 22 17:57:35 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 22 Nov 2021 17:57:35 GMT Subject: RFR: 8277572: Image class documentation incorrect for images encoded in data URIs Message-ID: The javadoc of `javafx.scene.image.Image` incorrectly states: 94 * If a URL uses the "data" scheme, the data must be base64-encoded 95 * and the MIME type must either be empty or a subtype of the 96 * {@code image} type. However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". The solution is to fix the documentation: 94 * If a URL uses the "data" scheme, the data must be base64-encoded + 95 * and the MIME type must be a subtype of the {@code image} type. - 95 * and the MIME type must either be empty or a subtype of the - 96 * {@code image} type. ------------- Commit messages: - Fixed incorrect documentation of image data URIs Changes: https://git.openjdk.java.net/jfx/pull/676/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277572 Stats: 32 lines in 2 files changed: 30 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/676.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/676/head:pull/676 PR: https://git.openjdk.java.net/jfx/pull/676 From duke at openjdk.java.net Mon Nov 22 18:30:01 2021 From: duke at openjdk.java.net (Martin Fox) Date: Mon, 22 Nov 2021 18:30:01 GMT Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z) > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace error. I?m not sure how to approach regression testing. MacOS 11 ships with 189 keyboard layouts and this PR changes the key assignments for 62 of them. On each layout there are just under 50 keys that might be affected. Some automated or manual sanity-checking tests would go a long way but the Robot code has bugs on every platform and I want to deal with the user-facing issues first (though this PR also fixes the Robot on Mac). For manual testing I run a JavaFX app that dumps out info on each key event. There?s one attached to this e-mail thread under the name KeyboardTest.txt. I use the Mac Keyboard Viewer app to visualize layouts that don?t match what?s printed on my keyboard. It?s also helpful to compare against a Windows box if you have one. When testing code changes I rely on a command line tool that runs through all the layouts and compares the results of the new algorithm against the old algorithm. This is useful for flagging issues that no amount of manual testing would be likely to find (ask me about Lithuanian digits some day) but I don?t really expect other testers to go that far. If you are testing this keep in mind that there are no key codes corresponding to accented characters or other characters that bear diacritic marks. Those keys will be assigned KeyCode.UNDEFINED. And stay away from dead keys, the way they behave on the Mac is, um, complicated. ------------- PR: https://git.openjdk.java.net/jfx/pull/425 From jgneff at openjdk.java.net Mon Nov 22 20:28:18 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 22 Nov 2021 20:28:18 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Fri, 17 Sep 2021 22:10:41 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Make build of SDK ZIP bundle reproducible >> - Merge branch 'master' into allow-reproducible-builds >> - Merge branch 'master' into allow-reproducible-builds >> - Include WebKit shared library for Windows >> >> Enable reproducible builds of the native WebKit shared library for >> Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. >> - Include media shared libraries for Windows >> >> Enable reproducible builds of the native media shared libraries for >> Windows when SOURCE_DATE_EPOCH is defined. The libraries are: >> >> fxplugins.dll >> glib-lite.dll >> gstreamer-lite.dll >> jfxmedia.dll >> - Enable reproducible builds with SOURCE_DATE_EPOCH >> - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH > > build.gradle line 559: > >> 557: buildDate = new java.util.Date(ms) >> 558: } >> 559: def buildTimestamp = new java.text.SimpleDateFormat("yyyy-MM-dd-HHmmss").format(buildDate) > > I think it would be useful to format `buildDate` using UTC as the time zone when `SOURCE_DATE_EPOCH` is set. Indeed. The build now uses the new `java.time.Instant` class to get the instant on the time-line, whether or not `SOURCE_DATE_EPOCH` is set, and creates the timestamp in UTC using the ISO 8601 date and time format. > build.gradle line 3518: > >> 3516: def lFlags = webkitProperties.linkFlags?.join(' ') ?: '' >> 3517: cmakeArgs = "$cmakeArgs -DCMAKE_C_FLAGS='${cFlags}' -DCMAKE_CXX_FLAGS='${cFlags}'" >> 3518: cmakeArgs = "$cmakeArgs -DCMAKE_SHARED_LINKER_FLAGS='${lFlags}'" > > I presume you've tested this both with and without `SOURCE_DATE_EPOCH`? Well, now I have! ?? Thanks. > build.gradle line 3914: > >> 3912: tasks.withType(AbstractArchiveTask) { >> 3913: if (sourceDateEpoch != null) { >> 3914: preserveFileTimestamps = false > > This is a problem given how gradle generates a zip archive when this is set. How hard would it be to force all time stamps to be `SOURCE_DATE_EPOCH`? It was harder than I had hoped, but I think I found a good solution. The only changes in the ZIP and JAR archives are shown in the `diff` extract below (from `zipinfo -v`): 29c29 < minimum software version required to extract: 1.0 --- > minimum software version required to extract: 2.0 33,34c33,34 < extended local header: no < file last modified on (DOS date/time): 1980 Feb 1 00:00:00 --- > extended local header: yes > file last modified on (DOS date/time): 2021 Nov 16 17:55:42 44c44 < MS-DOS file attributes (10 hex): dir --- > MS-DOS file attributes (00 hex): none where: * The minimum software version required to extract is now set to the correct value of 2.0, which is the minimum for file entries compressed with DEFLATE. * The extended local header is defined but with length zero. * The timestamp is set to the local date and time in UTC of the instant of the build. * The MS-DOS file attribute for a directory is not set. It does not appear to be useful, as an entry in a ZIP file is a directory if and only if its name ends with a slash ("/"). These changes are due to Gradle using the Apache Ant `org.apache.tools.zip.ZipEntry` class, while the build now uses the `java.util.zip.ZipEntry` class in OpenJDK to create the archives. ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From jgneff at openjdk.java.net Mon Nov 22 21:28:11 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 22 Nov 2021 21:28:11 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5] In-Reply-To: References: Message-ID: On Sat, 18 Sep 2021 15:15:10 GMT, Kevin Rushforth wrote: > I did a CI build yesterday and again today on all three platforms and compared the sdk between the two builds for each platform. On all three platforms the results are the same: All files were identical except the native jfxwebkit library. So there is something in the WebKit build that is affected by an external input (perhaps the system date or similar). I can recreate this difference, but only on macOS. **Lesson learned:** When testing reproducible builds on a permanent system, never use the Gradle Daemon! I always get a different `libjfxwebkit.dylib` file when I run the build with `bash gradlew --no-daemon`. Shown below are the versions of the compilers I'm using: john at linux:~$ gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 john at macos:~$ gcc --version Apple clang version 13.0.0 (clang-1300.0.29.3) john at win10:~$ gcc --version gcc (GCC) 11.2.0 When I dump each of the shared libraries with the following script, I get a text file with 10,413,716 lines, yet there are only 108 lines different between the two output files. #!/bin/bash # Dumps macOS shared libraries # Diffoscope fails due to missing '=' after '--arch-name' option: # llvm-objdump: error: unknown argument '--arch-name' llvm-objdump --arch-name=x86_64 --section="__TEXT,__text" --macho \ --demangle --no-leading-addr --no-show-raw-insn "$@" The differences are shown below: diff --git a/libjfxwebkit.5.txt b/libjfxwebkit.6.txt index 9d6932a..63f2b70 100644 --- a/libjfxwebkit.5.txt +++ b/libjfxwebkit.6.txt @@ -1,4 +1,4 @@ -libjfxwebkit.5.dylib: +libjfxwebkit.6.dylib: Contents of (__TEXT,__text) section __ZN6WebKit15StorageAreaImplD2Ev: pushq %rbp @@ -881412,30 +881412,22 @@ __ZN7WebCore30isCSSPropertyEnabledBySettingsENS_13CSSPropertyIDEPKNS_8SettingsE: movq %rsp, %rbp movb $1, %al testq %rsi, %rsi - je 0x319ee0 + je 0x319ee7 leal -258(%rdi), %ecx cmpw $37, %cx - ja 0x319eb7 + ja 0x319eb2 movzwl %cx, %ecx - leaq 79(%rip), %rdx + leaq 75(%rip), %rdx movslq (%rdx,%rcx,4), %rcx addq %rdx, %rcx jmpq *%rcx movb 466(%rsi), %al - andb $4, %al - shrb $2, %al - popq %rbp - retq + jmp 0x319ee2 + cmpw $43, %di + je 0x319edc movzwl %di, %ecx cmpl $366, %ecx - je 0x319ed5 - cmpw $43, %di - jne 0x319ee0 - movb 451(%rsi), %al - andb $4, %al - shrb $2, %al - popq %rbp - retq + jne 0x319ee7 movb 454(%rsi), %al andb $32, %al shrb $5, %al @@ -881446,46 +881438,52 @@ __ZN7WebCore30isCSSPropertyEnabledBySettingsENS_13CSSPropertyIDEPKNS_8SettingsE: shrb %al popq %rbp retq + movb 451(%rsi), %al + andb $4, %al + shrb $2, %al + popq %rbp + retq + nopl (%rax) + .long 4294967230 @ KIND_JUMP_TABLE32 + .long 4294967230 @ KIND_JUMP_TABLE32 + .long 4294967230 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967255 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967291 @ KIND_JUMP_TABLE32 + .long 4294967255 @ KIND_JUMP_TABLE32 + .long 4294967268 @ KIND_JUMP_TABLE32 + nopw %cs:(%rax,%rax) nop - .long 4294967226 @ KIND_JUMP_TABLE32 - .long 4294967226 @ KIND_JUMP_TABLE32 - .long 4294967226 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967269 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967280 @ KIND_JUMP_TABLE32 - .long 4294967269 @ KIND_JUMP_TABLE32 - .long 4294967282 @ KIND_JUMP_TABLE32 - nopl (%rax,%rax) __ZN7WebCore15getPropertyNameENS_13CSSPropertyIDE: leal -2(%rdi), %eax movzwl %ax, %eax @bmwiedemann Bernhard, does this look familiar? It appears to be similar to the [problem you fixed in WebKit][1] (twice). [1]: https://github.com/WebKit/WebKit/commits?author=bmwiedemann ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From kcr at openjdk.java.net Mon Nov 22 21:52:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Nov 2021 21:52:11 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v9] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:43:34 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove remaining references to old JUnit 4.8.2 > - Upgrade to JUnit 4.13.2 Looks good. I did a CI build with the latest changes. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/633 From kcr at openjdk.java.net Mon Nov 22 22:40:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 22 Nov 2021 22:40:15 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v9] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:43:34 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove remaining references to old JUnit 4.8.2 > - Upgrade to JUnit 4.13.2 @johanvos @tiainen Can one of you also review this to ensure it causes no problems with your builds? ------------- PR: https://git.openjdk.java.net/jfx/pull/633 From jgneff at openjdk.java.net Mon Nov 22 23:44:21 2021 From: jgneff at openjdk.java.net (John Neffenger) Date: Mon, 22 Nov 2021 23:44:21 GMT Subject: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v6] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 06:43:30 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For example, the following commands create a reproducible build: >> >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives or the `jmod` tool itself has the required support. For more information on the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more information on the command to recreate the JMOD files, see the [`strip-nondeterminism`][2] repository. I'd like to propose that we allow for reproducible builds in JavaFX 17 and consider making them the default in JavaFX 18. >> >> #### Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module stores the time of the build. Furthermore, for builds that don't run on the Hudson continuous integration tool, the class adds the build time to the system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned by the file system. The native shared libraries also store their object files in the order returned by the file system. Most file systems, though, do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics module stores the absolute path of its `.css` input file in the corresponding `.bss` output file, which is then included in the JavaFX Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the first three sources of non-determinism. A later pull request can modify the Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Get build timestamp in UTC and set ZIP timestamps > > Create the build timestamp as a zoned date and time in UTC instead > of a local date and time. If SOURCE_DATE_EPOCH is defined, set the > last modification time of ZIP and JAR entries to the local date and > time in UTC of the instant defined by SOURCE_DATE_EPOCH. > > Add a comment as a reminder to make JMOD files deterministic when > the following enhancements are complete: > > * Enable deterministic file content ordering for Jar and Jmod > https://bugs.openjdk.java.net/browse/JDK-8276764 > https://github.com/openjdk/jdk/pull/6395 > > * Enable jar and jmod to produce deterministic timestamped content > https://bugs.openjdk.java.net/browse/JDK-8276766 > https://github.com/openjdk/jdk/pull/6481 > - Merge branch 'master' into allow-reproducible-builds > - Make build of SDK ZIP bundle reproducible > - Merge branch 'master' into allow-reproducible-builds > - Merge branch 'master' into allow-reproducible-builds > - Include WebKit shared library for Windows > > Enable reproducible builds of the native WebKit shared library for > Windows (jfxwebkit.dll) when SOURCE_DATE_EPOCH is defined. > - Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll > - Enable reproducible builds with SOURCE_DATE_EPOCH > - 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH The results of 33 builds are shown in the table below: | Builds | Linux | macOS | Win10 | | ------- |:-----:|:-----:|:-----:| | Develop | ? | ? | ? | | Actions | ? | ? | ? | | Release | ? | ? | ? | where the check mark (?) means that the unit tests ran successfully and that the files in the `build` directory where identical between two builds on the same system except for the `libjfxwebkit.dylib` file on macOS and the JMOD files on all of the systems. The build types are shown below by their Gradle options and tasks: * **Develop:** `bash gradlew --no-daemon sdk jmods javadoc test -x :web:test` * **Actions:** `bash gradlew --no-daemon all test -x :web:test` * **Release:** `bash gradlew --no-daemon -PCONF=Release -PPROMOTED_BUILD_NUMBER=7 -PHUDSON_BUILD_NUMBER=101 -PHUDSON_JOB_NAME=jfx -PCOMPILE_WEBKIT=true -PCOMPILE_MEDIA=true -PBUILD_LIBAV_STUBS=true sdk jmods javadoc test` I ran each set of builds as shown by the following example: $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) $ bash gradlew --no-daemon cleanAll $ bash gradlew --no-daemon all $ mv build build1 $ bash gradlew --no-daemon cleanAll $ bash gradlew --no-daemon all $ mv build build2 $ bash gradlew --no-daemon all test -x :web:test I ran two more builds with `SOURCE_DATE_EPOCH` undefined on each system: a reference *Develop* build and a *Release* build with its unit tests. I also confirmed that the builds are reproducible, except for the JMOD files, on all of the following Linux architectures running Ubuntu 18.04 LTS: | Builds | amd64 | arm64 | armhf | i386 | ppc64el | s390x | | ------- |:-----:|:-----:|:-----:|:----:|:-------:|:-----:| | Develop | ? | ? | ? | ? | ? | ? | One bonus with reproducible builds is that you can compare across systems. For example, the following JAR files are now identical across operating systems and hardware architectures, just as one would expect: * javafx.base.jar * javafx.fxml.jar * javafx.swing.jar * javafx-swt.jar * javafx.web.jar ------------- PR: https://git.openjdk.java.net/jfx/pull/446 From mstrauss at openjdk.java.net Tue Nov 23 05:50:33 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 23 Nov 2021 05:50:33 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v2] In-Reply-To: References: Message-ID: > `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: > > 1. If the specified image subtype is not supported, an exception will be thrown. > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > > > Also, the javadoc of `javafx.scene.image.Image` incorrectly states: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > 95 * and the MIME type must either be empty or a subtype of the > 96 * {@code image} type. > > However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". > > The solution is to fix the documentation: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > + 95 * and the MIME type must be a subtype of the {@code image} type. > - 95 * and the MIME type must either be empty or a subtype of the > - 96 * {@code image} type. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: ImageStorage correctly handles MIME types in data URIs ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/676/files - new: https://git.openjdk.java.net/jfx/pull/676/files/4abb9b47..73f1bb13 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=00-01 Stats: 152 lines in 9 files changed: 85 ins; 8 del; 59 mod Patch: https://git.openjdk.java.net/jfx/pull/676.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/676/head:pull/676 PR: https://git.openjdk.java.net/jfx/pull/676 From jpereda at openjdk.java.net Tue Nov 23 10:02:18 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 23 Nov 2021 10:02:18 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. Worth pointing out that [JDK-8273558](https://bugs.openjdk.java.net/browse/JDK-8273558) gets fixed with this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From jpereda at openjdk.java.net Tue Nov 23 11:07:41 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 23 Nov 2021 11:07:41 GMT Subject: RFR: 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle Message-ID: This PR fixes a memory leak, as a follow-up of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). The tests pass on desktop (Linux/macOS/Windows) and there is no regression on Android (see [JDK-8254605](https://bugs.openjdk.java.net/browse/JDK-8254605)). ------------- Commit messages: - Enable test back and include required sw pipeline - Nullify focusedWindow when window is closed and add null checks Changes: https://git.openjdk.java.net/jfx/pull/677/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=677&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254956 Stats: 20 lines in 4 files changed: 11 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/677.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/677/head:pull/677 PR: https://git.openjdk.java.net/jfx/pull/677 From kcr at openjdk.java.net Tue Nov 23 15:21:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Nov 2021 15:21:28 GMT Subject: RFR: 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 11:00:51 GMT, Jose Pereda wrote: > This PR fixes a memory leak, as a follow-up of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). > > The tests pass on desktop (Linux/macOS/Windows) and there is no regression on Android (see [JDK-8254605](https://bugs.openjdk.java.net/browse/JDK-8254605)). The fix looks good to me. The newly reenabled test doesn't seem to verify the fix, though. It passes both before and after the fix on two different systems (possibly because some other recent change has made it insufficient to test for the leak). Do you have a test case that fails without this redo fix and passes with it? ------------- PR: https://git.openjdk.java.net/jfx/pull/677 From kcr at openjdk.java.net Tue Nov 23 15:37:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Nov 2021 15:37:12 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v2] In-Reply-To: References: Message-ID: <42em-6h7Ur2ZVVzFOy7bPRCcTAKGRDEA2NJGb78MAyM=.537bb6b9-3ca7-4d72-b7cf-260719424903@github.com> On Tue, 23 Nov 2021 05:50:33 GMT, Michael Strau? wrote: >> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: >> >> 1. If the specified image subtype is not supported, an exception will be thrown. >> 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: >> >> >> Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' >> >> >> Also, the javadoc of `javafx.scene.image.Image` incorrectly states: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> 95 * and the MIME type must either be empty or a subtype of the >> 96 * {@code image} type. >> >> However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". >> >> The solution is to fix the documentation: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> + 95 * and the MIME type must be a subtype of the {@code image} type. >> - 95 * and the MIME type must either be empty or a subtype of the >> - 96 * {@code image} type. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > ImageStorage correctly handles MIME types in data URIs > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > ``` > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > ``` This seems like an odd behavior to me, but if this is common practice among browsers, then it seems OK for us to do the same. In this case, it should be documented in the class docs of `Image`. ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From jpereda at openjdk.java.net Tue Nov 23 15:39:07 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 23 Nov 2021 15:39:07 GMT Subject: RFR: 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 11:00:51 GMT, Jose Pereda wrote: > This PR fixes a memory leak, as a follow-up of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). > > The tests pass on desktop (Linux/macOS/Windows) and there is no regression on Android (see [JDK-8254605](https://bugs.openjdk.java.net/browse/JDK-8254605)). Hmm, it does fail for me without the fix. For instance, on Mac (Big Sur), with JDK 11 or 16, and building from head: sh gradlew -PFULL_TEST=true :systemTests:test --info --tests=test.javafx.stage.FocusedWindowMonocleTest test.javafx.stage.FocusedWindowMonocleTest > testClosedFocusedStageLeak FAILED junit.framework.AssertionFailedError: Expected: but was: javafx.stage.Stage at 6caf0677 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNull(Assert.java:233) at junit.framework.Assert.assertNull(Assert.java:226) at test.javafx.stage.FocusedWindowTestBase.assertCollectable(FocusedWindowTestBase.java:97) at test.javafx.stage.FocusedWindowTestBase.testClosedFocusedStageLeakBase(FocusedWindowTestBase.java:81) at test.javafx.stage.FocusedWindowMonocleTest.testClosedFocusedStageLeak(FocusedWindowMonocleTest.java:48) ------------- PR: https://git.openjdk.java.net/jfx/pull/677 From kcr at openjdk.java.net Tue Nov 23 15:55:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Nov 2021 15:55:23 GMT Subject: RFR: 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 11:00:51 GMT, Jose Pereda wrote: > This PR fixes a memory leak, as a follow-up of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). > > The tests pass on desktop (Linux/macOS/Windows) and there is no regression on Android (see [JDK-8254605](https://bugs.openjdk.java.net/browse/JDK-8254605)). This was my mistake -- well, actually, an unfortunate design choice by gradle, but one I'm so familiar with I'm surprised I got bit by it. gradle will not rerun a test if it thinks the tests are up-to-date, and that's exactly what happened to me. Twice. This is why when I run individual tests, I (almost) always add the `cleanTest` target. When I do that, it fails for me, too, without your fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/677 From jpereda at openjdk.java.net Tue Nov 23 16:00:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 23 Nov 2021 16:00:10 GMT Subject: RFR: 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle In-Reply-To: References: Message-ID: <_TyvTd76OKfj3jryilcpyLULZr8n_Ddpv9BNLV6uJew=.fa70cb3a-630b-4e3e-a086-881a08e59ab5@github.com> On Tue, 23 Nov 2021 11:00:51 GMT, Jose Pereda wrote: > This PR fixes a memory leak, as a follow-up of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). > > The tests pass on desktop (Linux/macOS/Windows) and there is no regression on Android (see [JDK-8254605](https://bugs.openjdk.java.net/browse/JDK-8254605)). Yes, `cleanTest` is quite handy when you are just modifying the code base and running the same test all over again (else you need to modify the test just a tiny bit...) ------------- PR: https://git.openjdk.java.net/jfx/pull/677 From jpereda at openjdk.java.net Tue Nov 23 16:00:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 23 Nov 2021 16:00:10 GMT Subject: Integrated: 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle In-Reply-To: References: Message-ID: On Tue, 23 Nov 2021 11:00:51 GMT, Jose Pereda wrote: > This PR fixes a memory leak, as a follow-up of [JDK-8241840](https://bugs.openjdk.java.net/browse/JDK-8241840). > > The tests pass on desktop (Linux/macOS/Windows) and there is no regression on Android (see [JDK-8254605](https://bugs.openjdk.java.net/browse/JDK-8254605)). This pull request has now been integrated. Changeset: e694fb55 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/e694fb55692d3d438a947e2b0c307083e033ab30 Stats: 20 lines in 4 files changed: 11 ins; 6 del; 3 mod 8254956: [REDO] Memoryleak: Closed focused Stages are not collected with Monocle Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/677 From mstrauss at openjdk.java.net Tue Nov 23 16:03:21 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 23 Nov 2021 16:03:21 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v2] In-Reply-To: <42em-6h7Ur2ZVVzFOy7bPRCcTAKGRDEA2NJGb78MAyM=.537bb6b9-3ca7-4d72-b7cf-260719424903@github.com> References: <42em-6h7Ur2ZVVzFOy7bPRCcTAKGRDEA2NJGb78MAyM=.537bb6b9-3ca7-4d72-b7cf-260719424903@github.com> Message-ID: On Tue, 23 Nov 2021 15:33:49 GMT, Kevin Rushforth wrote: > This seems like an odd behavior to me, but if this is common practice among browsers, then it seems OK for us to do the same. In this case, it should be documented in the class docs of `Image`. I've tested this with Chrome and Edge, and these browsers go even further. If the image format has a detectable signature, the image will be displayed regardless of the specified MIME type (even if it is not an `image` type). The MIME type only matters for image formats without signature, like SVG. In this case, the image will not be displayed if the MIME type is incorrect. I think that a compromise works best for JavaFX. We probably don't want to allow plainly incorrect MIME types, but in cases where we know what the developer should have specified, a warning seems like a good nudge in the right direction. ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From mstrauss at openjdk.java.net Tue Nov 23 16:12:43 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 23 Nov 2021 16:12:43 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v3] In-Reply-To: References: Message-ID: > `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: > > 1. If the specified image subtype is not supported, an exception will be thrown. > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > > > Also, the javadoc of `javafx.scene.image.Image` incorrectly states: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > 95 * and the MIME type must either be empty or a subtype of the > 96 * {@code image} type. > > However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". > > The solution is to fix the documentation: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > + 95 * and the MIME type must be a subtype of the {@code image} type. > - 95 * and the MIME type must either be empty or a subtype of the > - 96 * {@code image} type. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Added documentation for MIME/data mismatch ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/676/files - new: https://git.openjdk.java.net/jfx/pull/676/files/73f1bb13..0167532b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=01-02 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/676.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/676/head:pull/676 PR: https://git.openjdk.java.net/jfx/pull/676 From kcr at openjdk.java.net Tue Nov 23 17:43:09 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 23 Nov 2021 17:43:09 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. I see that the `/contributor` command didn't work with the original contributor's GitHub username. You can instead take the contributor information from the HEAD commit of the pull request: `Naohiro Yoshimoto yosbits at gmail.com`. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From mstrauss at openjdk.java.net Tue Nov 23 23:29:10 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 23 Nov 2021 23:29:10 GMT Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v9] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 13:43:34 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with two additional commits since the last revision: > > - Remove remaining references to old JUnit 4.8.2 > - Upgrade to JUnit 4.13.2 The changes look good to me. The tests work as expected. ------------- Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.java.net/jfx/pull/633 From mstrauss at openjdk.java.net Wed Nov 24 03:43:42 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 24 Nov 2021 03:43:42 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v4] In-Reply-To: References: Message-ID: > `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: > > 1. If the specified image subtype is not supported, an exception will be thrown. > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > > > Also, the javadoc of `javafx.scene.image.Image` incorrectly states: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > 95 * and the MIME type must either be empty or a subtype of the > 96 * {@code image} type. > > However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". > > The solution is to fix the documentation: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > - 95 * and the MIME type must either be empty or a subtype of the > - 96 * {@code image} type. > + 95 * and the MIME type must be a subtype of the {@code image} type. > + 96 * The MIME type must match the image format of the data contained in > + 97 * the URL. In case of a mismatch between MIME type and image format, > + 98 * the image will be loaded if the image format can be determined by > + 99 * JavaFX, and a warning will be logged. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: Added test for image format without signature ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/676/files - new: https://git.openjdk.java.net/jfx/pull/676/files/0167532b..4cb5678a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=676&range=02-03 Stats: 89 lines in 8 files changed: 51 ins; 3 del; 35 mod Patch: https://git.openjdk.java.net/jfx/pull/676.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/676/head:pull/676 PR: https://git.openjdk.java.net/jfx/pull/676 From mstrauss at openjdk.java.net Wed Nov 24 04:28:24 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 24 Nov 2021 04:28:24 GMT Subject: RFR: 8276206: Rename TextBinding class to better express its purpose Message-ID: This PR renames `TextBinding` to `MnemonicInfo` and adds the following text to its javadoc: /** 33 + * Provides information about mnemonics contained within a string. ------------- Commit messages: - Rename TextBinding to MnemonicInfo Changes: https://git.openjdk.java.net/jfx/pull/678/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276206 Stats: 320 lines in 6 files changed: 146 ins; 146 del; 28 mod Patch: https://git.openjdk.java.net/jfx/pull/678.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/678/head:pull/678 PR: https://git.openjdk.java.net/jfx/pull/678 From mhanl at openjdk.java.net Wed Nov 24 09:14:18 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 24 Nov 2021 09:14:18 GMT Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost Message-ID: This PR fixes an issue where the `DatePicker` is not committing his value when the focus is lost. As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by the refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). ------------- Commit messages: - 8191995: Regression: DatePicker must commit on focusLost Changes: https://git.openjdk.java.net/jfx/pull/679/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=679&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8191995 Stats: 133 lines in 2 files changed: 133 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/679.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/679/head:pull/679 PR: https://git.openjdk.java.net/jfx/pull/679 From jpereda at openjdk.java.net Wed Nov 24 10:41:34 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 10:41:34 GMT Subject: RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView Message-ID: This PR improves drag and drop events on a WebView node, by generating the content from the dragboard only when the drag events starts, and not for every drag over event. A manual test is included that shows how the drag and drop experience improves, especially when dragging online images, as the time between each consecutive drag over event drops from hundreds of ms to tens of ms or even lower. This PR is somehow blocked by #668, as dragging some images fails on macOS. ------------- Commit messages: - Add manual test - Generate mime/values only when drag event starts Changes: https://git.openjdk.java.net/jfx/pull/680/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=680&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277133 Stats: 99 lines in 5 files changed: 89 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/680.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/680/head:pull/680 PR: https://git.openjdk.java.net/jfx/pull/680 From duke at openjdk.java.net Wed Nov 24 14:43:11 2021 From: duke at openjdk.java.net (yosbits) Date: Wed, 24 Nov 2021 14:43:11 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Mon, 22 Nov 2021 16:25:22 GMT, Michael Strau? wrote: >> I could move `int max = size();` outside the loop > > But why? The initialization block of a `for` statement is exactly where you'd put loop-scoped variables. This change significantly improves performance because the BitSet's size () method is an O (N) implementation. You may be wondering because it is O (1) in many other collections. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From kcr at openjdk.java.net Wed Nov 24 16:28:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 16:28:12 GMT Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2] In-Reply-To: References: Message-ID: <4AJNJUsoRubZaxpDrK2MncQv8_9MjIX7ME7l94FGjfs=.cea5a9cb-694b-43a0-8c33-f1da2177ea8e@github.com> On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] All my testing looks good. I confirm that the earlier reported problem on Linux is fixed. I am part way through the code review and so far haven't spotted any issues. ------------- PR: https://git.openjdk.java.net/jfx/pull/649 From kcr at openjdk.java.net Wed Nov 24 16:58:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 16:58:13 GMT Subject: RFR: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 11:19:13 GMT, Jose Pereda wrote: > This PR fixes an exception that can happen when dragging an image from a WebView on macOS. > > Dragging an image that is directly included like `` works fine, without exception. However, there are (at least) two other cases when the IAE is thrown: > > - Dragging an image that is part of an hyperlink, like ``. > - Dragging an image encoded as base64. > > The IAE happens only on macOS, where a native image is created in `GlassPasteboard.m` from an URL, and in those two cases the generated image has 0x0 dimensions: > > `` > > which leads to `ByteArrayFromPixels` being called with a null byte array. > > The included test reproduces the case by directly pushing the `MacPasteboard` content (instead of adding a more complex test with a webView and a drag and drop gesture). The fix looks good. The test looks good with one minor comment. tests/system/src/test/java/test/com/sun/glass/ui/mac/MacPasteboardTest.java line 56: > 54: public static void setup() throws Exception { > 55: Platform.startup(() -> { > 56: if (PlatformUtil.isMac()) { Minor: it might be cleaner to wrap the entire body of the `setup` and `teardown` methods in `if (PlatformUtil.isMac())` so that we don't even start FX on platforms other than macOS. ------------- PR: https://git.openjdk.java.net/jfx/pull/668 From kcr at openjdk.java.net Wed Nov 24 17:29:14 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 17:29:14 GMT Subject: RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 10:35:50 GMT, Jose Pereda wrote: > This PR improves drag and drop events on a WebView node, by generating the content from the dragboard only when the drag events starts, and not for every drag over event. > > A manual test is included that shows how the drag and drop experience improves, especially when dragging online images, as the time between each consecutive drag over event drops from hundreds of ms to tens of ms or even lower. > > This PR is somehow blocked by #668, as dragging some images fails on macOS. The fix looks good with one question, although it's likely fine as is. The manual test looks good, too (with one minor formatting issue). modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 1291: > 1289: setOnDragDone(event -> { > 1290: mimes = null; > 1291: values = null; Is it possible for `OnDragDone` to be missed? If so, I wonder if it is a good idea to also set `mimes` and `values` to `null` in the `OnDragDetected` handler? tests/manual/web/dnd/drag.html line 13: > 11: > 12: > 13: Minor: missing newline at end of file. ------------- PR: https://git.openjdk.java.net/jfx/pull/680 From kcr at openjdk.java.net Wed Nov 24 19:22:18 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 19:22:18 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: <2XfVqf-oqRVM1dbUrOp8Uk5gPDJiizGWgfF4OouZQnI=.ec49f10c-438f-459c-ab0b-a4d33aaa4ba1@github.com> On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. Looks good. I've tested this on all platforms and confirm that it fixes the issue with no regressions that I can see. I also confirm that the new test catches the problem (fails without and passes with the fix), and that this fixes [JDK-8273558](https://bugs.openjdk.java.net/browse/JDK-8273558), which can be closed as a duplicate. I left one minor formatting comment, but unless there are other changes, it probably isn't worth changing it. tests/system/src/test/resources/test/javafx/scene/web/testIObserver.html line 54: > 52:
Intersection ratio:
?
> 53: > 54: Minor: missing newline at end of file ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/664 From jpereda at openjdk.java.net Wed Nov 24 19:26:46 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 19:26:46 GMT Subject: RFR: 8160597: IllegalArgumentException when we initiate drag on Image [v2] In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 16:53:12 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Address feedback > > tests/system/src/test/java/test/com/sun/glass/ui/mac/MacPasteboardTest.java line 56: > >> 54: public static void setup() throws Exception { >> 55: Platform.startup(() -> { >> 56: if (PlatformUtil.isMac()) { > > Minor: it might be cleaner to wrap the entire body of the `setup` and `teardown` methods in `if (PlatformUtil.isMac())` so that we don't even start FX on platforms other than macOS. Done ------------- PR: https://git.openjdk.java.net/jfx/pull/668 From jpereda at openjdk.java.net Wed Nov 24 19:26:42 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 19:26:42 GMT Subject: RFR: 8160597: IllegalArgumentException when we initiate drag on Image [v2] In-Reply-To: References: Message-ID: > This PR fixes an exception that can happen when dragging an image from a WebView on macOS. > > Dragging an image that is directly included like `` works fine, without exception. However, there are (at least) two other cases when the IAE is thrown: > > - Dragging an image that is part of an hyperlink, like ``. > - Dragging an image encoded as base64. > > The IAE happens only on macOS, where a native image is created in `GlassPasteboard.m` from an URL, and in those two cases the generated image has 0x0 dimensions: > > `` > > which leads to `ByteArrayFromPixels` being called with a null byte array. > > The included test reproduces the case by directly pushing the `MacPasteboard` content (instead of adding a more complex test with a webView and a drag and drop gesture). Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/668/files - new: https://git.openjdk.java.net/jfx/pull/668/files/19f513ef..170715e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=668&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=668&range=00-01 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/668.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/668/head:pull/668 PR: https://git.openjdk.java.net/jfx/pull/668 From kcr at openjdk.java.net Wed Nov 24 19:38:12 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 19:38:12 GMT Subject: RFR: 8160597: IllegalArgumentException when we initiate drag on Image [v2] In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 19:26:42 GMT, Jose Pereda wrote: >> This PR fixes an exception that can happen when dragging an image from a WebView on macOS. >> >> Dragging an image that is directly included like `` works fine, without exception. However, there are (at least) two other cases when the IAE is thrown: >> >> - Dragging an image that is part of an hyperlink, like ``. >> - Dragging an image encoded as base64. >> >> The IAE happens only on macOS, where a native image is created in `GlassPasteboard.m` from an URL, and in those two cases the generated image has 0x0 dimensions: >> >> `` >> >> which leads to `ByteArrayFromPixels` being called with a null byte array. >> >> The included test reproduces the case by directly pushing the `MacPasteboard` content (instead of adding a more complex test with a webView and a drag and drop gesture). > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/668 From jpereda at openjdk.java.net Wed Nov 24 19:42:44 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 19:42:44 GMT Subject: RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView [v2] In-Reply-To: References: Message-ID: > This PR improves drag and drop events on a WebView node, by generating the content from the dragboard only when the drag events starts, and not for every drag over event. > > A manual test is included that shows how the drag and drop experience improves, especially when dragging online images, as the time between each consecutive drag over event drops from hundreds of ms to tens of ms or even lower. > > This PR is somehow blocked by #668, as dragging some images fails on macOS. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/680/files - new: https://git.openjdk.java.net/jfx/pull/680/files/95d245e7..2d1fbbbe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=680&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=680&range=00-01 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/680.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/680/head:pull/680 PR: https://git.openjdk.java.net/jfx/pull/680 From jpereda at openjdk.java.net Wed Nov 24 19:42:48 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 19:42:48 GMT Subject: RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView [v2] In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 17:23:30 GMT, Kevin Rushforth wrote: >> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: >> >> Address feedback > > modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 1291: > >> 1289: setOnDragDone(event -> { >> 1290: mimes = null; >> 1291: values = null; > > Is it possible for `OnDragDone` to be missed? If so, I wonder if it is a good idea to also set `mimes` and `values` to `null` in the `OnDragDetected` handler? It makes sense. Done. > tests/manual/web/dnd/drag.html line 13: > >> 11: >> 12: >> 13: > > Minor: missing newline at end of file. Done ------------- PR: https://git.openjdk.java.net/jfx/pull/680 From kcr at openjdk.java.net Wed Nov 24 19:53:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 19:53:04 GMT Subject: RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView [v2] In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 19:42:44 GMT, Jose Pereda wrote: >> This PR improves drag and drop events on a WebView node, by generating the content from the dragboard only when the drag events starts, and not for every drag over event. >> >> A manual test is included that shows how the drag and drop experience improves, especially when dragging online images, as the time between each consecutive drag over event drops from hundreds of ms to tens of ms or even lower. >> >> This PR is somehow blocked by #668, as dragging some images fails on macOS. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/680 From jpereda at openjdk.java.net Wed Nov 24 20:02:10 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 20:02:10 GMT Subject: Integrated: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: On Mon, 15 Nov 2021 11:19:13 GMT, Jose Pereda wrote: > This PR fixes an exception that can happen when dragging an image from a WebView on macOS. > > Dragging an image that is directly included like `` works fine, without exception. However, there are (at least) two other cases when the IAE is thrown: > > - Dragging an image that is part of an hyperlink, like ``. > - Dragging an image encoded as base64. > > The IAE happens only on macOS, where a native image is created in `GlassPasteboard.m` from an URL, and in those two cases the generated image has 0x0 dimensions: > > `` > > which leads to `ByteArrayFromPixels` being called with a null byte array. > > The included test reproduces the case by directly pushing the `MacPasteboard` content (instead of adding a more complex test with a webView and a drag and drop gesture). This pull request has now been integrated. Changeset: 6e6c7119 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/6e6c71190e5b9b07a323af0ab483dfc993302164 Stats: 157 lines in 5 files changed: 156 ins; 0 del; 1 mod 8160597: IllegalArgumentException when we initiate drag on Image Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/668 From jpereda at openjdk.java.net Wed Nov 24 20:12:07 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 20:12:07 GMT Subject: Integrated: 8277133: Dragboard contents retrieved all over again during a DND process on WebView In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 10:35:50 GMT, Jose Pereda wrote: > This PR improves drag and drop events on a WebView node, by generating the content from the dragboard only when the drag events starts, and not for every drag over event. > > A manual test is included that shows how the drag and drop experience improves, especially when dragging online images, as the time between each consecutive drag over event drops from hundreds of ms to tens of ms or even lower. > > This PR is somehow blocked by #668, as dragging some images fails on macOS. This pull request has now been integrated. Changeset: 423e1be1 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/423e1be18b62b92d3a2355d91243ee6fb29f237f Stats: 101 lines in 5 files changed: 91 ins; 0 del; 10 mod 8277133: Dragboard contents retrieved all over again during a DND process on WebView Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/680 From kcr at openjdk.java.net Wed Nov 24 23:21:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 24 Nov 2021 23:21:25 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Message-ID: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. ------------- Commit messages: - 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Changes: https://git.openjdk.java.net/jfx/pull/681/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=681&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277457 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/681.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/681/head:pull/681 PR: https://git.openjdk.java.net/jfx/pull/681 From jpereda at openjdk.java.net Wed Nov 24 23:54:05 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 24 Nov 2021 23:54:05 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") In-Reply-To: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: On Wed, 24 Nov 2021 23:05:05 GMT, Kevin Rushforth wrote: > As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. > > I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. Test works fine. Minor comments only. modules/javafx.web/src/main/java/com/sun/webkit/network/CookieJar.java line 47: > 45: @SuppressWarnings("removal") > 46: CookieHandler handler = > 47: AccessController.doPrivileged((PrivilegedAction) () -> CookieHandler.getDefault()); Not sure if there is a policy for this, but you could replace the lambda with the method reference? modules/javafx.web/src/main/java/com/sun/webkit/network/CookieJar.java line 71: > 69: @SuppressWarnings("removal") > 70: CookieHandler handler = > 71: AccessController.doPrivileged((PrivilegedAction) () -> CookieHandler.getDefault()); Same here ------------- Marked as reviewed by jpereda (Committer). PR: https://git.openjdk.java.net/jfx/pull/681 From kcr at openjdk.java.net Thu Nov 25 00:18:03 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Nov 2021 00:18:03 GMT Subject: RFR: 8276206: Rename TextBinding class to better express its purpose In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 04:23:59 GMT, Michael Strau? wrote: > This PR renames `TextBinding` to `MnemonicInfo` and adds the following text to its javadoc: > > /** > 33 + * Provides information about mnemonics contained within a string. Looks good. I'd like a review from one or both of @aghaisas or @kleopatra ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/678 From kcr at openjdk.java.net Thu Nov 25 00:29:36 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Nov 2021 00:29:36 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") [v2] In-Reply-To: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: > As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. > > I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Address review feedback: use method reference instead of lambda ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/681/files - new: https://git.openjdk.java.net/jfx/pull/681/files/ca436714..1d7a6064 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=681&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=681&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/681.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/681/head:pull/681 PR: https://git.openjdk.java.net/jfx/pull/681 From kcr at openjdk.java.net Thu Nov 25 00:29:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Nov 2021 00:29:42 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") [v2] In-Reply-To: References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: On Wed, 24 Nov 2021 23:40:01 GMT, Jose Pereda wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review feedback: use method reference instead of lambda > > modules/javafx.web/src/main/java/com/sun/webkit/network/CookieJar.java line 47: > >> 45: @SuppressWarnings("removal") >> 46: CookieHandler handler = >> 47: AccessController.doPrivileged((PrivilegedAction) () -> CookieHandler.getDefault()); > > Not sure if there is a policy for this, but you could replace the lambda with the method reference? Good idea. Done. > modules/javafx.web/src/main/java/com/sun/webkit/network/CookieJar.java line 71: > >> 69: @SuppressWarnings("removal") >> 70: CookieHandler handler = >> 71: AccessController.doPrivileged((PrivilegedAction) () -> CookieHandler.getDefault()); > > Same here Done. ------------- PR: https://git.openjdk.java.net/jfx/pull/681 From jpereda at openjdk.java.net Thu Nov 25 00:36:05 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 25 Nov 2021 00:36:05 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") [v2] In-Reply-To: References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: On Thu, 25 Nov 2021 00:29:36 GMT, Kevin Rushforth wrote: >> As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. >> >> I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback: use method reference instead of lambda Marked as reviewed by jpereda (Committer). ------------- PR: https://git.openjdk.java.net/jfx/pull/681 From martin at martinfox.com Thu Nov 25 00:55:23 2021 From: martin at martinfox.com (Martin Fox) Date: Wed, 24 Nov 2021 16:55:23 -0800 Subject: Cleaning up warnings in the Mac glass code Message-ID: The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn?t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea. I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There?s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing. Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants. You can see the changes I made in my github repository (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple commits, the first and biggest catching most of the easy stuff like constant renaming. In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught. From kcr at openjdk.java.net Thu Nov 25 01:03:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 25 Nov 2021 01:03:08 GMT Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin [v5] In-Reply-To: References: Message-ID: On Fri, 19 Nov 2021 11:42:16 GMT, Jeanette Winzenburg wrote: >> Cleanup of Tree-/TableRowSkin to support switching skins >> >> The misbehavior/s >> - memory leaks due to manually registered listeners that were not removed >> - side-effects due to listeners still active on old skin (like NPEs) >> >> Fix >> - use skin api for all listener registration (for automatic removal in dispose) >> - ~~do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))~~ not handled here, see [JDK-8277000](https://bugs.openjdk.java.net/browse/JDK-8277000) >> >> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. >> >> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) > > Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: > > changes as requested in review Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/632 From michaelstrau2 at gmail.com Thu Nov 25 03:44:55 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Thu, 25 Nov 2021 04:44:55 +0100 Subject: Cleaning up warnings in the Mac glass code In-Reply-To: References: Message-ID: That's a good idea. In general, warnings should always be treated as errors. On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote: > > The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn?t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea. > > I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There?s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing. > > Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants. > > You can see the changes I made in my github repository (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple commits, the first and biggest catching most of the easy stuff like constant renaming. > > In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught. > > > > From craigraw at gmail.com Thu Nov 25 09:36:25 2021 From: craigraw at gmail.com (Craig Raw) Date: Thu, 25 Nov 2021 11:36:25 +0200 Subject: Pull down menus don't work in XFCE Message-ID: Hi, I have multiple users reporting that pull-down menus don't work correctly on the XFCE window manager, amongst others. Menus close immediately after being opened and appear in the wrong location. This problem is discussed in https://bugs.openjdk.java.net/browse/JDK-8251240 and https://github.com/sparrowwallet/sparrow/issues/170. However, the workarounds noted there do not appear to solve the problem. JavaFX 16, OpenJDK 16. Given the popularity of this window manager I'd appreciate any other workarounds. Thanks, Craig From fastegal at openjdk.java.net Thu Nov 25 12:49:15 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Nov 2021 12:49:15 GMT Subject: Integrated: 8274061: Tree-/TableRowSkin: misbehavior on switching skin In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 16:01:38 GMT, Jeanette Winzenburg wrote: > Cleanup of Tree-/TableRowSkin to support switching skins > > The misbehavior/s > - memory leaks due to manually registered listeners that were not removed > - side-effects due to listeners still active on old skin (like NPEs) > > Fix > - use skin api for all listener registration (for automatic removal in dispose) > - ~~do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))~~ not handled here, see [JDK-8277000](https://bugs.openjdk.java.net/browse/JDK-8277000) > > Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins. > > Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065) This pull request has now been integrated. Changeset: d14be6a8 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/d14be6a811591df70ef99fd6ec5448423be6fb7d Stats: 1086 lines in 8 files changed: 1025 ins; 44 del; 17 mod 8274061: Tree-/TableRowSkin: misbehavior on switching skin Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/632 From fastegal at openjdk.java.net Thu Nov 25 12:52:03 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Nov 2021 12:52:03 GMT Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: > This PR fixes an issue where the `DatePicker` is not committing his value when the focus is lost. > As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by the refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) > > The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. > > Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) > -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). will review thoroughly soon - for now just a comment to get rid of that annoying yellow bar at the top ;) On first skim, it looks straightforward - adding the api same as for combo/spinner. I think you might get going and flesh out the csr. ------------- PR: https://git.openjdk.java.net/jfx/pull/679 From aghaisas at openjdk.java.net Thu Nov 25 14:34:13 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 25 Nov 2021 14:34:13 GMT Subject: RFR: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound [v3] In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 14:04:01 GMT, Abhinay Agarwal wrote: >> PathElements were skipped in AreaChart if the data point were outside axis bounds and had duplicate value for either x or y. This is now fixed with this PR. > > Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: > > Update line ending Marked as reviewed by aghaisas (Reviewer). Looks good to me. ------------- PR: https://git.openjdk.java.net/jfx/pull/667 From fastegal at openjdk.java.net Thu Nov 25 15:52:26 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 25 Nov 2021 15:52:26 GMT Subject: RFR: 8272118: ListViewSkin et al: must not cancel edit on scrolling Message-ID: Issue was that mouse pressed on the scrollbars of all virtualized controls cancelled the edit. That's inconsistent with other scroll triggers (mouseWheel, programmatic). Fixed by removing the cancel. Added tests that failed/passed before/after the fix. Also added tests that passed both before/after to guarantee that required functionality of the mouse pressed (= requesting focus on the control if needed) is still working. ------------- Commit messages: - 8272118: ListViewSkin et al: must not cancel edit on scrolling Changes: https://git.openjdk.java.net/jfx/pull/682/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=682&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272118 Stats: 594 lines in 6 files changed: 566 ins; 28 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/682.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/682/head:pull/682 PR: https://git.openjdk.java.net/jfx/pull/682 From michaelstrau2 at gmail.com Fri Nov 26 05:03:50 2021 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 26 Nov 2021 06:03:50 +0100 Subject: Cross-compiling JavaFX for Apple ARM64 Message-ID: JavaFX can be cross-compiled for Apple ARM64 on an Intel Mac by specifying TARGET_ARCH=arm64 for the Gradle build. This works for all native libraries except for WebKit, because TARGET_ARCH is not passed to WebKit's cmake script. Are there any plans to support this particular scenario? From duke at openjdk.java.net Fri Nov 26 05:27:07 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 26 Nov 2021 05:27:07 GMT Subject: Integrated: 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound In-Reply-To: References: Message-ID: On Fri, 12 Nov 2021 09:44:47 GMT, Abhinay Agarwal wrote: > PathElements were skipped in AreaChart if the data point were outside axis bounds and had duplicate value for either x or y. This is now fixed with this PR. This pull request has now been integrated. Changeset: 0dbdec4a Author: Abhinay Agarwal Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/0dbdec4af97063248758d917434d09242af42729 Stats: 592 lines in 3 files changed: 581 ins; 1 del; 10 mod 8276490: Incorrect path for duplicate x and y values, when path falls outside axis bound Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/667 From fastegal at openjdk.java.net Fri Nov 26 11:26:06 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Fri, 26 Nov 2021 11:26:06 GMT Subject: RFR: 8276206: Rename TextBinding class to better express its purpose In-Reply-To: References: Message-ID: <9bhuiyTRVNGFIUdC_YXX3o0Vm4r9X3zIP4n5WShUGjA=.340aab99-429a-46d5-b778-2c0f78ceab23@github.com> On Wed, 24 Nov 2021 04:23:59 GMT, Michael Strau? wrote: > This PR renames `TextBinding` to `MnemonicInfo` and adds the following text to its javadoc: > > /** > 33 + * Provides information about mnemonics contained within a string. looks good (modulo our disagreement on whether or not to do it at all :) ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/678 From duke at openjdk.java.net Fri Nov 26 12:58:06 2021 From: duke at openjdk.java.net (yosbits) Date: Fri, 26 Nov 2021 12:58:06 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. tests/manual/controls/SelectListViewTest.java line 18: > 16: // final int ROW_COUNT = 10_000_000; > 17: // final int ROW_COUNT = 7_000; > 18: There is a duplication of the number of test data. My test is below. ``` Java public class SelectListViewTest extends Application { final int ROW_COUNT = 70_000; // final int ROW_COUNT = 400_000; // final int ROW_COUNT = 10_000_000; // final int ROW_COUNT = 7_000; ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Fri Nov 26 13:13:12 2021 From: duke at openjdk.java.net (yosbits) Date: Fri, 26 Nov 2021 13:13:12 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. tests/manual/controls/SelectTableViewTest.java line 19: > 17: // final int ROW_COUNT = 80_000; > 18: // final int ROW_COUNT = 50_000; > 19: // final int ROW_COUNT = 8_000; The number is meaningful because it is the number of data I used to show the improvement effect in the original PR. Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) TableView selectAll: 8_000-> 700_000 selectRange: 7_000-> 50_000 ``` Java public class SelectTableViewTest extends Application { final int ROW_COUNT = 700_000; // final int ROW_COUNT = 80_000; // final int ROW_COUNT = 50_000; // final int ROW_COUNT = 8_000; final int COL_COUNT = 3; ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From mstrauss at openjdk.java.net Fri Nov 26 14:03:06 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 26 Nov 2021 14:03:06 GMT Subject: Integrated: 8276206: Rename TextBinding class to better express its purpose In-Reply-To: References: Message-ID: <10Q5sQIyQqQwzXiTjh6c2vnx1ZRuH2yU0hWAKdABsIw=.60747a0c-c239-46ac-aa8f-a067185b9745@github.com> On Wed, 24 Nov 2021 04:23:59 GMT, Michael Strau? wrote: > This PR renames `TextBinding` to `MnemonicInfo` and adds the following text to its javadoc: > > /** > 33 + * Provides information about mnemonics contained within a string. This pull request has now been integrated. Changeset: fc3792d5 Author: Michael Strau? Committer: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/fc3792d5cb39cd3706f28953c3f97bdecc07bba6 Stats: 320 lines in 6 files changed: 146 ins; 146 del; 28 mod 8276206: Rename TextBinding class to better express its purpose Reviewed-by: kcr, fastegal ------------- PR: https://git.openjdk.java.net/jfx/pull/678 From mhanl at openjdk.java.net Fri Nov 26 14:45:07 2021 From: mhanl at openjdk.java.net (Marius Hanl) Date: Fri, 26 Nov 2021 14:45:07 GMT Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: References: Message-ID: <2hpUBcfd6A12CeZhOaILED64hcpLFGEvfyIS60o4RoA=.20234c35-5c80-40dd-9b7d-fe88c8150180@github.com> On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: > This PR fixes an issue where the `DatePicker` is not committing his value when the focus is lost. > As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by the refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) > > The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. > > Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) > -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). I just finished the CSR. :) ------------- PR: https://git.openjdk.java.net/jfx/pull/679 From duke at openjdk.java.net Fri Nov 26 19:33:37 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 26 Nov 2021 19:33:37 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v2] In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Remove duplicate entry for test data ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/673/files - new: https://git.openjdk.java.net/jfx/pull/673/files/05f5df32..3158acd7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/673/head:pull/673 PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Fri Nov 26 19:33:41 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 26 Nov 2021 19:33:41 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v2] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 26 Nov 2021 12:54:59 GMT, yosbits wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove duplicate entry for test data > > tests/manual/controls/SelectListViewTest.java line 18: > >> 16: // final int ROW_COUNT = 10_000_000; >> 17: // final int ROW_COUNT = 7_000; >> 18: > > There is a duplication of the number of test data. > > My test is below. > > ``` Java > public class SelectListViewTest extends Application { > final int ROW_COUNT = 70_000; > // final int ROW_COUNT = 400_000; > // final int ROW_COUNT = 10_000_000; > // final int ROW_COUNT = 7_000; Thanks. I have fixed this. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Fri Nov 26 19:49:37 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 26 Nov 2021 19:49:37 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: > This work improves the performance of `MultipleSelectionModel` over large data sets by caching some values and avoiding unnecessary calls to `SelectedIndicesList#size`. It further improves the performance by reducing the number of iterations required to find the index of an element in the BitSet. > > The work is based on [an abandoned patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs > > There are currently 2 manual tests for this fix. Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: Update ROW_COUNT to 700_000 ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/673/files - new: https://git.openjdk.java.net/jfx/pull/673/files/3158acd7..8196b348 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=673&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/673.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/673/head:pull/673 PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Fri Nov 26 19:49:41 2021 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Fri, 26 Nov 2021 19:49:41 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 26 Nov 2021 13:10:08 GMT, yosbits wrote: >> Abhinay Agarwal has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ROW_COUNT to 700_000 > > tests/manual/controls/SelectTableViewTest.java line 19: > >> 17: // final int ROW_COUNT = 80_000; >> 18: // final int ROW_COUNT = 50_000; >> 19: // final int ROW_COUNT = 8_000; > > The number is meaningful because it is the number of data I used to show the improvement effect in the original PR. > > Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) > > TableView > > selectAll: 8_000-> 700_000 > selectRange: 7_000-> 50_000 > > > > > > ``` Java > public class SelectTableViewTest extends Application { > > final int ROW_COUNT = 700_000; > // final int ROW_COUNT = 80_000; > // final int ROW_COUNT = 50_000; > // final int ROW_COUNT = 8_000; > final int COL_COUNT = 3; I reduced ROW_COUNT from 700_000 to 70_000 as the tests were taking a few seconds to run on my machine. I have reverted these now. Nevertheless, time taken to run a test have a number of variables. Depending on the machine the tests are run, it may not necessarily always take 3 seconds :) ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From duke at openjdk.java.net Fri Nov 26 21:05:07 2021 From: duke at openjdk.java.net (yosbits) Date: Fri, 26 Nov 2021 21:05:07 GMT Subject: RFR: 8197991: Selecting many items in a TableView is very slow [v3] In-Reply-To: References: <8Ehgt-77SpRauD55qhTIq9BnqJhpRJDHVKhD5UoH9Hg=.0f942851-f14e-4c29-85d9-bab6031195ae@github.com> Message-ID: On Fri, 26 Nov 2021 19:44:14 GMT, Abhinay Agarwal wrote: >> tests/manual/controls/SelectTableViewTest.java line 19: >> >>> 17: // final int ROW_COUNT = 80_000; >>> 18: // final int ROW_COUNT = 50_000; >>> 19: // final int ROW_COUNT = 8_000; >> >> The number is meaningful because it is the number of data I used to show the improvement effect in the original PR. >> >> Reference value of the number of data that can be handled within 3 seconds of processing time (before-> after) >> >> TableView >> >> selectAll: 8_000-> 700_000 >> selectRange: 7_000-> 50_000 >> >> >> >> >> >> ``` Java >> public class SelectTableViewTest extends Application { >> >> final int ROW_COUNT = 700_000; >> // final int ROW_COUNT = 80_000; >> // final int ROW_COUNT = 50_000; >> // final int ROW_COUNT = 8_000; >> final int COL_COUNT = 3; > > I reduced ROW_COUNT from 700_000 to 70_000 as the tests were taking a few seconds to run on my machine. I have reverted these now. Nevertheless, time taken to run a test have a number of variables. Depending on the machine the tests are run, it may not necessarily always take 3 seconds :) The processing time changes for each operation. You probably adapted to the slow operation (selectRange). You can comment it out, but 700_000 is for selectAll. Although it depends on the device, the environment I have confirmed is his MacBook Pro in 2016. ------------- PR: https://git.openjdk.java.net/jfx/pull/673 From jvos at openjdk.java.net Mon Nov 29 12:01:31 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 12:01:31 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 Message-ID: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> After (re)setting the number of elements, make sure to do at least some estimation of the total size. Added a testcase for this scenario. ------------- Commit messages: - After (re)setting the number of elements, make sure to do at least some estimation of the total size. Changes: https://git.openjdk.java.net/jfx/pull/683/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276553 Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/683.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/683/head:pull/683 PR: https://git.openjdk.java.net/jfx/pull/683 From mstrauss at openjdk.java.net Mon Nov 29 14:41:14 2021 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 29 Nov 2021 14:41:14 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 In-Reply-To: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Mon, 29 Nov 2021 11:56:45 GMT, Johan Vos wrote: > After (re)setting the number of elements, make sure to do at least some estimation of the total size. > Added a testcase for this scenario. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 903: > 901: recalculateAndImproveEstimatedSize(2); > 902: > 903: cellCount.set(value); Can this be implemented in a way that doesn't violate the property contract? Since this property is public API, `setCellCount(int)` should just call `cellCountProperty().set(int)`. Maybe you can extract the composite operation here into a private method and use that instead of `setCellCount(int)`. `position` has the same problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Mon Nov 29 15:12:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Nov 2021 15:12:11 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. @aghaisas or @arapte can one of you be the second reviewer? ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From jvos at openjdk.java.net Mon Nov 29 15:37:26 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 15:37:26 GMT Subject: [jfx11u] RFR: 8160597: 6e6c71190e5b9b07a323af0ab483dfc993302164 Message-ID: clean backport from 18 to 11u ------------- Commit messages: - backport 8160597 Changes: https://git.openjdk.java.net/jfx11u/pull/62/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=62&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8160597 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/62.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/62/head:pull/62 PR: https://git.openjdk.java.net/jfx11u/pull/62 From kcr at openjdk.java.net Mon Nov 29 16:34:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Nov 2021 16:34:06 GMT Subject: [jfx11u] RFR: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: <9QzpBWLviXsysHCEeXirPqT6f-FQbTZXxtAcuTOT6M8=.8622a791-e57a-4456-9468-91e4154fc7a6@github.com> On Mon, 29 Nov 2021 15:32:44 GMT, Johan Vos wrote: > clean backport from 18 to 11u This looks like it is missing part of the original patch, which is why it isn't marked clean. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/62 From fastegal at openjdk.java.net Mon Nov 29 16:58:06 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Mon, 29 Nov 2021 16:58:06 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Mon, 29 Nov 2021 14:38:10 GMT, Michael Strau? wrote: >> After (re)setting the number of elements, make sure to do at least some estimation of the total size. >> Added a testcase for this scenario. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 903: > >> 901: recalculateAndImproveEstimatedSize(2); >> 902: >> 903: cellCount.set(value); > > Can this be implemented in a way that doesn't violate the property contract? Since this property is public API, `setCellCount(int)` should just call `cellCountProperty().set(int)`. Maybe you can extract the composite operation here into a private method and use that instead of `setCellCount(int)`. > > `position` has the same problem. good catch! the "additional" stuff typically is done in the properties' invalidated .. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Mon Nov 29 17:02:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Nov 2021 17:02:13 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Mon, 29 Nov 2021 16:55:16 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 903: >> >>> 901: recalculateAndImproveEstimatedSize(2); >>> 902: >>> 903: cellCount.set(value); >> >> Can this be implemented in a way that doesn't violate the property contract? Since this property is public API, `setCellCount(int)` should just call `cellCountProperty().set(int)`. Maybe you can extract the composite operation here into a private method and use that instead of `setCellCount(int)`. >> >> `position` has the same problem. > > good catch! the "additional" stuff typically is done in the properties' invalidated .. Exactly. This ensures consistent behavior regardless of how a property value is set. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Mon Nov 29 17:02:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 29 Nov 2021 17:02:13 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Mon, 29 Nov 2021 16:59:02 GMT, Kevin Rushforth wrote: >> good catch! the "additional" stuff typically is done in the properties' invalidated .. > > Exactly. This ensures consistent behavior regardless of how a property value is set. I should add that this looks like a preexisting problem, but one that would be good to fix if possible. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kevin.rushforth at oracle.com Mon Nov 29 18:10:02 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Nov 2021 10:10:02 -0800 Subject: Cleaning up warnings in the Mac glass code In-Reply-To: References: Message-ID: <9353b78d-0165-61fd-d4b0-d5fe99d6f6e5@oracle.com> I agree that this would be a good thing to aim for as long as we exclude deprecation warnings (given Apple's penchant for deprecating large API surfaces such as OpenGL or the older accessibility APIs we really can't have the use of deprecated APIs be an error). -- Kevin On 11/24/2021 7:44 PM, Michael Strau? wrote: > That's a good idea. In general, warnings should always be treated as errors. > > > On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote: >> The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn?t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea. >> >> I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There?s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing. >> >> Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants. >> >> You can see the changes I made in my github repository (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple commits, the first and biggest catching most of the easy stuff like constant renaming. >> >> In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught. >> >> >> >> From kevin.rushforth at oracle.com Mon Nov 29 18:34:37 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Nov 2021 10:34:37 -0800 Subject: Cross-compiling JavaFX for Apple ARM64 In-Reply-To: References: Message-ID: <5bc8f90c-6708-bfda-f85c-09e7b2e8e3b7@oracle.com> Not currently. I admit it would be nice, but there are some challenges that make this difficult. One of the main ones that Johan discovered is that the WebKit build system builds some tools (executable binaries) that are then used in later stages of the build. This means that those tools need to be built using the host architecture and not the target architecture, but at least one of them (LLIntOffsetsExtractor) depends on one of the WebKit modules, so then that would need to be built initially using the host architecture so that the tool could be built, and then rebuilt using the target arch. I have no idea how much work it would be to solve this. -- Kevin On 11/25/2021 9:03 PM, Michael Strau? wrote: > JavaFX can be cross-compiled for Apple ARM64 on an Intel Mac by > specifying TARGET_ARCH=arm64 for the Gradle build. > This works for all native libraries except for WebKit, because > TARGET_ARCH is not passed to WebKit's cmake script. Are there any > plans to support this particular scenario? From jvos at openjdk.java.net Mon Nov 29 18:46:13 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 18:46:13 GMT Subject: [jfx11u] Withdrawn: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 15:32:44 GMT, Johan Vos wrote: > clean backport from 18 to 11u This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jfx11u/pull/62 From jvos at openjdk.java.net Mon Nov 29 18:46:13 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 18:46:13 GMT Subject: [jfx11u] RFR: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 15:32:44 GMT, Johan Vos wrote: > clean backport from 18 to 11u I'll redo it properly ------------- PR: https://git.openjdk.java.net/jfx11u/pull/62 From jvos at openjdk.java.net Mon Nov 29 18:52:29 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 18:52:29 GMT Subject: [jfx11u] RFR: 8160597: IllegalArgumentException when we initiate drag on Image Message-ID: Clean backport for 8160597: IllegalArgumentException when we initiate drag on Image ------------- Commit messages: - 8160597: IllegalArgumentException when we initiate drag on Image Changes: https://git.openjdk.java.net/jfx11u/pull/63/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=63&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8160597 Stats: 157 lines in 5 files changed: 156 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/63.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/63/head:pull/63 PR: https://git.openjdk.java.net/jfx11u/pull/63 From jvos at openjdk.java.net Mon Nov 29 19:00:31 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 19:00:31 GMT Subject: [jfx11u] RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView Message-ID: <136-UjfPPaIgUuT2Cd_wiiGydWJqbpSt1hAJiQJqGa0=.28a32415-a5a3-428e-8624-2a3ffe80bf62@github.com> Clean backport of 8277133: Dragboard contents retrieved all over again during a DND process on WebView ------------- Commit messages: - 8277133: Dragboard contents retrieved all over again during a DND process on WebView Changes: https://git.openjdk.java.net/jfx11u/pull/64/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=64&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277133 Stats: 101 lines in 5 files changed: 91 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx11u/pull/64.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/64/head:pull/64 PR: https://git.openjdk.java.net/jfx11u/pull/64 From jvos at openjdk.java.net Mon Nov 29 19:05:29 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 19:05:29 GMT Subject: [jfx17u] RFR: 8160597: IllegalArgumentException when we initiate drag on Image Message-ID: Clean backport of 8160597: IllegalArgumentException when we initiate drag on Image ------------- Commit messages: - 8160597: IllegalArgumentException when we initiate drag on Image Changes: https://git.openjdk.java.net/jfx17u/pull/22/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=22&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8160597 Stats: 157 lines in 5 files changed: 156 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/22.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/22/head:pull/22 PR: https://git.openjdk.java.net/jfx17u/pull/22 From jvos at openjdk.java.net Mon Nov 29 19:06:33 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Mon, 29 Nov 2021 19:06:33 GMT Subject: [jfx17u] RFR: 8277133: Dragboard contents retrieved all over again during a DND process on WebView Message-ID: Clean backport of 8277133: Dragboard contents retrieved all over again during a DND process on WebView ------------- Commit messages: - 8277133: Dragboard contents retrieved all over again during a DND process on WebView Changes: https://git.openjdk.java.net/jfx17u/pull/23/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=23&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277133 Stats: 101 lines in 5 files changed: 91 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jfx17u/pull/23.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/23/head:pull/23 PR: https://git.openjdk.java.net/jfx17u/pull/23 From arapte at openjdk.java.net Tue Nov 30 06:43:10 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 30 Nov 2021 06:43:10 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. Looks good to me. Shall re-approve when PR is updated as per Kevin's suggestion. ------------- Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/664 From jvos at openjdk.java.net Tue Nov 30 08:09:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 08:09:08 GMT Subject: [jfx17u] Integrated: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: <4mSJObRAyNB9EQ02DnX2mT0p4xL_15Pkco0O0ztWLas=.e667642f-b3ae-4f68-99e7-d04206e615f4@github.com> On Mon, 29 Nov 2021 18:58:24 GMT, Johan Vos wrote: > Clean backport of 8160597: IllegalArgumentException when we initiate drag on Image This pull request has now been integrated. Changeset: f5680fe5 Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/f5680fe5feb1a0db1ecaa2830a273289d30268fa Stats: 157 lines in 5 files changed: 156 ins; 0 del; 1 mod 8160597: IllegalArgumentException when we initiate drag on Image Backport-of: 6e6c71190e5b9b07a323af0ab483dfc993302164 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/22 From jvos at openjdk.java.net Tue Nov 30 08:09:11 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 08:09:11 GMT Subject: [jfx11u] Integrated: 8160597: IllegalArgumentException when we initiate drag on Image In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 18:46:38 GMT, Johan Vos wrote: > Clean backport for 8160597: IllegalArgumentException when we initiate drag on Image This pull request has now been integrated. Changeset: 2ef24bef Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/2ef24bef0abe20305998710b12bb369becc44b77 Stats: 157 lines in 5 files changed: 156 ins; 0 del; 1 mod 8160597: IllegalArgumentException when we initiate drag on Image Backport-of: 6e6c71190e5b9b07a323af0ab483dfc993302164 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/63 From jvos at openjdk.java.net Tue Nov 30 10:25:07 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 10:25:07 GMT Subject: [jfx11u] Integrated: 8277133: Dragboard contents retrieved all over again during a DND process on WebView In-Reply-To: <136-UjfPPaIgUuT2Cd_wiiGydWJqbpSt1hAJiQJqGa0=.28a32415-a5a3-428e-8624-2a3ffe80bf62@github.com> References: <136-UjfPPaIgUuT2Cd_wiiGydWJqbpSt1hAJiQJqGa0=.28a32415-a5a3-428e-8624-2a3ffe80bf62@github.com> Message-ID: On Mon, 29 Nov 2021 18:55:04 GMT, Johan Vos wrote: > Clean backport of > 8277133: Dragboard contents retrieved all over again during a DND process on WebView This pull request has now been integrated. Changeset: 6a1b038e Author: Johan Vos URL: https://git.openjdk.java.net/jfx11u/commit/6a1b038e294ab6f1e98faa51befcd476846cc766 Stats: 101 lines in 5 files changed: 91 ins; 0 del; 10 mod 8277133: Dragboard contents retrieved all over again during a DND process on WebView Backport-of: 423e1be18b62b92d3a2355d91243ee6fb29f237f ------------- PR: https://git.openjdk.java.net/jfx11u/pull/64 From jvos at openjdk.java.net Tue Nov 30 10:25:11 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 10:25:11 GMT Subject: [jfx17u] Integrated: 8277133: Dragboard contents retrieved all over again during a DND process on WebView In-Reply-To: References: Message-ID: On Mon, 29 Nov 2021 19:01:16 GMT, Johan Vos wrote: > Clean backport of 8277133: Dragboard contents retrieved all over again during a DND process on WebView This pull request has now been integrated. Changeset: 4719350f Author: Johan Vos URL: https://git.openjdk.java.net/jfx17u/commit/4719350f26737c28206c38b297a1a6f94a3d6a63 Stats: 101 lines in 5 files changed: 91 ins; 0 del; 10 mod 8277133: Dragboard contents retrieved all over again during a DND process on WebView Backport-of: 423e1be18b62b92d3a2355d91243ee6fb29f237f ------------- PR: https://git.openjdk.java.net/jfx17u/pull/23 From jvos at openjdk.java.net Tue Nov 30 11:02:41 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 11:02:41 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: > After (re)setting the number of elements, make sure to do at least some estimation of the total size. > Added a testcase for this scenario. Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Move functionality in the setCellCount() to the invalidated block. Some hard numbers used in tests (counters for evaluations) were changed because of this. Instead of relying on hard values, I modified the failing was into relative ones. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/683/files - new: https://git.openjdk.java.net/jfx/pull/683/files/1a0ce697..b3fe2756 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=683&range=00-01 Stats: 18 lines in 4 files changed: 6 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/683.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/683/head:pull/683 PR: https://git.openjdk.java.net/jfx/pull/683 From jvos at openjdk.java.net Tue Nov 30 11:02:42 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 11:02:42 GMT Subject: RFR: 8276553: ListView scrollTo() is broken after fix for JDK-8089589 [v2] In-Reply-To: References: <8wZ60GDsTH3eBTHcKx7Ph4QyY8wDR5tRPUD0Ptlgn3g=.92d37f43-6113-4b93-b6ad-dc6d15b0ecd5@github.com> Message-ID: On Mon, 29 Nov 2021 17:00:10 GMT, Kevin Rushforth wrote: >> Exactly. This ensures consistent behavior regardless of how a property value is set. > > I should add that this looks like a preexisting problem, but one that would be good to fix if possible. Thanks for catching. I moved the additional code into the invalidated block, at the appropriate places. Note that this caused some changes in the flow at runtime, where the number of evaluations of `updateItem` changed. Those changes are of constant order (and not linear with the amount of cells), and I made some changes to the test as they depended on hard numbers. ------------- PR: https://git.openjdk.java.net/jfx/pull/683 From kcr at openjdk.java.net Tue Nov 30 12:12:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Nov 2021 12:12:22 GMT Subject: RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") [v2] In-Reply-To: References: <6sHVZJkC7SrALTF2H1IIEqpa8yYM9qLFxtZQPQBH5xI=.f494d030-5905-46a1-ab49-a36f352727ae@github.com> Message-ID: <-CgC_GDT_HA0EO-1OjmDiPUMm2kpK8YlespXjLro434=.9156a276-2c5a-4f4f-8293-be81de113c08@github.com> On Thu, 25 Nov 2021 00:29:36 GMT, Kevin Rushforth wrote: >> As indicated in the bug report, WebView needs to call to `CookieManager::getDefault` within a `doPrivileged` block so that it will work when a security manager is enabled. There are two calls in `com.sun.webkit.network.CookieJar` that are not wrapped in a `doPrivileged`. >> >> I added a manual test (since it requires loading a page over http/https which we can't do in our automated tests) based on the test program that was attached to JBS. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Address review feedback: use method reference instead of lambda @aghaisas can you be the second reviewer on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/681 From kcr at openjdk.java.net Tue Nov 30 12:12:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Nov 2021 12:12:23 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 06:40:16 GMT, Ambarish Rapte wrote: > Looks good to me. Shall re-approve when PR is updated as per Kevin's suggestion. @jperedadnr My suggestion was optional, so you can either integrate it as-is or make the (minor) change and we'll re-approve. ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From jpereda at openjdk.java.net Tue Nov 30 12:18:50 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 30 Nov 2021 12:18:50 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver [v2] In-Reply-To: References: Message-ID: > This PR enables intersection observer support for WebKit, and includes a system test. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/664/files - new: https://git.openjdk.java.net/jfx/pull/664/files/bf0f6437..11d44443 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=664&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=664&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/664.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/664/head:pull/664 PR: https://git.openjdk.java.net/jfx/pull/664 From jpereda at openjdk.java.net Tue Nov 30 12:18:51 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 30 Nov 2021 12:18:51 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. No problem, I just pushed the minor change. ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From kcr at openjdk.java.net Tue Nov 30 12:25:05 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Nov 2021 12:25:05 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver [v2] In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 12:18:50 GMT, Jose Pereda wrote: >> This PR enables intersection observer support for WebKit, and includes a system test. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From tsayao at openjdk.java.net Tue Nov 30 12:28:05 2021 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 30 Nov 2021 12:28:05 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7] In-Reply-To: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> References: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> Message-ID: On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Minimize changes It would be nice to have this fix on jfx 17, since currently the issue causes random windows to be focused and it's very confusing to the end user. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From fastegal at openjdk.java.net Tue Nov 30 12:37:27 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Nov 2021 12:37:27 GMT Subject: RFR: 8187307: ListView, TableView, TreeView: receives editCancel event when edit is committed Message-ID: The misbehaviour was that an edit handler received both a commit and cancel event when cell commitEdit is called. That happened whenever a collaborator reset the controls editing state (either directly or indirectly) while processing the editCommit event. The reason was that the cell had not yet updated its own editing state when receiving the change of editing from the control. Fix is to update cell's editing state before firing the event, that is change the sequence or method calls from fire/super.commit to super.commit/fire. Added tests that fail/pass before/after the fix. ------------- Commit messages: - 8187307: LisingtView, TableView, TreeView: receives editCancel event Changes: https://git.openjdk.java.net/jfx/pull/684/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=684&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8187307 Stats: 158 lines in 8 files changed: 117 ins; 29 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/684.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/684/head:pull/684 PR: https://git.openjdk.java.net/jfx/pull/684 From kcr at openjdk.java.net Tue Nov 30 13:31:28 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Nov 2021 13:31:28 GMT Subject: RFR: 8273089: Deprecate JavaFX GTK 2 library for removal Message-ID: <04oKL_ipIdgy8kBvGpyl2hNCxDzomHZlSRkchK9qrC0=.eb5a4d8d-9132-41fd-9a96-4f7738e2d1a7@github.com> This PR deprecates the JavaFX glass GTK 2 library for removal. Since there isn't an associated API, the mechanism for doing this is to print a "deprecated for removal" warning message when the `glassgtk2` library it is loaded. A message is printed regardless of why the GTK 2 library was loaded, which can happen for one of the following reasons: 1. The application or end user has explicitly requested GTK 2 using the `jdk.gtk.version` system property. 2. Another native library has already loaded the GTK 2 library (an application cannot load both the GTK 2 and GTK 3 libraries in the same process) 3. As a fallback if the gtk3 libraries are not available on the system. The warning messages are patterned after the security manager deprecation messages added as part of [JEP 411](https://openjdk.java.net/jeps/411). I added two system tests, one that sets the `jdk.gtk.version` system property to `2` and verifies that the warning message is printed, and one that doesn't set `jdk.gtk.version` and verifies that no warning message is printed. ------------- Commit messages: - 8273089: Deprecate JavaFX GTK 2 library for removal Changes: https://git.openjdk.java.net/jfx/pull/685/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=685&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273089 Stats: 221 lines in 4 files changed: 221 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/685.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/685/head:pull/685 PR: https://git.openjdk.java.net/jfx/pull/685 From arapte at openjdk.java.net Tue Nov 30 14:33:09 2021 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 30 Nov 2021 14:33:09 GMT Subject: RFR: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver [v2] In-Reply-To: References: Message-ID: <3IR0YhIaWRqEoLQUnfyTe6Y96Z4zSsEwFeVQGJT8tfQ=.6a07c7c2-ecc3-41d6-8564-ecdc35e2550b@github.com> On Tue, 30 Nov 2021 12:18:50 GMT, Jose Pereda wrote: >> This PR enables intersection observer support for WebKit, and includes a system test. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From fastegal at openjdk.java.net Tue Nov 30 14:37:11 2021 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Tue, 30 Nov 2021 14:37:11 GMT Subject: RFR: 8191995: Regression: DatePicker must commit on focusLost In-Reply-To: References: Message-ID: On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote: > This PR fixes an issue where the `DatePicker` is not committing his value when the focus is lost. > As the ticket also mentions, this is a regression which last worked on JavaFX 8 and got broken by the refactoring: [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) > > The fix is to provide the same api to the `DatePicker` which was introduced by [JDK-8150946](https://bugs.openjdk.java.net/browse/JDK-8150946) for `ComboBox` and `Spinner`. > > Note: While fixing this I found a possible bug which I tracked here: [JDK-8277756](https://bugs.openjdk.java.net/browse/JDK-8277756) > -> When creating a `DatePicker` with the second constructor (with `LocalDate` as parameter) two listener won't be added since they are only added at the first constructor (That's also why I added the focusProperty listener in the second constructor). fix looks good - verified that the new api and its implementation is the exact same as in ComboBox. Tests look good as well - verified the focused-related test fails/passes before/after the fix, all other tests pass after the fix. ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/679 From jpereda at openjdk.java.net Tue Nov 30 15:16:11 2021 From: jpereda at openjdk.java.net (Jose Pereda) Date: Tue, 30 Nov 2021 15:16:11 GMT Subject: Integrated: 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 18:20:11 GMT, Jose Pereda wrote: > This PR enables intersection observer support for WebKit, and includes a system test. This pull request has now been integrated. Changeset: b257647e Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/b257647eb6011782b414e17c33a024ab95af7263 Stats: 183 lines in 3 files changed: 180 ins; 1 del; 2 mod 8276847: JSException: ReferenceError: Can't find variable: IntersectionObserver Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/664 From kcr at openjdk.java.net Tue Nov 30 16:05:21 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Nov 2021 16:05:21 GMT Subject: RFR: 8277475: Update JDK_DOCS property to point to JDK 17 docs Message-ID: We are still pointing to the JDK 12 API docs when building the JavaFX docs. This PR updates the build to point to the JDK 17 API docs. ------------- Commit messages: - 8277475: Update JDK_DOCS property to point to JDK 17 docs Changes: https://git.openjdk.java.net/jfx/pull/686/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=686&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277475 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/686.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/686/head:pull/686 PR: https://git.openjdk.java.net/jfx/pull/686 From jvos at openjdk.java.net Tue Nov 30 18:14:08 2021 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 30 Nov 2021 18:14:08 GMT Subject: RFR: 8277475: Update JDK_DOCS property to point to JDK 17 docs In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 15:58:17 GMT, Kevin Rushforth wrote: > We are still pointing to the JDK 12 API docs when building the JavaFX docs. This PR updates the build to point to the JDK 17 API docs. This works and it is a good fix. Out of interest, I wonder if the entry in the verification-metadata matters. I modified the sha256 value in the verification metadata to a wrong value, but it still works. (modifying the URL for JavaSE 17 broke the process). ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/686 From kcr at openjdk.java.net Tue Nov 30 19:25:11 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 30 Nov 2021 19:25:11 GMT Subject: RFR: 8277475: Update JDK_DOCS property to point to JDK 17 docs In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 18:10:52 GMT, Johan Vos wrote: > Out of interest, I wonder if the entry in the verification-metadata matters. This entry is the checksum of a zip bundle we use for internal builds, since our builds are done behind a firewall with no proxy set. Here is the note from the JBS Description explaining this: "I will need to also create and host a zip bundle and add its checksum to gradle/verification-metadata.xml -- see [JDK-8266757](https://bugs.openjdk.java.net/browse/JDK-8266757) -- to avoid breaking our internal CI build." ------------- PR: https://git.openjdk.java.net/jfx/pull/686 From martin at martinfox.com Tue Nov 30 20:18:01 2021 From: martin at martinfox.com (Martin Fox) Date: Tue, 30 Nov 2021 12:18:01 -0800 Subject: Cleaning up warnings in the Mac glass code In-Reply-To: <9353b78d-0165-61fd-d4b0-d5fe99d6f6e5@oracle.com> References: <9353b78d-0165-61fd-d4b0-d5fe99d6f6e5@oracle.com> Message-ID: <9BBE23C4-B913-454C-AF47-A5C1150B1E59@martinfox.com> I can set this up to exclude deprecation warnings. When I turn on warnings-as-errors and exclude deprecations there are only a handful of changes needed in glass. I think they could be handled in a single pull request. I?ll need an issue number; will I be able to enter a bug for this through the public portal? I don?t want to hide deprecation warnings entirely since they do sometimes flag issues worth investigating (one is now on my to-do list). It?s still a lot of warnings so it?s probably worth coming up with a strategy for reducing them over time. > On Nov 29, 2021, at 10:10 AM, Kevin Rushforth wrote: > > I agree that this would be a good thing to aim for as long as we exclude deprecation warnings (given Apple's penchant for deprecating large API surfaces such as OpenGL or the older accessibility APIs we really can't have the use of deprecated APIs be an error). > > -- Kevin > > > On 11/24/2021 7:44 PM, Michael Strau? wrote: >> That's a good idea. In general, warnings should always be treated as errors. >> >> >> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote: >>> The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn?t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea. >>> >>> I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There?s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing. >>> >>> Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants. >>> >>> You can see the changes I made in my github repository (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple commits, the first and biggest catching most of the easy stuff like constant renaming. >>> >>> In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught. >>> >>> >>> >>> > From kevin.rushforth at oracle.com Tue Nov 30 20:24:52 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Nov 2021 12:24:52 -0800 Subject: [External] : Re: Cleaning up warnings in the Mac glass code In-Reply-To: <9BBE23C4-B913-454C-AF47-A5C1150B1E59@martinfox.com> References: <9353b78d-0165-61fd-d4b0-d5fe99d6f6e5@oracle.com> <9BBE23C4-B913-454C-AF47-A5C1150B1E59@martinfox.com> Message-ID: On 11/30/2021 12:18 PM, Martin Fox wrote: > I can set this up to exclude deprecation warnings. When I turn on warnings-as-errors and exclude deprecations there are only a handful of changes needed in glass. I think they could be handled in a single pull request. I?ll need an issue number; will I be able to enter a bug for this through the public portal? You could create a bug using https://bugreport.java.com/ but in this case I'll create it for you. > I don?t want to hide deprecation warnings entirely since they do sometimes flag issues worth investigating (one is now on my to-do list). It?s still a lot of warnings so it?s probably worth coming up with a strategy for reducing them over time. As long as all of the other warnings are errors, this seems good to me. -- Kevin >> On Nov 29, 2021, at 10:10 AM, Kevin Rushforth wrote: >> >> I agree that this would be a good thing to aim for as long as we exclude deprecation warnings (given Apple's penchant for deprecating large API surfaces such as OpenGL or the older accessibility APIs we really can't have the use of deprecated APIs be an error). >> >> -- Kevin >> >> >> On 11/24/2021 7:44 PM, Michael Strau? wrote: >>> That's a good idea. In general, warnings should always be treated as errors. >>> >>> >>> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote: >>>> The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn?t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea. >>>> >>>> I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There?s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing. >>>> >>>> Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants. >>>> >>>> You can see the changes I made in my github repository (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple commits, the first and biggest catching most of the easy stuff like constant renaming. >>>> >>>> In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught. >>>> >>>> >>>> >>>> > From kevin.rushforth at oracle.com Tue Nov 30 20:33:29 2021 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Nov 2021 12:33:29 -0800 Subject: [External] : Re: Cleaning up warnings in the Mac glass code In-Reply-To: References: <9353b78d-0165-61fd-d4b0-d5fe99d6f6e5@oracle.com> <9BBE23C4-B913-454C-AF47-A5C1150B1E59@martinfox.com> Message-ID: <114a6f58-f8bf-580e-9b7e-f0734903cc3a@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8278021 -- Kevin On 11/30/2021 12:24 PM, Kevin Rushforth wrote: > > > On 11/30/2021 12:18 PM, Martin Fox wrote: >> I can set this up to exclude deprecation warnings. When I turn on >> warnings-as-errors and exclude deprecations there are only a handful >> of changes needed in glass. I think they could be handled in a single >> pull request. I?ll need an issue number; will I be able to enter a >> bug for this through the public portal? > > You could create a bug using https://bugreport.java.com/ but in this > case I'll create it for you. > >> I don?t want to hide deprecation warnings entirely since they do >> sometimes flag issues worth investigating (one is now on my to-do >> list). It?s still a lot of warnings so it?s probably worth coming up >> with a strategy for reducing them over time. > > As long as all of the other warnings are errors, this seems good to me. > > -- Kevin > >>> On Nov 29, 2021, at 10:10 AM, Kevin Rushforth >>> wrote: >>> >>> I agree that this would be a good thing to aim for as long as we >>> exclude deprecation warnings (given Apple's penchant for deprecating >>> large API surfaces such as OpenGL or the older accessibility APIs we >>> really can't have the use of deprecated APIs be an error). >>> >>> -- Kevin >>> >>> >>> On 11/24/2021 7:44 PM, Michael Strau? wrote: >>>> That's a good idea. In general, warnings should always be treated >>>> as errors. >>>> >>>> >>>> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox >>>> wrote: >>>>> The Mac glass code generates a lot of compiler warnings. I tried >>>>> cleaning this up and discovered that two of the warnings are brand >>>>> new, courtesy of me. One of the headers in PR #651 has a typo that >>>>> I didn?t catch and neither did the two reviewers. The compiler >>>>> generated two warnings but they were lost in the sea. >>>>> >>>>> I turned on warnings-as-errors for the Mac glass code and waded >>>>> through the results. There are a couple of minor coding errors in >>>>> addition to mine which should be cleaned up (like passing NO to a >>>>> function that requires a non-null pointer). There?s also a few >>>>> deprecated calls across a small handful of files which have easy >>>>> replacements and are probably worth fixing. >>>>> >>>>> Unfortunately Apple re-named a bunch of constants in 10.12 and >>>>> deprecated the older forms (I think this was to rationalize the >>>>> naming with Swift). These form the bulk of the warnings and affect >>>>> multiple files. Not a fan of that sort of code churn but the >>>>> alternative is to live with a slew of warnings forever. Apple is >>>>> not going to un-deprecate those constants. >>>>> >>>>> You can see the changes I made in my github repository >>>>> (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple >>>>> commits, the first and biggest catching most of the easy stuff >>>>> like constant renaming. >>>>> >>>>> In the short term it might be worth disabling deprecation warnings >>>>> and turning on warnings-as-errors. Then at least outright coding >>>>> errors (like mine!) have a chance of being caught. >>>>> >>>>> >>>>> >>>>> >> > From martin at martinfox.com Tue Nov 30 21:18:53 2021 From: martin at martinfox.com (Martin Fox) Date: Tue, 30 Nov 2021 13:18:53 -0800 Subject: [External] : Re: Cleaning up warnings in the Mac glass code In-Reply-To: <114a6f58-f8bf-580e-9b7e-f0734903cc3a@oracle.com> References: <9353b78d-0165-61fd-d4b0-d5fe99d6f6e5@oracle.com> <9BBE23C4-B913-454C-AF47-A5C1150B1E59@martinfox.com> <114a6f58-f8bf-580e-9b7e-f0734903cc3a@oracle.com> Message-ID: <647AD121-1022-475A-8394-A0A6DB97E164@martinfox.com> Thanks. I wasn?t sure how an internal ?clean up the code? bug would fare coming through the public bug reporting portal. > On Nov 30, 2021, at 12:33 PM, Kevin Rushforth wrote: > > https://bugs.openjdk.java.net/browse/JDK-8278021 > > -- Kevin > > On 11/30/2021 12:24 PM, Kevin Rushforth wrote: >> >> >> On 11/30/2021 12:18 PM, Martin Fox wrote: >>> I can set this up to exclude deprecation warnings. When I turn on warnings-as-errors and exclude deprecations there are only a handful of changes needed in glass. I think they could be handled in a single pull request. I?ll need an issue number; will I be able to enter a bug for this through the public portal? >> >> You could create a bug using https://bugreport.java.com/ but in this case I'll create it for you. >> >>> I don?t want to hide deprecation warnings entirely since they do sometimes flag issues worth investigating (one is now on my to-do list). It?s still a lot of warnings so it?s probably worth coming up with a strategy for reducing them over time. >> >> As long as all of the other warnings are errors, this seems good to me. >> >> -- Kevin >> >>>> On Nov 29, 2021, at 10:10 AM, Kevin Rushforth wrote: >>>> >>>> I agree that this would be a good thing to aim for as long as we exclude deprecation warnings (given Apple's penchant for deprecating large API surfaces such as OpenGL or the older accessibility APIs we really can't have the use of deprecated APIs be an error). >>>> >>>> -- Kevin >>>> >>>> >>>> On 11/24/2021 7:44 PM, Michael Strau? wrote: >>>>> That's a good idea. In general, warnings should always be treated as errors. >>>>> >>>>> >>>>> On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote: >>>>>> The Mac glass code generates a lot of compiler warnings. I tried cleaning this up and discovered that two of the warnings are brand new, courtesy of me. One of the headers in PR #651 has a typo that I didn?t catch and neither did the two reviewers. The compiler generated two warnings but they were lost in the sea. >>>>>> >>>>>> I turned on warnings-as-errors for the Mac glass code and waded through the results. There are a couple of minor coding errors in addition to mine which should be cleaned up (like passing NO to a function that requires a non-null pointer). There?s also a few deprecated calls across a small handful of files which have easy replacements and are probably worth fixing. >>>>>> >>>>>> Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated the older forms (I think this was to rationalize the naming with Swift). These form the bulk of the warnings and affect multiple files. Not a fan of that sort of code churn but the alternative is to live with a slew of warnings forever. Apple is not going to un-deprecate those constants. >>>>>> >>>>>> You can see the changes I made in my github repository (beldenfox/jfx) in the branch ?macwarnings?. There?s multiple commits, the first and biggest catching most of the easy stuff like constant renaming. >>>>>> >>>>>> In the short term it might be worth disabling deprecation warnings and turning on warnings-as-errors. Then at least outright coding errors (like mine!) have a chance of being caught. >>>>>> >>>>>> >>>>>> >>>>>> >>> >> >