From psadhukhan at openjdk.org Mon Jul 1 05:49:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 Jul 2024 05:49:24 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException In-Reply-To: <7d7Tua0RylGyUJoQ81GlWgScWPdgxjMBtQJBSGvWSnw=.a66ca07b-dbdd-425f-90d4-2120cfc29d6c@github.com> References: <7d7Tua0RylGyUJoQ81GlWgScWPdgxjMBtQJBSGvWSnw=.a66ca07b-dbdd-425f-90d4-2120cfc29d6c@github.com> Message-ID: On Fri, 28 Jun 2024 14:12:37 GMT, Kevin Rushforth wrote: > To allow removing and then re-adding the `JFXPanel`, we would need to not call `Window.hide` when the `JFXPanel` is removed. I am not sure if this is a problem as just as `JFXPanel.removeNotify` does `Window.hide` but at the same time when we add JFXPanel to frame, it calls `JFXPanel.addNotify` which does `Window.show` so tit gets hidden when JFXPanel is removed and shown when JFXPanel is added ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2199284935 From psadhukhan at openjdk.org Mon Jul 1 05:49:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 Jul 2024 05:49:24 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException In-Reply-To: References: <7d7Tua0RylGyUJoQ81GlWgScWPdgxjMBtQJBSGvWSnw=.a66ca07b-dbdd-425f-90d4-2120cfc29d6c@github.com> Message-ID: <6T3CUm-t8y-yQXxhvFRkFVH_7qDs6npU4TzSR_clcdQ=.7b0f79c9-b51c-4f2c-ae0b-3cb03c96cfeb@github.com> On Mon, 1 Jul 2024 05:44:21 GMT, Prasanta Sadhukhan wrote: >> Can you add an automated test to cover this fix? >> >> Worth noting, this won't fully solve the problem that the reporter of this bug filed. The null check will prevent the NPE, but the scene will still not be visible. To allow removing and then re-adding the `JFXPanel`, we would need to not call `Window.hide` when the `JFXPanel` is removed. We should file a follow-on Enhancement to consider doing this, but that will need more discussion. The main point that would need to be solved is to figure out when to call `Window.hide` if not when the `JFXPanel` is removed. > >> To allow removing and then re-adding the `JFXPanel`, we would need to not call `Window.hide` when the `JFXPanel` is removed. > > I am not sure if this is a problem as just as `JFXPanel.removeNotify` does `Window.hide` but at the same time when we add JFXPanel to frame, it calls `JFXPanel.addNotify` which does `Window.show` so tit gets hidden when JFXPanel is removed and shown when JFXPanel is added > @prsadhuk One more question: Do you know what changed in JavaFX 21 to trigger the NPE? It is not reproducible in jfx21 as per my testing...The problematic code to call updateSceneState was added for [JDK-8274932](https://bugs.openjdk.org/browse/JDK-8274932) so it has regressed from jfx22 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2199287067 From javafx at ivoryemr.co.za Mon Jul 1 07:36:53 2024 From: javafx at ivoryemr.co.za (Jurgen Doll) Date: Mon, 01 Jul 2024 09:36:53 +0200 Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: Thank you Michael, Jose, Florian, and Markus In my mind the "Too many touch points reported" exception fix (#394) appears to not be the correct fix for that issue and is what caused this regression. There seems to be two possible paths forward, either revert #394 or integrate this. In both cases the "Too many touch points reported" issue will need to be readdressed. It would be nice to see this move forward somehow. Thanks again, Jurgen On Tue, 04 Jun 2024 18:28:47 +0200, Markus Mack wrote: > On Tue, 21 May 2024 14:25:51 GMT, Michael Strau? > wrote: > >> This PR fixes a bug >> ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was >> introduced with #394, which changed the following line in the >> `NotifyTouchInput` function (ViewContainer.cpp): >> >> - const bool isDirect = true; >> + const bool isDirect = IsTouchEvent(); >> >> >> `IsTouchEvent` is a small utility function that uses the Windows SDK >> function `GetMessageExtraInfo` to distinguish between mouse events and >> pen events as described in this article: >> https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages >> >> I think that using this function to distinguish between touchscreen >> events and pen events is erroneous. The linked article states: >> _"When your application receives a **mouse message** (such as >> WM_LBUTTONDOWN) [...]"_ >> >> But we are not receiving a mouse message in `NotifyTouchInput`, we are >> receiving a `WM_TOUCH` message. >> I couldn't find any information on whether this API usage is also >> supported for `WM_TOUCH` messages, but my testing shows that that's >> probably not the case (I tested this with a XPS 15 touchscreen laptop, >> where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). >> >> My suggestion is to check the `TOUCHEVENTF_PEN` flag of the >> `TOUCHINPUT` structure instead: >> >> const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; > > I attempted to test this with the sample app in > [JDK-8249737](https://bugs.openjdk.org/browse/JDK-8249737) and > [Microsoft.Windows.Simulator](https://stackoverflow.com/questions/40274660/windows-10-how-do-i-test-touch-events-without-a-touchscreen) > using the simulator's "Basic touch mode". > > The "Too many touch points reported" exception seems to be thrown > consistently with > `const bool isDirect = true;` (original before #394) > and `const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0;` (this > PR) > > I didn't see the exception with `const bool isDirect = IsTouchEvent();` > (#394) > and `const bool isDirect = false` (which is probably what IsTouchEvent() > returns here). > > Not sure what this simulator actually sends, but someone more > knowledgeable might want to have a look at what's happening. > > ------------- > > PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2147933056 From psadhukhan at openjdk.org Mon Jul 1 09:11:21 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 Jul 2024 09:11:21 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v2] In-Reply-To: References: Message-ID: > Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. > Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... > so when GlassScene.updateSceneState is called, it results in NPE. > Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision: - Test added - Test added ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1493/files - new: https://git.openjdk.org/jfx/pull/1493/files/14ac6ef3..6ddb5ab3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1493&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1493&range=00-01 Stats: 121 lines in 1 file changed: 121 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1493.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1493/head:pull/1493 PR: https://git.openjdk.org/jfx/pull/1493 From psadhukhan at openjdk.org Mon Jul 1 09:11:21 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 Jul 2024 09:11:21 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 08:49:49 GMT, Prasanta Sadhukhan wrote: > Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. > Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... > so when GlassScene.updateSceneState is called, it results in NPE. > Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state Check is not without precedence in this file..There are instance of `assert host != null;` and `host != null` check like below https://github.com/openjdk/jfx/blob/6a586b662592be3eb81670f0c5ce48061c2fc07c/modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java#L185 Automated test added ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2199627928 PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2199628476 From psadhukhan at openjdk.org Mon Jul 1 09:16:52 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 1 Jul 2024 09:16:52 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v3] In-Reply-To: References: Message-ID: > Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. > Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... > so when GlassScene.updateSceneState is called, it results in NPE. > Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: Test fix ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1493/files - new: https://git.openjdk.org/jfx/pull/1493/files/6ddb5ab3..2872159b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1493&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1493&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1493.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1493/head:pull/1493 PR: https://git.openjdk.org/jfx/pull/1493 From markus.mack at gmail.com Mon Jul 1 11:48:12 2024 From: markus.mack at gmail.com (Markus Mack) Date: Mon, 1 Jul 2024 13:48:12 +0200 Subject: Should we document Styleable properties? In-Reply-To: References: Message-ID: <3be32b70-1ab7-4f50-94d1-4b0d8493631e@gmail.com> I'd say this is a good idea. Both variants are good, we might want to mention CSS in the first one, though. Not sure how others do it, but I regularly struggle to find out which code properties correspond to which CSS styles. This is particularly the case for names like "background", "border", or "stroke", where there is no clean 1:1 correspondence, or similar names are used in multiple contexts. Some way of linking to the current CSS reference might also be helpful to find out about allowed arguments. If I google something like? "javafx css" I typically only get links to outdated versions of the CSS reference. Also, linking back from the CSS reference to the code properties' javadoc pages is something I've been missing - maybe this could be added without much additional effort if javadocs are updated according to this proposal? Am 28.06.2024 um 23:04 schrieb Andy Goryachev: > > Dear fellow developers: > > Should we document which properties are styleable with CSS in > javadoc?? Would that be useful? > > Example: > > /** > > ???? * Determines the caret blink period.? This property cannot be set > to {@code null}. > > ???? *

> > ???? * This is a {@link StyleableProperty} with the name {@code > -fx-caret-blink-period}. > > ???? *

> > alternative: > > ???? * This property can be styled with CSS using {@code > -fx-caret-blink-period} name. > > ???? * @implNote The property object implements {@link > StyleableProperty} interface. > > Other ideas are also welcome. > > -andy > From lkostyra at openjdk.org Mon Jul 1 13:52:28 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 1 Jul 2024 13:52:28 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v9] In-Reply-To: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> References: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> Message-ID: On Thu, 27 Jun 2024 13:43:37 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add delta for assertStageScreenBounds Marked as reviewed by lkostyra (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2151457529 From kcr at openjdk.org Mon Jul 1 14:25:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Jul 2024 14:25:25 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space In-Reply-To: References: Message-ID: On Fri, 7 Jun 2024 18:29:00 GMT, Martin Fox wrote: > When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). > > In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. > > Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. > > I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. > > I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. As a datapoint, we were doing some testing in the [jfx-sandbox:metal](https://github.com/openjdk/jfx-sandbox/tree/metal) branch, and had over a hundred test failures that we tracked down to the color profile not being set to sRGB (the test system had the default "Color LCD profile"). I applied the fix from this patch (and resolving a couple merge conflicts due to some Metal-specific changes in the sandbox branch), and ran one of the failing tests with the default "Color LCD" profile and it now passes. Even if this PR doesn't fix all of the problems, it seems like a good fix to consider. @beldenfox Can you merge in the latest master so we will see a test build on macOS / aarch64? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1473#issuecomment-2200290351 PR Comment: https://git.openjdk.org/jfx/pull/1473#issuecomment-2200295936 From mfox at openjdk.org Mon Jul 1 14:48:39 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 1 Jul 2024 14:48:39 GMT Subject: RFR: 8325445: [macOS] Colors are not displayed in sRGB color space [v2] In-Reply-To: References: Message-ID: <1yNmbNRJv1ctPQQuD-olmfB8udJo-3vM55-kxkZPXMk=.e0ae1682-13bd-4a2c-8404-f4549bb7c2d3@github.com> > When drawing to the screen JavaFX is producing sRGB colors but on macOS that?s not necessarily what the user is seeing. Since the pixels are not tagged as sRGB the OS is copying them unmodified to the frame buffer to be displayed in the screen?s color space. In general Mac?s don?t default to sRGB so the colors will be wrong. The fix for this is a one-liner; we just need to declare that our CALayer uses the sRGB color space so the OS will convert it to the screen?s space (presumably with a slight performance penalty). > > In the reverse direction the Robot should be returning sRGB colors. The getPixelColor calls were making no conversion. The getScreenCapture calls were converting to genericRGB, not sRGB, and so the results didn?t match the getPixelColor calls. This PR fixes these bugs; getPixelColor and getScreenCapture both return sRGB. > > Now that everything is working in the same space when JavaFX writes out a pixel and then reads it back in the colors should match within a limited tolerance (due to rounding issues when converting from float to int and back). But that just means the various glass code paths are using the same space to perform conversions, not that it?s sRGB. AWT is color space aware and so the automated test employs an AWT Robot to double-check the results. > > I swept through the rest of the Mac glass code and found a few places where colors were being converted to deviceRGB instead of sRGB e.g. when reading colors for PlatformPreferences or creating images for drag and drop. I could not think of a good way of writing automated tests for these cases. > > I started investigating this since Robot tests were failing unless the monitor?s profile was set to sRGB. Unfortunately this PR doesn?t entirely fix that. My monitor uses Display P3 and I?m still seeing failures on the SwingNodeJDialogTest. The test writes out pure BLUE colors and gets back colors with a surprising amount of red. I?ve verified that this has nothing to do with JavaFX, it happens when I use CoreGraphics to make the sRGB => Display P3 color conversions directly. I guess this is a cautionary tale about what happens when you work near the edges of a color space?s gamut. Martin Fox 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 20 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into colormgmt - Color space is two words. - Merge remote-tracking branch 'upstream/master' into colormgmt - Merge remote-tracking branch 'upstream/master' into colormgmt - Merge remote-tracking branch 'upstream/master' into colormgmt - Robot code is now executed inside autorelease pool - Cleaned up SRGBTest - Merge remote-tracking branch 'upstream/master' into colormgmt - We don't need to manually release the color space. - Merge remote-tracking branch 'upstream/master' into colormgmt - ... and 10 more: https://git.openjdk.org/jfx/compare/330ec3fa...41e3baf9 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1473/files - new: https://git.openjdk.org/jfx/pull/1473/files/ae06f5a4..41e3baf9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1473&range=00-01 Stats: 5789 lines in 84 files changed: 5650 ins; 49 del; 90 mod Patch: https://git.openjdk.org/jfx/pull/1473.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1473/head:pull/1473 PR: https://git.openjdk.org/jfx/pull/1473 From michaelstrau2 at gmail.com Mon Jul 1 16:45:01 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 1 Jul 2024 18:45:01 +0200 Subject: Should we document Styleable properties? In-Reply-To: References: Message-ID: If we do this, I suggest to add a custom tag for this purpose instead of repeating prose for every property. The javadoc tool will then render the content of this tag in the specification list section of the documentation (where tags such as @defaultValue will also appear). On Fri, Jun 28, 2024 at 11:21?PM Andy Goryachev wrote: > > Dear fellow developers: > > > > Should we document which properties are styleable with CSS in javadoc? Would that be useful? > > > > Example: > > > > /** > > * Determines the caret blink period. This property cannot be set to {@code null}. > > *

> > * This is a {@link StyleableProperty} with the name {@code -fx-caret-blink-period}. > > *

> > > > alternative: > > > > * This property can be styled with CSS using {@code -fx-caret-blink-period} name. > > * @implNote The property object implements {@link StyleableProperty} interface. > > > > > > Other ideas are also welcome. > > > > -andy From andy.goryachev at oracle.com Mon Jul 1 19:02:14 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 Jul 2024 19:02:14 +0000 Subject: Should we document Styleable properties? In-Reply-To: <3be32b70-1ab7-4f50-94d1-4b0d8493631e@gmail.com> References: <3be32b70-1ab7-4f50-94d1-4b0d8493631e@gmail.com> Message-ID: Thank you for your feedback! I agree: referring to places in cssref.html is a good idea. And perhaps even referring from cssref.html to javadoc might be also a good idea, though cssref.html does suggest the class which owns the corresponding properties, or at least the class in question can be found in most cases. -andy From: openjfx-dev on behalf of Markus Mack Date: Monday, July 1, 2024 at 04:48 To: openjfx-dev at openjdk.org Subject: Re: Should we document Styleable properties? I'd say this is a good idea. Both variants are good, we might want to mention CSS in the first one, though. Not sure how others do it, but I regularly struggle to find out which code properties correspond to which CSS styles. This is particularly the case for names like "background", "border", or "stroke", where there is no clean 1:1 correspondence, or similar names are used in multiple contexts. Some way of linking to the current CSS reference might also be helpful to find out about allowed arguments. If I google something like "javafx css" I typically only get links to outdated versions of the CSS reference. Also, linking back from the CSS reference to the code properties' javadoc pages is something I've been missing - maybe this could be added without much additional effort if javadocs are updated according to this proposal? Am 28.06.2024 um 23:04 schrieb Andy Goryachev: > > Dear fellow developers: > > Should we document which properties are styleable with CSS in > javadoc? Would that be useful? > > Example: > > /** > > * Determines the caret blink period. This property cannot be set > to {@code null}. > > *

> > * This is a {@link StyleableProperty} with the name {@code > -fx-caret-blink-period}. > > *

> > alternative: > > * This property can be styled with CSS using {@code > -fx-caret-blink-period} name. > > * @implNote The property object implements {@link > StyleableProperty} interface. > > Other ideas are also welcome. > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Mon Jul 1 19:16:22 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 Jul 2024 19:16:22 +0000 Subject: Should we document Styleable properties? In-Reply-To: References: Message-ID: Thank you for your feedback, Michael! Let me first make sure I understand your suggestion correctly: 1. add an annotation, let's say @css-prop 2. modify javadoc tool to create an automated link from the property name to a place in cssref.html 3. javadoc will render this as @css-prop this property can be styled with CSS using -fx-prop-name I don't know whether javadoc people will be happy about this idea: javadoc is a part of jdk and unfortunately javafx is not, though javadoc does offer certain features to make it play nice with javafx properties. This would also require non-trivial modification to cssref.html to add anchors where each property name is defined. Alternatively, it could simply point to a class, for which we do have an id (e.g. Cell) Overall, it is much more extensive | expensive proposition with external dependencies. Meaning the probability of it happening is very low. Having said that, this is a great idea, very developer-friendly. -andy From: openjfx-dev on behalf of Michael Strau? Date: Monday, July 1, 2024 at 09:45 To: Cc: openjfx-dev at openjdk.org Subject: Re: Should we document Styleable properties? If we do this, I suggest to add a custom tag for this purpose instead of repeating prose for every property. The javadoc tool will then render the content of this tag in the specification list section of the documentation (where tags such as @defaultValue will also appear). On Fri, Jun 28, 2024 at 11:21?PM Andy Goryachev wrote: > > Dear fellow developers: > > > > Should we document which properties are styleable with CSS in javadoc? Would that be useful? > > > > Example: > > > > /** > > * Determines the caret blink period. This property cannot be set to {@code null}. > > *

> > * This is a {@link StyleableProperty} with the name {@code -fx-caret-blink-period}. > > *

> > > > alternative: > > > > * This property can be styled with CSS using {@code -fx-caret-blink-period} name. > > * @implNote The property object implements {@link StyleableProperty} interface. > > > > > > Other ideas are also welcome. > > > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Jul 1 20:34:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Jul 2024 20:34:25 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:16:52 GMT, Prasanta Sadhukhan wrote: >> Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. >> Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... >> so when GlassScene.updateSceneState is called, it results in NPE. >> Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test fix modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java line 160: > 158: Platform.runLater(() -> { > 159: QuantumToolkit.runWithRenderLock(() -> { > 160: if (host != null) { I think we need a different solution here, as mentioned in line 58 // TODO: synchronize access to embedder from ET and RT ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1493#discussion_r1661510943 From angorya at openjdk.org Mon Jul 1 20:46:22 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 1 Jul 2024 20:46:22 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:16:52 GMT, Prasanta Sadhukhan wrote: >> Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. >> Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... >> so when GlassScene.updateSceneState is called, it results in NPE. >> Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test fix Kevin is right, this fix does not solve the issue mentioned in the ticket. Once the fxPanel is added back, its content is not visible. Does not matter whether removing/adding happens at startup or the button event handler. (attaching a slightly modified test case to the ticket, notice lines 30 and 44. Also, I think swing requires validate() and repaint() called after modifying the component's children. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2200985904 From kevin.rushforth at oracle.com Mon Jul 1 20:48:44 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Jul 2024 13:48:44 -0700 Subject: Should we document Styleable properties? In-Reply-To: References: Message-ID: <40d6621c-9759-475a-83a3-649746c6edbf@oracle.com> A new javadoc tag seems unlikely. Especially for something like this where the ask would be to automatically link it to some html file (cssref.html) somewhere in the current JavaFX sources. One more thing to point out, is that even if we could get such a tag added to the JDK javadoc doclet, it would be quite a while before we could use it in JavaFX. We would have to get it into JDK 24 or 25 and then wait until we update to that JDK as the minimum needed to build JavaFX. So maybe in JavaFX 27 we could start using it. So it's a nice idea, but doesn't seem practical to implement. -- Kevin On 7/1/2024 12:16 PM, Andy Goryachev wrote: > > Thank you for your feedback, Michael! > > Let me first make sure I understand your suggestion correctly: > > 1. add an annotation, let's say @css-prop > 2. modify javadoc tool to create an automated link from the property > name to a place in cssref.html > 3. javadoc will render this as > > @css-prop this property can be styled with CSS using href="...">-fx-prop-name > > I don't know whether javadoc people will be happy about this idea: > javadoc is a part of jdk and unfortunately javafx is not, though > javadoc does offer certain features to make it play nice with javafx > properties. > > This would also require non-trivial modification to cssref.html to add > anchors where each property name is defined. Alternatively, it could > simply point to a class, for which we do have an id (e.g. id="cell">Cell) > > Overall, it is much more extensive | expensive proposition with > external dependencies.? Meaning the probability of it happening is > very low. > > Having said that, this is a great idea, very developer-friendly. > > -andy > > *From: *openjfx-dev on behalf of > Michael Strau? > *Date: *Monday, July 1, 2024 at 09:45 > *To: * > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: Should we document Styleable properties? > > If we do this, I suggest to add a custom tag for this purpose instead > of repeating prose for every property. > The javadoc tool will then render the content of this tag in the > specification list section of the documentation (where tags such as > @defaultValue will also appear). > > > On Fri, Jun 28, 2024 at 11:21?PM Andy Goryachev > wrote: > > > > Dear fellow developers: > > > > > > > > Should we document which properties are styleable with CSS in > javadoc?? Would that be useful? > > > > > > > > Example: > > > > > > > >???? /** > > > >????? * Determines the caret blink period.? This property cannot be > set to {@code null}. > > > >????? *

> > > >????? * This is a {@link StyleableProperty} with the name {@code > -fx-caret-blink-period}. > > > >????? *

> > > > > > > > alternative: > > > > > > > >????? * This property can be styled with CSS using {@code > -fx-caret-blink-period} name. > > > >????? * @implNote The property object implements {@link > StyleableProperty} interface. > > > > > > > > > > > > Other ideas are also welcome. > > > > > > > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Jul 1 20:58:55 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 1 Jul 2024 22:58:55 +0200 Subject: Should we document Styleable properties? In-Reply-To: References: Message-ID: The javadoc tool already supports custom tags out of the box with the "-tag" command line option. For example, adding this line in the gradle javadoc task (build.gradle L4241) would introduce a custom tag: options.tags("styleableProperty:a:CSS property name:") Of course, there's no special processing of custom tags, so we would have to add a link manually if we want one. But that's certainly not a worse situation compared to adding a manual link in prose text. On Mon, Jul 1, 2024 at 9:16?PM Andy Goryachev wrote: > > Thank you for your feedback, Michael! > > > > Let me first make sure I understand your suggestion correctly: > > > > add an annotation, let's say @css-prop > modify javadoc tool to create an automated link from the property name to a place in cssref.html > javadoc will render this as > > > > @css-prop this property can be styled with CSS using -fx-prop-name > > > > I don't know whether javadoc people will be happy about this idea: javadoc is a part of jdk and unfortunately javafx is not, though javadoc does offer certain features to make it play nice with javafx properties. > > > > This would also require non-trivial modification to cssref.html to add anchors where each property name is defined. Alternatively, it could simply point to a class, for which we do have an id (e.g. Cell) > > > > Overall, it is much more extensive | expensive proposition with external dependencies. Meaning the probability of it happening is very low. > > > > Having said that, this is a great idea, very developer-friendly. > > > > -andy From kevin.rushforth at oracle.com Mon Jul 1 21:11:55 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 1 Jul 2024 14:11:55 -0700 Subject: Should we document Styleable properties? In-Reply-To: References: Message-ID: <8a48ac6d-591a-4261-87f9-8de11dbf2323@oracle.com> Sure, something like this would be possible if it helps minimize boilerplate. -- Kevin On 7/1/2024 1:58 PM, Michael Strau? wrote: > The javadoc tool already supports custom tags out of the box with the > "-tag" command line option. For example, adding this line in the > gradle javadoc task (build.gradle L4241) would introduce a custom tag: > > options.tags("styleableProperty:a:CSS property name:") > > Of course, there's no special processing of custom tags, so we would > have to add a link manually if we want one. But that's certainly not a > worse situation compared to adding a manual link in prose text. > > > On Mon, Jul 1, 2024 at 9:16?PM Andy Goryachev wrote: >> Thank you for your feedback, Michael! >> >> >> >> Let me first make sure I understand your suggestion correctly: >> >> >> >> add an annotation, let's say @css-prop >> modify javadoc tool to create an automated link from the property name to a place in cssref.html >> javadoc will render this as >> >> >> >> @css-prop this property can be styled with CSS using -fx-prop-name >> >> >> >> I don't know whether javadoc people will be happy about this idea: javadoc is a part of jdk and unfortunately javafx is not, though javadoc does offer certain features to make it play nice with javafx properties. >> >> >> >> This would also require non-trivial modification to cssref.html to add anchors where each property name is defined. Alternatively, it could simply point to a class, for which we do have an id (e.g. Cell) >> >> >> >> Overall, it is much more extensive | expensive proposition with external dependencies. Meaning the probability of it happening is very low. >> >> >> >> Having said that, this is a great idea, very developer-friendly. >> >> >> >> -andy From andy.goryachev at oracle.com Mon Jul 1 21:19:52 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 1 Jul 2024 21:19:52 +0000 Subject: Should we document Styleable properties? In-Reply-To: <8a48ac6d-591a-4261-87f9-8de11dbf2323@oracle.com> References: <8a48ac6d-591a-4261-87f9-8de11dbf2323@oracle.com> Message-ID: Would even work with Eclipse out of the box: [cid:image002.png at 01DACBC1.BB882780] I also like the fact that we won't need to maintain links manually as there would not be any. -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Monday, July 1, 2024 at 14:12 To: openjfx-dev at openjdk.org Subject: Re: Should we document Styleable properties? Sure, something like this would be possible if it helps minimize boilerplate. -- Kevin On 7/1/2024 1:58 PM, Michael Strau? wrote: > The javadoc tool already supports custom tags out of the box with the > "-tag" command line option. For example, adding this line in the > gradle javadoc task (build.gradle L4241) would introduce a custom tag: > > options.tags("styleableProperty:a:CSS property name:") > > Of course, there's no special processing of custom tags, so we would > have to add a link manually if we want one. But that's certainly not a > worse situation compared to adding a manual link in prose text. > > > On Mon, Jul 1, 2024 at 9:16?PM Andy Goryachev wrote: >> Thank you for your feedback, Michael! >> >> >> >> Let me first make sure I understand your suggestion correctly: >> >> >> >> add an annotation, let's say @css-prop >> modify javadoc tool to create an automated link from the property name to a place in cssref.html >> javadoc will render this as >> >> >> >> @css-prop this property can be styled with CSS using -fx-prop-name >> >> >> >> I don't know whether javadoc people will be happy about this idea: javadoc is a part of jdk and unfortunately javafx is not, though javadoc does offer certain features to make it play nice with javafx properties. >> >> >> >> This would also require non-trivial modification to cssref.html to add anchors where each property name is defined. Alternatively, it could simply point to a class, for which we do have an id (e.g. Cell) >> >> >> >> Overall, it is much more extensive | expensive proposition with external dependencies. Meaning the probability of it happening is very low. >> >> >> >> Having said that, this is a great idea, very developer-friendly. >> >> >> >> -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 169476 bytes Desc: image002.png URL: From michaelstrau2 at gmail.com Mon Jul 1 21:33:18 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 1 Jul 2024 23:33:18 +0200 Subject: Should we document Styleable properties? In-Reply-To: References: <8a48ac6d-591a-4261-87f9-8de11dbf2323@oracle.com> Message-ID: Further testing shows that while the javadoc tool does support custom tags, it doesn?t lift custom tags defined on JavaFX property fields to the property method documentation. Lifting documentation from the property field to property methods is a JavaFX-specific feature of Javadoc. At first glance, there seems to be no particular reason why custom tags are ignored in this situation; probably it just wasn?t implemented. So if we add this custom tag, it won?t show up on the generated HTML. We could start using a custom tag, and then file an enhancement request for Javadoc to lift custom tags to methods just as it does with other tags. What?s your opinion on that? Andy Goryachev schrieb am Mo. 1. Juli 2024 um 23:20: > Would even work with Eclipse out of the box: > > > > > > I also like the fact that we won't need to maintain links manually as > there would not be any. > > > > -andy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Mon Jul 1 22:01:25 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 1 Jul 2024 22:01:25 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 09:16:52 GMT, Prasanta Sadhukhan wrote: >> Adding, then removing, and then adding a JFXPanel to the same component in the Swing scene graph leads to a NullPointerException in GlassScene because the sceneState is null. >> Removing JFXPanel calls JFXPanel.removeNotify which calls Window.hide which calls SceneHelper.disposePeer -> Scene.disposePeer -> EmbeddedScene.dispose -> GlassScene.dispose which sets "sceneState" to null... >> so when GlassScene.updateSceneState is called, it results in NPE. >> Fix is to check if `host` (which is usually javafx.embed.swing.JFXPanel$HostContainer for active JFXPanel) has been reset/deleted which is done when `EmbeddedScene.dispose` is called during removeNotify and abstain from updating the scene state > > Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: > > Test fix tests/system/src/test/java/test/javafx/embed/swing/JFXPanelNPETest.java line 106: > 104: frame.remove(fxPanel); > 105: // fxPanel added to frame again > 106: frame.add(fxPanel); // <-- leads to NullPointerException You can use JUnit5 to write this test (class) and use `assertDoesNotThrow(() -> frame.add(fxPanel));`, which makes this a bit better to understand ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1493#discussion_r1661580655 From kcr at openjdk.org Mon Jul 1 22:19:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 1 Jul 2024 22:19:24 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v2] In-Reply-To: <7QJTGc4K0huX4wyNPqoizg22cAT7AwO5_WiUCRIuGNI=.84f00c04-4120-4b58-a751-24ed51589c0a@github.com> References: <7QJTGc4K0huX4wyNPqoizg22cAT7AwO5_WiUCRIuGNI=.84f00c04-4120-4b58-a751-24ed51589c0a@github.com> Message-ID: On Fri, 28 Jun 2024 18:12:37 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>


>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. https://bugs.openjdk.org/browse/JDK-8335468 >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. https://bugs.openjdk.org/browse/JDK-8335470 >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. https://bugs.openjdk.org/browse/JDK-8335469 >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > ... > > Alexander Zvegintsev has updated the pull request incrementally with two additional commits since the last revision: > > - do not throw SecurityException > - Revert "remove HEADLESS check" The code changes all look good. I've done a fair bit of testing already, and will finish up my testing tomorrow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1490#issuecomment-2201171104 From psadhukhan at openjdk.org Tue Jul 2 03:48:24 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Tue, 2 Jul 2024 03:48:24 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v3] In-Reply-To: References: Message-ID: On Mon, 1 Jul 2024 20:43:44 GMT, Andy Goryachev wrote: > Kevin is right, this fix does not solve the issue mentioned in the ticket. Once the fxPanel is added back, its content is not visible. Does not matter whether removing/adding happens at startup or the button event handler. > > (attaching a slightly modified test case to the ticket, notice lines 30 and 44. > > Also, I think swing requires validate() and repaint() called after modifying the component's children. OK..I guess I probably misunderstood the expectation...it says EXPECTED - The JFXPanel is visible to the user of the application and no Exceptions are thrown. ACTUAL - The JFXPanel is visible but the following Exception is thrown which I deciphered as the JFXPanel window being visible and I guess in original testcase execution, the "TestButton" was still visible, only NPE was thrown.. ANyway, I guess it was mentioned that "We should file a follow-on Enhancement to consider doing this" and regarding synchro mentioned at line58, I guess we already have `QuantumToolkit.runWithRenderLock` in the problematic code ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2201826620 From jpereda at openjdk.org Tue Jul 2 08:26:33 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Tue, 2 Jul 2024 08:26:33 GMT Subject: [jfx17u] RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly Message-ID: Hi all, This pull request contains a clean backport of commit [a118d333](https://github.com/openjdk/jfx/commit/a118d33314a363336134d31c45b50329594e5a24) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. The commit being backported was authored by Phil Race on 20 Oct 2021 and was reviewed by Kevin Rushforth and Pankaj Bansal. Thanks! ------------- Commit messages: - Backport a118d33314a363336134d31c45b50329594e5a24 Changes: https://git.openjdk.org/jfx17u/pull/195/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8236689 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/195.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/195/head:pull/195 PR: https://git.openjdk.org/jfx17u/pull/195 From ebresie at gmail.com Tue Jul 2 12:41:05 2024 From: ebresie at gmail.com (Eric Bresie) Date: Tue, 2 Jul 2024 07:41:05 -0500 Subject: Should we document Styleable properties? In-Reply-To: References: <8a48ac6d-591a-4261-87f9-8de11dbf2323@oracle.com> Message-ID: A little off topic but? There is a pending JEP for allowing markup to be included in javadocs https://openjdk.org/jeps/467 Eric Bresie ebresie at gmail.com On Mon, Jul 1, 2024 at 4:35?PM Michael Strau? wrote: > Further testing shows that while the javadoc tool does support custom > tags, it doesn?t lift custom tags defined on JavaFX property fields to the > property method documentation. > > Lifting documentation from the property field to property methods is a > JavaFX-specific feature of Javadoc. At first glance, there seems to be no > particular reason why custom tags are ignored in this situation; probably > it just wasn?t implemented. > > So if we add this custom tag, it won?t show up on the generated HTML. We > could start using a custom tag, and then file an enhancement request for > Javadoc to lift custom tags to methods just as it does with other tags. > What?s your opinion on that? > > > Andy Goryachev schrieb am Mo. 1. Juli 2024 um > 23:20: > >> Would even work with Eclipse out of the box: >> >> >> >> >> >> I also like the fact that we won't need to maintain links manually as >> there would not be any. >> >> >> >> -andy >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From azvegint at openjdk.org Tue Jul 2 13:07:55 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 2 Jul 2024 13:07:55 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v3] In-Reply-To: References: Message-ID: <46RFV08Udj0aT7t5nfWj5XUDG_VD6F2nkn8Glxs0hw0=.9ca7fc99-4dd2-4651-9473-fe70bb9d3639@github.com> > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. https://bugs.openjdk.org/browse/JDK-8335468 > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. https://bugs.openjdk.org/browse/JDK-8335470 > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. https://bugs.openjdk.org/browse/JDK-8335469 > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: fix the SwingNodeJDialogTest.testNodeRemovalBeforeShow test failure ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1490/files - new: https://git.openjdk.org/jfx/pull/1490/files/33fa5385..2b051251 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=01-02 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1490.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1490/head:pull/1490 PR: https://git.openjdk.org/jfx/pull/1490 From azvegint at openjdk.org Tue Jul 2 13:15:26 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 2 Jul 2024 13:15:26 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v3] In-Reply-To: <46RFV08Udj0aT7t5nfWj5XUDG_VD6F2nkn8Glxs0hw0=.9ca7fc99-4dd2-4651-9473-fe70bb9d3639@github.com> References: <46RFV08Udj0aT7t5nfWj5XUDG_VD6F2nkn8Glxs0hw0=.9ca7fc99-4dd2-4651-9473-fe70bb9d3639@github.com> Message-ID: On Tue, 2 Jul 2024 13:07:55 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. https://bugs.openjdk.org/browse/JDK-8335468 >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. https://bugs.openjdk.org/browse/JDK-8335470 >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. https://bugs.openjdk.org/browse/JDK-8335469 >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > ... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix the SwingNodeJDialogTest.testNodeRemovalBeforeShow test failure tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodeBase.java line 209: > 207: > 208: // Emulating mouse clicks on XWayland with XTEST does not currently affect the Wayland compositor, > 209: // so trying to click on the window title or window body will not bring the window to the front. This is the [same issue](https://bugs.openjdk.org/browse/JDK-8280990) we have in OpenJDK, when the emulated mouse click doesn't put one window in front of another. After this fix and applying a fix for [the hang issue](https://bugs.openjdk.org/browse/JDK-8335468), all the `SwingNodeJDialogTest` tests are passing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1662486921 From angorya at openjdk.org Tue Jul 2 17:16:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 2 Jul 2024 17:16:25 GMT Subject: RFR: 8334593: Adding, removing and then adding a JFXPanel again leads to NullPointerException [v3] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 03:45:24 GMT, Prasanta Sadhukhan wrote: > QuantumToolkit.runWithRenderLock locking a class field may not be sufficient. or rather, cannot be sufficient when multiple threads are accessing the field, as there are no guarantees as to the order of invocations. Instead, we might need to pass the reference as a variable to the lambda which executes in a different thread. This way no matter what happens to the field, the code that executes in a different context will always have the right object. And, it might be better not to share the field between the threads and toolkits. Always mutate a particular field in the context of one toolkit - like fieldAWT / fieldFX. Just a suggestion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1493#issuecomment-2203876227 From kcr at openjdk.org Tue Jul 2 19:49:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Jul 2024 19:49:25 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v3] In-Reply-To: <46RFV08Udj0aT7t5nfWj5XUDG_VD6F2nkn8Glxs0hw0=.9ca7fc99-4dd2-4651-9473-fe70bb9d3639@github.com> References: <46RFV08Udj0aT7t5nfWj5XUDG_VD6F2nkn8Glxs0hw0=.9ca7fc99-4dd2-4651-9473-fe70bb9d3639@github.com> Message-ID: On Tue, 2 Jul 2024 13:07:55 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. https://bugs.openjdk.org/browse/JDK-8335468 >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. https://bugs.openjdk.org/browse/JDK-8335470 >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. https://bugs.openjdk.org/browse/JDK-8335469 >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > ... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix the SwingNodeJDialogTest.testNodeRemovalBeforeShow test failure Testing is complete. No new issues. I only see the `SwingNodeJDialogTest` failure. I did leave one minor naming comment and will reapprove if you make the suggested change. modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 68: > 66: > 67: private static final String REL_NAME = > 68: ".java/.robot/screencast-tokens.properties"; I recommend changing `.robot` to `robot` (without the dot) to match AWT. The parent dir already starts with `.` so no need to hide subdirectories. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1490#pullrequestreview-2154214895 PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1662763222 From azvegint at openjdk.org Tue Jul 2 20:04:39 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 2 Jul 2024 20:04:39 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v4] In-Reply-To: References: Message-ID: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. https://bugs.openjdk.org/browse/JDK-8335468 > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. https://bugs.openjdk.org/browse/JDK-8335470 > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. https://bugs.openjdk.org/browse/JDK-8335469 > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There... Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: fix default token path ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1490/files - new: https://git.openjdk.org/jfx/pull/1490/files/2b051251..2c5d425e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1490&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1490.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1490/head:pull/1490 PR: https://git.openjdk.org/jfx/pull/1490 From azvegint at openjdk.org Tue Jul 2 20:04:39 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 2 Jul 2024 20:04:39 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v3] In-Reply-To: References: <46RFV08Udj0aT7t5nfWj5XUDG_VD6F2nkn8Glxs0hw0=.9ca7fc99-4dd2-4651-9473-fe70bb9d3639@github.com> Message-ID: On Tue, 2 Jul 2024 15:36:59 GMT, Kevin Rushforth wrote: >> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: >> >> fix the SwingNodeJDialogTest.testNodeRemovalBeforeShow test failure > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 68: > >> 66: >> 67: private static final String REL_NAME = >> 68: ".java/.robot/screencast-tokens.properties"; > > I recommend changing `.robot` to `robot` (without the dot) to match AWT. The parent dir already starts with `.` so no need to hide subdirectories. Sure, updated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1663091938 From kcr at openjdk.org Tue Jul 2 20:11:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Jul 2024 20:11:25 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v4] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 20:04:39 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. https://bugs.openjdk.org/browse/JDK-8335468 >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. https://bugs.openjdk.org/browse/JDK-8335470 >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. https://bugs.openjdk.org/browse/JDK-8335469 >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > ... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix default token path Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1490#pullrequestreview-2154767706 From kcr at openjdk.org Tue Jul 2 21:04:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Jul 2024 21:04:26 GMT Subject: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: On Tue, 21 May 2024 14:25:51 GMT, Michael Strau? wrote: > This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; It seems reasonable to get this fix in and then file a new "redo" bug for [JDK-8249737](https://bugs.openjdk.org/browse/JDK-8249737), with the bug title: [REDO] java.lang.RuntimeException: Too many touch points reported That new bug can be linked as "related to" [JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115) and [JDK-8249737](https://bugs.openjdk.org/browse/JDK-8249737). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1459#pullrequestreview-2154868189 From kcr at openjdk.org Tue Jul 2 21:06:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 2 Jul 2024 21:06:26 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v8] In-Reply-To: References: <_UGgNledBmc9soLnBx7bjOXk8RdZxqHycxeKT_wtA-E=.0d23a4dc-f092-4baf-bfd5-442b0aad94af@github.com> Message-ID: On Thu, 27 Jun 2024 11:49:04 GMT, Marius Hanl wrote: >> Change looks good, but I'm still seeing failures on my macOS system (Sonoma 14.5, MacBook Pro M1 Max): >> >> >> SizeToSceneTest > testInitialSizeOnSizeToSceneThenFullscreen() FAILED >> org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) >> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) >> at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) >> at app//test.javafx.stage.SizeToSceneTest.testInitialSizeOnSizeToSceneThenFullscreen(SizeToSceneTest.java:150) >> >> SizeToSceneTest > testInitialSizeAfterShowFullscreenThenSizeToScene() FAILED >> org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) >> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) >> at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) >> at app//test.javafx.stage.SizeToSceneTest.testInitialSizeAfterShowFullscreenThenSizeToScene(SizeToSceneTest.java:186) >> >> SizeToSceneTest > testInitialSizeAfterShowSizeToSceneThenFullscreen() FAILED >> org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) >> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) >> at app//test.javafx.stage.SizeToSceneTest.assertStageScreenBounds(SizeToSceneTest.java:76) >> at app//test.javafx.stage.SizeToSceneTest.testInitialSizeAfterShowSizeToSceneThenFullscreen(SizeToSceneTest.java:162) >> >> SizeToSceneTest > testInitialSizeOnFullscreenThenSizeToScene() FAILED >> org.opentest4j.AssertionFailedError: 1080.0 >= 1085.0 ==> expected: but was: >> at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) >> at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) >> at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) >> ... > >> Change looks good, but I'm still seeing failures on my macOS system (Sonoma 14.5, MacBook Pro M1 Max): > > ~I'm confused, the screen height is reported as 1085? ...~ > > Search the web led me to this: > Browser size for Mac: > 1920 -> 1903 | 1200 -> 1085 > > So it looks like JavaFX is using 1080 for whatever reason while the visible bounds are 1085. Weird, but my next push will add a delta now. @Maran23 This is ready for you to integrate now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2204415200 From prr at openjdk.org Tue Jul 2 21:42:24 2024 From: prr at openjdk.org (Phil Race) Date: Tue, 2 Jul 2024 21:42:24 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v4] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 20:04:39 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. https://bugs.openjdk.org/browse/JDK-8335468 >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. https://bugs.openjdk.org/browse/JDK-8335470 >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. https://bugs.openjdk.org/browse/JDK-8335469 >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > ... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix default token path Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1490#pullrequestreview-2154925482 From mstrauss at openjdk.org Tue Jul 2 22:39:24 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 2 Jul 2024 22:39:24 GMT Subject: Integrated: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ In-Reply-To: References: Message-ID: On Tue, 21 May 2024 14:25:51 GMT, Michael Strau? wrote: > This PR fixes a bug ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was introduced with #394, which changed the following line in the `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function `GetMessageExtraInfo` to distinguish between mouse events and pen events as described in this article: https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported for `WM_TOUCH` messages, but my testing shows that that's probably not the case (I tested this with a XPS 15 touchscreen laptop, where `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; This pull request has now been integrated. Changeset: 6c3fb5f5 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/6c3fb5f557597a5a226d4a7bd41d84b7feb4a162 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8289115: Touch events is not dispatched after upgrade to JAVAFX17+ Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1459 From mhanl at openjdk.org Wed Jul 3 09:20:29 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 3 Jul 2024 09:20:29 GMT Subject: Integrated: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window In-Reply-To: References: Message-ID: On Mon, 26 Feb 2024 20:51:56 GMT, Marius Hanl wrote: > This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. > > The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. > Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). This pull request has now been integrated. Changeset: 5656b80f Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/5656b80f8a584a2d4d791f9fab83f1719b29f986 Stats: 300 lines in 3 files changed: 299 ins; 0 del; 1 mod 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window Reviewed-by: lkostyra, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1382 From azvegint at openjdk.org Wed Jul 3 09:56:26 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 3 Jul 2024 09:56:26 GMT Subject: Integrated: 8326712: Robot tests fail on XWayland In-Reply-To: References: Message-ID: <4VZvpRJH89LWgwaxF_awxUKuNdUz9mG2OLLdjpM4HdQ=.979c18b0-261f-41ee-8527-d28807238dfe@github.com> On Wed, 26 Jun 2024 11:25:37 GMT, Alexander Zvegintsev wrote: > Most of the headful test failures on XWayland are due to screen capture is not working. > > Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. > Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. > > This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). > > The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. > Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. > > >
> > So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. > For ease of review, you can skip the changes in the first two commits: > - First commit is a direct copy of files from OpenJDK > - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). > > properties added: > > - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) > - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` > >
> > What are the remaining issues? > > 1. https://bugs.openjdk.org/browse/JDK-8335468 > > After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. > > This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. > So a change is required on OpenJDK side to fix this issue. > > 2. https://bugs.openjdk.org/browse/JDK-8335470 > > Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. > > 3. https://bugs.openjdk.org/browse/JDK-8335469 > > Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > This is to reduce overhead in case of frequent consecutive screen captures. > > There... This pull request has now been integrated. Changeset: 459b15fc Author: Alexander Zvegintsev URL: https://git.openjdk.org/jfx/commit/459b15fc61e7a78f29c16fe665370657c1236b3f Stats: 14865 lines in 104 files changed: 14852 ins; 0 del; 13 mod 8326712: Robot tests fail on XWayland Reviewed-by: kcr, prr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1490 From duke at openjdk.org Wed Jul 3 10:00:29 2024 From: duke at openjdk.org (elfoxus) Date: Wed, 3 Jul 2024 10:00:29 GMT Subject: RFR: JDK-8298104: NPE on synchronizeSceneNodes() In-Reply-To: References: Message-ID: On Fri, 22 Dec 2023 10:19:28 GMT, Daniel wrote: >> A null pointer exception occurs on the ScenePulseListener when iterating through the dirty node list. >> A null check is needed on the node before calling node.getScene(). >> >> The error occurs occasionally and causes the application to crash. >> >> Issue: [JDK-8298104: NPE on synchronizeSceneNodes()](https://bugs.openjdk.org/browse/JDK-8298104) > > Hi John, > > I've been working on moving our project from Java 8 to Java 17 and JavaFX 21 for the past month. But I can't seem to fix a bug that keeps showing up, even after running the applications for over 10 days on JavaFX version 21.0.1. > Now, I'm having trouble compiling javafx-graphics for Windows. Any ideas on how to figure out what's causing the problem? > > **If anyone has the ability to assist us with this issue, please get in touch with me. I would be willing to compensate for your help**. > > best regards, > Daniel > > ![image](https://github.com/openjdk/jfx/assets/5691507/7f932d67-9a5d-448e-a87c-519ddeb42767) > > > 2023-12-15 11:00:37,026 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] AdviseUncaughtExceptionHandler uncaughtException detects NullPointerException > 2023-12-15 11:00:37,026 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] NullPointerException => > java.lang.NullPointerException: Cannot invoke "javafx.scene.Node.getScene()" because "" is null > at javafx.scene.Scene$ScenePulseListener.synchronizeSceneNodes(Scene.java:2483) > at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2630) > at com.sun.javafx.tk.Toolkit.lambda$runPulse$2(Toolkit.java:401) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:399) > at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:400) > at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:430) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572) > at com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565) > at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$11(QuantumToolkit.java:352) > at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95) > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method) > at com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:185) > at java.base/java.lang.Thread.run(Thread.java:840) > 2023-12-15 11:00:37,027 ERROR [JavaFX Application Thread] c.m.a.e.AdviseUncaughtExceptionHandler [?:?] Exception > java.lang.NullPointerException: Cannot invoke "javafx.scene.Node.getScene()" because "" is null > at... I'm interested if you @buedi handled this issue, I mean whether you found reason behind it. In my current project I am facing the same problem. It happens hardly ever and only on one machine in my client's environment, so debugging is kinda hard. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1123#issuecomment-2205621496 From arapte at openjdk.org Wed Jul 3 14:30:32 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 3 Jul 2024 14:30:32 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 10:25:58 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag > - JDK-8322619: Fix waiting for the stage > - JDK-8322619: Improve output message in test > - JDK-8322619: Avoid using of Thread.sleep(..) > - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. I have tested the patch with several samples. Fix looks good. Though the test fails on my Mac machine with below error. Please verify.. NGNodeDirtyFlagTest > testNGNodesNotDirty FAILED org.junit.ComparisonFailure: A node was not rendered properly. Wrong color found expected:<[LIGHTGREEN]> but was:<[0x81ee7eff]> at org.junit.Assert.assertEquals(Assert.java:117) at test.com.sun.prism.impl.NGNodeDirtyFlagTest.checkColor(NGNodeDirtyFlagTest.java:135) at test.com.sun.prism.impl.NGNodeDirtyFlagTest.lambda$checkLineColor$5(NGNodeDirtyFlagTest.java:126) 1 test completed, 1 failed > Task :systemTests:test FAILED ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2206289173 From arapte at openjdk.org Wed Jul 3 14:34:30 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 3 Jul 2024 14:34:30 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 10:25:58 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag > - JDK-8322619: Fix waiting for the stage > - JDK-8322619: Improve output message in test > - JDK-8322619: Avoid using of Thread.sleep(..) > - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. Few minor comments on the tests, apart from the failure that I see on Mac. Otherwise I could not find any issues. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 49: > 47: static MyApp myApp; > 48: > 49: private CountDownLatch latch = new CountDownLatch(1); minor: latch is unused variable. Should be removed. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 68: > 66: root = new StackPane(); > 67: primaryStage.setScene(new Scene(root, 500, 400)); > 68: Please add `primaryStage.setAlwaysOnTop(true);` call here, without it the test can fail fail intermittently if the test window gets behind any other window. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 121: > 119: checkLineColor(root, lineColor.get()); > 120: } > 121: minor: can remove the empty line. ------------- PR Review: https://git.openjdk.org/jfx/pull/1451#pullrequestreview-2152023072 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1661400361 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664293406 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664293879 From kcr at openjdk.org Wed Jul 3 14:59:28 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Jul 2024 14:59:28 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 10:25:58 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag > - JDK-8322619: Fix waiting for the stage > - JDK-8322619: Improve output message in test > - JDK-8322619: Avoid using of Thread.sleep(..) > - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. Changes requested by kcr (Lead). tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 1: > 1: package test.com.sun.prism.impl; This needs a standard Copyright header. Also, all tests that use Robot _must_ be under the `test.robot.**` package hierarchy. Please move the test and change the package. ------------- PR Review: https://git.openjdk.org/jfx/pull/1451#pullrequestreview-2156694557 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664338216 From kcr at openjdk.org Wed Jul 3 15:08:25 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Jul 2024 15:08:25 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 10:25:58 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag > - JDK-8322619: Fix waiting for the stage > - JDK-8322619: Improve output message in test > - JDK-8322619: Avoid using of Thread.sleep(..) > - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. A couple more test comments. tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 135: > 133: Bounds screenBounds = node.localToScreen(node.getBoundsInLocal()); > 134: WritableImage image = robot.getScreenCapture(null, screenBounds.getMinX(), screenBounds.getMinY(), 100, 100); > 135: Assert.assertEquals("A node was not rendered properly. Wrong color found", name(expected), name(image.getPixelReader().getColor(1, 1))); This method of color comparison seems convoluted and error prone. I recommend using one of the existing color comparison methods with toloerance. See VisualTestBase, for example. ------------- PR Review: https://git.openjdk.org/jfx/pull/1451#pullrequestreview-2156718906 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664352683 From kcr at openjdk.org Wed Jul 3 15:08:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 3 Jul 2024 15:08:26 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: <-aM8iPWyRxWz4kRccG0p4UevksyScaYuvH1taoEiQRU=.7ff0c729-5b92-489a-8b0a-f42ba5cccf8a@github.com> On Wed, 3 Jul 2024 14:30:45 GMT, Ambarish Rapte wrote: >> eduardsdv 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag >> - JDK-8322619: Fix waiting for the stage >> - JDK-8322619: Improve output message in test >> - JDK-8322619: Avoid using of Thread.sleep(..) >> - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. > > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 68: > >> 66: root = new StackPane(); >> 67: primaryStage.setScene(new Scene(root, 500, 400)); >> 68: > > Please add `primaryStage.setAlwaysOnTop(true);` call here, without it the test can fail fail intermittently if the test window gets behind any other window. Also, we generally recommend an undecorated stage for any tests that do a screen capture. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664354188 From duke at openjdk.org Wed Jul 3 16:26:39 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 3 Jul 2024 16:26:39 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v4] In-Reply-To: References: Message-ID: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with ``gradlew -PFULL_TEST=true :systemTests:test --tests NGNodeDirtyFlagTest`` eduardsdv has updated the pull request incrementally with four additional commits since the last revision: - JDK-8322619: Move to the test.robot.com.sun.prism package and use TOLERANCE when comparing colors - JDK-8322619: Add copyright header - JDK-8322619: Add waiting for rendering before taking a snapshot - JDK-8322619: Remove unused field; Add stage.setAlwaysOnTop(..); stage.initStyle(..) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1451/files - new: https://git.openjdk.org/jfx/pull/1451/files/e3bd58f3..ac971e14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=02-03 Stats: 353 lines in 2 files changed: 163 ins; 190 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1451.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/jfx/pull/1451 From duke at openjdk.org Wed Jul 3 16:39:28 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 3 Jul 2024 16:39:28 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: <-4LDpIN6KzB26lZ2j4Rx8vsq8kand5Xj75XTqb6r-Gs=.a706fad8-c3a4-469f-8020-2e5e220fb642@github.com> On Wed, 3 Jul 2024 14:55:16 GMT, Kevin Rushforth wrote: >> eduardsdv 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag >> - JDK-8322619: Fix waiting for the stage >> - JDK-8322619: Improve output message in test >> - JDK-8322619: Avoid using of Thread.sleep(..) >> - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. > > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 1: > >> 1: package test.com.sun.prism.impl; > > This needs a standard Copyright header. > > Also, all tests that use Robot _must_ be under the `test.robot.**` package hierarchy. Please move the test and change the package. I moved it to the ``test.robot.com.sun.prism`` package and added the copyright header. Now the test needs an additional parameter in the start command **-PUSE_ROBOT=true**: ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 135: > >> 133: Bounds screenBounds = node.localToScreen(node.getBoundsInLocal()); >> 134: WritableImage image = robot.getScreenCapture(null, screenBounds.getMinX(), screenBounds.getMinY(), 100, 100); >> 135: Assert.assertEquals("A node was not rendered properly. Wrong color found", name(expected), name(image.getPixelReader().getColor(1, 1))); > > This method of color comparison seems convoluted and error prone. I recommend using one of the existing color comparison methods with toloerance. See VisualTestBase, for example. The test now uses ``VisualTestBase.assertColorEquals(Color expected, Color actual, double delta)`` to compare colors. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664469982 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664474502 From duke at openjdk.org Wed Jul 3 16:39:29 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 3 Jul 2024 16:39:29 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: <2gvuHt8zisNZTh1q9ROmnx0mFJzofSvDpkI-XqCHk_M=.6b87d16d-50f0-446e-95be-59ba72eccef2@github.com> On Mon, 1 Jul 2024 18:24:36 GMT, Ambarish Rapte wrote: >> eduardsdv 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag >> - JDK-8322619: Fix waiting for the stage >> - JDK-8322619: Improve output message in test >> - JDK-8322619: Avoid using of Thread.sleep(..) >> - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. > > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 49: > >> 47: static MyApp myApp; >> 48: >> 49: private CountDownLatch latch = new CountDownLatch(1); > > minor: latch is unused variable. Should be removed. Done > tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 121: > >> 119: checkLineColor(root, lineColor.get()); >> 120: } >> 121: > > minor: can remove the empty line. Done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664465784 PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664467869 From duke at openjdk.org Wed Jul 3 16:39:31 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 3 Jul 2024 16:39:31 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: <-aM8iPWyRxWz4kRccG0p4UevksyScaYuvH1taoEiQRU=.7ff0c729-5b92-489a-8b0a-f42ba5cccf8a@github.com> References: <-aM8iPWyRxWz4kRccG0p4UevksyScaYuvH1taoEiQRU=.7ff0c729-5b92-489a-8b0a-f42ba5cccf8a@github.com> Message-ID: <4BO0F2nvORXrOJWzrn2nPZxXmlqL3OytKI9FDPQlLPQ=.54cb7676-83bc-44ab-80d6-c6d0ad457c89@github.com> On Wed, 3 Jul 2024 15:05:50 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/com/sun/prism/impl/NGNodeDirtyFlagTest.java line 68: >> >>> 66: root = new StackPane(); >>> 67: primaryStage.setScene(new Scene(root, 500, 400)); >>> 68: >> >> Please add `primaryStage.setAlwaysOnTop(true);` call here, without it the test can fail fail intermittently if the test window gets behind any other window. > > Also, we generally recommend an undecorated stage for any tests that do a screen capture. The test now extends the ``VisualTestBase`` and therefore the stage is now alwaysOnTop and undecorated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1451#discussion_r1664467625 From duke at openjdk.org Wed Jul 3 16:46:28 2024 From: duke at openjdk.org (eduardsdv) Date: Wed, 3 Jul 2024 16:46:28 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v3] In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 14:27:19 GMT, Ambarish Rapte wrote: >> eduardsdv 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'refs/remotes/origin/master' into bugfix/JDK-8322619-render-dirty-flag >> - JDK-8322619: Fix waiting for the stage >> - JDK-8322619: Improve output message in test >> - JDK-8322619: Avoid using of Thread.sleep(..) >> - JDK-8322619: Combine clearDirtyTree() and clearDirty() methods. > > I have tested the patch with several samples. Fix looks good. > Though the test fails on my Mac machine with below error. > Please verify.. > > > NGNodeDirtyFlagTest > testNGNodesNotDirty FAILED > org.junit.ComparisonFailure: A node was not rendered properly. Wrong color found expected:<[LIGHTGREEN]> but was:<[0x81ee7eff]> > at org.junit.Assert.assertEquals(Assert.java:117) > at test.com.sun.prism.impl.NGNodeDirtyFlagTest.checkColor(NGNodeDirtyFlagTest.java:135) > at test.com.sun.prism.impl.NGNodeDirtyFlagTest.lambda$checkLineColor$5(NGNodeDirtyFlagTest.java:126) > > 1 test completed, 1 failed > >> Task :systemTests:test FAILED @arapte: The failed test on the Mac is probably caused by the lack of synchronization between the JavaFX and QuantumRenderer threads. I added the ``waitForRenderer()`` method to wait for the stage to render before checking the colors.. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2206776887 From angorya at openjdk.org Wed Jul 3 17:48:27 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Jul 2024 17:48:27 GMT Subject: RFR: 8326712: Robot tests fail on XWayland [v4] In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 20:04:39 GMT, Alexander Zvegintsev wrote: >> Most of the headful test failures on XWayland are due to screen capture is not working. >> >> Wayland, unlike X11, does not allow arbitrary applications to capture the screen contents directly. >> Instead, screen capture functionality is managed by the compositor, which can enforce stricter controls and permissions, requiring explicit user approval for screen capture operations. >> >> This issue is already resolved in OpenJDK ([base issue](https://bugs.openjdk.org/browse/JDK-8280982), there are subsequent fixes) by using the [ScreenCast XDG portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.ScreenCast.html). >> >> The XDG ScreenCast portal is utilized for capturing screen data as it provides a secure and standardized method for applications to access screen content. >> Additionally, it allows for the reuse of user permissions without requiring repeated confirmations, streamlining the user experience and enhancing convenience. >> >> >>
>> >> So this changeset is a copy of the OpenJDK fixes with the addition of the JavaFX customization. >> For ease of review, you can skip the changes in the first two commits: >> - First commit is a direct copy of files from OpenJDK >> - Second commit removes the `gtk-` prefix before the `gtk_...` and `g_...` function calls (in AWT all gtk functions are dynamically loaded, we don't need that in JavaFX). >> >> properties added: >> >> - `javafx.robot.screenshotMethod`, accepts `gtk`(existing gtk method) and `dbusScreencast`(added by this changeset, used by default for Wayland) >> - `javafx.robot.screenshotDebug` prints debug info if it is set to `true` >> >>
>> >> What are the remaining issues? >> >> 1. https://bugs.openjdk.org/browse/JDK-8335468 >> >> After applying this fix, system tests will pass except for the `SwingNodeJDialogTest` test. >> >> This interop test calls `java.awt.Robot#getPixelColor` which internally `gtk->g_main_context_iteration(NULL, TRUE);` causes a blocking of javafx gtk loop, so the test hangs. >> So a change is required on OpenJDK side to fix this issue. >> >> 2. https://bugs.openjdk.org/browse/JDK-8335470 >> >> Even after solving the `#1`, the `SwingNodeJDialogTest.testNodeRemovalBeforeShow` case is still failing. >> >> 3. https://bugs.openjdk.org/browse/JDK-8335469 >> >> Internally the ScreenCast session keeps open for [2s](https://github.com/openjdk/jdk/blob/d457609f700bbb1fed233f1a04501c995852e5ac/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62). > ... > > Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision: > > fix default token path modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension.java line 39: > 37: } > 38: > 39: public boolean equals(Object obj) { [JDK-8335633](https://bugs.openjdk.org/browse/JDK-8335633) Missing @Override in Dimension ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1490#discussion_r1664551499 From angorya at openjdk.org Wed Jul 3 17:55:33 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 3 Jul 2024 17:55:33 GMT Subject: RFR: 8335633: Missing @Override in Dimension Message-ID: added missing @Override annotations ------------- Commit messages: - 8335633: Missing @Override in Dimension Changes: https://git.openjdk.org/jfx/pull/1494/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1494&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335633 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1494.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1494/head:pull/1494 PR: https://git.openjdk.org/jfx/pull/1494 From arapte at openjdk.org Wed Jul 3 20:29:23 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 3 Jul 2024 20:29:23 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v4] In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 16:26:39 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: >> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv has updated the pull request incrementally with four additional commits since the last revision: > > - JDK-8322619: Move to the test.robot.com.sun.prism package and use TOLERANCE when comparing colors > - JDK-8322619: Add copyright header > - JDK-8322619: Add waiting for rendering before taking a snapshot > - JDK-8322619: Remove unused field; Add stage.setAlwaysOnTop(..); stage.initStyle(..) The newer version still fails on my Mac machine. Attaching modified test that executes as expected on my Windows and Mac machines. The main change that makes it work on Mac is the change in `checkColor()` method. There are some additional minor changes, and I recommend to keep those. Please do test on your machines. [NGNodeDirtyFlagTest.java.zip](https://github.com/user-attachments/files/16090444/NGNodeDirtyFlagTest.java.zip) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2207192990 From jhendrikx at openjdk.org Wed Jul 3 21:04:22 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Wed, 3 Jul 2024 21:04:22 GMT Subject: RFR: 8335633: Missing @Override in Dimension In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 17:50:03 GMT, Andy Goryachev wrote: > added missing @Override annotations Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1494#pullrequestreview-2157430364 From duke at openjdk.org Thu Jul 4 07:38:50 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 4 Jul 2024 07:38:50 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: > ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` eduardsdv has updated the pull request incrementally with one additional commit since the last revision: JDK-8322619: Use VisualTestBase.getColor(..) ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1451/files - new: https://git.openjdk.org/jfx/pull/1451/files/ac971e14..229927cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1451.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/jfx/pull/1451 From duke at openjdk.org Thu Jul 4 07:43:25 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 4 Jul 2024 07:43:25 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v4] In-Reply-To: References: Message-ID: <0OcAKXslgo7o1tNLT6_fznzR2OnyG-cl5DDcKwxZEjY=.6c3e49b5-162e-4495-a9ad-3eaf48527f8a@github.com> On Wed, 3 Jul 2024 20:26:35 GMT, Ambarish Rapte wrote: >> eduardsdv has updated the pull request incrementally with four additional commits since the last revision: >> >> - JDK-8322619: Move to the test.robot.com.sun.prism package and use TOLERANCE when comparing colors >> - JDK-8322619: Add copyright header >> - JDK-8322619: Add waiting for rendering before taking a snapshot >> - JDK-8322619: Remove unused field; Add stage.setAlwaysOnTop(..); stage.initStyle(..) > > The newer version still fails on my Mac machine. > > Attaching modified test that executes as expected on my Windows and Mac machines. > The main change that makes it work on Mac is the change in `checkColor()` method. > There are some additional minor changes, and I recommend to keep those. > Please do test on your machines. > > [NGNodeDirtyFlagTest.java.zip](https://github.com/user-attachments/files/16090444/NGNodeDirtyFlagTest.java.zip) Yes, the test with your suggestion also works under Windows. Thank you, @arapte. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2208319678 From arapte at openjdk.org Thu Jul 4 07:53:28 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 4 Jul 2024 07:53:28 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v4] In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 20:26:35 GMT, Ambarish Rapte wrote: >> eduardsdv has updated the pull request incrementally with four additional commits since the last revision: >> >> - JDK-8322619: Move to the test.robot.com.sun.prism package and use TOLERANCE when comparing colors >> - JDK-8322619: Add copyright header >> - JDK-8322619: Add waiting for rendering before taking a snapshot >> - JDK-8322619: Remove unused field; Add stage.setAlwaysOnTop(..); stage.initStyle(..) > > The newer version still fails on my Mac machine. > > Attaching modified test that executes as expected on my Windows and Mac machines. > The main change that makes it work on Mac is the change in `checkColor()` method. > There are some additional minor changes, and I recommend to keep those. > Please do test on your machines. > > [NGNodeDirtyFlagTest.java.zip](https://github.com/user-attachments/files/16090444/NGNodeDirtyFlagTest.java.zip) > Yes, the test with your suggestion also works under Windows. Thank you, @arapte. Thanks for verifying. In that case, let's remove the `waitForRenderer()` method that was added to solve the test failure on Mac but is not required anymore. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2208335671 From duke at openjdk.org Thu Jul 4 08:06:39 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 4 Jul 2024 08:06:39 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v6] In-Reply-To: References: Message-ID: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: > ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` eduardsdv has updated the pull request incrementally with one additional commit since the last revision: JDK-8322619: Remove waiting for the QuantumRenderer ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1451/files - new: https://git.openjdk.org/jfx/pull/1451/files/229927cc..a7646e8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1451&range=04-05 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1451.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1451/head:pull/1451 PR: https://git.openjdk.org/jfx/pull/1451 From duke at openjdk.org Thu Jul 4 08:06:39 2024 From: duke at openjdk.org (eduardsdv) Date: Thu, 4 Jul 2024 08:06:39 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v4] In-Reply-To: References: Message-ID: <7RRTxAlleiuboXhNVbqhnWZaforuRMG_TTT7Xrfut8A=.6c275837-2621-42bb-9d44-5251626ffd28@github.com> On Thu, 4 Jul 2024 07:51:00 GMT, Ambarish Rapte wrote: >> Yes, the test with your suggestion also works under Windows. Thank you, @arapte. > >Thanks for verifying. In that case, let's remove the waitForRenderer() method that was added to solve the test failure on Mac but is not required anymore. I removed the method. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2208357342 From mhanl at openjdk.org Thu Jul 4 09:32:39 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 4 Jul 2024 09:32:39 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: add many more unit tests for Tooltip ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/bd57e79d..6abc47b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=07-08 Stats: 191 lines in 4 files changed: 178 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Thu Jul 4 09:32:40 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 4 Jul 2024 09:32:40 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v8] In-Reply-To: References: Message-ID: <71J69QKGSa5kqK-EX1AAhI9pLwGzMOMx7d7IA_ibbyU=.94de5a50-d141-4def-a7e6-243e6c021b2c@github.com> On Wed, 26 Jun 2024 10:43:30 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Use Helper class instead TIL how we can test things that involves animations like `Timeline`. Wrote a lot of unit tests for `Tooltip` as well now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2208525243 From arapte at openjdk.org Thu Jul 4 10:14:23 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 4 Jul 2024 10:14:23 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v6] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 08:06:39 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: >> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8322619: Remove waiting for the QuantumRenderer Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1451#pullrequestreview-2158554495 From kcr at openjdk.org Thu Jul 4 12:53:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jul 2024 12:53:26 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v6] In-Reply-To: References: Message-ID: <0izH1EfT7FyVwH9x7_LQ7ItXhbfA8mkIL7FTywA0HQs=.5b8d0d49-e6e5-4d20-97af-9711c70ad0d6@github.com> On Thu, 4 Jul 2024 08:06:39 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: >> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8322619: Remove waiting for the QuantumRenderer @lukostyra Can you be the second reviewer on this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2208901691 From kcr at openjdk.org Thu Jul 4 12:55:23 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 4 Jul 2024 12:55:23 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v5] In-Reply-To: References: Message-ID: On Fri, 17 May 2024 12:36:22 GMT, Florian Kirmaier wrote: >> Florian Kirmaier has updated the pull request incrementally with two additional commits since the last revision: >> >> - JDK-8322619: Add test >> - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" >> >> This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. > > Sorry for creating the CSR, it was an accident. > > Now that Eduard has both created an alternative solution, but also has reviewed that this solution is correct, and provided an unit-test - I think this (or the other) PR is ready to move forwards. > > @kevinrushforth > What do you think? > > This is still quite a fundamental bug which is probably quite prevalent, > because when it happens it is really hard to notice it. > But it probably happens more often than we think. @FlorianKirmaier since it looks like we are going with PR #1451 as the solution, please close this PR (or move it to Draft until #1451 is integrated and then close it). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2208904453 From azvegint at openjdk.org Thu Jul 4 13:28:23 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 4 Jul 2024 13:28:23 GMT Subject: RFR: 8335633: Missing @Override in Dimension In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 17:50:03 GMT, Andy Goryachev wrote: > added missing @Override annotations Marked as reviewed by azvegint (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1494#pullrequestreview-2158934205 From mstrauss at openjdk.org Thu Jul 4 19:40:57 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 4 Jul 2024 19:40:57 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `ImagePattern` > - `LinearGradient` > - `RadialGradient` > - `Stop` > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the target list, the excess elements are discarded.... 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 13 additional commits since the last revision: - fix line separators - add documentation to Point2D/3D - change documentation - add specification - add exports - revert change - revert change - added more tests - added specification and tests - Merge branch 'master' into feature/interpolatable - ... and 3 more: https://git.openjdk.org/jfx/compare/c74fcdf3...08ed751b ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1471/files - new: https://git.openjdk.org/jfx/pull/1471/files/bb84c57d..08ed751b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1471&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1471&range=01-02 Stats: 24002 lines in 240 files changed: 23316 ins; 106 del; 580 mod Patch: https://git.openjdk.org/jfx/pull/1471.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1471/head:pull/1471 PR: https://git.openjdk.org/jfx/pull/1471 From nlisker at openjdk.org Thu Jul 4 19:40:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 4 Jul 2024 19:40:57 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v2] In-Reply-To: <0DsPTNpLGdTQR603Iscp4K79eMJQvyBygZh6CzoSrgY=.22060bf4-bd01-4326-99b4-874029421a60@github.com> References: <0DsPTNpLGdTQR603Iscp4K79eMJQvyBygZh6CzoSrgY=.22060bf4-bd01-4326-99b4-874029421a60@github.com> Message-ID: <--2W3_lPO3SF7AvBRpbaYBoULwEUKSNbukOLCO-1JDQ=.82fcca70-a899-4dd8-be4c-4f9e2a1ed762@github.com> On Tue, 4 Jun 2024 20:46:28 GMT, Kevin Rushforth wrote: > @nlisker would you be willing to be the second reviewer? I could do some of the review, but probably no time for a full one. > Since you propose interpolating objects that aren't simple sets of floating-point fields, the overridden interpolate method should specify the behavior of the fields that are not. For example, different types of Paint are sometimes interpolatable and sometimes return either the start or end; some fields of BackgroundImage are interpolatable and others (notably the image itself) return either the start or the end; and so forth. When I did the (simple) interpolation work on [Point2D/3D](https://bugs.openjdk.org/browse/JDK-8226454) I also looked at `Border` and `Background` because animating the color of these is rather common. The problem is that they are rather complex and don't interpolate trivially as a whole. As a user, if I want to interpolate between images, I would think of a smooth transition between them, not a jump cut. There are other oddities as well. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2151084870 From nlisker at openjdk.org Thu Jul 4 19:40:57 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Thu, 4 Jul 2024 19:40:57 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders In-Reply-To: References: Message-ID: On Mon, 3 Jun 2024 09:48:40 GMT, Florian Kirmaier wrote: > Note that this PR also changes the specification of Interpolatable to make users aware that they shouldn't assume any particular identity of the object returned from the interpolate() method. This allows the implementation to re-use objects and reduce the number of object allocations. There is an issue for that already: https://bugs.openjdk.org/browse/JDK-8226911. You can take it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2151085981 From mstrauss at openjdk.org Thu Jul 4 19:55:23 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 4 Jul 2024 19:55:23 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 19:40:57 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `ImagePattern` >> - `LinearGradient` >> - `RadialGradient` >> - `Stop` >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target li... > > 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 13 additional commits since the last revision: > > - fix line separators > - add documentation to Point2D/3D > - change documentation > - add specification > - add exports > - revert change > - revert change > - added more tests > - added specification and tests > - Merge branch 'master' into feature/interpolatable > - ... and 3 more: https://git.openjdk.org/jfx/compare/d436b7df...08ed751b I've added a new "interpolation type" specification for all components of interpolatable classes. This mirrors the "animation type" of the CSS specification, which is listed as an entry in the property table. Please also read the updated top-level post of this PR, which goes into more detail about this new specification. @kevinrushforth This might be a candidate for a late enhancement, because the risk is relatively low (it's mostly the addition of the `interpolate()` method to various types), and it seems to be important to make the CSS transitions feature useful (backgrounds and borders will probably be one of the most obvious things developers will want to animate). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2209504560 From mstrauss at openjdk.org Thu Jul 4 20:13:25 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 4 Jul 2024 20:13:25 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 19:40:57 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `ImagePattern` >> - `LinearGradient` >> - `RadialGradient` >> - `Stop` >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target li... > > 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 13 additional commits since the last revision: > > - fix line separators > - add documentation to Point2D/3D > - change documentation > - add specification > - add exports > - revert change > - revert change > - added more tests > - added specification and tests > - Merge branch 'master' into feature/interpolatable > - ... and 3 more: https://git.openjdk.org/jfx/compare/60cc590f...08ed751b modules/javafx.graphics/src/main/java/javafx/scene/paint/Stop.java line 267: > 265: public Stop(@NamedArg("offset") double offset, @NamedArg(value="color", defaultValue="BLACK") Color color) { > 266: this.offset = offset; > 267: this.color = Objects.requireNonNullElse(color, Color.TRANSPARENT); Note that a `null` color is now treated as `TRANSPARENT` for the following reasons: 1. The previous implementation was broken: if a `Stop` is constructed with a `null` color, the `hashCode()` method throws a NPE because it doesn't check for `null`. 2. It doesn't make sense to have a stop with `null` color. What does it even mean? 3. When the stop list is normalized, an empty or null list is treated as a two-stop list with `TRANSPARENT` color (see `normalize()`). So we already have a scenario where `null` is treated as `TRANSPARENT`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1471#discussion_r1666040056 From nlisker at gmail.com Fri Jul 5 01:56:01 2024 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 5 Jul 2024 04:56:01 +0300 Subject: Should we document Styleable properties? In-Reply-To: References: <8a48ac6d-591a-4261-87f9-8de11dbf2323@oracle.com> Message-ID: As discussed previously regarding auto-generation of css styleables, an annotation on the property can be made displayable in javadoc. The problem is that it will display *all* the parameters of the annotation. For autogeneration, we need more than what we would like to display, so perhaps two different annotations could work, one for the autogeneration and one for doc marking. On Tue, Jul 2, 2024 at 3:49?PM Eric Bresie wrote: > A little off topic but? > > There is a pending JEP for allowing markup to be included in javadocs > https://openjdk.org/jeps/467 > > Eric Bresie > ebresie at gmail.com > > > On Mon, Jul 1, 2024 at 4:35?PM Michael Strau? > wrote: > >> Further testing shows that while the javadoc tool does support custom >> tags, it doesn?t lift custom tags defined on JavaFX property fields to the >> property method documentation. >> >> Lifting documentation from the property field to property methods is a >> JavaFX-specific feature of Javadoc. At first glance, there seems to be no >> particular reason why custom tags are ignored in this situation; probably >> it just wasn?t implemented. >> >> So if we add this custom tag, it won?t show up on the generated HTML. We >> could start using a custom tag, and then file an enhancement request for >> Javadoc to lift custom tags to methods just as it does with other tags. >> What?s your opinion on that? >> >> >> Andy Goryachev schrieb am Mo. 1. Juli 2024 >> um 23:20: >> >>> Would even work with Eclipse out of the box: >>> >>> >>> >>> >>> >>> I also like the fact that we won't need to maintain links manually as >>> there would not be any. >>> >>> >>> >>> -andy >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Fri Jul 5 13:45:32 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 5 Jul 2024 13:45:32 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled +1 for this change from me. I use VS Code for development, on the marketplace most popular and recommended Java support extension is the Red Hat extension which is essentially repackaged Eclipse. It was always frustrating to try and open JFX only to find out that something doesn't load correctly because the plugin overwrote .project and .classpath files. I checked this PR and with default extension settings it loads properly. All regular features also work fine, so the plugin definitely works correctly after this PR. I only noticed that there are still modified `.project` files in `apps` directory - I wonder if it's just VS Code plugin deal, but it doesn't seem to interrupt the build process for the plugin. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2210903489 From angorya at openjdk.org Fri Jul 5 14:56:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 Jul 2024 14:56:38 GMT Subject: Integrated: 8335633: Missing @Override in Dimension In-Reply-To: References: Message-ID: On Wed, 3 Jul 2024 17:50:03 GMT, Andy Goryachev wrote: > added missing @Override annotations This pull request has now been integrated. Changeset: 72701e6c Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/72701e6cb4095b8f5042f54ae6bb2c0cec446bcf Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8335633: Missing @Override in Dimension Reviewed-by: jhendrikx, azvegint ------------- PR: https://git.openjdk.org/jfx/pull/1494 From angorya at openjdk.org Fri Jul 5 17:08:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 Jul 2024 17:08:36 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 13:42:58 GMT, Lukasz Kostyra wrote: >> This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. >> >> Problem >> ======= >> Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. >> >> Solution >> ====== >> Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. >> >> Advantages >> ========= >> 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. >> 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. >> >> NOTES: >> - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) >> - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. >> - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled > > +1 for this change from me. > > I use VS Code for development, on the marketplace most popular and recommended Java support extension is the Red Hat extension which is essentially repackaged Eclipse. It was always frustrating to try and open JFX only to find out that something doesn't load correctly because the plugin overwrote .project and .classpath files. > > I checked this PR and with default extension settings it loads properly. All regular features also work fine, so the plugin definitely works correctly after this PR. I only noticed that there are still modified `.project` files in `apps` directory - I wonder if it's just VS Code plugin deal, but it doesn't seem to interrupt the build process for the plugin. @lukostyra thank you for testing! there should be no changes made to the .project or any other files. could you reset your workspace and maybe try again? if the changes do appear, what are they? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2211173801 From angorya at openjdk.org Fri Jul 5 17:18:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 5 Jul 2024 17:18:38 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add many more unit tests for Tooltip modules/javafx.controls/src/test/java/test/javafx/scene/control/TooltipTest.java line 657: > 655: // Style: .tooltip { -fx-show-delay: 200ms; } > 656: stageLoader.getStage().getScene().getStylesheets() > 657: .add("data:base64,LnRvb2x0aXAgeyAtZngtc2hvdy1kZWxheTogMjAwbXM7IH0="); this is clever. can we generate the base64-encoded string on the fly? something along the lines return "data:text/css;base64," + Base64.getEncoder().encodeToString(b); (here and elsewhere?) tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 81: > 79: > 80: @AfterAll > 81: static void exit() { I still not convinced I like the concept of non-public methods in tests, since they are annotated. Why do we need to do this? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1667006308 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1667007247 From mhanl at openjdk.org Sat Jul 6 11:15:43 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 6 Jul 2024 11:15:43 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: <1fSQo-ECSvBRB9NvP3QJwmhnNfsAfCbKnNZcjC0-5zg=.1a37aba0-7a47-434f-b43b-44d17ce6aadf@github.com> On Fri, 5 Jul 2024 17:11:54 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> add many more unit tests for Tooltip > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TooltipTest.java line 657: > >> 655: // Style: .tooltip { -fx-show-delay: 200ms; } >> 656: stageLoader.getStage().getScene().getStylesheets() >> 657: .add("data:base64,LnRvb2x0aXAgeyAtZngtc2hvdy1kZWxheTogMjAwbXM7IH0="); > > this is clever. can we generate the base64-encoded string on the fly? something along the lines > > > return "data:text/css;base64," + Base64.getEncoder().encodeToString(b); > > > (here and elsewhere?) Thought about this well, didn't test yet ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1667350521 From mhanl at openjdk.org Sat Jul 6 11:20:40 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 6 Jul 2024 11:20:40 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: <_wEHyveJREGixQ84k3DgrH9f5UOph3sH7dpmg1LxMzs=.82d77cb4-5499-4c12-8268-a70fa6e5bce5@github.com> On Fri, 5 Jul 2024 17:13:47 GMT, Andy Goryachev wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> add many more unit tests for Tooltip > > tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 81: > >> 79: >> 80: @AfterAll >> 81: static void exit() { > > I still not convinced I like the concept of non-public methods in tests, since they are annotated. > > Why do we need to do this? Please check: https://stackoverflow.com/questions/55215949/why-junit-5-default-access-modifier-changed-to-package-private It is essentially the good old 'why make something public when you do not need it?'. It follows the way encapsulation is meant to be, by lowering the visibility as far as you can for something that is not meant to be called from the outside. Also static code analysis will check that and issue a code smell, which makes sense. Quoting Sonarlint here: " JUnit5 is more tolerant regarding the visibility of test classes and methods than JUnit4, which required everything to be public. Test classes and methods can have any visibility except private. It is however recommended to use the default package visibility to improve readability. Test classes, test methods, and lifecycle methods are not required to be public, but they must not be private. It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ? for example, when a test class is extended by a test class in another package. Another technical reason for making classes and methods public is to simplify testing on the module path when using the Java Module System. ? JUnit5 User Guide " ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1667351090 From nlisker at gmail.com Sat Jul 6 23:38:18 2024 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 7 Jul 2024 02:38:18 +0300 Subject: [External] : Re: Eclipse and Gradle in OpenJFX In-Reply-To: References: Message-ID: Sorry for the late reply, I have a lot on my plate. why we need to jump through the hoops with the initial import (reverting > the changes etc.) even if it described and We don't *need* to, but using Gradle within Eclipse makes it easier to work with, at least for some people. The Gradle integration for Eclipse removes the need for a separate command line. You can run all the Gradle commands from within Eclipse. what 'eclipse' task you are referring to? There is no 'eclipse' task in > build.gradle as far as I can see (see below) I have 2 tasks from the 'eclipse' plugin ( https://docs.gradle.org/current/userguide/eclipse_plugin.html). It looks like that plugin is applied automatically in my workspace for all Gradle projects. That plugin adds a task called 'eclipse' that creates the Eclipse project and classpath files from the gradle build file. When I use it in my projects, it works very well and I don't need to add special --add-modules arguments, for example. I just tried it with OpenJFX and it works very badly. I played with the huge gradle build file to see where the problems come from. In summary, that file was written with Gradle 2 it seems and uses features that aren't needed anymore and it trips the plugin up. What is the value of keeping these steps and complicating the process (with > Eclipse)? Working directly from the IDE without needing a command line. However, I suppose that anyone who wants to use Gradle from Eclipse can convert the projects to Gradle projects. Then again, anyone who doesn't want that can disable the Gradle nature of the projects. Both of these are a one-time action. I will continue the technical discussion on https://github.com/openjdk/jfx/pull/1491. On Thu, Jun 20, 2024 at 6:16?PM Andy Goryachev wrote: > Nir: > > > > I don't understand two things: > > > > 1. why we need to jump through the hoops with the initial import > (reverting the changes etc.) even if it described and > 2. what 'eclipse' task you are referring to? There is no 'eclipse' > task in build.gradle as far as I can see (see below) > > > > What is the value of keeping these steps and complicating the process > (with Eclipse)? > > > > -andy > > > > > > > > > > > > > > $ gradle -q :tasks --all > > Defining Closed Properties > > [...snip...] > > > > *------------------------------------------------------------* > > *Tasks runnable from root project 'rt'* > > *------------------------------------------------------------* > > > > Default tasks: sdk > > > > *Basic tasks* > > *-----------* > > appsMac - Runs the apps creation tasks > > buildModuleBaseMac - creates javafx.base property files > > buildModuleGraphicsMac - copies javafx.graphics native libraries > > buildModuleLibsMac > > buildModuleMediaMac - copies javafx.media native libraries > > buildModuleSWTMac - copies SWT JAR > > buildModuleWebMac - copies javafx.web native libraries > > clean - Deletes the build directory and the build directory of all sub > projects > > cleanAll - Scrubs the repo of build artifacts > > findbugsMac - Runs the findbugs creation tasks > > javadoc - Generates the JavaDoc for all the public API > > javafxSwtMac - Creates the javafx-swt.jar for the mac target > > base:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > controls:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > fxml:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > graphics:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > media:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > swing:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > web:jmodCopyLibMac - copied Windows DLLs into javafx subdir for jmods > > publicExportsMac - Creates the public export bundles > > publicExportsStandaloneMac - Creates the disk layout for sdk, jmods, and > docs > > sdkArtifactsMac - Copies bundled and standalone sdk dirs into artifacts > for mac > > sdkMac > > targzJmodsMac - Creates the public jmods tar.gz bundle > > targzSdkMac - Creates the public sdk tar.gz bundle > > zipsMac - Creates the public zip bundles > > zipsStandaloneMac - Creates the public zip bundles > > > > *Build tasks* > > *-----------* > > base:assemble - Assembles the outputs of this project. > > closedTests:assemble - Assembles the outputs of this project. > > controls:assemble - Assembles the outputs of this project. > > fxml:assemble - Assembles the outputs of this project. > > graphics:assemble - Assembles the outputs of this project. > > media:assemble - Assembles the outputs of this project. > > swing:assemble - Assembles the outputs of this project. > > swt:assemble - Assembles the outputs of this project. > > systemTests:assemble - Assembles the outputs of this project. > > web:assemble - Assembles the outputs of this project. > > base:build - Assembles and tests this project. > > closedTests:build - Assembles and tests this project. > > controls:build - Assembles and tests this project. > > fxml:build - Assembles and tests this project. > > graphics:build - Assembles and tests this project. > > media:build - Assembles and tests this project. > > swing:build - Assembles and tests this project. > > swt:build - Assembles and tests this project. > > systemTests:build - Assembles and tests this project. > > web:build - Assembles and tests this project. > > base:buildDependents - Assembles and tests this project and all projects > that depend on it. > > closedTests:buildDependents - Assembles and tests this project and all > projects that depend on it. > > controls:buildDependents - Assembles and tests this project and all > projects that depend on it. > > fxml:buildDependents - Assembles and tests this project and all projects > that depend on it. > > graphics:buildDependents - Assembles and tests this project and all > projects that depend on it. > > media:buildDependents - Assembles and tests this project and all projects > that depend on it. > > swing:buildDependents - Assembles and tests this project and all projects > that depend on it. > > swt:buildDependents - Assembles and tests this project and all projects > that depend on it. > > systemTests:buildDependents - Assembles and tests this project and all > projects that depend on it. > > web:buildDependents - Assembles and tests this project and all projects > that depend on it. > > base:buildModuleMac > > controls:buildModuleMac > > fxml:buildModuleMac > > graphics:buildModuleMac > > media:buildModuleMac > > swing:buildModuleMac > > web:buildModuleMac > > buildModulesMac > > buildModuleZipMac > > base:buildNeeded - Assembles and tests this project and all projects it > depends on. > > closedTests:buildNeeded - Assembles and tests this project and all > projects it depends on. > > controls:buildNeeded - Assembles and tests this project and all projects > it depends on. > > fxml:buildNeeded - Assembles and tests this project and all projects it > depends on. > > graphics:buildNeeded - Assembles and tests this project and all projects > it depends on. > > media:buildNeeded - Assembles and tests this project and all projects it > depends on. > > swing:buildNeeded - Assembles and tests this project and all projects it > depends on. > > swt:buildNeeded - Assembles and tests this project and all projects it > depends on. > > systemTests:buildNeeded - Assembles and tests this project and all > projects it depends on. > > web:buildNeeded - Assembles and tests this project and all projects it > depends on. > > buildRunArgsMac > > graphics:ccMacFont - Compiles native sources for font for mac > > graphics:ccMacGlass - Compiles native sources for glass for mac > > graphics:ccMacIio - Compiles native sources for iio for mac > > graphics:ccMacPrism - Compiles native sources for prism for mac > > graphics:ccMacPrismES2 - Compiles native sources for prismES2 for mac > > graphics:ccMacPrismSW - Compiles native sources for prismSW for mac > > base:classes - Assembles main classes. > > closedTests:classes - Assembles main classes. > > controls:classes - Assembles main classes. > > fxml:classes - Assembles main classes. > > graphics:classes - Assembles main classes. > > media:classes - Assembles main classes. > > swing:classes - Assembles main classes. > > swt:classes - Assembles main classes. > > systemTests:classes - Assembles main classes. > > web:classes - Assembles main classes. > > base:clean - Deletes the build directory. > > closedTests:clean - Deletes the build directory. > > controls:clean - Deletes the build directory. > > fxml:clean - Deletes the build directory. > > graphics:clean - Deletes the build directory. > > media:clean - Deletes the build directory. > > swing:clean - Deletes the build directory. > > swt:clean - Deletes the build directory. > > systemTests:clean - Deletes the build directory. > > web:clean - Deletes the build directory. > > graphics:cleanNative - Clean all native libraries and objects for Graphics > > graphics:cleanNativeDecora - Clean native objects for Decora > > graphics:cleanNativeFont - Clean native objects for font > > graphics:cleanNativeGlass - Clean native objects for glass > > graphics:cleanNativeIio - Clean native objects for iio > > graphics:cleanNativePrism - Clean native objects for prism > > graphics:cleanNativePrismES2 - Clean native objects for prismES2 > > graphics:cleanNativePrismSW - Clean native objects for prismSW > > createMSPfile > > base:jar - Assembles a jar archive containing the classes of the 'main' > feature. > > closedTests:jar - Assembles a jar archive containing the classes of the > 'main' feature. > > controls:jar - Assembles a jar archive containing the classes of the > 'main' feature. > > fxml:jar - Assembles a jar archive containing the classes of the 'main' > feature. > > graphics:jar - Assembles a jar archive containing the classes of the > 'main' feature. > > media:jar - Assembles a jar archive containing the classes of the 'main' > feature. > > swing:jar - Assembles a jar archive containing the classes of the 'main' > feature. > > swt:jar - Assembles a jar archive containing the classes of the 'main' > feature. > > systemTests:jar - Assembles a jar archive containing the classes of the > 'main' feature. > > web:jar - Assembles a jar archive containing the classes of the 'main' > feature. > > base:jmodMac > > controls:jmodMac > > fxml:jmodMac > > graphics:jmodMac > > media:jmodMac > > swing:jmodMac > > web:jmodMac > > graphics:jslcClasses - Assembles jslc classes. > > graphics:linkMacFont - Creates native dynamic library for font for mac > > graphics:linkMacGlass - Creates native dynamic library for glass for mac > > graphics:linkMacIio - Creates native dynamic library for iio for mac > > graphics:linkMacPrism - Creates native dynamic library for prism for mac > > graphics:linkMacPrismES2 - Creates native dynamic library for prismES2 > for mac > > graphics:linkMacPrismSW - Creates native dynamic library for prismSW for > mac > > graphics:native - Compiles and Builds all native libraries for Graphics > > graphics:nativeDecora - Generates JNI headers, compiles, and builds > native dynamic library for Decora > > graphics:nativeFont - Generates JNI headers, compiles, and builds native > dynamic library for font for all compile targets > > graphics:nativeGlass - Generates JNI headers, compiles, and builds native > dynamic library for glass for all compile targets > > graphics:nativeIio - Generates JNI headers, compiles, and builds native > dynamic library for iio for all compile targets > > graphics:nativePrism - Generates JNI headers, compiles, and builds native > dynamic library for prism for all compile targets > > graphics:nativePrismES2 - Generates JNI headers, compiles, and builds > native dynamic library for prismES2 for all compile targets > > graphics:nativePrismSW - Generates JNI headers, compiles, and builds > native dynamic library for prismSW for all compile targets > > graphics:shadersClasses - Assembles shaders classes. > > base:shimsClasses - Assembles shims classes. > > controls:shimsClasses - Assembles shims classes. > > fxml:shimsClasses - Assembles shims classes. > > graphics:shimsClasses - Assembles shims classes. > > swing:shimsClasses - Assembles shims classes. > > web:shimsClasses - Assembles shims classes. > > graphics:stubClasses - Assembles stub classes. > > systemTests:testapp1Classes - Assembles testapp1 classes. > > systemTests:testapp2Classes - Assembles testapp2 classes. > > systemTests:testapp3Classes - Assembles testapp3 classes. > > systemTests:testapp4Classes - Assembles testapp4 classes. > > systemTests:testapp5Classes - Assembles testapp5 classes. > > systemTests:testapp6Classes - Assembles testapp6 classes. > > systemTests:testapp7Classes - Assembles testapp7 classes. > > base:testClasses - Assembles test classes. > > closedTests:testClasses - Assembles test classes. > > controls:testClasses - Assembles test classes. > > fxml:testClasses - Assembles test classes. > > graphics:testClasses - Assembles test classes. > > media:testClasses - Assembles test classes. > > swing:testClasses - Assembles test classes. > > swt:testClasses - Assembles test classes. > > systemTests:testClasses - Assembles test classes. > > web:testClasses - Assembles test classes. > > systemTests:testscriptapp1Classes - Assembles testscriptapp1 classes. > > systemTests:testscriptapp2Classes - Assembles testscriptapp2 classes. > > media:toolsClasses - Assembles tools classes. > > > > *Build Setup tasks* > > *-----------------* > > init - Initializes a new Gradle build. > > wrapper - Generates Gradle wrapper files. > > > > *Documentation tasks* > > *-------------------* > > base:javadoc - Generates Javadoc API documentation for the 'main' feature. > > closedTests:javadoc - Generates Javadoc API documentation for the 'main' > feature. > > controls:javadoc - Generates Javadoc API documentation for the 'main' > feature. > > fxml:javadoc - Generates Javadoc API documentation for the 'main' feature. > > graphics:javadoc - Generates Javadoc API documentation for the 'main' > feature. > > media:javadoc - Generates Javadoc API documentation for the 'main' > feature. > > swing:javadoc - Generates Javadoc API documentation for the 'main' > feature. > > swt:javadoc - Generates Javadoc API documentation for the 'main' feature. > > systemTests:javadoc - Generates Javadoc API documentation for the 'main' > feature. > > web:javadoc - Generates Javadoc API documentation for the 'main' feature. > > > > *Help tasks* > > *----------* > > buildEnvironment - Displays all buildscript dependencies declared in root > project 'rt'. > > apps:buildEnvironment - Displays all buildscript dependencies declared in > project ':apps'. > > base:buildEnvironment - Displays all buildscript dependencies declared in > project ':base'. > > closedTests:buildEnvironment - Displays all buildscript dependencies > declared in project ':closedTests'. > > controls:buildEnvironment - Displays all buildscript dependencies > declared in project ':controls'. > > fxml:buildEnvironment - Displays all buildscript dependencies declared in > project ':fxml'. > > graphics:buildEnvironment - Displays all buildscript dependencies > declared in project ':graphics'. > > media:buildEnvironment - Displays all buildscript dependencies declared > in project ':media'. > > swing:buildEnvironment - Displays all buildscript dependencies declared > in project ':swing'. > > swt:buildEnvironment - Displays all buildscript dependencies declared in > project ':swt'. > > systemTests:buildEnvironment - Displays all buildscript dependencies > declared in project ':systemTests'. > > web:buildEnvironment - Displays all buildscript dependencies declared in > project ':web'. > > dependencies - Displays all dependencies declared in root project 'rt'. > > apps:dependencies - Displays all dependencies declared in project ':apps'. > > base:dependencies - Displays all dependencies declared in project ':base'. > > closedTests:dependencies - Displays all dependencies declared in project > ':closedTests'. > > controls:dependencies - Displays all dependencies declared in project > ':controls'. > > fxml:dependencies - Displays all dependencies declared in project ':fxml'. > > graphics:dependencies - Displays all dependencies declared in project > ':graphics'. > > media:dependencies - Displays all dependencies declared in project > ':media'. > > swing:dependencies - Displays all dependencies declared in project > ':swing'. > > swt:dependencies - Displays all dependencies declared in project ':swt'. > > systemTests:dependencies - Displays all dependencies declared in project > ':systemTests'. > > web:dependencies - Displays all dependencies declared in project ':web'. > > dependencyInsight - Displays the insight into a specific dependency in > root project 'rt'. > > apps:dependencyInsight - Displays the insight into a specific dependency > in project ':apps'. > > base:dependencyInsight - Displays the insight into a specific dependency > in project ':base'. > > closedTests:dependencyInsight - Displays the insight into a specific > dependency in project ':closedTests'. > > controls:dependencyInsight - Displays the insight into a specific > dependency in project ':controls'. > > fxml:dependencyInsight - Displays the insight into a specific dependency > in project ':fxml'. > > graphics:dependencyInsight - Displays the insight into a specific > dependency in project ':graphics'. > > media:dependencyInsight - Displays the insight into a specific dependency > in project ':media'. > > swing:dependencyInsight - Displays the insight into a specific dependency > in project ':swing'. > > swt:dependencyInsight - Displays the insight into a specific dependency > in project ':swt'. > > systemTests:dependencyInsight - Displays the insight into a specific > dependency in project ':systemTests'. > > web:dependencyInsight - Displays the insight into a specific dependency > in project ':web'. > > help - Displays a help message. > > apps:help - Displays a help message. > > base:help - Displays a help message. > > closedTests:help - Displays a help message. > > controls:help - Displays a help message. > > fxml:help - Displays a help message. > > graphics:help - Displays a help message. > > media:help - Displays a help message. > > swing:help - Displays a help message. > > swt:help - Displays a help message. > > systemTests:help - Displays a help message. > > web:help - Displays a help message. > > javaToolchains - Displays the detected java toolchains. > > apps:javaToolchains - Displays the detected java toolchains. > > base:javaToolchains - Displays the detected java toolchains. > > closedTests:javaToolchains - Displays the detected java toolchains. > > controls:javaToolchains - Displays the detected java toolchains. > > fxml:javaToolchains - Displays the detected java toolchains. > > graphics:javaToolchains - Displays the detected java toolchains. > > media:javaToolchains - Displays the detected java toolchains. > > swing:javaToolchains - Displays the detected java toolchains. > > swt:javaToolchains - Displays the detected java toolchains. > > systemTests:javaToolchains - Displays the detected java toolchains. > > web:javaToolchains - Displays the detected java toolchains. > > outgoingVariants - Displays the outgoing variants of root project 'rt'. > > apps:outgoingVariants - Displays the outgoing variants of project ':apps'. > > base:outgoingVariants - Displays the outgoing variants of project ':base'. > > closedTests:outgoingVariants - Displays the outgoing variants of project > ':closedTests'. > > controls:outgoingVariants - Displays the outgoing variants of project > ':controls'. > > fxml:outgoingVariants - Displays the outgoing variants of project ':fxml'. > > graphics:outgoingVariants - Displays the outgoing variants of project > ':graphics'. > > media:outgoingVariants - Displays the outgoing variants of project > ':media'. > > swing:outgoingVariants - Displays the outgoing variants of project > ':swing'. > > swt:outgoingVariants - Displays the outgoing variants of project ':swt'. > > systemTests:outgoingVariants - Displays the outgoing variants of project > ':systemTests'. > > web:outgoingVariants - Displays the outgoing variants of project ':web'. > > projects - Displays the sub-projects of root project 'rt'. > > apps:projects - Displays the sub-projects of project ':apps'. > > base:projects - Displays the sub-projects of project ':base'. > > closedTests:projects - Displays the sub-projects of project > ':closedTests'. > > controls:projects - Displays the sub-projects of project ':controls'. > > fxml:projects - Displays the sub-projects of project ':fxml'. > > graphics:projects - Displays the sub-projects of project ':graphics'. > > media:projects - Displays the sub-projects of project ':media'. > > swing:projects - Displays the sub-projects of project ':swing'. > > swt:projects - Displays the sub-projects of project ':swt'. > > systemTests:projects - Displays the sub-projects of project > ':systemTests'. > > web:projects - Displays the sub-projects of project ':web'. > > properties - Displays the properties of root project 'rt'. > > apps:properties - Displays the properties of project ':apps'. > > base:properties - Displays the properties of project ':base'. > > closedTests:properties - Displays the properties of project > ':closedTests'. > > controls:properties - Displays the properties of project ':controls'. > > fxml:properties - Displays the properties of project ':fxml'. > > graphics:properties - Displays the properties of project ':graphics'. > > media:properties - Displays the properties of project ':media'. > > swing:properties - Displays the properties of project ':swing'. > > swt:properties - Displays the properties of project ':swt'. > > systemTests:properties - Displays the properties of project > ':systemTests'. > > web:properties - Displays the properties of project ':web'. > > resolvableConfigurations - Displays the configurations that can be > resolved in root project 'rt'. > > apps:resolvableConfigurations - Displays the configurations that can be > resolved in project ':apps'. > > base:resolvableConfigurations - Displays the configurations that can be > resolved in project ':base'. > > closedTests:resolvableConfigurations - Displays the configurations that > can be resolved in project ':closedTests'. > > controls:resolvableConfigurations - Displays the configurations that can > be resolved in project ':controls'. > > fxml:resolvableConfigurations - Displays the configurations that can be > resolved in project ':fxml'. > > graphics:resolvableConfigurations - Displays the configurations that can > be resolved in project ':graphics'. > > media:resolvableConfigurations - Displays the configurations that can be > resolved in project ':media'. > > swing:resolvableConfigurations - Displays the configurations that can be > resolved in project ':swing'. > > swt:resolvableConfigurations - Displays the configurations that can be > resolved in project ':swt'. > > systemTests:resolvableConfigurations - Displays the configurations that > can be resolved in project ':systemTests'. > > web:resolvableConfigurations - Displays the configurations that can be > resolved in project ':web'. > > tasks - Displays the tasks runnable from root project 'rt' (some of the > displayed tasks may belong to subprojects). > > apps:tasks - Displays the tasks runnable from project ':apps'. > > base:tasks - Displays the tasks runnable from project ':base'. > > closedTests:tasks - Displays the tasks runnable from project > ':closedTests'. > > controls:tasks - Displays the tasks runnable from project ':controls'. > > fxml:tasks - Displays the tasks runnable from project ':fxml'. > > graphics:tasks - Displays the tasks runnable from project ':graphics'. > > media:tasks - Displays the tasks runnable from project ':media'. > > swing:tasks - Displays the tasks runnable from project ':swing'. > > swt:tasks - Displays the tasks runnable from project ':swt'. > > systemTests:tasks - Displays the tasks runnable from project > ':systemTests'. > > web:tasks - Displays the tasks runnable from project ':web'. > > > > *Verification tasks* > > *------------------* > > base:check - Runs all checks. > > closedTests:check - Runs all checks. > > controls:check - Runs all checks. > > fxml:check - Runs all checks. > > graphics:check - Runs all checks. > > media:check - Runs all checks. > > swing:check - Runs all checks. > > swt:check - Runs all checks. > > systemTests:check - Runs all checks. > > web:check - Runs all checks. > > base:test - Runs the test suite. > > closedTests:test - Runs the test suite. > > controls:test - Runs the test suite. > > fxml:test - Runs the test suite. > > graphics:test - Runs the test suite. > > media:test - Runs the test suite. > > swing:test - Runs the test suite. > > swt:test - Runs the test suite. > > systemTests:test - Runs the test suite. > > web:test - Runs the test suite. > > > > *Other tasks* > > *-----------* > > all > > antUpdateCacheIfNeeded > > apps > > appsjar > > apps:appsJarMac > > media:buildMacGlib > > media:buildMacGStreamer > > media:buildMacNative > > media:buildMacPlugins > > buildModules > > media:buildNativeTargets > > checkCache > > chmodArtifactsSdkMac > > apps:cleanMac > > base:cleanOpenLegalStandaloneMac > > controls:cleanOpenLegalStandaloneMac > > fxml:cleanOpenLegalStandaloneMac > > graphics:cleanOpenLegalStandaloneMac > > media:cleanOpenLegalStandaloneMac > > swing:cleanOpenLegalStandaloneMac > > web:cleanOpenLegalStandaloneMac > > closedSystemTests > > graphics:compileDecoraCompilers - Compile the Decora JSL Compilers > > graphics:compileDecoraHLSLShaders - Compile Decora HLSL files into .obj > files > > graphics:compileDecoraNativeShadersMac - Compiles Decora SSE natives for > mac > > graphics:compileFullJava - Compile all of the graphics java classes - > main and shaders > > base:compileJava - Compiles main Java source. > > closedTests:compileJava - Compiles main Java source. > > controls:compileJava - Compiles main Java source. > > fxml:compileJava - Compiles main Java source. > > graphics:compileJava - Compiles main Java source. > > media:compileJava - Compiles main Java source. > > swing:compileJava - Compiles main Java source. > > swt:compileJava - Compiles main Java source. > > systemTests:compileJava - Compiles main Java source. > > web:compileJava - Compiles main Java source. > > web:compileJavaDOMBinding > > web:compileJavaDOMBindingMac > > graphics:compileJslcJava - Compiles jslc Java source. > > web:compileNativeMac > > graphics:compilePrismCompilers - Compile the Prism JSL Compilers > > graphics:compilePrismHLSLShaders - Compile Prism HLSL files into .obj > files > > graphics:compileShadersJava - Compiles shaders Java source. > > base:compileShimsJava - Compiles shims Java source. > > controls:compileShimsJava - Compiles shims Java source. > > fxml:compileShimsJava - Compiles shims Java source. > > graphics:compileShimsJava - Compiles shims Java source. > > swing:compileShimsJava - Compiles shims Java source. > > web:compileShimsJava - Compiles shims Java source. > > graphics:compileStubJava - Compiles stub Java source. > > systemTests:compileTestapp1Java - Compiles testapp1 Java source. > > systemTests:compileTestapp2Java - Compiles testapp2 Java source. > > systemTests:compileTestapp3Java - Compiles testapp3 Java source. > > systemTests:compileTestapp4Java - Compiles testapp4 Java source. > > systemTests:compileTestapp5Java - Compiles testapp5 Java source. > > systemTests:compileTestapp6Java - Compiles testapp6 Java source. > > systemTests:compileTestapp7Java - Compiles testapp7 Java source. > > base:compileTestJava - Compiles test Java source. > > closedTests:compileTestJava - Compiles test Java source. > > controls:compileTestJava - Compiles test Java source. > > fxml:compileTestJava - Compiles test Java source. > > graphics:compileTestJava - Compiles test Java source. > > media:compileTestJava - Compiles test Java source. > > swing:compileTestJava - Compiles test Java source. > > swt:compileTestJava - Compiles test Java source. > > systemTests:compileTestJava - Compiles test Java source. > > web:compileTestJava - Compiles test Java source. > > systemTests:compileTestscriptapp1Java - Compiles testscriptapp1 Java > source. > > systemTests:compileTestscriptapp2Java - Compiles testscriptapp2 Java > source. > > media:compileToolsJava - Compiles tools Java source. > > components - Displays the components produced by root project 'rt'. > [deprecated] > > apps:components - Displays the components produced by project ':apps'. > [deprecated] > > base:components - Displays the components produced by project ':base'. > [deprecated] > > closedTests:components - Displays the components produced by project > ':closedTests'. [deprecated] > > controls:components - Displays the components produced by project > ':controls'. [deprecated] > > fxml:components - Displays the components produced by project ':fxml'. > [deprecated] > > graphics:components - Displays the components produced by project > ':graphics'. [deprecated] > > media:components - Displays the components produced by project ':media'. > [deprecated] > > swing:components - Displays the components produced by project ':swing'. > [deprecated] > > swt:components - Displays the components produced by project ':swt'. > [deprecated] > > systemTests:components - Displays the components produced by project > ':systemTests'. [deprecated] > > web:components - Displays the components produced by project ':web'. > [deprecated] > > copyAppsArtifacts > > copyAppsArtifacts3DViewerMac > > copyAppsArtifactsEnsemble8Mac > > copyAppsArtifactsMac > > copyAppsArtifactsMandelbrotSetMac > > copyAppsArtifactsModenaMac > > copyAppsArtifactsProjectProperties3DViewerMac > > copyAppsArtifactsProjectPropertiesEnsemble8Mac > > copyAppsArtifactsProjectPropertiesMandelbrotSetMac > > copyAppsArtifactsProjectPropertiesModenaMac > > copyAppsArtifactsReadmeMac > > copyAppsArtifactsSources3DViewerMac > > copyAppsArtifactsSourcesEnsemble8Mac > > copyAppsArtifactsSourcesMandelbrotSetMac > > copyAppsArtifactsSourcesModenaMac > > copyArtifactsDocsMac > > copyArtifactsJmodsMac > > copyArtifactsSdkMac > > copyArtifactsToysCanvasTestMac > > copyArtifactsToysColorCubeMac > > copyArtifactsToysEarthCubeFX2Mac > > copyArtifactsToysEmbeddedSwingMac > > copyArtifactsToysFX8-3DAPIMac > > copyArtifactsToysGradientsMac > > copyArtifactsToysHelloMac > > copyArtifactsToysHelloWorldMac > > copyArtifactsToysMac > > copyArtifactsToysPickTest3DMac > > copyArtifactsToysRobotMac > > copyArtifactsToysVersionInfoMac > > copyArtifactsToysVideoCubeMac > > copyArtifactsToysZBufferTestMac > > base:copyBinFilesMac > > controls:copyBinFilesMac > > fxml:copyBinFilesMac > > graphics:copyBinFilesMac > > media:copyBinFilesMac > > swing:copyBinFilesMac > > web:copyBinFilesMac > > base:copyBuildPropertiesMac > > controls:copyBuildPropertiesMac > > fxml:copyBuildPropertiesMac > > graphics:copyBuildPropertiesMac > > media:copyBuildPropertiesMac > > swing:copyBuildPropertiesMac > > web:copyBuildPropertiesMac > > base:copyClassFilesMac > > controls:copyClassFilesMac > > fxml:copyClassFilesMac > > graphics:copyClassFilesMac > > media:copyClassFilesMac > > swing:copyClassFilesMac > > web:copyClassFilesMac > > base:copyClosedLegalStandaloneMac > > controls:copyClosedLegalStandaloneMac > > fxml:copyClosedLegalStandaloneMac > > graphics:copyClosedLegalStandaloneMac > > media:copyClosedLegalStandaloneMac > > swing:copyClosedLegalStandaloneMac > > web:copyClosedLegalStandaloneMac > > base:copyDocFilesMac > > controls:copyDocFilesMac > > fxml:copyDocFilesMac > > graphics:copyDocFilesMac > > media:copyDocFilesMac > > swing:copyDocFilesMac > > web:copyDocFilesMac > > web:copyDumpTreeNativeMac > > base:copyGeneratedShims > > controls:copyGeneratedShims > > fxml:copyGeneratedShims > > graphics:copyGeneratedShims > > swing:copyGeneratedShims > > web:copyGeneratedShims > > web:copyICUFile > > base:copyLegalMac > > controls:copyLegalMac > > fxml:copyLegalMac > > graphics:copyLegalMac > > media:copyLegalMac > > swing:copyLegalMac > > web:copyLegalMac > > base:copyLegalStandaloneMac > > controls:copyLegalStandaloneMac > > fxml:copyLegalStandaloneMac > > graphics:copyLegalStandaloneMac > > media:copyLegalStandaloneMac > > swing:copyLegalStandaloneMac > > web:copyLegalStandaloneMac > > base:copyLibFilesMac > > controls:copyLibFilesMac > > fxml:copyLibFilesMac > > graphics:copyLibFilesMac > > media:copyLibFilesMac > > swing:copyLibFilesMac > > web:copyLibFilesMac > > base:copyLibFilesStandaloneMac > > controls:copyLibFilesStandaloneMac > > fxml:copyLibFilesStandaloneMac > > graphics:copyLibFilesStandaloneMac > > media:copyLibFilesStandaloneMac > > swing:copyLibFilesStandaloneMac > > web:copyLibFilesStandaloneMac > > base:copyNativeFilesStandaloneMac > > controls:copyNativeFilesStandaloneMac > > fxml:copyNativeFilesStandaloneMac > > graphics:copyNativeFilesStandaloneMac > > media:copyNativeFilesStandaloneMac > > swing:copyNativeFilesStandaloneMac > > web:copyNativeFilesStandaloneMac > > web:copyNativeMac > > web:copyPreGeneratedWrappers > > controls:copyShimBss > > base:copySourceFilesMac > > controls:copySourceFilesMac > > fxml:copySourceFilesMac > > graphics:copySourceFilesMac > > media:copySourceFilesMac > > swing:copySourceFilesMac > > web:copySourceFilesMac > > systemTests:copyTestapp2 > > systemTests:copyTestapp3 > > systemTests:copyTestapp4 > > systemTests:copyTestapp5 > > systemTests:copyTestapp6 > > systemTests:copyTestapp7 > > systemTests:copyTestscriptapp1 > > systemTests:copyTestscriptapp2 > > copyToArtifactsBundledSDKMac > > copyToArtifactsDocsApiMac > > copyToArtifactsExportsMac > > copyToArtifactsStandaloneSDKMac > > copyToArtifactsTestMac > > copyToysToArtifactsMac > > systemTests:createTestapp1Jar1 > > systemTests:createTestapp1Jar2 > > systemTests:createTestApps > > createTestArgfiles > > createTestArgfilesMac > > dependentComponents - Displays the dependent components of components in > root project 'rt'. [deprecated] > > apps:dependentComponents - Displays the dependent components of > components in project ':apps'. [deprecated] > > base:dependentComponents - Displays the dependent components of > components in project ':base'. [deprecated] > > closedTests:dependentComponents - Displays the dependent components of > components in project ':closedTests'. [deprecated] > > controls:dependentComponents - Displays the dependent components of > components in project ':controls'. [deprecated] > > fxml:dependentComponents - Displays the dependent components of > components in project ':fxml'. [deprecated] > > graphics:dependentComponents - Displays the dependent components of > components in project ':graphics'. [deprecated] > > media:dependentComponents - Displays the dependent components of > components in project ':media'. [deprecated] > > swing:dependentComponents - Displays the dependent components of > components in project ':swing'. [deprecated] > > swt:dependentComponents - Displays the dependent components of components > in project ':swt'. [deprecated] > > systemTests:dependentComponents - Displays the dependent components of > components in project ':systemTests'. [deprecated] > > web:dependentComponents - Displays the dependent components of components > in project ':web'. [deprecated] > > downloadJdkDocs > > web:drtJar > > findbugs > > graphics:generateDecoraShaders - Generate Decora shaders from JSL > > graphics:generateGrammarSource > > media:generateMediaErrorHeader > > graphics:generatePrismShaders - Generate Prism shaders from JSL > > apps:getLucene > > graphics:initShaderDirs > > jdkZip > > jmods > > graphics:linkDecoraNativeShadersMac - Creates native dynamic library for > Decora SSE mac > > closedTests:manualTest > > mkdirArtifactsMac > > mkdirBundledSDKMac > > mkdirStandaloneSDKMac > > model - Displays the configuration model of root project 'rt'. > [deprecated] > > apps:model - Displays the configuration model of project ':apps'. > [deprecated] > > base:model - Displays the configuration model of project ':base'. > [deprecated] > > closedTests:model - Displays the configuration model of project > ':closedTests'. [deprecated] > > controls:model - Displays the configuration model of project ':controls'. > [deprecated] > > fxml:model - Displays the configuration model of project ':fxml'. > [deprecated] > > graphics:model - Displays the configuration model of project ':graphics'. > [deprecated] > > media:model - Displays the configuration model of project ':media'. > [deprecated] > > swing:model - Displays the configuration model of project ':swing'. > [deprecated] > > swt:model - Displays the configuration model of project ':swt'. > [deprecated] > > systemTests:model - Displays the configuration model of project > ':systemTests'. [deprecated] > > web:model - Displays the configuration model of project ':web'. > [deprecated] > > base:modularJarStandaloneMac > > controls:modularJarStandaloneMac > > fxml:modularJarStandaloneMac > > graphics:modularJarStandaloneMac > > media:modularJarStandaloneMac > > swing:modularJarStandaloneMac > > web:modularJarStandaloneMac > > base:modularPublicationJarMac > > controls:modularPublicationJarMac > > fxml:modularPublicationJarMac > > graphics:modularPublicationJarMac > > media:modularPublicationJarMac > > swing:modularPublicationJarMac > > web:modularPublicationJarMac > > base:moduleEmptyPublicationJarMac > > controls:moduleEmptyPublicationJarMac > > fxml:moduleEmptyPublicationJarMac > > graphics:moduleEmptyPublicationJarMac > > media:moduleEmptyPublicationJarMac > > swing:moduleEmptyPublicationJarMac > > web:moduleEmptyPublicationJarMac > > perf > > prepareKotlinBuildScriptModel > > prepOpenJfxStubs > > graphics:processDecoraShaders - Copy hlsl / frag shaders to > build/resources/jsl-decora > > graphics:processDecoraShimsShaders - Copy hlsl / frag shaders to shims > > graphics:processJslcResources - Processes jslc resources. > > graphics:processPrismShaders - Copy hlsl / frag shaders to > build/resources/jsl-prism > > graphics:processPrismShimsShaders - Copy hlsl / frag shaders to shims > > base:processResources - Processes main resources. > > closedTests:processResources - Processes main resources. > > controls:processResources - Processes main resources. > > fxml:processResources - Processes main resources. > > graphics:processResources - Processes main resources. > > media:processResources - Processes main resources. > > swing:processResources - Processes main resources. > > swt:processResources - Processes main resources. > > systemTests:processResources - Processes main resources. > > web:processResources - Processes main resources. > > graphics:processShaders > > graphics:processShadersResources - Processes shaders resources. > > base:processShimsResources - Processes shims resources. > > controls:processShimsResources - Processes shims resources. > > fxml:processShimsResources - Processes shims resources. > > graphics:processShimsResources - Processes shims resources. > > swing:processShimsResources - Processes shims resources. > > web:processShimsResources - Processes shims resources. > > graphics:processShimsShaders > > graphics:processStubResources - Processes stub resources. > > systemTests:processTestapp1Resources - Processes testapp1 resources. > > systemTests:processTestapp2Resources - Processes testapp2 resources. > > systemTests:processTestapp3Resources - Processes testapp3 resources. > > systemTests:processTestapp4Resources - Processes testapp4 resources. > > systemTests:processTestapp5Resources - Processes testapp5 resources. > > systemTests:processTestapp6Resources - Processes testapp6 resources. > > systemTests:processTestapp7Resources - Processes testapp7 resources. > > base:processTestResources - Processes test resources. > > closedTests:processTestResources - Processes test resources. > > controls:processTestResources - Processes test resources. > > fxml:processTestResources - Processes test resources. > > graphics:processTestResources - Processes test resources. > > media:processTestResources - Processes test resources. > > swing:processTestResources - Processes test resources. > > swt:processTestResources - Processes test resources. > > systemTests:processTestResources - Processes test resources. > > web:processTestResources - Processes test resources. > > systemTests:processTestscriptapp1Resources - Processes testscriptapp1 > resources. > > systemTests:processTestscriptapp2Resources - Processes testscriptapp2 > resources. > > media:processToolsResources - Processes tools resources. > > base:processVersionInfo - Replace params in VersionInfo and copy file to > destination > > publicExports > > sdk > > shims > > showFlags > > showFlagsMAC > > systemTests:systemTestSetup > > testAntImport > > web:testWebArchiveJar > > updateCacheIfNeeded > > base:validateSourceSets > > controls:validateSourceSets > > fxml:validateSourceSets > > graphics:validateSourceSets > > media:validateSourceSets > > swing:validateSourceSets > > swt:validateSourceSets > > systemTests:validateSourceSets > > web:validateSourceSets > > verifyJava > > zipDocsMac > > zipJmodsMac > > zips > > zipSdkMac > > zipSourceFilesStandaloneMac > > > > > > > > > > *From: *Nir Lisker > *Date: *Tuesday, June 18, 2024 at 17:30 > *To: *Thiago Milczarek Say?o > *Cc: *Andy Goryachev , openjfx-dev at openjdk.org > > *Subject: *[External] : Re: Eclipse and Gradle in OpenJFX > > It has been a while since I tried a clean import of jfx, but the > instructions in > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse > seem correct, unless something changed. What you describe is written there. > Only the initial import requires a gradle build, and after reverting the > project and classpath changes, you can work with ECJ (unless you need tasks > to build native code etc.) > > > > What is worth looking at is the 'eclipse' gradle task that tries to > generate these files according to the gradle files. However, the way the > project is built in gradle is both complicated and very old (compliant with > gradle 2 I think), so I don't know how well that will work. In my modern > projects, the 'eclipse' task works really well and allows me to not check > in the eclipse files: a gradle refresh/synch is run once (does all the > configuration and dependency management), and then running 'eclipse' once > sets up the eclipse side. > > > > On Tue, Jun 18, 2024 at 10:52?PM Thiago Milczarek Say?o < > thiago.sayao at gmail.com> wrote: > > Andy, > > > > We kind of did the opposite for Intellij (got rid of the .iml files and > went for gradle import): > > > > https://github.com/openjdk/jfx/pull/1009 > > > > > I couldn't get it to detect the manual tests tho. Changing some gradle > files worked, but would require a deeper review, so we went without it. > > > > -- Thiago. > > > > Em ter., 18 de jun. de 2024 ?s 16:05, Andy Goryachev < > andy.goryachev at oracle.com> escreveu: > > Dear developers: > > > > Does anyone use gradle in Eclipse (Buildship plug-in) with the OpenJFX > repo? > > > > The reason I am asking is that in my experience, the gradle nature in > OpenJFX is either misconfigured, or obsolete, or both. There is a rather > old wiki page [0] which describes the Eclipse setup, though I don't think > it is correct anymore. The initial import of the repository in Eclipse > triggers an internal gradle run which creates/modifies a bunch of > .classpath and .project files which must be undone before the workspace > becomes usable. In any case, only a proper command line gradle build is > supported anyway. > > > > I would like to propose removing the gradle nature from Eclipse's .project > files in OpenJFX. Once done, the projects can be trivially imported into a > new workspace with no extra steps required. This change has no impact on > command line build whatsoever. > > > > What do you think? > > > > Thank you > > -andy > > > > > > > > *References* > > > > [1] > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at openjdk.org Sun Jul 7 00:36:40 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Sun, 7 Jul 2024 00:36:40 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled Continuing the [mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2024-June/047467.html) discussion with more technical details. Gradle tries to configure Eclipse based on its build file. This includes things like source folders, compiler settings, dependencies and others. In the cases that I have tried in my projects, this works well. One problem that still remains with this configuration is that it's not aware of the locations of the modules. This causes missing module errors when launching, which require `-add-modules` to remedy. The [eclipse plugin](https://docs.gradle.org/current/userguide/eclipse_plugin.html) solves this by resolving the paths locally for your gradle cache. This tends to be the preferred way to do things from my experience since you don't need to push eclipse-specific files to the repo. The gradle files need to be there anyway, so it makes sense to configure eclipse from them and you maintain uniformity between the different development environments. Where this fails is with OpenJFX projects. The monolithic and old gradle file uses conventions from old gradle versions. This causes faulty generation of the eclipse files with and without the eclipse plugin. For example, all the source folders (`src/main/java`, `src/test/java`...) are prepended with the project/module name (`base/src/main/java`) because of manual source set configurations that shouldn't exist, at least not the way they are now. The problem presented in the issue has 2 solutions: 1. Opt out: Include the Gralde nature by default, do all the initial building, then revert the Eclipse files. If you want to disable the Gradle integration, you can do so as well be removing the nature within the IDE. 2. Opt in: Don't include the Gradle nature by default and do all the initial building. If you want the Gradle integration, you can add it within the IDE. Both of these are one-time actions. I'm fine with either since I find the one-time action to be cheap. By the way, with this change you will also have to update the [wiki page](https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse) to a state where the Java import is the standard and there's an opt-in for the Gradle integration. @hjohn Do you have any remarks? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2212068694 From tsayao at openjdk.org Sun Jul 7 18:00:37 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 7 Jul 2024 18:00:37 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v14] In-Reply-To: <33srjwey90heIukzArpnKZDRLl66pHE5rzR65p7SX38=.845d578e-01a7-4c14-b077-9078aaaa0dc1@github.com> References: <33srjwey90heIukzArpnKZDRLl66pHE5rzR65p7SX38=.845d578e-01a7-4c14-b077-9078aaaa0dc1@github.com> Message-ID: On Sun, 9 Jun 2024 13:12:44 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'refs/heads/master' into egl > - Merge branch 'refs/heads/master' into egl > - Merge branch 'refs/heads/master' into egl > - Use prismES2EGLX11 as build name > - Merge branch 'master' into egl > - Prefer EGL over GLX > - Merge branch 'master' into egl > - Merge branch 'master' into egl > > # Conflicts: > # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c > - Use EGL instead of GLX I will get back to this next week. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2212523607 From jhendrikx at openjdk.org Mon Jul 8 09:13:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 8 Jul 2024 09:13:38 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 00:34:01 GMT, Nir Lisker wrote: > Do you have any remarks? I personally don't launch build tools from the IDE (neither Gradle, nor Maven) but only use such tools to import projects; after the import I expect the IDE to be able to build and run tests without intervention of any build tool. I will use the build tooling (usually on the command line) only as a last resort if I can't get it to work that way (which is sometimes the case for a complicated project like JavaFX, especially when I need to run a non-headless test). Importing and working this way works for almost any project, but never has worked for me with JavaFX (which was a big barrier for me when I first tried contributing to FX -- I even tried switching IDE's, but it wasn't much better there either). What annoys me the most with the FX project is the inability to run certain tests directly from the IDE by right clicking and selecting `Run as... JUnit test`. I work around this by running the test once, then changing its configuration and adding a standard incantation to its command line (`-Djavafx.toolkit`, `-Djava.library.path`, some `--add-modules`) -- I can live with that, although it is less than ideal (right clicking and running a test would be nice to have working out of the box for JavaFX). I doubt however this change will make this any better or worse :) So, I'm fine with either solution here. As I don't use Gradle integration, I'd lean slightly to just removing it, or alternatively, fixing the problems in the gradle build so Buildship recognizes it properly. Since I suspect the latter is not an easy task, removing the Gradle nature seems like a good alternative. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2213464459 From arapte at openjdk.org Mon Jul 8 13:35:50 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 8 Jul 2024 13:35:50 GMT Subject: RFR: 8295945: Revert unintended change to copyright start year Message-ID: A quick fix to correct the created copyright year. The created year in the header was unintentionally modified previously from 2021 to 2017. ------------- Commit messages: - correct copyright year Changes: https://git.openjdk.org/jfx/pull/1496/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1496&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295945 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1496.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1496/head:pull/1496 PR: https://git.openjdk.org/jfx/pull/1496 From tsayao at openjdk.org Mon Jul 8 13:39:39 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 8 Jul 2024 13:39:39 GMT Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v14] In-Reply-To: <33srjwey90heIukzArpnKZDRLl66pHE5rzR65p7SX38=.845d578e-01a7-4c14-b077-9078aaaa0dc1@github.com> References: <33srjwey90heIukzArpnKZDRLl66pHE5rzR65p7SX38=.845d578e-01a7-4c14-b077-9078aaaa0dc1@github.com> Message-ID: On Sun, 9 Jun 2024 13:12:44 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'refs/heads/master' into egl > - Merge branch 'refs/heads/master' into egl > - Merge branch 'refs/heads/master' into egl > - Use prismES2EGLX11 as build name > - Merge branch 'master' into egl > - Prefer EGL over GLX > - Merge branch 'master' into egl > - Merge branch 'master' into egl > > # Conflicts: > # modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c > - Use EGL instead of GLX Would it be better to still default to GLX and have a flag to use EGL (and switch within a few releases), or to go with EGL and have a flag to fallback to GLX? Currently (on this PR) it defaults to EGL first, and if it fails, try GLX (I don't know a scenario where EGL won't work, on Xorg o XWayland). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2214100176 From arapte at openjdk.org Mon Jul 8 13:44:04 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 8 Jul 2024 13:44:04 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl Message-ID: The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). The PR adds the "offset < 0" check to both the methods. ------------- Commit messages: - add missing check Changes: https://git.openjdk.org/jfx/pull/1497/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331603 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1497.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1497/head:pull/1497 PR: https://git.openjdk.org/jfx/pull/1497 From kcr at openjdk.org Mon Jul 8 13:49:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 13:49:36 GMT Subject: RFR: 8295945: Revert unintended change to copyright start year In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 13:31:03 GMT, Ambarish Rapte wrote: > A quick fix to correct the created copyright year. > The created year in the header was unintentionally modified previously from 2021 to 2017. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1496#pullrequestreview-2163379488 From lkostyra at openjdk.org Mon Jul 8 14:28:48 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 8 Jul 2024 14:28:48 GMT Subject: RFR: 8335216: [windows] Missing error check for GetSystemDirectory in glass Message-ID: When GetSystemDirectory does not have enough space to output a path to Windows' system directory, it will return a different value than 0 (more notably, the amount of bytes actually needed including null terminator). This was not checked, so the very rare hypothetical situation where Windows' system directory is different than the "standard" `C:\Windows` and longer than MAX_PATH was not properly handled. For now I simply changed the code to print an error and exit. This could be improved further to instead dynamically allocate space for the system directory though. Other changes, also mentioned in the issue: - We use `wchar_t` explicitly here, so I changed `GetSystemDirectory` to `GetSystemDirectoryW` to ensure the code compiles even without UNICODE being defined - `wcscat_s` can potentially fail for the same reasons as above, so this situation is also handled now. ------------- Commit messages: - Improve Windows API use in RoActivationSupport Changes: https://git.openjdk.org/jfx/pull/1498/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1498&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335216 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1498.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1498/head:pull/1498 PR: https://git.openjdk.org/jfx/pull/1498 From lkostyra at openjdk.org Mon Jul 8 15:03:39 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 8 Jul 2024 15:03:39 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Fri, 5 Jul 2024 17:06:11 GMT, Andy Goryachev wrote: > if the changes do appear, what are they? @andy-goryachev-oracle I tried it again after clearing the workspace folder and they do appear again. I also had some old git index settings applied which hid most of .project changes. Turns out that basically all `.project` files are modified, but I don't know if we can really help that - even when you tell VSCode Java plugin to not populate the workspace with project files, it sees they exist in the repo and uses/modifies them anyway. I saw a few issues on GitHub regarding this with no real resolution. All of `.project`s have the same bit added (seems like something internal for the plugin): 1720448829339 30 org.eclipse.core.resources.regexFilterMatcher node_modules|.git|__CREATED_BY_JAVA_LANGUAGE_SERVER__ Regardless, the change does prevent the plugin from modifying `.classpath` files, which lets the project index and build properly. I don't expect to ever have to tinker with `.project` files for any reason, so it's good enough for me. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2214360311 From angorya at openjdk.org Mon Jul 8 15:57:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 15:57:37 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 13:39:49 GMT, Ambarish Rapte wrote: > The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). > The PR adds the "offset < 0" check to both the methods. modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 88: > 86: width < 0 || width > (surfaceWidth - x) || > 87: height < 0 || height > (surfaceHeight - y) || > 88: scanLength < width || offset < 0) { this might be a naive question: would it make more sense to fail earlier, i.e. to test the offset before getting the surface pointer? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1497#discussion_r1668900214 From kcr at openjdk.org Mon Jul 8 16:13:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 16:13:38 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 15:55:29 GMT, Andy Goryachev wrote: >> The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). >> The PR adds the "offset < 0" check to both the methods. > > modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 88: > >> 86: width < 0 || width > (surfaceWidth - x) || >> 87: height < 0 || height > (surfaceHeight - y) || >> 88: scanLength < width || offset < 0) { > > this might be a naive question: would it make more sense to fail earlier, i.e. to test the offset before getting the surface pointer? No, that would be a larger change and out of scope. More importantly, the order of the checks doesn't matter. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1497#discussion_r1668922585 From kcr at openjdk.org Mon Jul 8 16:19:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 16:19:39 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 13:39:49 GMT, Ambarish Rapte wrote: > The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). > The PR adds the "offset < 0" check to both the methods. I will review this. It's a simple enough change, but a second reviewer wouldn't be a bad idea. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1497#issuecomment-2214580042 From angorya at openjdk.org Mon Jul 8 17:38:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 17:38:37 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: <6j3L0e69usa2zHzni8fP0CFDlICWWiQcwveCT3Fz6BQ=.b48c1676-bc13-43c9-b695-70da0f22db71@github.com> On Mon, 8 Jul 2024 15:01:08 GMT, Lukasz Kostyra wrote: >> @lukostyra thank you for testing! there should be no changes made to the .project or any other files. could you reset your workspace and maybe try again? >> >> if the changes do appear, what are they? > >> if the changes do appear, what are they? > > @andy-goryachev-oracle I tried it again after clearing the workspace folder and they do appear again. > > I also had some old git index settings applied which hid most of .project changes. Turns out that basically all `.project` files are modified, but I don't know if we can really help that - even when you tell VSCode Java plugin to not populate the workspace with project files, it sees they exist in the repo and uses/modifies them anyway. I saw a few issues on GitHub regarding this with no real resolution. > > All of `.project`s have the same bit added (seems like something internal for the plugin): > > > > 1720448829339 > > 30 > > org.eclipse.core.resources.regexFilterMatcher > node_modules|.git|__CREATED_BY_JAVA_LANGUAGE_SERVER__ > > > > > > Regardless, the change does prevent the plugin from modifying `.classpath` files, which lets the project index and build properly. I don't expect to ever have to tinker with `.project` files for any reason, so it's good enough for me. Thank you @lukostyra for checking! > All of `.project`s have the same bit added (seems like something internal for the plugin): This change looks innocuous enough - at least it does not break the build. Why VSCode does it is a mystery, but I suppose that's a bug in VSCode plugin. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2214793261 From angorya at openjdk.org Mon Jul 8 17:42:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 17:42:40 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 09:08:19 GMT, John Hendrikx wrote: > What annoys me the most with the FX project is the inability to run certain tests directly from the IDE by right clicking and selecting `Run as... JUnit test`. Yep, same issue here, and same workaround. I wonder if it is possible to create a separate project(s) for tests that will have all the necessary dependencies added (as a separate issue). For example, headless tests require addition of these vm args: -Djava.library.path="../../../build/sdk/lib" -Djavafx.toolkit="test.com.sun.javafx.pgstub.StubToolkit" -ea while system tests are slightly different: --add-modules=javafx.base,javafx.graphics,javafx.controls,javafx.swing --add-opens javafx.controls/test.com.sun.javafx.scene.control.test=javafx.base --add-exports javafx.base/com.sun.javafx=ALL-UNNAMED -Djava.library.path="../../../../build/sdk/lib" ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2214798897 From angorya at openjdk.org Mon Jul 8 17:49:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 17:49:40 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Sun, 7 Jul 2024 00:34:01 GMT, Nir Lisker wrote: >> This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. >> >> Problem >> ======= >> Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. >> >> Solution >> ====== >> Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. >> >> Advantages >> ========= >> 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. >> 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. >> >> NOTES: >> - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) >> - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. >> - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled > > Continuing the [mailing list](https://mail.openjdk.org/pipermail/openjfx-dev/2024-June/047467.html) discussion with more technical details. > > Gradle tries to configure Eclipse based on its build file. This includes things like source folders, compiler settings, dependencies and others. In the cases that I have tried in my projects, this works well. One problem that still remains with this configuration is that it's not aware of the locations of the modules. This causes missing module errors when launching, which require `-add-modules` to remedy. The [eclipse plugin](https://docs.gradle.org/current/userguide/eclipse_plugin.html) solves this by resolving the paths locally for your gradle cache. > > This tends to be the preferred way to do things from my experience since you don't need to push eclipse-specific files to the repo. The gradle files need to be there anyway, so it makes sense to configure eclipse from them and you maintain uniformity between the different development environments. Where this fails is with OpenJFX projects. The monolithic and old gradle file uses conventions from old gradle versions. This causes faulty generation of the eclipse files with and without the eclipse plugin. For example, all the source folders (`src/main/java`, `src/test/java`...) are prepended with the project/module name (`base/src/main/java`) because of manual source set configurations that shouldn't exist, at least not the way they are now. > > The problem presented in the issue has 2 solutions: > 1. Opt out: Include the Gralde nature by default, do all the initial building, then revert the Eclipse files. If you want to disable the Gradle integration, you can do so as well be removing the nature within the IDE. > 2. Opt in: Don't include the Gradle nature by default and do all the initial building. If you want the Gradle integration, you can add it within the IDE. > Both of these are one-time actions. > > I'm fine with either since I find the one-time action to be cheap. > > By the way, with this change you will also have to update the [wiki page](https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse) to a state where the Java import is the standard and there's an opt-in for the Gradle integration. > > @hjohn Do you have any remarks? thank you @nlisker for your thoughts! > The [eclipse plugin](https://docs.gradle.org/current/userguide/eclipse_plugin.html) solves this by resolving the paths locally for your gradle cache. so this is a non-standard setup, meaning it is not described in the https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse wiki page. Still, I would like to propose we proceed with this change even if it is a temporary one (until the Buildship plug-in gets mature enough to be able to import the gradle configuration cleanly) because it prevents the said Buildship from messing up the project files and breaking the build every time the project(s) are imported or reopened. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2214817426 From kcr at openjdk.org Mon Jul 8 17:50:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 17:50:40 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 13:39:49 GMT, Ambarish Rapte wrote: > The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). > The PR adds the "offset < 0" check to both the methods. The fix looks good with one suggestion to expand it. Thank you for filing [JDK-8335879](https://bugs.openjdk.org/browse/JDK-8335879) as a further follow-up. I recommend to change `dstX` and `dstY` to `const` variables as part of this PR, since we rely on them being non-negative. The follow-on bug would then be to remove those variables entirely, if we decide it is even worth doing. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1497#issuecomment-2214817770 From angorya at openjdk.org Mon Jul 8 17:51:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 17:51:41 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: <1fSQo-ECSvBRB9NvP3QJwmhnNfsAfCbKnNZcjC0-5zg=.1a37aba0-7a47-434f-b43b-44d17ce6aadf@github.com> References: <1fSQo-ECSvBRB9NvP3QJwmhnNfsAfCbKnNZcjC0-5zg=.1a37aba0-7a47-434f-b43b-44d17ce6aadf@github.com> Message-ID: On Sat, 6 Jul 2024 11:12:48 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TooltipTest.java line 657: >> >>> 655: // Style: .tooltip { -fx-show-delay: 200ms; } >>> 656: stageLoader.getStage().getScene().getStylesheets() >>> 657: .add("data:base64,LnRvb2x0aXAgeyAtZngtc2hvdy1kZWxheTogMjAwbXM7IH0="); >> >> this is clever. can we generate the base64-encoded string on the fly? something along the lines >> >> >> return "data:text/css;base64," + Base64.getEncoder().encodeToString(b); >> >> >> (here and elsewhere?) > > Thought about this well, didn't test yet see for example https://github.com/openjdk/jfx/blob/72701e6cb4095b8f5042f54ae6bb2c0cec446bcf/modules/javafx.graphics/src/test/java/test/javafx/scene/Node_transition_Test.java#L142 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669046878 From angorya at openjdk.org Mon Jul 8 17:55:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 17:55:40 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: <_wEHyveJREGixQ84k3DgrH9f5UOph3sH7dpmg1LxMzs=.82d77cb4-5499-4c12-8268-a70fa6e5bce5@github.com> References: <_wEHyveJREGixQ84k3DgrH9f5UOph3sH7dpmg1LxMzs=.82d77cb4-5499-4c12-8268-a70fa6e5bce5@github.com> Message-ID: On Sat, 6 Jul 2024 11:18:07 GMT, Marius Hanl wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 81: >> >>> 79: >>> 80: @AfterAll >>> 81: static void exit() { >> >> I still not convinced I like the concept of non-public methods in tests, since they are annotated. >> >> Why do we need to do this? > > Please check: https://stackoverflow.com/questions/55215949/why-junit-5-default-access-modifier-changed-to-package-private > > It is essentially the good old 'why make something public when you do not need it?'. > It follows the way encapsulation is meant to be, by lowering the visibility as far as you can for something that is not meant to be called from the outside. > > Also static code analysis will check that and issue a code smell, which makes sense. Quoting Sonarlint here: > > " > JUnit5 is more tolerant regarding the visibility of test classes and methods than JUnit4, which required everything to be public. Test classes and methods can have any visibility except private. It is however recommended to use the default package visibility to improve readability. > > Test classes, test methods, and lifecycle methods are not required to be public, but they must not be private. > It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ? for example, when a test class is extended by a test class in another package. Another technical reason for making classes and methods public is to simplify testing on the module path when using the Java Module System. > ? JUnit5 User Guide > " thank you for clarification! there seems to be no downside to making the test methods non public, and some upside. we might suggest doing so for every new test we write, similarly to the requirement to use junit5 instead of junit4. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669051087 From kcr at openjdk.org Mon Jul 8 17:57:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 17:57:37 GMT Subject: RFR: 8335216: [windows] Missing error check for GetSystemDirectory in glass In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:24:27 GMT, Lukasz Kostyra wrote: > When GetSystemDirectory does not have enough space to output a path to Windows' system directory, it will return a different value than 0 (more notably, the amount of bytes actually needed including null terminator). This was not checked, so the very rare hypothetical situation where Windows' system directory is different than the "standard" `C:\Windows` and longer than MAX_PATH was not properly handled. > > For now I simply changed the code to print an error and exit. This could be improved further to instead dynamically allocate space for the system directory though. > > Other changes, also mentioned in the issue: > - We use `wchar_t` explicitly here, so I changed `GetSystemDirectory` to `GetSystemDirectoryW` to ensure the code compiles even without UNICODE being defined > - `wcscat_s` can potentially fail for the same reasons as above, so this situation is also handled now. I'll review this. @mstr2 Would you like to be the second reviewer? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1498#issuecomment-2214830534 From mstrauss at openjdk.org Mon Jul 8 18:08:37 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 8 Jul 2024 18:08:37 GMT Subject: RFR: 8335216: [windows] Missing error check for GetSystemDirectory in glass In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:24:27 GMT, Lukasz Kostyra wrote: > When GetSystemDirectory does not have enough space to output a path to Windows' system directory, it will return a different value than 0 (more notably, the amount of bytes actually needed including null terminator). This was not checked, so the very rare hypothetical situation where Windows' system directory is different than the "standard" `C:\Windows` and longer than MAX_PATH was not properly handled. > > For now I simply changed the code to print an error and exit. This could be improved further to instead dynamically allocate space for the system directory though. > > Other changes, also mentioned in the issue: > - We use `wchar_t` explicitly here, so I changed `GetSystemDirectory` to `GetSystemDirectoryW` to ensure the code compiles even without UNICODE being defined > - `wcscat_s` can potentially fail for the same reasons as above, so this situation is also handled now. I've checked the specification of `GetSystemDirectoryW` and `wcscat_s`. The patch will correctly catch failure cases. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1498#pullrequestreview-2164023380 From angorya at openjdk.org Mon Jul 8 18:26:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 18:26:41 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add many more unit tests for Tooltip LGTM. If you want to change to base64 encoding on the fly, I'll re-approve (this PR still needs a second reviewer). ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2164063322 From kcr at openjdk.org Mon Jul 8 20:30:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 20:30:37 GMT Subject: RFR: 8335216: [windows] Missing error check for GetSystemDirectory in glass In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:24:27 GMT, Lukasz Kostyra wrote: > When GetSystemDirectory does not have enough space to output a path to Windows' system directory, it will return a different value than 0 (more notably, the amount of bytes actually needed including null terminator). This was not checked, so the very rare hypothetical situation where Windows' system directory is different than the "standard" `C:\Windows` and longer than MAX_PATH was not properly handled. > > For now I simply changed the code to print an error and exit. This could be improved further to instead dynamically allocate space for the system directory though. > > Other changes, also mentioned in the issue: > - We use `wchar_t` explicitly here, so I changed `GetSystemDirectory` to `GetSystemDirectoryW` to ensure the code compiles even without UNICODE being defined > - `wcscat_s` can potentially fail for the same reasons as above, so this situation is also handled now. Looks good. I ran a quick sanity test as well. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1498#pullrequestreview-2164343864 From kcr at openjdk.org Mon Jul 8 21:20:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 21:20:40 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add many more unit tests for Tooltip The new system test isn't stable on Windows. I ran it several times, and most of the time I see one or two failures. Here are the results from a couple of the test runs: Test run 1: TooltipTest > testShowDelayCssShowTooltipTwice() FAILED org.opentest4j.AssertionFailedError: 193 <= 150 ==> expected: but was: TooltipTest > testSmallShowDelayCssTooltip() FAILED org.opentest4j.AssertionFailedError: 160 <= 150 ==> expected: but was: Test run 2: TooltipTest > testShowDelayCssShowTooltipTwice() FAILED org.opentest4j.AssertionFailedError: 165 <= 150 ==> expected: but was: TooltipTest > testChangeShowDelayTooltip() FAILED org.opentest4j.AssertionFailedError: 151 <= 150 ==> expected: but was: This is likely due to either inaccuracies in the timer itself or in measuring the elapsed time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2215341859 From angorya at openjdk.org Mon Jul 8 21:25:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 21:25:37 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 21:17:34 GMT, Kevin Rushforth wrote: > org.opentest4j.AssertionFailedError: 193 <= 150 ==> expected: but was: I don't see `testShowDelayCssShowTooltipTwice()` checking for the value of 150... Where did it come from? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2215358385 From kcr at openjdk.org Mon Jul 8 21:44:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 21:44:38 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add many more unit tests for Tooltip > > org.opentest4j.AssertionFailedError: 193 <= 150 ==> expected: but was: > > I don't see `testShowDelayCssShowTooltipTwice()` checking for the value of 150... Where did it come from? It's 100 (expected value) plus 50 (maximum delta). Here is the call stack: L72: assertTrue(tooltipShowTime <= maximumTime, tooltipShowTime + " <= " + maximumTime); L64: assertTooltipShowDelay(tooltipShowTime, expectedTime, 50); L209: assertTooltipShowDelay(tooltipShowTime, 100); ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2215398503 From kcr at openjdk.org Mon Jul 8 22:00:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 22:00:39 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add many more unit tests for Tooltip I left a few inline comments, including a possible suggestion to fix the intermittent test failures. tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 64: > 62: > 63: private static void assertTooltipShowDelay(long tooltipShowTime, long expectedTime) { > 64: assertTooltipShowDelay(tooltipShowTime, expectedTime, 50); If I change this to 100, then all tests pass most of the time. So maybe 150 or 200 would be a better maximum delta? If you do make this change, then you will need to find all of the three-arg calls with a maxDifference less than that and change them to the two-arg version. tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 109: > 107: long maximumTime = expectedTime + 100; > 108: > 109: assertTooltipShowDelay(tooltipShowTime, expectedTime, maximumTime); The third argument is a maximum difference, not a max time. So unless there is some reason to add the expected time twice, I would just use a larger constant delta.. You might even be able to get rid of the third arg depending on what we eventually go with for the default max delta. tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 122: > 120: assertTrue(tooltip.isShowing()); > 121: > 122: assertTooltipShowDelay(tooltipShowTime, 30, 100); This is an example of the three-arg call where you can eliminate the third arg if you make the default > 100. ------------- PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2164415777 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669372751 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669376935 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669378097 From kcr at openjdk.org Mon Jul 8 22:00:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 22:00:40 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: <_wEHyveJREGixQ84k3DgrH9f5UOph3sH7dpmg1LxMzs=.82d77cb4-5499-4c12-8268-a70fa6e5bce5@github.com> Message-ID: On Mon, 8 Jul 2024 17:53:21 GMT, Andy Goryachev wrote: >> Please check: https://stackoverflow.com/questions/55215949/why-junit-5-default-access-modifier-changed-to-package-private >> >> It is essentially the good old 'why make something public when you do not need it?'. >> It follows the way encapsulation is meant to be, by lowering the visibility as far as you can for something that is not meant to be called from the outside. >> >> Also static code analysis will check that and issue a code smell, which makes sense. Quoting Sonarlint here: >> >> " >> JUnit5 is more tolerant regarding the visibility of test classes and methods than JUnit4, which required everything to be public. Test classes and methods can have any visibility except private. It is however recommended to use the default package visibility to improve readability. >> >> Test classes, test methods, and lifecycle methods are not required to be public, but they must not be private. >> It is generally recommended to omit the public modifier for test classes, test methods, and lifecycle methods unless there is a technical reason for doing so ? for example, when a test class is extended by a test class in another package. Another technical reason for making classes and methods public is to simplify testing on the module path when using the Java Module System. >> ? JUnit5 User Guide >> " > > thank you for clarification! > > there seems to be no downside to making the test methods non public, and some upside. > we might suggest doing so for every new test we write, similarly to the requirement to use junit5 instead of junit4. This seems like a good suggestion to me. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669316152 From angorya at openjdk.org Mon Jul 8 22:27:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 22:27:39 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 21:49:42 GMT, Kevin Rushforth wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> add many more unit tests for Tooltip > > tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 64: > >> 62: >> 63: private static void assertTooltipShowDelay(long tooltipShowTime, long expectedTime) { >> 64: assertTooltipShowDelay(tooltipShowTime, expectedTime, 50); > > If I change this to 100, then all tests pass most of the time. So maybe 150 or 200 would be a better maximum delta? > > If you do make this change, then you will need to find all of the three-arg calls with a maxDifference less than that and change them to the two-arg version. even with max=200 we might see occasional failures due to load or other circumstances. I wonder a better approach would be to check whether the measurement of the delay falls sufficiently outside of the default 1000 ms (which in itself might be more than that)? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669397953 From kcr at openjdk.org Mon Jul 8 22:43:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 22:43:39 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:25:07 GMT, Andy Goryachev wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 64: >> >>> 62: >>> 63: private static void assertTooltipShowDelay(long tooltipShowTime, long expectedTime) { >>> 64: assertTooltipShowDelay(tooltipShowTime, expectedTime, 50); >> >> If I change this to 100, then all tests pass most of the time. So maybe 150 or 200 would be a better maximum delta? >> >> If you do make this change, then you will need to find all of the three-arg calls with a maxDifference less than that and change them to the two-arg version. > > even with max=200 we might see occasional failures due to load or other circumstances. > > I wonder a better approach would be to check whether the measurement of the delay falls sufficiently outside of the default 1000 ms (which in itself might be more than that)? We have many tests that will occasionally fail with a heavily loaded system. The question is whether we can come up with a max delta that we can reliably use that is less than the difference between the default value and the test value. Otherwise, we can't distinguish them. On two different test systems, both of which fail pretty consistently with 50 msec, I see a 100% pass rate over several tries with 150 msec. More testing is needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669410740 From angorya at openjdk.org Mon Jul 8 23:01:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 23:01:48 GMT Subject: RFR: 8335934: Change JavaFX release version to 24 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:51:47 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 24. I will integrate this to `master` as part of forking the `jfx23` stabilization branch, which is scheduled for Thursday, July 11, 2024 at 16:00 UTC. build/target versions are still 21? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1499#issuecomment-2215486547 From nlisker at openjdk.org Mon Jul 8 23:30:36 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 8 Jul 2024 23:30:36 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1491#pullrequestreview-2164597681 From nlisker at openjdk.org Mon Jul 8 23:30:37 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 8 Jul 2024 23:30:37 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 09:08:19 GMT, John Hendrikx wrote: > I work around this by running the test once, then changing its configuration and adding a standard incantation to its command line (`-Djavafx.toolkit`, `-Djava.library.path`, some `--add-modules`) The `--add-modules` could be taken care of by the eclipse plugin. The other 2 are javafx specific. > fixing the problems in the gradle build so Buildship recognizes it properly. Since I suspect the latter is not an easy task, removing the Gradle nature seems like a good alternative. Yes, https://github.com/openjdk/jfx/pull/1232 should be part of the effort to simplify the gradle build file. It will take several iterations on that file to modernize OpenJFX's build. > so this is a non-standard setup, meaning it is not described in the https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse wiki page. Yes, it's not described in the wiki because it can't read the gradle file properly to begin with. > Still, I would like to propose we proceed with this change even if it is a temporary one (until the Buildship plug-in gets mature enough to be able to import the gradle configuration cleanly) because it prevents the said Buildship from messing up the project files and breaking the build every time the project(s) are imported or reopened. I'm fine with this. Just noting that we're not waiting on Buildship to catch up, we need our `build.gradle` to catch up :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2215516698 From angorya at openjdk.org Mon Jul 8 22:55:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 8 Jul 2024 22:55:39 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:40:42 GMT, Kevin Rushforth wrote: >> even with max=200 we might see occasional failures due to load or other circumstances. >> >> I wonder a better approach would be to check whether the measurement of the delay falls sufficiently outside of the default 1000 ms (which in itself might be more than that)? > > We have many tests that will occasionally fail with a heavily loaded system. > > The question is whether we can come up with a max delta that we can reliably use that is less than the difference between the default value and the test value. Otherwise, we can't distinguish them. > > On two different test systems, both of which fail pretty consistently with 50 msec, I see a 100% pass rate over several tries with 150 msec. More testing is needed. Another possibility is the code that measures the time it takes to show the tooltip. The current code uses Util.waitForLatch(), L244 which was written for a different use case and actually introduces a small measurement error as it includes the time needed for the context switch. Perhaps a better solution would be to note the timestamp in L271 where the tooltip listener gets called (similar to the way the start moment is captured in L241) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1669418098 From kcr at openjdk.org Mon Jul 8 23:01:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 23:01:48 GMT Subject: RFR: 8335934: Change JavaFX release version to 24 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:57:03 GMT, Andy Goryachev wrote: > build/target versions are still 21? Not at all relevant to this PR, but yes they are. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1499#issuecomment-2215489243 From kcr at openjdk.org Mon Jul 8 23:01:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 23:01:48 GMT Subject: RFR: 8335934: Change JavaFX release version to 24 Message-ID: Bump the version number of JavaFX to 24. I will integrate this to `master` as part of forking the `jfx23` stabilization branch, which is scheduled for Thursday, July 11, 2024 at 16:00 UTC. ------------- Commit messages: - 8335934: Change JavaFX release version to 24 Changes: https://git.openjdk.org/jfx/pull/1499/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1499&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335934 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1499.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1499/head:pull/1499 PR: https://git.openjdk.org/jfx/pull/1499 From kcr at openjdk.org Mon Jul 8 23:01:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 8 Jul 2024 23:01:48 GMT Subject: RFR: 8335934: Change JavaFX release version to 24 In-Reply-To: References: Message-ID: <8Qm__nosCYdH2f-YCtm_xO96pOIBeE9zDoaA0-layzQ=.3075ccc6-425b-4169-a83c-edc54252c174@github.com> On Mon, 8 Jul 2024 22:51:47 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 24. I will integrate this to `master` as part of forking the `jfx23` stabilization branch, which is scheduled for Thursday, July 11, 2024 at 16:00 UTC. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1499#issuecomment-2215484632 From john.hendrikx at gmail.com Tue Jul 9 00:07:20 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 02:07:20 +0200 Subject: CSS Lookups and their origins (possible regression) Message-ID: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> Hi List, TLDR; should a CSS reference like -fx-base convert all styles that use this value (or derive from it) become AUTHOR level styles (higher priority than setters) ? Long version: In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value could be reset on an unrelated control. This happened when the CSS engine encountered a stylable that is overridden by the user (with a setter), and decided NOT to proceed with the full CSS value calculation (as it could not override the user setting if that CSS value had lower priority).? However, not proceeding with the calculation meant that a "SKIP" was stored in a shared cache which was incorrect.? This is because when this "SKIP" is later encountered for an unrelated control (the cache entries are shared for controls with the same styles at the same level), they could get their values reset because they were assumed to be unstyled. However, this fix has exposed what seems to be a deeper bug or perhaps an unfortunate default: JavaFX has a special feature where you can refer to certain other styles by using a reference (which is resolved, recursively, to a final value).? This does not seem to be a CSS standard, but is a feature only FX has. It works by saying something like: ??? -fx-base: RED; And then using it like this: ??? -fx-text-fill: -fx-base; This feature works accross stylesheets of different origins, so an AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT refers to -fx-base, the value comes from the AUTHOR stylesheet. JavaFX then changes the origin of the style to the highest priority encountered while resolving the reference.? This means that Modena can specify "-fx-text-fill: -fx-base", and when "-fx-base" is then part of the AUTHOR style sheet, that ALL Modena styles that use -fx-base will be considered AUTHOR level styles, as per this comment: // The origin of this parsed value is the greatest of // any of the resolved reference. If a resolved reference // comes from an inline style, for example, then the value // calculated from the resolved lookup should have inline // as its origin. Otherwise, an inline style could be // stored in shared cache. I feel that this is a really unfortunate choice.? The style after all was specified by Modena, only its value came from another (higher priority) style sheet.? I think a more logical choice would have been to not change the priority at all, unless a "-fx-text-fill" is explicitly made part of the AUTHOR stylesheet. A consequence of this (and which is much more visible after the fix) is that creating a Label with a setTextFill(Color.YELLOW) in its constructor will only result in a yellow text fill if the AUTHOR stylesheet did not override any of the Modena colors involved in calculating the Modena -fx-text-fill default. Overriding -fx-base in any way will result in the text fill of the label to be overridden (as the reference came from an AUTHOR stylesheet, which trumps a setter which is of a lower style origin). The comment also alludes to a potential problem.? If an inline style would specify "-fx-base", but would be treated as if it came from Modena (USER_AGENT level), then this value could get stored in the cache as everything except INLINE styles can be cached. However, I feel that the changing of style origin level was then probably done to solve a CACHING problem, instead of what made logical sense for users.? If we agree that a resolved reference should not change the style origin level, then this would need to be addressed, by perhaps marking such a calculated value as uncacheable, instead of overloading the meaning of style origin. I'd like to hear your thoughts, and also how to proceed.? JavaFX versions before 21 seemingly allowed overriding reference without much consequence because if the user overrode the value manually, the cache entry would be set to "SKIP".? Now that this is no longer the case, JavaFX more aggressively overrides user set values if they happen to use a referenced value.? See code below. --John .root { -fx-base: #ff0000; } packageapp; importjavafx.application.Application; importjavafx.scene.Scene; importjavafx.scene.control.Label; importjavafx.scene.paint.Color; importjavafx.stage.Stage; publicclassTestApp extendsApplication { publicstaticvoidmain(String[] args) { launch(args); } @Override publicvoidstart(Stage primaryStage) { Scene scene = newScene(newMyLabel()); // See the difference with/without -fx-base in the stylesheet scene.getStylesheets().add(TestApp.class.getResource("/style.css").toExternalForm()); primaryStage.setScene(scene); primaryStage.show(); } } classMyLabel extendsLabel { publicMyLabel() { setTextFill(Color.YELLOW); setText("Hello world"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Jul 9 00:11:18 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 02:11:18 +0200 Subject: CSS Lookups and their origins (possible regression) In-Reply-To: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> Message-ID: <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> I realized I worded the TLDR poorly. Let me try again: TLDR; should styles which use references (like -fx-base used in Modena) become AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet?? The act of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR level, as if you specified them directly... --John On 09/07/2024 02:07, John Hendrikx wrote: > > Hi List, > > TLDR; should a CSS reference like -fx-base convert all styles that use > this value (or derive from it) become AUTHOR level styles (higher > priority than setters) ? > > Long version: > > In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS > value could be reset on an unrelated control. > > This happened when the CSS engine encountered a stylable that is > overridden by the user (with a setter), and decided NOT to proceed > with the full CSS value calculation (as it could not override the user > setting if that CSS value had lower priority).? However, not > proceeding with the calculation meant that a "SKIP" was stored in a > shared cache which was incorrect. This is because when this "SKIP" is > later encountered for an unrelated control (the cache entries are > shared for controls with the same styles at the same level), they > could get their values reset because they were assumed to be unstyled. > > However, this fix has exposed what seems to be a deeper bug or perhaps > an unfortunate default: > > JavaFX has a special feature where you can refer to certain other > styles by using a reference (which is resolved, recursively, to a > final value).? This does not seem to be a CSS standard, but is a > feature only FX has. > > It works by saying something like: > > ??? -fx-base: RED; > > And then using it like this: > > ??? -fx-text-fill: -fx-base; > > This feature works accross stylesheets of different origins, so an > AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT refers > to -fx-base, the value comes from the AUTHOR stylesheet. > > JavaFX then changes the origin of the style to the highest priority > encountered while resolving the reference.? This means that Modena can > specify "-fx-text-fill: -fx-base", and when "-fx-base" is then part of > the AUTHOR style sheet, that ALL Modena styles that use -fx-base will > be considered AUTHOR level styles, as per this comment: > > // The origin of this parsed value is the greatest of > > // any of the resolved reference. If a resolved reference > > // comes from an inline style, for example, then the value > > // calculated from the resolved lookup should have inline > > // as its origin. Otherwise, an inline style could be > > // stored in shared cache. > > I feel that this is a really unfortunate choice.? The style after all > was specified by Modena, only its value came from another (higher > priority) style sheet.? I think a more logical choice would have been > to not change the priority at all, unless a "-fx-text-fill" is > explicitly made part of the AUTHOR stylesheet. > > A consequence of this (and which is much more visible after the fix) > is that creating a Label with a setTextFill(Color.YELLOW) in its > constructor will only result in a yellow text fill if the AUTHOR > stylesheet did not override any of the Modena colors involved in > calculating the Modena -fx-text-fill default. Overriding -fx-base in > any way will result in the text fill of the label to be overridden (as > the reference came from an AUTHOR stylesheet, which trumps a setter > which is of a lower style origin). > > The comment also alludes to a potential problem.? If an inline style > would specify "-fx-base", but would be treated as if it came from > Modena (USER_AGENT level), then this value could get stored in the > cache as everything except INLINE styles can be cached.? However, I > feel that the changing of style origin level was then probably done to > solve a CACHING problem, instead of what made logical sense for > users.? If we agree that a resolved reference should not change the > style origin level, then this would need to be addressed, by perhaps > marking such a calculated value as uncacheable, instead of overloading > the meaning of style origin. > > I'd like to hear your thoughts, and also how to proceed. JavaFX > versions before 21 seemingly allowed overriding reference without much > consequence because if the user overrode the value manually, the cache > entry would be set to "SKIP".? Now that this is no longer the case, > JavaFX more aggressively overrides user set values if they happen to > use a referenced value.? See code below. > > --John > > .root { > > -fx-base: #ff0000; > > } > > packageapp; > > importjavafx.application.Application; > > importjavafx.scene.Scene; > > importjavafx.scene.control.Label; > > importjavafx.scene.paint.Color; > > importjavafx.stage.Stage; > > publicclassTestApp extendsApplication { > > publicstaticvoidmain(String[] args) { > > launch(args); > > } > > @Override > > publicvoidstart(Stage primaryStage) { > > Scene scene = newScene(newMyLabel()); > > // See the difference with/without -fx-base in the stylesheet > > scene.getStylesheets().add(TestApp.class.getResource("/style.css").toExternalForm()); > > primaryStage.setScene(scene); > > primaryStage.show(); > > } > > } > > classMyLabel extendsLabel { > > publicMyLabel() { > > setTextFill(Color.YELLOW); > > setText("Hello world"); > > } > > } > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Tue Jul 9 06:47:38 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 9 Jul 2024 06:47:38 GMT Subject: Integrated: 8335216: [windows] Missing error check for GetSystemDirectory in glass In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 14:24:27 GMT, Lukasz Kostyra wrote: > When GetSystemDirectory does not have enough space to output a path to Windows' system directory, it will return a different value than 0 (more notably, the amount of bytes actually needed including null terminator). This was not checked, so the very rare hypothetical situation where Windows' system directory is different than the "standard" `C:\Windows` and longer than MAX_PATH was not properly handled. > > For now I simply changed the code to print an error and exit. This could be improved further to instead dynamically allocate space for the system directory though. > > Other changes, also mentioned in the issue: > - We use `wchar_t` explicitly here, so I changed `GetSystemDirectory` to `GetSystemDirectoryW` to ensure the code compiles even without UNICODE being defined > - `wcscat_s` can potentially fail for the same reasons as above, so this situation is also handled now. This pull request has now been integrated. Changeset: 56e07dbc Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/56e07dbc9b04af06fc8cd1970595d19cb77fea4a Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod 8335216: [windows] Missing error check for GetSystemDirectory in glass Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1498 From jvos at openjdk.org Tue Jul 9 06:49:08 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 06:49:08 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v19] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into 8319779-systemmenu - process more reviewer comments - Process reviewer comments - Merge branch 'master' into 8319779-systemmenu - Add more type info - Add type info Fix issue where notifications are missed when a new property is used. - Merge branch 'master' into 8319779-systemmenu - Remove whiteline and language error - Ignore test in case the underlying GlassSystemMenu is not supported. - Update modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassSystemMenu.java Co-authored-by: John Hendrikx - ... and 11 more: https://git.openjdk.org/jfx/compare/56e07dbc...55dc803f ------------- Changes: https://git.openjdk.org/jfx/pull/1283/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=18 Stats: 663 lines in 5 files changed: 462 ins; 192 del; 9 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From michaelstrau2 at gmail.com Tue Jul 9 06:55:44 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 9 Jul 2024 08:55:44 +0200 Subject: CSS Lookups and their origins (possible regression) In-Reply-To: <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> Message-ID: If I understand the scenario correctly, then the current behavior seems to be incorrect if we assume that CSS references in JavaFX are semantically equivalent to custom properties as defined by the CSS Custom Properties specification [0]. The specification states: "Custom properties are ordinary properties, so they can be declared on any element, are resolved with the normal inheritance and cascade rules [...]" If you redeclare Modena's "-fx-base" property in an author stylesheet, then the new declaration will be more specific than the original declaration. This means that all of Modena's styles that are referencing "-fx-base" should now reference the more specific version of that property. However, this shouldn't change the cascading behavior of Modena's styles themselves. In other words: simply referencing a custom property shouldn't transitively make the referencing property more specific. [0] https://www.w3.org/TR/css-variables-1/#defining-variables On Tue, Jul 9, 2024 at 2:11?AM John Hendrikx wrote: > > I realized I worded the TLDR poorly. > > Let me try again: > > TLDR; should styles which use references (like -fx-base used in Modena) become AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR level, as if you specified them directly... > > --John From jvos at openjdk.org Tue Jul 9 07:15:11 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 07:15:11 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v20] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with three additional commits since the last revision: - Add changes back to the test in the new location - Use git mv to move file from old to new location - Revert remove/add of test file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/55dc803f..8e30b998 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=19 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=18-19 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From arapte at openjdk.org Tue Jul 9 07:23:09 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Jul 2024 07:23:09 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl [v2] In-Reply-To: References: Message-ID: > The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). > The PR adds the "offset < 0" check to both the methods. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: const vars ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1497/files - new: https://git.openjdk.org/jfx/pull/1497/files/7424f752..3e4a8987 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1497&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1497&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1497.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1497/head:pull/1497 PR: https://git.openjdk.org/jfx/pull/1497 From arapte at openjdk.org Tue Jul 9 07:50:40 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Jul 2024 07:50:40 GMT Subject: RFR: 8335934: Change JavaFX release version to 24 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:51:47 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 24. I will integrate this to `master` as part of forking the `jfx23` stabilization branch, which is scheduled for Thursday, July 11, 2024 at 16:00 UTC. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1499#pullrequestreview-2165358897 From jvos at openjdk.org Tue Jul 9 09:06:58 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 09:06:58 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v21] In-Reply-To: References: Message-ID: > A listener was added but never removed. > This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 Johan Vos has updated the pull request incrementally with one additional commit since the last revision: Allow scheduled runnables to be executed on the FX App Thread before checking for exceptions. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1283/files - new: https://git.openjdk.org/jfx/pull/1283/files/8e30b998..39bf43da Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=20 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1283&range=19-20 Stats: 10 lines in 1 file changed: 3 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1283.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1283/head:pull/1283 PR: https://git.openjdk.org/jfx/pull/1283 From jvos at openjdk.org Tue Jul 9 09:15:43 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 09:15:43 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 12:39:11 GMT, Ambarish Rapte wrote: >> Johan Vos has updated the pull request incrementally with two additional commits since the last revision: >> >> - process more reviewer comments >> - Process reviewer comments > > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 1: > >> 1: /* > > This test file is moved from a different location, could do `git mv` instead removing and adding. I manually reverted the add/remove part, and replaced it with `git mv`. I assume/hope that by squashing the commits, the add/remove will not be part of the change. > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > > This file is moved, so the copyright should reflect same. Should be : `2023, 2024` right, done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670094429 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670091229 From jvos at openjdk.org Tue Jul 9 09:15:45 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 09:15:45 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: On Thu, 13 Jun 2024 07:17:01 GMT, John Hendrikx wrote: >> Johan Vos has updated the pull request incrementally with one additional commit since the last revision: >> >> Add more type info > > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 287: > >> 285: >> 286: @Test >> 287: public void testJDK8309935() { > > minor: Not sure what our policies are, but I find test names like this pretty useless, perhaps a short indication what this is doing? It is a good question. We don't have a consistent approach yet. I personally like the link to the JBS issue as that has (or should have) all info. I added a short indication, but the real info should be on the issue, imho. (this is something we should discuss on the mailing list) > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 346: > >> 344: }); >> 345: Util.runAndWait(() -> { >> 346: }); > > I checked the code that `runAndWait` would do when you pass in 0 runnables, and it basically does no waiting at all (less than a microsecond for sure). If this is really essential (I removed it and the test still passed) then I think a `sleep` might be better. The Util.runAndWait was indeed not a good idea. The problem is not that the test might not pass, the problem is that the test might not fail if we don't wait for things that need to run to complete. But this is better done with a Platform.runLater() which will add a runnable to the queue, so when that is executed, we know that all previously scheduled runnables completed. I changed the approach ehre. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670088321 PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670090848 From jvos at openjdk.org Tue Jul 9 09:20:40 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 09:20:40 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 14:25:52 GMT, Ambarish Rapte wrote: >> Johan Vos has updated the pull request incrementally with two additional commits since the last revision: >> >> - process more reviewer comments >> - Process reviewer comments > > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 321: > >> 319: Stage stage = new Stage(); >> 320: stage.setScene(new Scene(root)); >> 321: stage.show(); > > I think, a CountDownLatch should be added to make sure that stage is shown before proceeding. I don't completely understand this. The stage.show() is a blocking call, and the runnable that it might schedule will be executed before other runnables (part of the processing in the rest of the method) are scheduled. I added a CountDownLatch at the end of the processing, so that we allow for the processing to run into exceptions before we finalize the test. Does that make sense? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670106371 From jvos at openjdk.org Tue Jul 9 09:25:36 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 9 Jul 2024 09:25:36 GMT Subject: RFR: 8335934: Change JavaFX release version to 24 In-Reply-To: References: Message-ID: <6yt5EPbYXNA9DcjMwrioi6V1KRuwfr8a2BFwxwsFI8s=.c0b69318-395f-4f58-8424-fbb26e0e39f5@github.com> On Mon, 8 Jul 2024 22:51:47 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 24. I will integrate this to `master` as part of forking the `jfx23` stabilization branch, which is scheduled for Thursday, July 11, 2024 at 16:00 UTC. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1499#pullrequestreview-2165650586 From johan.vos at gluonhq.com Tue Jul 9 09:33:10 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 9 Jul 2024 11:33:10 +0200 Subject: consistent naming for tests Message-ID: Hi, An interesting question from John Hendrikx ( https://github.com/openjdk/jfx/pull/1283/#discussion_r1637684395) probably needs some general discussion on this list. Afaik, we don't have guidelines for how to name tests (in https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#coding-style-and-testing-guidelines ) In the different test files we have, I see different patterns: * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) * in some cases, tests have a concise but somehow meaningful name (e.g. `testScrollBarStaysVisible`) * in some cases, tests refer to JBS issues (e.g. testJDK8309935) * in some cases, the test is explained in comments. I think it would be good to have some consistency going forward. (I'm not advocating we need to rename existing tests!) I don't have a strong preference myself, but I think the link to the JBS issue that triggered the creation of a specific test is always good to have. I am also very ok with comments, but I learned not everyone likes that. Thoughts? - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lkostyra at openjdk.org Tue Jul 9 11:16:41 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 9 Jul 2024 11:16:41 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v6] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 08:06:39 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: >> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8322619: Remove waiting for the QuantumRenderer Changes look good. Run all tests on all platforms I have available for me (Win 11, macOS 14.5, Ubuntu 22.04) and noticed no regressions or issues. Ensemble also works fine. ------------- Marked as reviewed by lkostyra (Committer). PR Review: https://git.openjdk.org/jfx/pull/1451#pullrequestreview-2166014426 From duke at openjdk.org Tue Jul 9 11:32:42 2024 From: duke at openjdk.org (duke) Date: Tue, 9 Jul 2024 11:32:42 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v6] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 08:06:39 GMT, eduardsdv wrote: >> This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. >> >> This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. >> Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. >> >> Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. >> This guarantees: >> 1. that all dirty flags are removed after rendering, and >> 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. >> Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. >> >> The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. >> >> The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: >> ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8322619: Remove waiting for the QuantumRenderer @eduardsdv Your change (at version a7646e8ed072e51e1fd912ffa1f7087024f3557a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1451#issuecomment-2217405349 From jhendrikx at openjdk.org Tue Jul 9 11:38:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 11:38:40 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v21] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 09:06:58 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Allow scheduled runnables to be executed on the FX App Thread before checking for exceptions. LGTM, note that I couldn't test this as I don't have access to a Mac, but I didn't see a problem on Windows with these changes. ------------- Marked as reviewed by jhendrikx (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-2166059441 From jhendrikx at openjdk.org Tue Jul 9 11:38:41 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 11:38:41 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v16] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 09:09:30 GMT, Johan Vos wrote: >> tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 287: >> >>> 285: >>> 286: @Test >>> 287: public void testJDK8309935() { >> >> minor: Not sure what our policies are, but I find test names like this pretty useless, perhaps a short indication what this is doing? > > It is a good question. We don't have a consistent approach yet. I personally like the link to the JBS issue as that has (or should have) all info. I added a short indication, but the real info should be on the issue, imho. > (this is something we should discuss on the mailing list) I see that you added a comment now, that helps a lot, thanks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670352389 From kcr at openjdk.org Tue Jul 9 11:40:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 11:40:37 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:53:24 GMT, Andy Goryachev wrote: >> We have many tests that will occasionally fail with a heavily loaded system. >> >> The question is whether we can come up with a max delta that we can reliably use that is less than the difference between the default value and the test value. Otherwise, we can't distinguish them. >> >> On two different test systems, both of which fail pretty consistently with 50 msec, I see a 100% pass rate over several tries with 150 msec. More testing is needed. > > Another possibility is the code that measures the time it takes to show the tooltip. > > The current code uses Util.waitForLatch(), L244 which was written for a different use case and actually introduces a small measurement error as it includes the time needed for the context switch. Perhaps a better solution would be to note the timestamp in L271 where the tooltip listener gets called (similar to the way the start moment is captured in L241) Good catch. Capturing the current time in the listener will be more accurate than doing it after the latch wait. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1670360729 From kcr at openjdk.org Tue Jul 9 11:43:36 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 11:43:36 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 07:23:09 GMT, Ambarish Rapte wrote: >> The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). >> The PR adds the "offset < 0" check to both the methods. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > const vars Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1497#pullrequestreview-2166070380 From john.hendrikx at gmail.com Tue Jul 9 11:52:35 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 13:52:35 +0200 Subject: consistent naming for tests In-Reply-To: References: Message-ID: On 09/07/2024 11:33, Johan Vos wrote: > Hi, > > An interesting question from John Hendrikx > (https://github.com/openjdk/jfx/pull/1283/#discussion_r1637684395) > probably needs some general discussion on this list. > Afaik, we don't have guidelines for how to name tests (in > https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#coding-style-and-testing-guidelines) > > In the different test files we have, I see different patterns: > * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) > * in some cases, tests have a concise but somehow meaningful?name > (e.g. `testScrollBarStaysVisible`) > * in some cases, tests refer to JBS issues (e.g. testJDK8309935) > * in some cases, the test is explained in comments. > > I think it would be good to have some consistency going forward. (I'm > not advocating we need to rename existing tests!) > I don't have a strong preference myself, but I think the link to the > JBS issue that triggered the creation of a specific test is always > good to have. I am also very ok with comments, but I learned not > everyone likes that. Hi Johan, I didn't like the test name primarily because it has an indirection in it -- to know what it is supposed to do, I need to go to another system, log in, and read the issue.? The issue often however also won't really have just one problem or just a tiny description.? So although I think it is fine to refer to an issue number, I think the test itself would still benefit of a reminder what it is testing (and I see you added a comment now, so that helps). Same goes for comments in the code; I often just see code lines marked with "RT-xyz" or "JDK-xyz" -- sometimes referring a non-public issue.? Just a small description in the code what the problem was is way more helpful to (future) maintainers, like ourselves, then a random number without further explanation. As for test naming, it will depend a bit on what you're testing. Sometimes using a nested class pattern like this is good: ??? class ListTest { ??????? @Nested ??????? class WhenEmpty { ????????????? void thenIsEmptyShouldReturnTrue() { ???????????????? ? assertThat(list.isEmpty()).isTrue(); ????????????? } ????????????? void thenSizeShouldBe0() { ?????????????????? assertThat(list.size()).isEqualTo(0); ????????????? } ????????????? void thenGettingFirstElementShouldThrowException() { ?????????????????? assertThatThrownBy(() -> list.get(0)) .isInstanceOf(IndexOutOfBoundsException.class) ??????????????????????? .hasMessage("index 0"); ????????????? } ????????????? @Nested ????????????? class AndFiveElementsAreAdded { ??????????????????? // add 5 elements in beforeEach ??????????????????? void thenIsEmptyShouldReturnFalse() {} ? ? ? ? ? ? ? ? ? ? // etc ????????????? } ??????? } ??????? // or if nesting becomes too crazy, start from base again: ??????? @Nested ??????? class WhenContainingFiveElements { ????????????? void thenIterationShouldReturnThoseFiveElements() { ??????????????????? assertThat(list).containsExactly(List.of("A", "B", "C", "D", "E")); ????????????? } ????????????? // etc. ??????? } ??? } The above pattern has top level nested classes start with "When" followed by a given state, nested classes start with "And" and a modification of the state, and test method naming follows the pattern "then should ".? When combined with a DisplayNameGenerator that transforms camel case names to spaced names, the tests form more or less normal English sentences. (Note: I used AssertJ here for much more fluently readable asserts) That said, I wouldn't go for a fixed naming pattern for test methods as it can be a bit situational, but I do think they should be descriptive. --John > > Thoughts? > > - Johan From jhendrikx at openjdk.org Tue Jul 9 12:25:07 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 12:25:07 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v3] In-Reply-To: References: Message-ID: <3zAkezcQdRwh_ywCSvYhDzizk22J9voayhUmTShA5x8=.b36a94da-f794-4598-bb67-afae1137733e@github.com> > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' of https://git.openjdk.org/jfx into feature/selectors-to-private-api-standalone - Add since tags - Move SimpleSelector and CompoundSelector to private classes ------------- Changes: https://git.openjdk.org/jfx/pull/1333/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=02 Stats: 178 lines in 10 files changed: 49 ins; 90 del; 39 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From duke at openjdk.org Tue Jul 9 13:00:43 2024 From: duke at openjdk.org (eduardsdv) Date: Tue, 9 Jul 2024 13:00:43 GMT Subject: Integrated: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Mon, 6 May 2024 14:14:05 GMT, eduardsdv wrote: > This is an alternative solution to the PR: https://github.com/openjdk/jfx/pull/1310. > > This solution is based on the invariant that if a node is marked as dirty, all ancestors must also be marked as dirty and that if an ancestor is marked as clean, all descendants must also be marked as clean. > Therefore I removed the ``clearDirtyTree()`` method and put its content to the ``clearDirty()`` method. > > Furthermore, since dirty flag is only used when rendering by ``ViewPainter``, it should also be deleted by ``ViewPainter`` only. > This guarantees: > 1. that all dirty flags are removed after rendering, and > 2. that no dirty flags are removed when a node is rendered, e.g. by creating a snapshot or printing. > Therefore I removed all calls of the methods ``clearDirty()`` and ``clearDirtyTree()`` from all other classes except the ``ViewerPainter``. > > The new version of the ``clearDirty()`` method together with calling it from the ``ViewerPainter`` needs to visit far fewer nodes compared to the version prior this PR. > > The supplied test checks that the nodes are updated even if they are partially covered, which led to the error in the version before the PR. The test can be started with: > ``gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests NGNodeDirtyFlagTest`` This pull request has now been integrated. Changeset: 9723a9c4 Author: Eduard Sedov Committer: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/9723a9c4ce3a4490df962b83da0df71b1e5145f1 Stats: 243 lines in 11 files changed: 172 ins; 47 del; 24 mod 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty Reviewed-by: arapte, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1451 From jhendrikx at openjdk.org Tue Jul 9 13:01:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 13:01:38 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled Marked as reviewed by jhendrikx (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1491#pullrequestreview-2166250937 From jhendrikx at openjdk.org Tue Jul 9 13:05:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 13:05:38 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 17:22:22 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add since tags > > This PR should probably be moved to draft. Now that the deprecation for removal is targeted for 23, this won't happen until JavaFX 24. @kevinrushforth I think this is ready for a closer inspection again; in a strict sense there are API additions in this PR, but because of how `sealed` works, they're not accessible except to permitted sub types (and none of those permitted types are public API). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2217687797 From kcr at openjdk.org Tue Jul 9 14:05:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 14:05:38 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 13:03:18 GMT, John Hendrikx wrote: > I think this is ready for a closer inspection again I'll put it on my review queue for after Thursday's fork. > in a strict sense there are API additions in this PR, but because of how `sealed` works, they're not accessible except to permitted sub types (and none of those permitted types are public API). Right, the API additions are the package-scope constructor and the `readBinary` method, although as you say, they are only accessible to internal JavaFX classes. Since `Selector` will be a sealed class with all permitted classes being internal, no package-scope methods can be accessed by an application. The main API change is the removal of the terminally-deprecated `SimpleSelector` and `CompoundSelector` classes. With that in mind, a better title for this bug would be: "Remove SimpleSelector and CompoundSelector classes" You could add the existing title as a summary: "/summary Move SimpleSelector and CompoundSelector to internal packages" ------------- PR Comment: https://git.openjdk.org/jfx/pull/1333#issuecomment-2217830387 From andy.goryachev at oracle.com Tue Jul 9 14:52:12 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 14:52:12 +0000 Subject: consistent naming for tests In-Reply-To: References: Message-ID: +1 for comments, links to the JS tickets, and descriptive names. Speaking of the test names, I wanted to bring up an issue that I've encountered recently which concerns the use of @Nested - https://bugs.openjdk.org/browse/JDK-8334497 Two test files consistently generate an error in Eclipse - ObservableValueFluentBindingsTest - LazyObjectBindingTest I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), and it only manifests itself in Eclipse and not in the gradle build - perhaps Eclipse actually verifies the removal of files? Anyway, a suggestion - if you use @Nested, please keep the class names short. Thank you -andy From: openjfx-dev on behalf of Johan Vos Date: Tuesday, July 9, 2024 at 02:33 To: openjfx-dev Subject: consistent naming for tests Hi, An interesting question from John Hendrikx (https://github.com/openjdk/jfx/pull/1283/#discussion_r1637684395) probably needs some general discussion on this list. Afaik, we don't have guidelines for how to name tests (in https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#coding-style-and-testing-guidelines) In the different test files we have, I see different patterns: * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) * in some cases, tests have a concise but somehow meaningful name (e.g. `testScrollBarStaysVisible`) * in some cases, tests refer to JBS issues (e.g. testJDK8309935) * in some cases, the test is explained in comments. I think it would be good to have some consistency going forward. (I'm not advocating we need to rename existing tests!) I don't have a strong preference myself, but I think the link to the JBS issue that triggered the creation of a specific test is always good to have. I am also very ok with comments, but I learned not everyone likes that. Thoughts? - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jul 9 14:52:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 14:52:41 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 09:13:13 GMT, Johan Vos wrote: >> tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 1: >> >>> 1: /* >> >> This test file is moved from a different location, could do `git mv` instead removing and adding. > > I manually reverted the add/remove part, and replaced it with `git mv`. I assume/hope that by squashing the commits, the add/remove will not be part of the change. git doesn't actually track renames and copies, so there is ultimately no difference between a "git mv" and "git rm; git add", at least not when done as part of a single commit. What git does is a heuristic when presenting diffs based on how similar the two files are. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670664270 From kcr at openjdk.org Tue Jul 9 14:52:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 14:52:42 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Wed, 19 Jun 2024 14:25:52 GMT, Ambarish Rapte wrote: >> Johan Vos has updated the pull request incrementally with two additional commits since the last revision: >> >> - process more reviewer comments >> - Process reviewer comments > > tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 321: > >> 319: Stage stage = new Stage(); >> 320: stage.setScene(new Scene(root)); >> 321: stage.show(); > > I think, a CountDownLatch should be added to make sure that stage is shown before proceeding. One correction: `Stage.show` is not a blocking call. I haven't looked at it closely, but perhaps what @arapte meant was to suggest that the test wait on a latch that is triggered when the Stage::showing event is delivered? Many of our headful tests do that, but I don't know whether that would be applicable here or not. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1670667153 From andy.goryachev at oracle.com Tue Jul 9 15:03:32 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 15:03:32 +0000 Subject: CSS Lookups and their origins (possible regression) In-Reply-To: <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> Message-ID: I've used this feature in the past to change the colors in all the controls, so to me this is the expected behavior. So in your case (if I got it right), you need to set the direct style on the label (.setStyle("-fx-text-fill:yellow")) instead of setting the text fill programmatically. Right? -andy From: openjfx-dev on behalf of John Hendrikx Date: Monday, July 8, 2024 at 17:11 To: openjfx-dev Subject: Re: CSS Lookups and their origins (possible regression) I realized I worded the TLDR poorly. Let me try again: TLDR; should styles which use references (like -fx-base used in Modena) become AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR level, as if you specified them directly... --John On 09/07/2024 02:07, John Hendrikx wrote: Hi List, TLDR; should a CSS reference like -fx-base convert all styles that use this value (or derive from it) become AUTHOR level styles (higher priority than setters) ? Long version: In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value could be reset on an unrelated control. This happened when the CSS engine encountered a stylable that is overridden by the user (with a setter), and decided NOT to proceed with the full CSS value calculation (as it could not override the user setting if that CSS value had lower priority). However, not proceeding with the calculation meant that a "SKIP" was stored in a shared cache which was incorrect. This is because when this "SKIP" is later encountered for an unrelated control (the cache entries are shared for controls with the same styles at the same level), they could get their values reset because they were assumed to be unstyled. However, this fix has exposed what seems to be a deeper bug or perhaps an unfortunate default: JavaFX has a special feature where you can refer to certain other styles by using a reference (which is resolved, recursively, to a final value). This does not seem to be a CSS standard, but is a feature only FX has. It works by saying something like: -fx-base: RED; And then using it like this: -fx-text-fill: -fx-base; This feature works accross stylesheets of different origins, so an AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT refers to -fx-base, the value comes from the AUTHOR stylesheet. JavaFX then changes the origin of the style to the highest priority encountered while resolving the reference. This means that Modena can specify "-fx-text-fill: -fx-base", and when "-fx-base" is then part of the AUTHOR style sheet, that ALL Modena styles that use -fx-base will be considered AUTHOR level styles, as per this comment: // The origin of this parsed value is the greatest of // any of the resolved reference. If a resolved reference // comes from an inline style, for example, then the value // calculated from the resolved lookup should have inline // as its origin. Otherwise, an inline style could be // stored in shared cache. I feel that this is a really unfortunate choice. The style after all was specified by Modena, only its value came from another (higher priority) style sheet. I think a more logical choice would have been to not change the priority at all, unless a "-fx-text-fill" is explicitly made part of the AUTHOR stylesheet. A consequence of this (and which is much more visible after the fix) is that creating a Label with a setTextFill(Color.YELLOW) in its constructor will only result in a yellow text fill if the AUTHOR stylesheet did not override any of the Modena colors involved in calculating the Modena -fx-text-fill default. Overriding -fx-base in any way will result in the text fill of the label to be overridden (as the reference came from an AUTHOR stylesheet, which trumps a setter which is of a lower style origin). The comment also alludes to a potential problem. If an inline style would specify "-fx-base", but would be treated as if it came from Modena (USER_AGENT level), then this value could get stored in the cache as everything except INLINE styles can be cached. However, I feel that the changing of style origin level was then probably done to solve a CACHING problem, instead of what made logical sense for users. If we agree that a resolved reference should not change the style origin level, then this would need to be addressed, by perhaps marking such a calculated value as uncacheable, instead of overloading the meaning of style origin. I'd like to hear your thoughts, and also how to proceed. JavaFX versions before 21 seemingly allowed overriding reference without much consequence because if the user overrode the value manually, the cache entry would be set to "SKIP". Now that this is no longer the case, JavaFX more aggressively overrides user set values if they happen to use a referenced value. See code below. --John .root { -fx-base: #ff0000; } package app; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.paint.Color; import javafx.stage.Stage; public class TestApp extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { Scene scene = new Scene(new MyLabel()); // See the difference with/without -fx-base in the stylesheet scene.getStylesheets().add(TestApp.class.getResource("/style.css").toExternalForm()); primaryStage.setScene(scene); primaryStage.show(); } } class MyLabel extends Label { public MyLabel() { setTextFill(Color.YELLOW); setText("Hello world"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Jul 9 15:08:14 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2024 08:08:14 -0700 Subject: consistent naming for tests In-Reply-To: References: Message-ID: <744c674f-ca8c-4a7f-b550-d0b4372f7b05@oracle.com> I generally like descriptive names for test methods (and classes) rather than encoding the bug ID in the name. A comment with the bug ID is very helpful, and I would support making that a best practice. If the purpose of a test is non-obvious, a comment explaining it is a good idea. -- Kevin On 7/9/2024 2:33 AM, Johan Vos wrote: > Hi, > > An interesting question from John Hendrikx > (https://github.com/openjdk/jfx/pull/1283/#discussion_r1637684395) > probably needs some general discussion on this list. > Afaik, we don't have guidelines for how to name tests (in > https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#coding-style-and-testing-guidelines) > > In the different test files we have, I see different patterns: > * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) > * in some cases, tests have a concise but somehow meaningful?name > (e.g. `testScrollBarStaysVisible`) > * in some cases, tests refer to JBS issues (e.g. testJDK8309935) > * in some cases, the test is explained in comments. > > I think it would be good to have some consistency going forward. (I'm > not advocating we need to rename existing tests!) > I don't have a strong preference myself, but I think the link to the > JBS issue that triggered the creation of a specific test is always > good to have. I am also very ok with comments, but I learned not > everyone likes that. > > Thoughts? > > - Johan From kcr at openjdk.org Tue Jul 9 15:16:50 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 15:16:50 GMT Subject: RFR: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty [v7] In-Reply-To: References: Message-ID: On Fri, 28 Jun 2024 10:34:58 GMT, Florian Kirmaier wrote: >> In some situations, a part of the SG is no longer rendered. >> I created a test program that showcases this problem. >> >> Explanation: >> >> This can happen, when a part of the SG, is covered by another Node. >> In this part, one node is totally covered, and the other node is visible. >> >> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. >> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. >> >> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. >> >> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. >> >> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. >> >> Useful parameters for further investigations: >> -Djavafx.pulseLogger=true >> -Dprism.printrendergraph=true >> -Djavafx.pulseLogger.threshold=0 >> >> PR: >> This PR ensures the dirty flag is set to false of the tree when the culling is used. >> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. >> It would be great to have some feedback on this solution - maybe guiding me to a better solution. >> >> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. > > Florian Kirmaier 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 seven additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8322544-render-culling > - JDK-8322619: Adjust test: remove Thread.sleep(), runAndWait() > - JDK-8322619: Add test > - Revert "JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0" > > This reverts commit 5f9f1574515c078c1fd0dccd476325090a0b284d. > - JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0 > - reverted accidental change in the .idea folder > - JDK-8322619 Fix for rendering bug, related to overlap - culling - dirtynodes This PR should be closed now that PR #1451 is integrated. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1310#pullrequestreview-2166623300 From john.hendrikx at gmail.com Tue Jul 9 15:22:20 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 17:22:20 +0200 Subject: consistent naming for tests In-Reply-To: References: Message-ID: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> On 09/07/2024 16:52, Andy Goryachev wrote: > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > I admit I have a weird setup (EncFS on Linux Mint running on MacBook > Pro), and it only manifests itself in Eclipse and not in the gradle > build - perhaps Eclipse actually verifies the removal of files? > > Anyway, a suggestion - if you use @Nested, please keep the class names > /short/. > This is not an Eclipse bug as I never encounter such issues.? 143 characters is rather short these days, but I suppose we could limit the nesting a bit.? Still, I'd look into a way to alleviate this problem in your setup, sooner or later this is going to be a problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Jul 9 15:24:59 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 17:24:59 +0200 Subject: CSS Lookups and their origins (possible regression) In-Reply-To: References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> Message-ID: It's not that you can't use -fx-base, but that as it is currently that all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority (above setters) even though you didn't specifically specify them in your own stylesheet.? All such styles are being elevated from USER_AGENT to AUTHOR level (which is above USER level which is used for setters). --John On 09/07/2024 17:03, Andy Goryachev wrote: > > I've used this feature in the past to change the colors in all the > controls, so to me this is the expected behavior. > > So in your case (if I got it right), you need to set the direct style > on the label (.setStyle("-fx-text-fill:yellow")) instead of setting > the text fill programmatically.? Right? > > -andy > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Monday, July 8, 2024 at 17:11 > *To: *openjfx-dev > *Subject: *Re: CSS Lookups and their origins (possible regression) > > I realized I worded the TLDR poorly. > > Let me try again: > > TLDR; should styles which use references (like -fx-base used in > Modena) become AUTHOR level styles if -fx-base is specified in an > AUTHOR stylesheet?? The act of simply specifying -fx-base in your own > AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR > level, as if you specified them directly... > > --John > > On 09/07/2024 02:07, John Hendrikx wrote: > > Hi List, > > TLDR; should a CSS reference like -fx-base convert all styles that > use this value (or derive from it) become AUTHOR level styles > (higher priority than setters) ? > > Long version: > > In JavaFX 21, I did a fix (see #1072) to solve a problem where a > CSS value could be reset on an unrelated control. > > This happened when the CSS engine encountered a stylable that is > overridden by the user (with a setter), and decided NOT to proceed > with the full CSS value calculation (as it could not override the > user setting if that CSS value had lower priority).? However, not > proceeding with the calculation meant that a "SKIP" was stored in > a shared cache which was incorrect.? This is because when this > "SKIP" is later encountered for an unrelated control (the cache > entries are shared for controls with the same styles at the same > level), they could get their values reset because they were > assumed to be unstyled. > > However, this fix has exposed what seems to be a deeper bug or > perhaps an unfortunate default: > > JavaFX has a special feature where you can refer to certain other > styles by using a reference (which is resolved, recursively, to a > final value).? This does not seem to be a CSS standard, but is a > feature only FX has. > > It works by saying something like: > > ??? -fx-base: RED; > > And then using it like this: > > ??? -fx-text-fill: -fx-base; > > This feature works accross stylesheets of different origins, so an > AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT > refers to -fx-base, the value comes from the AUTHOR stylesheet. > > JavaFX then changes the origin of the style to the highest > priority encountered while resolving the reference.? This means > that Modena can specify "-fx-text-fill: -fx-base", and when > "-fx-base" is then part of the AUTHOR style sheet, that ALL Modena > styles that use -fx-base will be considered AUTHOR level styles, > as per this comment: > > // The origin of this parsed value is the greatest of > > // any of the resolved reference. If a resolved reference > > // comes from an inline style, for example, then the value > > // calculated from the resolved lookup should have inline > > // as its origin. Otherwise, an inline style could be > > // stored in shared cache. > > I feel that this is a really unfortunate choice.? The style after > all was specified by Modena, only its value came from another > (higher priority) style sheet.? I think a more logical choice > would have been to not change the priority at all, unless a > "-fx-text-fill" is explicitly made part of the AUTHOR stylesheet. > > A consequence of this (and which is much more visible after the > fix) is that creating a Label with a setTextFill(Color.YELLOW) in > its constructor will only result in a yellow text fill if the > AUTHOR stylesheet did not override any of the Modena colors > involved in calculating the Modena -fx-text-fill default. > Overriding -fx-base in any way will result in the text fill of the > label to be overridden (as the reference came from an AUTHOR > stylesheet, which trumps a setter which is of a lower style origin). > > The comment also alludes to a potential problem.? If an inline > style would specify "-fx-base", but would be treated as if it came > from Modena (USER_AGENT level), then this value could get stored > in the cache as everything except INLINE styles can be cached.? > However, I feel that the changing of style origin level was then > probably done to solve a CACHING problem, instead of what made > logical sense for users.? If we agree that a resolved reference > should not change the style origin level, then this would need to > be addressed, by perhaps marking such a calculated value as > uncacheable, instead of overloading the meaning of style origin. > > I'd like to hear your thoughts, and also how to proceed.? JavaFX > versions before 21 seemingly allowed overriding reference without > much consequence because if the user overrode the value manually, > the cache entry would be set to "SKIP".? Now that this is no > longer the case, JavaFX more aggressively overrides user set > values if they happen to use a referenced value.? See code below. > > --John > > .root { > > -fx-base: #ff0000; > > } > > *package*app; > > *import*javafx.application.Application; > > *import*javafx.scene.Scene; > > *import*javafx.scene.control.Label; > > *import*javafx.scene.paint.Color; > > *import*javafx.stage.Stage; > > *public**class*TestApp *extends*Application { > > *public**static**void*main(String[] args) { > > /launch/(args); > > } > > @Override > > *public**void*start(Stage primaryStage) { > > Scene scene = *new*Scene(*new*MyLabel()); > > // See the difference with/without -fx-base in the _stylesheet_ > > scene.getStylesheets().add(TestApp.*class*.getResource("/style.css").toExternalForm()); > > primaryStage.setScene(scene); > > primaryStage.show(); > > } > > } > > *class*MyLabel *extends*Label { > > *public*MyLabel() { > > setTextFill(Color.YELLOW); > > setText("Hello world"); > > } > > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Jul 9 15:30:18 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2024 08:30:18 -0700 Subject: consistent naming for tests In-Reply-To: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: <56256338-811a-48bf-b328-543f8ab5ba55@oracle.com> This might be a combination of Eclipse and eCryptfs. I agree that 143 chars is very short for a max length. -- Kevin On 7/9/2024 8:22 AM, John Hendrikx wrote: > > > On 09/07/2024 16:52, Andy Goryachev wrote: >> >> Two test files consistently generate an error in Eclipse >> >> - ObservableValueFluentBindingsTest >> - LazyObjectBindingTest >> >> I admit I have a weird setup (EncFS on Linux Mint running on MacBook >> Pro), and it only manifests itself in Eclipse and not in the gradle >> build - perhaps Eclipse actually verifies the removal of files? >> >> Anyway, a suggestion - if you use @Nested, please keep the class >> names /short/. >> > This is not an Eclipse bug as I never encounter such issues. 143 > characters is rather short these days, but I suppose we could limit > the nesting a bit.? Still, I'd look into a way to alleviate this > problem in your setup, sooner or later this is going to be a problem. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 15:37:01 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 15:37:01 +0000 Subject: [External] : Re: consistent naming for tests In-Reply-To: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: Have you tried building in Eclipse on the latest Linux Mint? Or building on an EncFS mount? I don't know why Mint decided to use EncFS knowing its issues, and I suppose I can try fixing my setup (it's a default Mint installation), but I was quite surprised myself and thought that it might be just as easy to fix the tests... here is how the fix might look: https://github.com/andy-goryachev-oracle/jfx/pull/9 -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:22 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: [External] : Re: consistent naming for tests On 09/07/2024 16:52, Andy Goryachev wrote: Two test files consistently generate an error in Eclipse - ObservableValueFluentBindingsTest - LazyObjectBindingTest I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), and it only manifests itself in Eclipse and not in the gradle build - perhaps Eclipse actually verifies the removal of files? Anyway, a suggestion - if you use @Nested, please keep the class names short. This is not an Eclipse bug as I never encounter such issues. 143 characters is rather short these days, but I suppose we could limit the nesting a bit. Still, I'd look into a way to alleviate this problem in your setup, sooner or later this is going to be a problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jul 9 15:41:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 15:41:43 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v3] In-Reply-To: <3zAkezcQdRwh_ywCSvYhDzizk22J9voayhUmTShA5x8=.b36a94da-f794-4598-bb67-afae1137733e@github.com> References: <3zAkezcQdRwh_ywCSvYhDzizk22J9voayhUmTShA5x8=.b36a94da-f794-4598-bb67-afae1137733e@github.com> Message-ID: On Tue, 9 Jul 2024 12:25:07 GMT, John Hendrikx wrote: >> Moves `SimpleSelector` and `CompoundSelector` to internal packages. >> >> This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. >> >> This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). >> >> This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: >> >> - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses >> - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) >> - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible >> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant >> - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` >> - No need anymore for the `SimpleSelectorShim` > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into feature/selectors-to-private-api-standalone > - Add since tags > - Move SimpleSelector and CompoundSelector to private classes I left a couple quick comments on the API changes. I'll review the rest after the fork. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 51: > 49: * Explicit constructor for subtype use. > 50: * > 51: * @since 23 The pattern we use elsewhere is: "Constructor for subclasses to call." Also, that should be `@since 24`. modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 197: > 195: * @return a selector, never {@code null} > 196: * @throws IOException if reading from {@code DataInputStream} fails > 197: * @since 23 That should be `@since 24`. ------------- PR Review: https://git.openjdk.org/jfx/pull/1333#pullrequestreview-2166691276 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670750269 PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670751417 From andy.goryachev at oracle.com Tue Jul 9 15:43:41 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 15:43:41 +0000 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> Message-ID: > all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority I think it works as designed (and as expected). -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:25 To: Andy Goryachev , openjfx-dev Subject: [External] : Re: CSS Lookups and their origins (possible regression) It's not that you can't use -fx-base, but that as it is currently that all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority (above setters) even though you didn't specifically specify them in your own stylesheet. All such styles are being elevated from USER_AGENT to AUTHOR level (which is above USER level which is used for setters). --John On 09/07/2024 17:03, Andy Goryachev wrote: I've used this feature in the past to change the colors in all the controls, so to me this is the expected behavior. So in your case (if I got it right), you need to set the direct style on the label (.setStyle("-fx-text-fill:yellow")) instead of setting the text fill programmatically. Right? -andy From: openjfx-dev on behalf of John Hendrikx Date: Monday, July 8, 2024 at 17:11 To: openjfx-dev Subject: Re: CSS Lookups and their origins (possible regression) I realized I worded the TLDR poorly. Let me try again: TLDR; should styles which use references (like -fx-base used in Modena) become AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR level, as if you specified them directly... --John On 09/07/2024 02:07, John Hendrikx wrote: Hi List, TLDR; should a CSS reference like -fx-base convert all styles that use this value (or derive from it) become AUTHOR level styles (higher priority than setters) ? Long version: In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value could be reset on an unrelated control. This happened when the CSS engine encountered a stylable that is overridden by the user (with a setter), and decided NOT to proceed with the full CSS value calculation (as it could not override the user setting if that CSS value had lower priority). However, not proceeding with the calculation meant that a "SKIP" was stored in a shared cache which was incorrect. This is because when this "SKIP" is later encountered for an unrelated control (the cache entries are shared for controls with the same styles at the same level), they could get their values reset because they were assumed to be unstyled. However, this fix has exposed what seems to be a deeper bug or perhaps an unfortunate default: JavaFX has a special feature where you can refer to certain other styles by using a reference (which is resolved, recursively, to a final value). This does not seem to be a CSS standard, but is a feature only FX has. It works by saying something like: -fx-base: RED; And then using it like this: -fx-text-fill: -fx-base; This feature works accross stylesheets of different origins, so an AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT refers to -fx-base, the value comes from the AUTHOR stylesheet. JavaFX then changes the origin of the style to the highest priority encountered while resolving the reference. This means that Modena can specify "-fx-text-fill: -fx-base", and when "-fx-base" is then part of the AUTHOR style sheet, that ALL Modena styles that use -fx-base will be considered AUTHOR level styles, as per this comment: // The origin of this parsed value is the greatest of // any of the resolved reference. If a resolved reference // comes from an inline style, for example, then the value // calculated from the resolved lookup should have inline // as its origin. Otherwise, an inline style could be // stored in shared cache. I feel that this is a really unfortunate choice. The style after all was specified by Modena, only its value came from another (higher priority) style sheet. I think a more logical choice would have been to not change the priority at all, unless a "-fx-text-fill" is explicitly made part of the AUTHOR stylesheet. A consequence of this (and which is much more visible after the fix) is that creating a Label with a setTextFill(Color.YELLOW) in its constructor will only result in a yellow text fill if the AUTHOR stylesheet did not override any of the Modena colors involved in calculating the Modena -fx-text-fill default. Overriding -fx-base in any way will result in the text fill of the label to be overridden (as the reference came from an AUTHOR stylesheet, which trumps a setter which is of a lower style origin). The comment also alludes to a potential problem. If an inline style would specify "-fx-base", but would be treated as if it came from Modena (USER_AGENT level), then this value could get stored in the cache as everything except INLINE styles can be cached. However, I feel that the changing of style origin level was then probably done to solve a CACHING problem, instead of what made logical sense for users. If we agree that a resolved reference should not change the style origin level, then this would need to be addressed, by perhaps marking such a calculated value as uncacheable, instead of overloading the meaning of style origin. I'd like to hear your thoughts, and also how to proceed. JavaFX versions before 21 seemingly allowed overriding reference without much consequence because if the user overrode the value manually, the cache entry would be set to "SKIP". Now that this is no longer the case, JavaFX more aggressively overrides user set values if they happen to use a referenced value. See code below. --John .root { -fx-base: #ff0000; } package app; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.paint.Color; import javafx.stage.Stage; public class TestApp extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { Scene scene = new Scene(new MyLabel()); // See the difference with/without -fx-base in the stylesheet scene.getStylesheets().add(TestApp.class.getResource("/style.css").toExternalForm()); primaryStage.setScene(scene); primaryStage.show(); } } class MyLabel extends Label { public MyLabel() { setTextFill(Color.YELLOW); setText("Hello world"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jul 9 15:47:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jul 2024 15:47:36 GMT Subject: RFR: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled thank you for reviewing! will integrate after the fork. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1491#issuecomment-2218054668 From kevin.rushforth at oracle.com Tue Jul 9 16:02:50 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2024 09:02:50 -0700 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: <0cb6c586-438c-4b38-b71b-8f45e77899cf@oracle.com> > https://github.com/andy-goryachev-oracle/jfx/pull/9 Hmm. I don't really like the abbreviations. They would change something that is self-explanatory to something completely opaque, although I see you did leave the descriptive name as a comment. -- Kevin On 7/9/2024 8:37 AM, Andy Goryachev wrote: > > Have you tried building in Eclipse on the latest Linux Mint?? Or > building on an EncFS mount? > > I don't know why Mint decided to use EncFS knowing its issues, and I > suppose I can try fixing my setup (it's a default Mint installation), > but I was quite surprised myself and thought that it might be just as > easy to fix the tests... here is how the fix might look: > > https://github.com/andy-goryachev-oracle/jfx/pull/9 > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 08:22 > *To: *Andy Goryachev , Johan Vos > , openjfx-dev > *Subject: *[External] : Re: consistent naming for tests > > On 09/07/2024 16:52, Andy Goryachev wrote: > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > I admit I have a weird setup (EncFS on Linux Mint running on > MacBook Pro), and it only manifests itself in Eclipse and not in > the gradle build - perhaps Eclipse actually verifies the removal > of files? > > Anyway, a suggestion - if you use @Nested, please keep the class > names /short/. > > This is not an Eclipse bug as I never encounter such issues.? 143 > characters is rather short these days, but I suppose we could limit > the nesting a bit.? Still, I'd look into a way to alleviate this > problem in your setup, sooner or later this is going to be a problem. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 16:06:32 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 16:06:32 +0000 Subject: [External] : Re: consistent naming for tests In-Reply-To: <0cb6c586-438c-4b38-b71b-8f45e77899cf@oracle.com> References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <0cb6c586-438c-4b38-b71b-8f45e77899cf@oracle.com> Message-ID: I know - very few people would like that solution. I would welcome other suggestions. The only thing I can say in my defense is that this is only a test, so as long as the intent is clear we should be fine. -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, July 9, 2024 at 09:03 To: openjfx-dev at openjdk.org Subject: Re: [External] : Re: consistent naming for tests https://github.com/andy-goryachev-oracle/jfx/pull/9 Hmm. I don't really like the abbreviations. They would change something that is self-explanatory to something completely opaque, although I see you did leave the descriptive name as a comment. -- Kevin On 7/9/2024 8:37 AM, Andy Goryachev wrote: Have you tried building in Eclipse on the latest Linux Mint? Or building on an EncFS mount? I don't know why Mint decided to use EncFS knowing its issues, and I suppose I can try fixing my setup (it's a default Mint installation), but I was quite surprised myself and thought that it might be just as easy to fix the tests... here is how the fix might look: https://github.com/andy-goryachev-oracle/jfx/pull/9 -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:22 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: [External] : Re: consistent naming for tests On 09/07/2024 16:52, Andy Goryachev wrote: Two test files consistently generate an error in Eclipse - ObservableValueFluentBindingsTest - LazyObjectBindingTest I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), and it only manifests itself in Eclipse and not in the gradle build - perhaps Eclipse actually verifies the removal of files? Anyway, a suggestion - if you use @Nested, please keep the class names short. This is not an Eclipse bug as I never encounter such issues. 143 characters is rather short these days, but I suppose we could limit the nesting a bit. Still, I'd look into a way to alleviate this problem in your setup, sooner or later this is going to be a problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Jul 9 17:10:36 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Jul 2024 17:10:36 GMT Subject: Integrated: 8295945: Revert unintended change to copyright start year In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 13:31:03 GMT, Ambarish Rapte wrote: > A quick fix to correct the created copyright year. > The created year in the header was unintentionally modified previously from 2021 to 2017. This pull request has now been integrated. Changeset: dbda2cce Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/dbda2cce0352692c622e6cc1bc664d779c013fcb Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8295945: Revert unintended change to copyright start year Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1496 From angorya at openjdk.org Tue Jul 9 17:27:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jul 2024 17:27:32 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 07:23:09 GMT, Ambarish Rapte wrote: >> The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). >> The PR adds the "offset < 0" check to both the methods. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > const vars lgtm modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 70: > 68: jint x, jint y, jint width, jint height) { > 69: const jint dstX = 0; > 70: const jint dstY = 0; if it were up to me, I'd remove these as part of this PR. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1497#pullrequestreview-2166934862 PR Review Comment: https://git.openjdk.org/jfx/pull/1497#discussion_r1670898504 From john.hendrikx at gmail.com Tue Jul 9 17:31:29 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 19:31:29 +0200 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: Perhaps it is something Eclipse does differently.? Normally nested classed are numbered ($1, $2), so perhaps ecj is compiling these with differently filenames. --John On 09/07/2024 17:37, Andy Goryachev wrote: > Have you tried building in Eclipse on the latest Linux Mint?? Or > building on an EncFS mount? > > I don't know why Mint decided to use EncFS knowing its issues, and I > suppose I can try fixing my setup (it's a default Mint installation), > but I was quite surprised myself and thought that it might be just as > easy to fix the tests... here is how the fix might look: > > https://github.com/andy-goryachev-oracle/jfx/pull/9 > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 08:22 > *To: *Andy Goryachev , Johan Vos > , openjfx-dev > *Subject: *[External] : Re: consistent naming for tests > > On 09/07/2024 16:52, Andy Goryachev wrote: > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > I admit I have a weird setup (EncFS on Linux Mint running on > MacBook Pro), and it only manifests itself in Eclipse and not in > the gradle build - perhaps Eclipse actually verifies the removal > of files? > > Anyway, a suggestion - if you use @Nested, please keep the class > names /short/. > > This is not an Eclipse bug as I never encounter such issues.? 143 > characters is rather short these days, but I suppose we could limit > the nesting a bit.? Still, I'd look into a way to alleviate this > problem in your setup, sooner or later this is going to be a problem. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 17:35:29 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 17:35:29 +0000 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: Anonymous classes are named $1. Nested classes retain their name. >From the ticket: https://bugs.openjdk.org/browse/JDK-8334497 Could not delete: /home/ag/Projects/jfx-2/jfx/rt/modules/javafx.base/testbin/test/javafx/beans/value/ObservableValueFluentBindingsTest$When_flatMap_Called$WithNotNullReturns_ObservableValue_Which$WhenObservedForInvalidations$AndWhenUnobserved.class. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:31 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: Re: [External] : Re: consistent naming for tests Perhaps it is something Eclipse does differently. Normally nested classed are numbered ($1, $2), so perhaps ecj is compiling these with differently filenames. --John On 09/07/2024 17:37, Andy Goryachev wrote: Have you tried building in Eclipse on the latest Linux Mint? Or building on an EncFS mount? I don't know why Mint decided to use EncFS knowing its issues, and I suppose I can try fixing my setup (it's a default Mint installation), but I was quite surprised myself and thought that it might be just as easy to fix the tests... here is how the fix might look: https://github.com/andy-goryachev-oracle/jfx/pull/9 -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:22 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: [External] : Re: consistent naming for tests On 09/07/2024 16:52, Andy Goryachev wrote: Two test files consistently generate an error in Eclipse - ObservableValueFluentBindingsTest - LazyObjectBindingTest I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), and it only manifests itself in Eclipse and not in the gradle build - perhaps Eclipse actually verifies the removal of files? Anyway, a suggestion - if you use @Nested, please keep the class names short. This is not an Eclipse bug as I never encounter such issues. 143 characters is rather short these days, but I suppose we could limit the nesting a bit. Still, I'd look into a way to alleviate this problem in your setup, sooner or later this is going to be a problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jul 9 17:36:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jul 2024 17:36:02 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 10:36:57 GMT, John Hendrikx wrote: >> I'll add the `@since 23`, however it can't be called by anyone except FX itself. >> >> Some background: the readBinary/writeBinary methods are ultimately called via the publicly accessible methods `loadBinary` and `saveBinary` in `javafx.css.Stylesheet`. >> >> The reason it needs to be `protected` now is because `CompoundSelector` is using this (but IMHO, it shouldn't have). Why I say it shouldn't? That's because it already knows what it will be reading will all be `SimpleSelector`s, as it stores a counter (a `short`) and then loads that many `SimpleSelector`s. However, by not taking the direct route of using `SimpleSelector#readBinary` (and the corresponding `SimpleSelector#writeBinary`) there is an additional `byte` prefix indicating the type of selector -- this isn't needed and wastes some space in the binary format. >> >> Changing that now however would make the binary format incompatible with earlier versions, so I think making this `protected` is a reasonable solution. It also mirrors the `writeBinary` method then, which was already `protected`. > > I missed something in my above evaluation. The counterpart method `writeBinary` is not `static`. Although that makes sense as in that case you do have an instance you wish to write, it does make the read/write API asymmetric. > > It's not possible to make `readBinary` an instance method though as it is the method that is creating those instances. > > The other way around is possible (make `writeBinary` static), but it would then again need a pattern match to determine the correct static `writeBinary` to call when writing an arbitrary `Selector`. However, this would have allowed `CompoundSelector` to call a static version of `SimpleSelector#writeBinary` and `readBinary`, avoiding the extra identifying byte in the binary format, and avoiding the cast when reading it back. > > The read/write loops below: > > + > final int nSelectors = is.readShort(); > final List selectors = new ArrayList<>(); > for (int n=0; n selectors.add((SimpleSelector)Selector.readBinary(bssVersion, is,strings)); > } > + > os.writeShort(selectors.size()); // writes the number of SimpleSelectors to the binary stream > for (int n=0; n< selectors.size(); n++) selectors.get(n).writeBinary(os,stringStore); // writes each individually > > Would then have become: > > + > final int nSelectors = is.readShort(); > final List selectors = new ArrayList<>(); > for (int n=0; n selectors.add(SimpleSelector.readBinary(bssVersion, is,strings)); // cast is gone > } > + > os.writeShort(selectors.size()); // writes the number of SimpleSelectors to the binary stream > for (int n=0; n< selectors.size(); n++) SimpleSelector.writeBinaryStatic(selectors.get(n), os, stringStore); // writes each individually it looks to me readBinary should be static, and writeBinary an instance method - this is a normal pattern. the asymmetry is dictated by the fact that we don't have an instance when reading, so typically read() methods read the stream and create an instance at the last moment with the specific constructor. unless, of course, the design allows for mutation and the fields can be set(). Alternatively, readBinary() could be moved to another class (helper? reader?) to avoid making this an API change. what do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670922573 From angorya at openjdk.org Tue Jul 9 17:36:01 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jul 2024 17:36:01 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v3] In-Reply-To: References: Message-ID: On Fri, 19 Jan 2024 09:33:15 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 102: >> >>> 100: >>> 101: return new Match(this, s.getPseudoClassStates(), idCount, styleClassCount); >>> 102: } >> >> I presume you are moving the implementations to this base class because some of the types, constructors (e.g., Match), or methods only have package visibility? Using the accessor pattern via a Helper class is usually how we deal with this. Have you considered that? It would allow the implementation to remain in the subclasses. > > Yes, correct, `CompoundSelector` accesses the package private fields `idCount` and `styleClassCount` of `Match` directly, which it can't do anymore after being moved to a different package; these lines: > > idCount += match.idCount; > styleClassCount += match.styleClassCount; > > I'm aware of the Helper classes, but I feel that they are a much more invasive concept (and also harder to follow) to achieve this than doing a pattern match with `instanceof` (which can be replaced with pattern matches for switch once we can use Java 21). However, if you think this is a requirement, I'm happy to change it -- that said, we're not locked in either choice as far as I can see. > > Alternatively, with everything needed in `Selector` being publicly accessible, I'm not sure if the match creation really needed to be in `Selector` or its subtypes at all. It feels like more a job for an external type to handle (like how you don't write serialization logic for JSON or XML in each subtype). If it were up to me, I'd probably create a static method in `Match` which given a `Selector` creates the match. That way, no `Match` internals need exposing at all. I could still do this, as the method needed could be package private, and then all the match fields can be made fully private. what do you think of Match MatchHelper.create(SimpleSelector) Match MatchHelper.create(CompoundSelector) ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670912593 From angorya at openjdk.org Tue Jul 9 17:36:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jul 2024 17:36:00 GMT Subject: RFR: 8323706: Move SimpleSelector and CompoundSelector to internal packages [v3] In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 23:57:05 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: >> >> - Merge branch 'master' of https://git.openjdk.org/jfx into feature/selectors-to-private-api-standalone >> - Add since tags >> - Move SimpleSelector and CompoundSelector to private classes > > modules/javafx.graphics/src/main/java/javafx/css/Selector.java line 96: > >> 94: * @return a match, never {@code null} >> 95: */ >> 96: public final Match createMatch() { > > This is a compatible change only because this class is sealed. I do have a question, though, about whether it should remain abstract. I agree with Kevin here: the implementation should be moved to respective child classes. If Match constructor is not public, then we should create a factory method in a helper, for example. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670911089 From john.hendrikx at gmail.com Tue Jul 9 17:45:02 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 19:45:02 +0200 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> Message-ID: <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> Well, it is coming as a surprise to many. With the fix for the CSS caching bug since JavaFX 21, this "normal" behavior is becoming much more obvious. Let me repeat one more time: If I have a Label, and I manually set its text fill with a setter to YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. Now do this in JavaFX 21.? As soon as you add the stylesheet with `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even though technically this value for -fx-text-fill is defined by Modena (which should not be overriding set values).? Nowhere did we **actualy** override -fx-text-fill, yet the CSS subsystem now sees **all** values defined by Modena that are somehow linked to -fx-base as defined directly by the developer... The reason this didn't happen in JavaFX prior to 21 is because there was a bug where a CSS value was not fully calculated if the property it encountered was overridden via a set value. That was a bug however as cache entries are shared amongst similar styled nodes, and so not calculating it fully could have effects on other nodes that shared that cache entry but did NOT have a property set directly.? Now that this bug is fixed, this problem is odd behavior is popping up where simply specifying -fx-base in an empty stylesheet is somehow overriding a programmatically set text fill.? Users are confused by this, as nowhere in their stylesheet do they themselves override text fill. This entire mechanism is not specified by CSS, but is unique to FX.? The most similar mechanism in CSS (see Michael's answer) says the priority of a style should not be changed when it is using a reference. --John On 09/07/2024 17:43, Andy Goryachev wrote: > > > all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority > > I think it works as designed (and as expected). > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 08:25 > *To: *Andy Goryachev , openjfx-dev > > *Subject: *[External] : Re: CSS Lookups and their origins (possible > regression) > > It's not that you can't use -fx-base, but that as it is currently that > all styles used in Modena that rely on -fx-base directly or indirectly > suddenly have a higher priority (above setters) even though you didn't > specifically specify them in your own stylesheet.? All such styles are > being elevated from USER_AGENT to AUTHOR level (which is above USER > level which is used for setters). > > --John > > On 09/07/2024 17:03, Andy Goryachev wrote: > > I've used this feature in the past to change the colors in all the > controls, so to me this is the expected behavior. > > So in your case (if I got it right), you need to set the direct > style on the label (.setStyle("-fx-text-fill:yellow")) instead of > setting the text fill programmatically.? Right? > > -andy > > *From: *openjfx-dev > on behalf of John Hendrikx > > *Date: *Monday, July 8, 2024 at 17:11 > *To: *openjfx-dev > > *Subject: *Re: CSS Lookups and their origins (possible regression) > > I realized I worded the TLDR poorly. > > Let me try again: > > TLDR; should styles which use references (like -fx-base used in > Modena) become AUTHOR level styles if -fx-base is specified in an > AUTHOR stylesheet?? The act of simply specifying -fx-base in your > own AUTHOR stylesheet elevates hundreds of styles from Modena to > AUTHOR level, as if you specified them directly... > > --John > > On 09/07/2024 02:07, John Hendrikx wrote: > > Hi List, > > TLDR; should a CSS reference like -fx-base convert all styles > that use this value (or derive from it) become AUTHOR level > styles (higher priority than setters) ? > > Long version: > > In JavaFX 21, I did a fix (see #1072) to solve a problem where > a CSS value could be reset on an unrelated control. > > This happened when the CSS engine encountered a stylable that > is overridden by the user (with a setter), and decided NOT to > proceed with the full CSS value calculation (as it could not > override the user setting if that CSS value had lower > priority).? However, not proceeding with the calculation meant > that a "SKIP" was stored in a shared cache which was > incorrect.? This is because when this "SKIP" is later > encountered for an unrelated control (the cache entries are > shared for controls with the same styles at the same level), > they could get their values reset because they were assumed to > be unstyled. > > However, this fix has exposed what seems to be a deeper bug or > perhaps an unfortunate default: > > JavaFX has a special feature where you can refer to certain > other styles by using a reference (which is resolved, > recursively, to a final value).? This does not seem to be a > CSS standard, but is a feature only FX has. > > It works by saying something like: > > ??? -fx-base: RED; > > And then using it like this: > > ??? -fx-text-fill: -fx-base; > > This feature works accross stylesheets of different origins, > so an AUTHOR stylesheet can specify -fx-base, and when a > USER_AGENT refers to -fx-base, the value comes from the AUTHOR > stylesheet. > > JavaFX then changes the origin of the style to the highest > priority encountered while resolving the reference.? This > means that Modena can specify "-fx-text-fill: -fx-base", and > when "-fx-base" is then part of the AUTHOR style sheet, that > ALL Modena styles that use -fx-base will be considered AUTHOR > level styles, as per this comment: > > // The origin of this parsed value is the greatest of > > // any of the resolved reference. If a resolved reference > > // comes from an inline style, for example, then the value > > // calculated from the resolved lookup should have inline > > // as its origin. Otherwise, an inline style could be > > // stored in shared cache. > > I feel that this is a really unfortunate choice.? The style > after all was specified by Modena, only its value came from > another (higher priority) style sheet.? I think a more logical > choice would have been to not change the priority at all, > unless a "-fx-text-fill" is explicitly made part of the AUTHOR > stylesheet. > > A consequence of this (and which is much more visible after > the fix) is that creating a Label with a > setTextFill(Color.YELLOW) in its constructor will only result > in a yellow text fill if the AUTHOR stylesheet did not > override any of the Modena colors involved in calculating the > Modena -fx-text-fill default.? Overriding -fx-base in any way > will result in the text fill of the label to be overridden (as > the reference came from an AUTHOR stylesheet, which trumps a > setter which is of a lower style origin). > > The comment also alludes to a potential problem.? If an inline > style would specify "-fx-base", but would be treated as if it > came from Modena (USER_AGENT level), then this value could get > stored in the cache as everything except INLINE styles can be > cached.? However, I feel that the changing of style origin > level was then probably done to solve a CACHING problem, > instead of what made logical sense for users. If we agree that > a resolved reference should not change the style origin level, > then this would need to be addressed, by perhaps marking such > a calculated value as uncacheable, instead of overloading the > meaning of style origin. > > I'd like to hear your thoughts, and also how to proceed.? > JavaFX versions before 21 seemingly allowed overriding > reference without much consequence because if the user > overrode the value manually, the cache entry would be set to > "SKIP".? Now that this is no longer the case, JavaFX more > aggressively overrides user set values if they happen to use a > referenced value.? See code below. > > --John > > .root { > > -fx-base: #ff0000; > > } > > *package*app; > > *import*javafx.application.Application; > > *import*javafx.scene.Scene; > > *import*javafx.scene.control.Label; > > *import*javafx.scene.paint.Color; > > *import*javafx.stage.Stage; > > *public**class*TestApp *extends*Application { > > *public**static**void*main(String[] args) { > > /launch/(args); > > } > > @Override > > *public**void*start(Stage primaryStage) { > > Scene scene = *new*Scene(*new*MyLabel()); > > // See the difference with/without -fx-base in the _stylesheet_ > > scene.getStylesheets().add(TestApp.*class*.getResource("/style.css").toExternalForm()); > > primaryStage.setScene(scene); > > primaryStage.show(); > > } > > } > > *class*MyLabel *extends*Label { > > *public*MyLabel() { > > setTextFill(Color.YELLOW); > > setText("Hello world"); > > } > > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Tue Jul 9 17:46:54 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 19:46:54 +0200 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: Then I can't explain why it doesn't fail on Gradle; it must be generating similar named classes then, but perhaps at a different location (not on encfs) ?. --John On 09/07/2024 19:35, Andy Goryachev wrote: > > Anonymous classes are named $1.? Nested classes retain their name. > > From the ticket: > > https://bugs.openjdk.org/browse/JDK-8334497 > > Could not delete: > /home/ag/Projects/jfx-2/jfx/rt/modules/javafx.base/testbin/test/javafx/beans/value/ObservableValueFluentBindingsTest$When_flatMap_Called$WithNotNullReturns_ObservableValue_Which$WhenObservedForInvalidations$AndWhenUnobserved.class. > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 10:31 > *To: *Andy Goryachev , Johan Vos > , openjfx-dev > *Subject: *Re: [External] : Re: consistent naming for tests > > Perhaps it is something Eclipse does differently. Normally nested > classed are numbered ($1, $2), so perhaps ecj is compiling these with > differently filenames. > > --John > > On 09/07/2024 17:37, Andy Goryachev wrote: > > Have you tried building in Eclipse on the latest Linux Mint?? Or > building on an EncFS mount? > > I don't know why Mint decided to use EncFS knowing its issues, and > I suppose I can try fixing my setup (it's a default Mint > installation), but I was quite surprised myself and thought that > it might be just as easy to fix the tests... here is how the fix > might look: > > https://github.com/andy-goryachev-oracle/jfx/pull/9 > > > -andy > > *From: *John Hendrikx > > *Date: *Tuesday, July 9, 2024 at 08:22 > *To: *Andy Goryachev > , Johan Vos > , > openjfx-dev > *Subject: *[External] : Re: consistent naming for tests > > On 09/07/2024 16:52, Andy Goryachev wrote: > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > I admit I have a weird setup (EncFS on Linux Mint running on > MacBook Pro), and it only manifests itself in Eclipse and not > in the gradle build - perhaps Eclipse actually verifies the > removal of files? > > Anyway, a suggestion - if you use @Nested, please keep the > class names /short/. > > This is not an Eclipse bug as I never encounter such issues.? 143 > characters is rather short these days, but I suppose we could > limit the nesting a bit.? Still, I'd look into a way to alleviate > this problem in your setup, sooner or later this is going to be a > problem. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 17:50:54 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 17:50:54 +0000 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: or gradle may not be verifying that the file is actually deleted. Eclipse allows for online replacement (? or whatever that feature is called when it can recompile and replace classes in a running vm), so perhaps it is more diligent when it comes to deleting. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:47 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: Re: [External] : Re: consistent naming for tests Then I can't explain why it doesn't fail on Gradle; it must be generating similar named classes then, but perhaps at a different location (not on encfs) ?. --John On 09/07/2024 19:35, Andy Goryachev wrote: Anonymous classes are named $1. Nested classes retain their name. >From the ticket: https://bugs.openjdk.org/browse/JDK-8334497 Could not delete: /home/ag/Projects/jfx-2/jfx/rt/modules/javafx.base/testbin/test/javafx/beans/value/ObservableValueFluentBindingsTest$When_flatMap_Called$WithNotNullReturns_ObservableValue_Which$WhenObservedForInvalidations$AndWhenUnobserved.class. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:31 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: Re: [External] : Re: consistent naming for tests Perhaps it is something Eclipse does differently. Normally nested classed are numbered ($1, $2), so perhaps ecj is compiling these with differently filenames. --John On 09/07/2024 17:37, Andy Goryachev wrote: Have you tried building in Eclipse on the latest Linux Mint? Or building on an EncFS mount? I don't know why Mint decided to use EncFS knowing its issues, and I suppose I can try fixing my setup (it's a default Mint installation), but I was quite surprised myself and thought that it might be just as easy to fix the tests... here is how the fix might look: https://github.com/andy-goryachev-oracle/jfx/pull/9 -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:22 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: [External] : Re: consistent naming for tests On 09/07/2024 16:52, Andy Goryachev wrote: Two test files consistently generate an error in Eclipse - ObservableValueFluentBindingsTest - LazyObjectBindingTest I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), and it only manifests itself in Eclipse and not in the gradle build - perhaps Eclipse actually verifies the removal of files? Anyway, a suggestion - if you use @Nested, please keep the class names short. This is not an Eclipse bug as I never encounter such issues. 143 characters is rather short these days, but I suppose we could limit the nesting a bit. Still, I'd look into a way to alleviate this problem in your setup, sooner or later this is going to be a problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue Jul 9 17:56:33 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 17:56:33 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v4] In-Reply-To: References: Message-ID: > Moves `SimpleSelector` and `CompoundSelector` to internal packages. > > This can be done with only a minor API break, as `SimpleSelector` and `CompoundSelector` were public before. However, these classes could not be constructed by 3rd parties. The only way to access them was by doing a cast (generally they're accessed via `Selector` not by their sub types). The reason they were public at all was because the CSS engine needs to be able to access them from internal packages. > > This change fixes a mistake (or possibly something that couldn't be modelled at the time) when the CSS API was first made public. The intention was always to have a `Selector` interface/abstract class, with private implementations (`SimpleSelector` and `CompoundSelector`). > > This PR as said has a small API break. The other changes are (AFAICS) source and binary compatible: > > - Made `Selector` `sealed` only permitting `SimpleSelector` and `CompoundSelector` -- as `Selector` had a package private constructor, there are no concerns with pre-existing subclasses > - `Selector` has a few more methods that are now `protected` -- given that the class is now sealed, these modified methods are not accessible (they may still require rudimentary documentation I suppose) > - `Selector` now has a `public` default constructor -- as the class is sealed, it is inaccessible > - `SimpleSelector` and `CompoundSelector` have a few more `public` methods, but they're internal now, so it is irrelevant > - `createMatch` was implemented directly in `Selector` to avoid having to expose package private fields in `Match` for use by `CompoundSelector` > - No need anymore for the `SimpleSelectorShim` John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1333/files - new: https://git.openjdk.org/jfx/pull/1333/files/e177ef16..4702972d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1333&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1333.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1333/head:pull/1333 PR: https://git.openjdk.org/jfx/pull/1333 From andy.goryachev at oracle.com Tue Jul 9 18:00:11 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 18:00:11 +0000 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> Message-ID: 1) a buggy implementation coupled with lack of specification creates a certain expectation 2) bug gets fixed 3) people complain because the feature now works as it should? I think (and this is my personal opinion, in the absence of a formal specification) that this works as expected now. The statement " Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:45 To: Andy Goryachev , openjfx-dev Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Well, it is coming as a surprise to many. With the fix for the CSS caching bug since JavaFX 21, this "normal" behavior is becoming much more obvious. Let me repeat one more time: If I have a Label, and I manually set its text fill with a setter to YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. Now do this in JavaFX 21. As soon as you add the stylesheet with `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even though technically this value for -fx-text-fill is defined by Modena (which should not be overriding set values). Nowhere did we **actualy** override -fx-text-fill, yet the CSS subsystem now sees **all** values defined by Modena that are somehow linked to -fx-base as defined directly by the developer... The reason this didn't happen in JavaFX prior to 21 is because there was a bug where a CSS value was not fully calculated if the property it encountered was overridden via a set value. That was a bug however as cache entries are shared amongst similar styled nodes, and so not calculating it fully could have effects on other nodes that shared that cache entry but did NOT have a property set directly. Now that this bug is fixed, this problem is odd behavior is popping up where simply specifying -fx-base in an empty stylesheet is somehow overriding a programmatically set text fill. Users are confused by this, as nowhere in their stylesheet do they themselves override text fill. This entire mechanism is not specified by CSS, but is unique to FX. The most similar mechanism in CSS (see Michael's answer) says the priority of a style should not be changed when it is using a reference. --John On 09/07/2024 17:43, Andy Goryachev wrote: > all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority I think it works as designed (and as expected). -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:25 To: Andy Goryachev , openjfx-dev Subject: [External] : Re: CSS Lookups and their origins (possible regression) It's not that you can't use -fx-base, but that as it is currently that all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority (above setters) even though you didn't specifically specify them in your own stylesheet. All such styles are being elevated from USER_AGENT to AUTHOR level (which is above USER level which is used for setters). --John On 09/07/2024 17:03, Andy Goryachev wrote: I've used this feature in the past to change the colors in all the controls, so to me this is the expected behavior. So in your case (if I got it right), you need to set the direct style on the label (.setStyle("-fx-text-fill:yellow")) instead of setting the text fill programmatically. Right? -andy From: openjfx-dev on behalf of John Hendrikx Date: Monday, July 8, 2024 at 17:11 To: openjfx-dev Subject: Re: CSS Lookups and their origins (possible regression) I realized I worded the TLDR poorly. Let me try again: TLDR; should styles which use references (like -fx-base used in Modena) become AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR level, as if you specified them directly... --John On 09/07/2024 02:07, John Hendrikx wrote: Hi List, TLDR; should a CSS reference like -fx-base convert all styles that use this value (or derive from it) become AUTHOR level styles (higher priority than setters) ? Long version: In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value could be reset on an unrelated control. This happened when the CSS engine encountered a stylable that is overridden by the user (with a setter), and decided NOT to proceed with the full CSS value calculation (as it could not override the user setting if that CSS value had lower priority). However, not proceeding with the calculation meant that a "SKIP" was stored in a shared cache which was incorrect. This is because when this "SKIP" is later encountered for an unrelated control (the cache entries are shared for controls with the same styles at the same level), they could get their values reset because they were assumed to be unstyled. However, this fix has exposed what seems to be a deeper bug or perhaps an unfortunate default: JavaFX has a special feature where you can refer to certain other styles by using a reference (which is resolved, recursively, to a final value). This does not seem to be a CSS standard, but is a feature only FX has. It works by saying something like: -fx-base: RED; And then using it like this: -fx-text-fill: -fx-base; This feature works accross stylesheets of different origins, so an AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT refers to -fx-base, the value comes from the AUTHOR stylesheet. JavaFX then changes the origin of the style to the highest priority encountered while resolving the reference. This means that Modena can specify "-fx-text-fill: -fx-base", and when "-fx-base" is then part of the AUTHOR style sheet, that ALL Modena styles that use -fx-base will be considered AUTHOR level styles, as per this comment: // The origin of this parsed value is the greatest of // any of the resolved reference. If a resolved reference // comes from an inline style, for example, then the value // calculated from the resolved lookup should have inline // as its origin. Otherwise, an inline style could be // stored in shared cache. I feel that this is a really unfortunate choice. The style after all was specified by Modena, only its value came from another (higher priority) style sheet. I think a more logical choice would have been to not change the priority at all, unless a "-fx-text-fill" is explicitly made part of the AUTHOR stylesheet. A consequence of this (and which is much more visible after the fix) is that creating a Label with a setTextFill(Color.YELLOW) in its constructor will only result in a yellow text fill if the AUTHOR stylesheet did not override any of the Modena colors involved in calculating the Modena -fx-text-fill default. Overriding -fx-base in any way will result in the text fill of the label to be overridden (as the reference came from an AUTHOR stylesheet, which trumps a setter which is of a lower style origin). The comment also alludes to a potential problem. If an inline style would specify "-fx-base", but would be treated as if it came from Modena (USER_AGENT level), then this value could get stored in the cache as everything except INLINE styles can be cached. However, I feel that the changing of style origin level was then probably done to solve a CACHING problem, instead of what made logical sense for users. If we agree that a resolved reference should not change the style origin level, then this would need to be addressed, by perhaps marking such a calculated value as uncacheable, instead of overloading the meaning of style origin. I'd like to hear your thoughts, and also how to proceed. JavaFX versions before 21 seemingly allowed overriding reference without much consequence because if the user overrode the value manually, the cache entry would be set to "SKIP". Now that this is no longer the case, JavaFX more aggressively overrides user set values if they happen to use a referenced value. See code below. --John .root { -fx-base: #ff0000; } package app; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.paint.Color; import javafx.stage.Stage; public class TestApp extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { Scene scene = new Scene(new MyLabel()); // See the difference with/without -fx-base in the stylesheet scene.getStylesheets().add(TestApp.class.getResource("/style.css").toExternalForm()); primaryStage.setScene(scene); primaryStage.show(); } } class MyLabel extends Label { public MyLabel() { setTextFill(Color.YELLOW); setText("Hello world"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhendrikx at openjdk.org Tue Jul 9 18:01:22 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 9 Jul 2024 18:01:22 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v4] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 17:32:29 GMT, Andy Goryachev wrote: >> I missed something in my above evaluation. The counterpart method `writeBinary` is not `static`. Although that makes sense as in that case you do have an instance you wish to write, it does make the read/write API asymmetric. >> >> It's not possible to make `readBinary` an instance method though as it is the method that is creating those instances. >> >> The other way around is possible (make `writeBinary` static), but it would then again need a pattern match to determine the correct static `writeBinary` to call when writing an arbitrary `Selector`. However, this would have allowed `CompoundSelector` to call a static version of `SimpleSelector#writeBinary` and `readBinary`, avoiding the extra identifying byte in the binary format, and avoiding the cast when reading it back. >> >> The read/write loops below: >> >> + >> final int nSelectors = is.readShort(); >> final List selectors = new ArrayList<>(); >> for (int n=0; n> selectors.add((SimpleSelector)Selector.readBinary(bssVersion, is,strings)); >> } >> + >> os.writeShort(selectors.size()); // writes the number of SimpleSelectors to the binary stream >> for (int n=0; n< selectors.size(); n++) selectors.get(n).writeBinary(os,stringStore); // writes each individually >> >> Would then have become: >> >> + >> final int nSelectors = is.readShort(); >> final List selectors = new ArrayList<>(); >> for (int n=0; n> selectors.add(SimpleSelector.readBinary(bssVersion, is,strings)); // cast is gone >> } >> + >> os.writeShort(selectors.size()); // writes the number of SimpleSelectors to the binary stream >> for (int n=0; n< selectors.size(); n++) SimpleSelector.writeBinaryStatic(selectors.get(n), os, stringStore); // writes each individually > > it looks to me readBinary should be static, and writeBinary an instance method - this is a normal pattern. the asymmetry is dictated by the fact that we don't have an instance when reading, so typically read() methods read the stream and create an instance at the last moment with the specific constructor. unless, of course, the design allows for mutation and the fields can be set(). > > Alternatively, readBinary() could be moved to another class (helper? reader?) to avoid making this an API change. > > what do you think? I can see if I can externalize this or if that would run into issues. Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API. In other words, this could wait and be done separately or never. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670949974 From john.hendrikx at gmail.com Tue Jul 9 18:04:38 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 20:04:38 +0200 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> Message-ID: <7968d2a4-d5ea-92ad-7d0f-0840ed16d997@gmail.com> Perhaps, and I guess we're lucky the classes don't fully overlap then... if encfs just cuts off too long names when reading/writing, then as long as the filename is still unique enough that is going to work.? As soon as two file names would overlap, they would overwrite each other and there's no way that the code would still work then. I doubt however this is reasonable to fix in Eclipse; the filesystem is not behaving correctly -- encfs should error out instead of silently truncating too long names. --John On 09/07/2024 19:50, Andy Goryachev wrote: > > or gradle may not be verifying that the file is actually deleted. > > Eclipse allows for online replacement (? or whatever that feature is > called when it can recompile and replace classes in a running vm), so > perhaps it is more diligent when it comes to deleting. > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 10:47 > *To: *Andy Goryachev , Johan Vos > , openjfx-dev > *Subject: *Re: [External] : Re: consistent naming for tests > > Then I can't explain why it doesn't fail on Gradle; it must be > generating similar named classes then, but perhaps at a different > location (not on encfs) ?. > > --John > > On 09/07/2024 19:35, Andy Goryachev wrote: > > Anonymous classes are named $1. Nested classes retain their name. > > From the ticket: > > https://bugs.openjdk.org/browse/JDK-8334497 > > Could not delete: > /home/ag/Projects/jfx-2/jfx/rt/modules/javafx.base/testbin/test/javafx/beans/value/ObservableValueFluentBindingsTest$When_flatMap_Called$WithNotNullReturns_ObservableValue_Which$WhenObservedForInvalidations$AndWhenUnobserved.class. > > -andy > > *From: *John Hendrikx > > *Date: *Tuesday, July 9, 2024 at 10:31 > *To: *Andy Goryachev > , Johan Vos > , > openjfx-dev > *Subject: *Re: [External] : Re: consistent naming for tests > > Perhaps it is something Eclipse does differently.? Normally nested > classed are numbered ($1, $2), so perhaps ecj is compiling these > with differently filenames. > > --John > > On 09/07/2024 17:37, Andy Goryachev wrote: > > Have you tried building in Eclipse on the latest Linux Mint?? > Or building on an EncFS mount? > > I don't know why Mint decided to use EncFS knowing its issues, > and I suppose I can try fixing my setup (it's a default Mint > installation), but I was quite surprised myself and thought > that it might be just as easy to fix the tests... here is how > the fix might look: > > https://github.com/andy-goryachev-oracle/jfx/pull/9 > > > -andy > > *From: *John Hendrikx > > *Date: *Tuesday, July 9, 2024 at 08:22 > *To: *Andy Goryachev > , Johan Vos > , > openjfx-dev > > *Subject: *[External] : Re: consistent naming for tests > > On 09/07/2024 16:52, Andy Goryachev wrote: > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > I admit I have a weird setup (EncFS on Linux Mint running > on MacBook Pro), and it only manifests itself in Eclipse > and not in the gradle build - perhaps Eclipse actually > verifies the removal of files? > > Anyway, a suggestion - if you use @Nested, please keep the > class names /short/. > > This is not an Eclipse bug as I never encounter such issues.? > 143 characters is rather short these days, but I suppose we > could limit the nesting a bit.? Still, I'd look into a way to > alleviate this problem in your setup, sooner or later this is > going to be a problem. > > --John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Jul 9 18:09:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 9 Jul 2024 18:09:21 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v4] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 17:58:30 GMT, John Hendrikx wrote: >> it looks to me readBinary should be static, and writeBinary an instance method - this is a normal pattern. the asymmetry is dictated by the fact that we don't have an instance when reading, so typically read() methods read the stream and create an instance at the last moment with the specific constructor. unless, of course, the design allows for mutation and the fields can be set(). >> >> Alternatively, readBinary() could be moved to another class (helper? reader?) to avoid making this an API change. >> >> what do you think? > > I can see if I can externalize this or if that would run into issues. Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API. > > In other words, this could wait and be done separately or never. moving it to an internal class would eliminate the public API. I agree with you that the risk is rather low because because the probability of people ever touching these classes is nearly zero. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670959871 From andy.goryachev at oracle.com Tue Jul 9 18:09:28 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 18:09:28 +0000 Subject: [External] : Re: consistent naming for tests In-Reply-To: <7968d2a4-d5ea-92ad-7d0f-0840ed16d997@gmail.com> References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <7968d2a4-d5ea-92ad-7d0f-0840ed16d997@gmail.com> Message-ID: I wonder what other filesystems do? I just want our code to compile in Eclipse on Linux Mint. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 11:04 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: Re: [External] : Re: consistent naming for tests Perhaps, and I guess we're lucky the classes don't fully overlap then... if encfs just cuts off too long names when reading/writing, then as long as the filename is still unique enough that is going to work. As soon as two file names would overlap, they would overwrite each other and there's no way that the code would still work then. I doubt however this is reasonable to fix in Eclipse; the filesystem is not behaving correctly -- encfs should error out instead of silently truncating too long names. --John On 09/07/2024 19:50, Andy Goryachev wrote: or gradle may not be verifying that the file is actually deleted. Eclipse allows for online replacement (? or whatever that feature is called when it can recompile and replace classes in a running vm), so perhaps it is more diligent when it comes to deleting. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:47 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: Re: [External] : Re: consistent naming for tests Then I can't explain why it doesn't fail on Gradle; it must be generating similar named classes then, but perhaps at a different location (not on encfs) ?. --John On 09/07/2024 19:35, Andy Goryachev wrote: Anonymous classes are named $1. Nested classes retain their name. >From the ticket: https://bugs.openjdk.org/browse/JDK-8334497 Could not delete: /home/ag/Projects/jfx-2/jfx/rt/modules/javafx.base/testbin/test/javafx/beans/value/ObservableValueFluentBindingsTest$When_flatMap_Called$WithNotNullReturns_ObservableValue_Which$WhenObservedForInvalidations$AndWhenUnobserved.class. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:31 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: Re: [External] : Re: consistent naming for tests Perhaps it is something Eclipse does differently. Normally nested classed are numbered ($1, $2), so perhaps ecj is compiling these with differently filenames. --John On 09/07/2024 17:37, Andy Goryachev wrote: Have you tried building in Eclipse on the latest Linux Mint? Or building on an EncFS mount? I don't know why Mint decided to use EncFS knowing its issues, and I suppose I can try fixing my setup (it's a default Mint installation), but I was quite surprised myself and thought that it might be just as easy to fix the tests... here is how the fix might look: https://github.com/andy-goryachev-oracle/jfx/pull/9 -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:22 To: Andy Goryachev , Johan Vos , openjfx-dev Subject: [External] : Re: consistent naming for tests On 09/07/2024 16:52, Andy Goryachev wrote: Two test files consistently generate an error in Eclipse - ObservableValueFluentBindingsTest - LazyObjectBindingTest I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), and it only manifests itself in Eclipse and not in the gradle build - perhaps Eclipse actually verifies the removal of files? Anyway, a suggestion - if you use @Nested, please keep the class names short. This is not an Eclipse bug as I never encounter such issues. 143 characters is rather short these days, but I suppose we could limit the nesting a bit. Still, I'd look into a way to alleviate this problem in your setup, sooner or later this is going to be a problem. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jul 9 18:18:22 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 9 Jul 2024 18:18:22 GMT Subject: RFR: 8323706: Remove SimpleSelector and CompoundSelector classes [v4] In-Reply-To: References: Message-ID: <1zDUx128qH7bAlDa7OogDREycm4Md1SB5oQY-zAO4Lc=.405c65ac-e380-4d23-80c5-67b44c153509@github.com> On Tue, 9 Jul 2024 18:06:55 GMT, Andy Goryachev wrote: >> I can see if I can externalize this or if that would run into issues. Also please note, although technically an API change, it is NOT an accessible API (and so can be removed at any time) because only the permitted types can access this API. >> >> In other words, this could wait and be done separately or never. > > moving it to an internal class would eliminate the public API. > > I agree with you that the risk is rather low because because the probability of people ever touching these classes is nearly zero. I am fine with either approach. If it is easy, you can move it now, but there are no compatibility concerns with doing it later since a protected method of a sealed class without any exported subclasses is not accessible. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1333#discussion_r1670971671 From john.hendrikx at gmail.com Tue Jul 9 18:21:28 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 9 Jul 2024 20:21:28 +0200 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> Message-ID: <22719829-feea-1556-5d1e-07e3d92b9805@gmail.com> Hi Andy, I'm confused, nowhere do I propose to remove or otherwise make the CSS reference system implemented by FX unusable. I'm first trying to ascertain if this would be expected behavior (it is indeed unspecified, and the default currently seems to have been chosen for implementation ease, not for user friendliness). **IF** we're considering this worth changing, the change would simply be that when you override a variable (like -fx-base) that this is done WITHOUT elevating all styles that use it to the level of an AUTHOR stylesheet (ie. they remain at USER_AGENT level as they're specified by Modena).? This is not a bad view, because in a sense, we're not really specifying a style, we're only overriding a variable.? The actual style is still specified in Modena, which is a USER_AGENT level stylesheet. As for the bug fix, please read up a bit more on what was fixed, and what this is now exposing.? The fix is almost completely unrelated (it fixed accidental changes to unrelated controls at the same level (ie. siblings) due to cache sharing where one has had a programmatic change, and the other didn't).? This was caused by a CSS calculation bug (calculation was skipped for all styleable properties that already had a setter change, if they were encountered first by the CSS system).? Now that this isn't the case anymore, set values are overwritten with CSS styles more aggressively.? Normally those however are only styles that originate from an AUTHOR stylesheet, so this can be seen as expected by the user (after all, they WROTE that stylesheet).? But because all styles that use a variable are being promoted to AUTHOR level, this also includes all unseen styles in Modena if you specify the variable in your AUTHOR stylesheet. > Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. That really depends on your view point.? Is overriding a variable the same as defining all styles (in your AUTHOR stylesheet) that use that variable?? If it was a pre-processor, that created a fully resolved Modena.css, then this would not be the case.? But it is not implemented as such. > And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. To be clear, I'm not proposing to change that at all. --John On 09/07/2024 20:00, Andy Goryachev wrote: > > 1) a buggy implementation coupled with lack of specification creates a > certain expectation > > 2) bug gets fixed > > 3) people complain because the feature now works as it should? > > I think (and this is my personal opinion, in the absence of a formal > specification) that this works as expected now.? The statement " > Nowhere did we **actualy** override -fx-text-fill" is not technically > correct since this color depends on -fx-base. > > And I would not want to change how it works currently because this is > the only way (short of overwriting the whole modena.css styleshseet) > for an application to effect a system-wide change like reacting to > changes in the user preferences or the platform theme. > > -andy > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 10:45 > *To: *Andy Goryachev , openjfx-dev > > *Subject: *Re: [External] : Re: CSS Lookups and their origins > (possible regression) > > Well, it is coming as a surprise to many. With the fix for the CSS > caching bug since JavaFX 21, this "normal" behavior is becoming much > more obvious. > > Let me repeat one more time: > > If I have a Label, and I manually set its text fill with a setter to > YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside > from `-fx-base: WHITE`, the label's text fill stays YELLOW. > > Now do this in JavaFX 21.? As soon as you add the stylesheet with > `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even > though technically this value for -fx-text-fill is defined by Modena > (which should not be overriding set values).? Nowhere did we > **actualy** override -fx-text-fill, yet the CSS subsystem now sees > **all** values defined by Modena that are somehow linked to -fx-base > as defined directly by the developer... > > The reason this didn't happen in JavaFX prior to 21 is because there > was a bug where a CSS value was not fully calculated if the property > it encountered was overridden via a set value. That was a bug however > as cache entries are shared amongst similar styled nodes, and so not > calculating it fully could have effects on other nodes that shared > that cache entry but did NOT have a property set directly.? Now that > this bug is fixed, this problem is odd behavior is popping up where > simply specifying -fx-base in an empty stylesheet is somehow > overriding a programmatically set text fill.? Users are confused by > this, as nowhere in their stylesheet do they themselves override text > fill. > > This entire mechanism is not specified by CSS, but is unique to FX.? > The most similar mechanism in CSS (see Michael's answer) says the > priority of a style should not be changed when it is using a reference. > > --John > > On 09/07/2024 17:43, Andy Goryachev wrote: > > > all styles used in Modena that rely on -fx-base directly or > indirectly suddenly have a higher priority > > I think it works as designed (and as expected). > > -andy > > *From: *John Hendrikx > > *Date: *Tuesday, July 9, 2024 at 08:25 > *To: *Andy Goryachev > , openjfx-dev > > *Subject: *[External] : Re: CSS Lookups and their origins > (possible regression) > > It's not that you can't use -fx-base, but that as it is currently > that all styles used in Modena that rely on -fx-base directly or > indirectly suddenly have a higher priority (above setters) even > though you didn't specifically specify them in your own > stylesheet.? All such styles are being elevated from USER_AGENT to > AUTHOR level (which is above USER level which is used for setters). > > --John > > On 09/07/2024 17:03, Andy Goryachev wrote: > > I've used this feature in the past to change the colors in all > the controls, so to me this is the expected behavior. > > So in your case (if I got it right), you need to set the > direct style on the label (.setStyle("-fx-text-fill:yellow")) > instead of setting the text fill programmatically.? Right? > > -andy > > *From: *openjfx-dev > on behalf of John > Hendrikx > > *Date: *Monday, July 8, 2024 at 17:11 > *To: *openjfx-dev > > *Subject: *Re: CSS Lookups and their origins (possible regression) > > I realized I worded the TLDR poorly. > > Let me try again: > > TLDR; should styles which use references (like -fx-base used > in Modena) become AUTHOR level styles if -fx-base is specified > in an AUTHOR stylesheet?? The act of simply specifying > -fx-base in your own AUTHOR stylesheet elevates hundreds of > styles from Modena to AUTHOR level, as if you specified them > directly... > > --John > > On 09/07/2024 02:07, John Hendrikx wrote: > > Hi List, > > TLDR; should a CSS reference like -fx-base convert all > styles that use this value (or derive from it) become > AUTHOR level styles (higher priority than setters) ? > > Long version: > > In JavaFX 21, I did a fix (see #1072) to solve a problem > where a CSS value could be reset on an unrelated control. > > This happened when the CSS engine encountered a stylable > that is overridden by the user (with a setter), and > decided NOT to proceed with the full CSS value calculation > (as it could not override the user setting if that CSS > value had lower priority).? However, not proceeding with > the calculation meant that a "SKIP" was stored in a shared > cache which was incorrect.? This is because when this > "SKIP" is later encountered for an unrelated control (the > cache entries are shared for controls with the same styles > at the same level), they could get their values reset > because they were assumed to be unstyled. > > However, this fix has exposed what seems to be a deeper > bug or perhaps an unfortunate default: > > JavaFX has a special feature where you can refer to > certain other styles by using a reference (which is > resolved, recursively, to a final value).? This does not > seem to be a CSS standard, but is a feature only FX has. > > It works by saying something like: > > ??? -fx-base: RED; > > And then using it like this: > > ??? -fx-text-fill: -fx-base; > > This feature works accross stylesheets of different > origins, so an AUTHOR stylesheet can specify -fx-base, and > when a USER_AGENT refers to -fx-base, the value comes from > the AUTHOR stylesheet. > > JavaFX then changes the origin of the style to the highest > priority encountered while resolving the reference.? This > means that Modena can specify "-fx-text-fill: -fx-base", > and when "-fx-base" is then part of the AUTHOR style > sheet, that ALL Modena styles that use -fx-base will be > considered AUTHOR level styles, as per this comment: > > // The origin of this parsed value is the greatest of > > // any of the resolved reference. If a resolved reference > > // comes from an inline style, for example, then the value > > // calculated from the resolved lookup should have inline > > // as its origin. Otherwise, an inline style could be > > // stored in shared cache. > > I feel that this is a really unfortunate choice.? The > style after all was specified by Modena, only its value > came from another (higher priority) style sheet.? I think > a more logical choice would have been to not change the > priority at all, unless a "-fx-text-fill" is explicitly > made part of the AUTHOR stylesheet. > > A consequence of this (and which is much more visible > after the fix) is that creating a Label with a > setTextFill(Color.YELLOW) in its constructor will only > result in a yellow text fill if the AUTHOR stylesheet did > not override any of the Modena colors involved in > calculating the Modena -fx-text-fill default.? Overriding > -fx-base in any way will result in the text fill of the > label to be overridden (as the reference came from an > AUTHOR stylesheet, which trumps a setter which is of a > lower style origin). > > The comment also alludes to a potential problem.? If an > inline style would specify "-fx-base", but would be > treated as if it came from Modena (USER_AGENT level), then > this value could get stored in the cache as everything > except INLINE styles can be cached.? However, I feel that > the changing of style origin level was then probably done > to solve a CACHING problem, instead of what made logical > sense for users.? If we agree that a resolved reference > should not change the style origin level, then this would > need to be addressed, by perhaps marking such a calculated > value as uncacheable, instead of overloading the meaning > of style origin. > > I'd like to hear your thoughts, and also how to proceed.? > JavaFX versions before 21 seemingly allowed overriding > reference without much consequence because if the user > overrode the value manually, the cache entry would be set > to "SKIP".? Now that this is no longer the case, JavaFX > more aggressively overrides user set values if they happen > to use a referenced value.? See code below. > > --John > > .root { > > -fx-base: #ff0000; > > } > > *package*app; > > *import*javafx.application.Application; > > *import*javafx.scene.Scene; > > *import*javafx.scene.control.Label; > > *import*javafx.scene.paint.Color; > > *import*javafx.stage.Stage; > > *public**class*TestApp *extends*Application { > > *public**static**void*main(String[] args) { > > /launch/(args); > > } > > @Override > > *public**void*start(Stage primaryStage) { > > Scene scene = *new*Scene(*new*MyLabel()); > > // See the difference with/without -fx-base in the > _stylesheet_ > > scene.getStylesheets().add(TestApp.*class*.getResource("/style.css").toExternalForm()); > > primaryStage.setScene(scene); > > primaryStage.show(); > > } > > } > > *class*MyLabel *extends*Label { > > *public*MyLabel() { > > setTextFill(Color.YELLOW); > > setText("Hello world"); > > } > > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Jul 9 18:24:20 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Jul 2024 18:24:20 GMT Subject: RFR: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl [v2] In-Reply-To: References: Message-ID: <3rYURQL4BaGiScfTtMYRUVfIVUVSW5hYoCOrufmZwx0=.39472a0e-e5c6-4691-975f-482700ae788b@github.com> On Tue, 9 Jul 2024 17:10:07 GMT, Andy Goryachev wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> const vars > > modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 70: > >> 68: jint x, jint y, jint width, jint height) { >> 69: const jint dstX = 0; >> 70: const jint dstY = 0; > > if it were up to me, I'd remove these as part of this PR. Thank you Andy, We shall revisit this later under another issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1497#discussion_r1670979183 From pedro.duquevieira at gmail.com Tue Jul 9 18:28:20 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Jul 2024 19:28:20 +0100 Subject: [External] : Re: CSS Lookups and their origins (possible regression) Message-ID: Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Tue Jul 9 18:31:21 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 9 Jul 2024 18:31:21 GMT Subject: Integrated: 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl In-Reply-To: References: Message-ID: <0yA7QcgsGdhwgmlEbVk9SZ6D4o0bCDr5NuP3Ac1-f18=.c45380b3-e1fa-4e79-99bd-71d4c2d2ed34@github.com> On Mon, 8 Jul 2024 13:39:49 GMT, Ambarish Rapte wrote: > The parameter "offset" is not validated in the 2 native methods getRGBImpl() and setRGBImpl() of com.sun.pisces.AbstractSurface (in JAbstractSurface.c). > The PR adds the "offset < 0" check to both the methods. This pull request has now been integrated. Changeset: e0fdb42b Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/e0fdb42b9fc0c09d8d7bf751f5adb9d8f07c0c4c Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8331603: Cleanup native AbstractSurface methods getRGBImpl, setRGBImpl Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1497 From andy.goryachev at oracle.com Tue Jul 9 18:36:22 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 18:36:22 +0000 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: <22719829-feea-1556-5d1e-07e3d92b9805@gmail.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> <22719829-feea-1556-5d1e-07e3d92b9805@gmail.com> Message-ID: Yes, sorry, I read it as if you were proposing to change the behavior. My mistake. I still think this is a good discussion to have. Perhaps we ought to clarify the behavior somewhere? My understanding of CSS is that it does not work as a pre-processor. Rather, it's a single set of global things where everyone can change everything at run time, using the simple set of rules to determine whose changes are on top. I think (guessing here) it works the same in WWW CSS (there is no well-defined standard there either, but that is a different story, ). I wish there was a public API to create stylesheets programmatically, bypassing the parser altogether. But this is unlikely to happen. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 11:21 To: Andy Goryachev , openjfx-dev Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi Andy, I'm confused, nowhere do I propose to remove or otherwise make the CSS reference system implemented by FX unusable. I'm first trying to ascertain if this would be expected behavior (it is indeed unspecified, and the default currently seems to have been chosen for implementation ease, not for user friendliness). **IF** we're considering this worth changing, the change would simply be that when you override a variable (like -fx-base) that this is done WITHOUT elevating all styles that use it to the level of an AUTHOR stylesheet (ie. they remain at USER_AGENT level as they're specified by Modena). This is not a bad view, because in a sense, we're not really specifying a style, we're only overriding a variable. The actual style is still specified in Modena, which is a USER_AGENT level stylesheet. As for the bug fix, please read up a bit more on what was fixed, and what this is now exposing. The fix is almost completely unrelated (it fixed accidental changes to unrelated controls at the same level (ie. siblings) due to cache sharing where one has had a programmatic change, and the other didn't). This was caused by a CSS calculation bug (calculation was skipped for all styleable properties that already had a setter change, if they were encountered first by the CSS system). Now that this isn't the case anymore, set values are overwritten with CSS styles more aggressively. Normally those however are only styles that originate from an AUTHOR stylesheet, so this can be seen as expected by the user (after all, they WROTE that stylesheet). But because all styles that use a variable are being promoted to AUTHOR level, this also includes all unseen styles in Modena if you specify the variable in your AUTHOR stylesheet. > Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. That really depends on your view point. Is overriding a variable the same as defining all styles (in your AUTHOR stylesheet) that use that variable? If it was a pre-processor, that created a fully resolved Modena.css, then this would not be the case. But it is not implemented as such. > And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. To be clear, I'm not proposing to change that at all. --John On 09/07/2024 20:00, Andy Goryachev wrote: 1) a buggy implementation coupled with lack of specification creates a certain expectation 2) bug gets fixed 3) people complain because the feature now works as it should? I think (and this is my personal opinion, in the absence of a formal specification) that this works as expected now. The statement " Nowhere did we **actualy** override -fx-text-fill " is not technically correct since this color depends on -fx-base. And I would not want to change how it works currently because this is the only way (short of overwriting the whole modena.css styleshseet) for an application to effect a system-wide change like reacting to changes in the user preferences or the platform theme. -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 10:45 To: Andy Goryachev , openjfx-dev Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Well, it is coming as a surprise to many. With the fix for the CSS caching bug since JavaFX 21, this "normal" behavior is becoming much more obvious. Let me repeat one more time: If I have a Label, and I manually set its text fill with a setter to YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. Now do this in JavaFX 21. As soon as you add the stylesheet with `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even though technically this value for -fx-text-fill is defined by Modena (which should not be overriding set values). Nowhere did we **actualy** override -fx-text-fill, yet the CSS subsystem now sees **all** values defined by Modena that are somehow linked to -fx-base as defined directly by the developer... The reason this didn't happen in JavaFX prior to 21 is because there was a bug where a CSS value was not fully calculated if the property it encountered was overridden via a set value. That was a bug however as cache entries are shared amongst similar styled nodes, and so not calculating it fully could have effects on other nodes that shared that cache entry but did NOT have a property set directly. Now that this bug is fixed, this problem is odd behavior is popping up where simply specifying -fx-base in an empty stylesheet is somehow overriding a programmatically set text fill. Users are confused by this, as nowhere in their stylesheet do they themselves override text fill. This entire mechanism is not specified by CSS, but is unique to FX. The most similar mechanism in CSS (see Michael's answer) says the priority of a style should not be changed when it is using a reference. --John On 09/07/2024 17:43, Andy Goryachev wrote: > all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority I think it works as designed (and as expected). -andy From: John Hendrikx Date: Tuesday, July 9, 2024 at 08:25 To: Andy Goryachev , openjfx-dev Subject: [External] : Re: CSS Lookups and their origins (possible regression) It's not that you can't use -fx-base, but that as it is currently that all styles used in Modena that rely on -fx-base directly or indirectly suddenly have a higher priority (above setters) even though you didn't specifically specify them in your own stylesheet. All such styles are being elevated from USER_AGENT to AUTHOR level (which is above USER level which is used for setters). --John On 09/07/2024 17:03, Andy Goryachev wrote: I've used this feature in the past to change the colors in all the controls, so to me this is the expected behavior. So in your case (if I got it right), you need to set the direct style on the label (.setStyle("-fx-text-fill:yellow")) instead of setting the text fill programmatically. Right? -andy From: openjfx-dev on behalf of John Hendrikx Date: Monday, July 8, 2024 at 17:11 To: openjfx-dev Subject: Re: CSS Lookups and their origins (possible regression) I realized I worded the TLDR poorly. Let me try again: TLDR; should styles which use references (like -fx-base used in Modena) become AUTHOR level styles if -fx-base is specified in an AUTHOR stylesheet? The act of simply specifying -fx-base in your own AUTHOR stylesheet elevates hundreds of styles from Modena to AUTHOR level, as if you specified them directly... --John On 09/07/2024 02:07, John Hendrikx wrote: Hi List, TLDR; should a CSS reference like -fx-base convert all styles that use this value (or derive from it) become AUTHOR level styles (higher priority than setters) ? Long version: In JavaFX 21, I did a fix (see #1072) to solve a problem where a CSS value could be reset on an unrelated control. This happened when the CSS engine encountered a stylable that is overridden by the user (with a setter), and decided NOT to proceed with the full CSS value calculation (as it could not override the user setting if that CSS value had lower priority). However, not proceeding with the calculation meant that a "SKIP" was stored in a shared cache which was incorrect. This is because when this "SKIP" is later encountered for an unrelated control (the cache entries are shared for controls with the same styles at the same level), they could get their values reset because they were assumed to be unstyled. However, this fix has exposed what seems to be a deeper bug or perhaps an unfortunate default: JavaFX has a special feature where you can refer to certain other styles by using a reference (which is resolved, recursively, to a final value). This does not seem to be a CSS standard, but is a feature only FX has. It works by saying something like: -fx-base: RED; And then using it like this: -fx-text-fill: -fx-base; This feature works accross stylesheets of different origins, so an AUTHOR stylesheet can specify -fx-base, and when a USER_AGENT refers to -fx-base, the value comes from the AUTHOR stylesheet. JavaFX then changes the origin of the style to the highest priority encountered while resolving the reference. This means that Modena can specify "-fx-text-fill: -fx-base", and when "-fx-base" is then part of the AUTHOR style sheet, that ALL Modena styles that use -fx-base will be considered AUTHOR level styles, as per this comment: // The origin of this parsed value is the greatest of // any of the resolved reference. If a resolved reference // comes from an inline style, for example, then the value // calculated from the resolved lookup should have inline // as its origin. Otherwise, an inline style could be // stored in shared cache. I feel that this is a really unfortunate choice. The style after all was specified by Modena, only its value came from another (higher priority) style sheet. I think a more logical choice would have been to not change the priority at all, unless a "-fx-text-fill" is explicitly made part of the AUTHOR stylesheet. A consequence of this (and which is much more visible after the fix) is that creating a Label with a setTextFill(Color.YELLOW) in its constructor will only result in a yellow text fill if the AUTHOR stylesheet did not override any of the Modena colors involved in calculating the Modena -fx-text-fill default. Overriding -fx-base in any way will result in the text fill of the label to be overridden (as the reference came from an AUTHOR stylesheet, which trumps a setter which is of a lower style origin). The comment also alludes to a potential problem. If an inline style would specify "-fx-base", but would be treated as if it came from Modena (USER_AGENT level), then this value could get stored in the cache as everything except INLINE styles can be cached. However, I feel that the changing of style origin level was then probably done to solve a CACHING problem, instead of what made logical sense for users. If we agree that a resolved reference should not change the style origin level, then this would need to be addressed, by perhaps marking such a calculated value as uncacheable, instead of overloading the meaning of style origin. I'd like to hear your thoughts, and also how to proceed. JavaFX versions before 21 seemingly allowed overriding reference without much consequence because if the user overrode the value manually, the cache entry would be set to "SKIP". Now that this is no longer the case, JavaFX more aggressively overrides user set values if they happen to use a referenced value. See code below. --John .root { -fx-base: #ff0000; } package app; import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.paint.Color; import javafx.stage.Stage; public class TestApp extends Application { public static void main(String[] args) { launch(args); } @Override public void start(Stage primaryStage) { Scene scene = new Scene(new MyLabel()); // See the difference with/without -fx-base in the stylesheet scene.getStylesheets().add(TestApp.class.getResource("/style.css").toExternalForm()); primaryStage.setScene(scene); primaryStage.show(); } } class MyLabel extends Label { public MyLabel() { setTextFill(Color.YELLOW); setText("Hello world"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 18:40:31 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 18:40:31 +0000 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: Message-ID: > That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. and this is probably the right approach. -andy From: openjfx-dev on behalf of Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 11:28 To: openjfx-dev at openjdk.org Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Tue Jul 9 19:00:02 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Jul 2024 20:00:02 +0100 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: Message-ID: >> That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40?PM Andy Goryachev wrote: > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 19:17:01 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 19:17:01 +0000 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: Message-ID: If your stylesheet defines the necessary variables, the "users" should be able to redefine them, correct? Or maybe allow for programmatic control of the stylesheet, similar to https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java Alternatively, we would need a new public API to allow you to do what you want how you want. Perhaps if you could tell us about the problem you are trying to solve, exactly, and the APIs that are missing. -andy From: Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 12:00 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) >> That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40?PM Andy Goryachev > wrote: > That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. and this is probably the right approach. -andy From: openjfx-dev > on behalf of Pedro Duque Vieira > Date: Tuesday, July 9, 2024 at 11:28 To: openjfx-dev at openjdk.org > Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Tue Jul 9 19:26:11 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Jul 2024 20:26:11 +0100 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: Message-ID: Perhaps I should have been clearer. I mentioned that example merely to make a point on how having a stylesheet set as an AUTHOR stylesheet can be a problem (Modena or a custom theme library like JMetro) :-) . It wasn't actually to create a new separate discussion. As for the other discussion not exactly related to the one in this thread (having custom themes be user agent stylesheets) I think I have found a way to make multiple stylesheets be a user agent stylesheet. That was my main problem as JMetro is composed of more than 1 stylesheet. I'm also doing it while still just using the javafx standard API. Thus far it's working except for some minor bugs (which I'm inclined to think are bugs in JavaFX itself). Thanks! On Tue, Jul 9, 2024 at 8:17?PM Andy Goryachev wrote: > If your stylesheet defines the necessary variables, the "users" should be > able to redefine them, correct? > > > > Or maybe allow for programmatic control of the stylesheet, similar to > > > https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 > > > https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java > > > > Alternatively, we would need a new public API to allow you to do what you > want how you want. Perhaps if you could tell us about the problem you are > trying to solve, exactly, and the APIs that are missing. > > > > -andy > > > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:00 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > >> That's why now in the new theme I'm creating I'm setting everything > to be an user agent stylesheet. > > > > > and this is probably the right approach. > > > > Correct. That's why I agree with John and why the current behavior is > likely undesired. :-) > > > > On Tue, Jul 9, 2024 at 7:40?PM Andy Goryachev > wrote: > > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 19:34:27 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 19:34:27 +0000 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: Message-ID: Thank you for clarification! Glad you were able to do what you wanted. But really, if there are bugs, I would rather have them filed and fixed. -andy From: Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 12:26 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Perhaps I should have been clearer. I mentioned that example merely to make a point on how having a stylesheet set as an AUTHOR stylesheet can be a problem (Modena or a custom theme library like JMetro) :-) . It wasn't actually to create a new separate discussion. As for the other discussion not exactly related to the one in this thread (having custom themes be user agent stylesheets) I think I have found a way to make multiple stylesheets be a user agent stylesheet. That was my main problem as JMetro is composed of more than 1 stylesheet. I'm also doing it while still just using the javafx standard API. Thus far it's working except for some minor bugs (which I'm inclined to think are bugs in JavaFX itself). Thanks! On Tue, Jul 9, 2024 at 8:17?PM Andy Goryachev > wrote: If your stylesheet defines the necessary variables, the "users" should be able to redefine them, correct? Or maybe allow for programmatic control of the stylesheet, similar to https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java Alternatively, we would need a new public API to allow you to do what you want how you want. Perhaps if you could tell us about the problem you are trying to solve, exactly, and the APIs that are missing. -andy From: Pedro Duque Vieira > Date: Tuesday, July 9, 2024 at 12:00 To: Andy Goryachev > Cc: openjfx-dev at openjdk.org > Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) >> That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. > and this is probably the right approach. Correct. That's why I agree with John and why the current behavior is likely undesired. :-) On Tue, Jul 9, 2024 at 7:40?PM Andy Goryachev > wrote: > That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. and this is probably the right approach. -andy From: openjfx-dev > on behalf of Pedro Duque Vieira > Date: Tuesday, July 9, 2024 at 11:28 To: openjfx-dev at openjdk.org > Subject: Re: [External] : Re: CSS Lookups and their origins (possible regression) Hi guys, I agree with John Hendrikx on this. The thing is not that you override the "css variable" value but that you end up overriding the priority of the rules in Modena which the developer won't likely want to. One other thing I'd add is that developers also like to use css themselves. If modena rules suddenly start to have the priority of AUTHOR this becomes much harder. They have to make their rules always more specific than Modena's that now have increased priority besides the fact that they need to be aware that this is actually happening and is the problem (in my experience many developers won't know this). On a related note, I created a theme called JMetro. When implementing it I made it so that it was composed of author stylesheets (there wasn't a way to set it as a user agent stylesheet back when I started). That's also how 90% of themes work. However this is an issue as developers wanting to override styles set by JMetro will have a hard time figuring out how to make their rules specificity in their CSS higher than JMetro's so they get overridden (I've had complaints on this). That's why now in the new theme I'm creating I'm setting everything to be an user agent stylesheet. Thanks, -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 20:04:21 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 20:04:21 +0000 Subject: UI elements sizing in Modena.css Message-ID: Since we touched the modena.css, I would like to ask the group's opinion on whether we should fix the way modena.css sizes UI elements. Please see https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing the font size also unexpectedly changed the scrollbar. What do you think about introducing a set of variables similar to -fx-base but for sizing/padding, placing them early on to depend on the font size in the .root selector instead of the font in the actual control? Something along the lines of .root { -fx-size-3px: 0.25em; ... } .scroll-bar:horizontal > .increment-button > .increment-arrow { -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px; } instead of .scroll-bar:horizontal > .increment-button > .increment-arrow { -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */ } This way we still permit the UI components resize with the main font, while keeping the sizes of all the control surfaces consistent? This will require a trivial change in InsetsConverter. What do you think? -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Jul 9 20:16:50 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 Jul 2024 13:16:50 -0700 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: <22719829-feea-1556-5d1e-07e3d92b9805@gmail.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> <22719829-feea-1556-5d1e-07e3d92b9805@gmail.com> Message-ID: <55d5f616-e801-438f-83b8-54f3d1997549@oracle.com> My reading of this is that the fix for the caching bug, JDK-8245919 [1] via PR #1072 [2], has inadvertently exposed previously hidden behavior that is at best an undesirable feature and at worst a bug (I'd call it a bug). It seems quite unexpected to me that overriding a variable defined in a user agent stylesheet in an? AUTHOR stylesheet would elevate all properties derived from that variable to AUTHOR stylesheet status. Assuming I'm not missing something, we ought to consider fixing this. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8245919 [2] https://github.com/openjdk/jfx/pull/1072 On 7/9/2024 11:21 AM, John Hendrikx wrote: > > Hi Andy, > > I'm confused, nowhere do I propose to remove or otherwise make the CSS > reference system implemented by FX unusable. > > I'm first trying to ascertain if this would be expected behavior (it > is indeed unspecified, and the default currently seems to have been > chosen for implementation ease, not for user friendliness). > > **IF** we're considering this worth changing, the change would simply > be that when you override a variable (like -fx-base) that this is done > WITHOUT elevating all styles that use it to the level of an AUTHOR > stylesheet (ie. they remain at USER_AGENT level as they're specified > by Modena).? This is not a bad view, because in a sense, we're not > really specifying a style, we're only overriding a variable.? The > actual style is still specified in Modena, which is a USER_AGENT level > stylesheet. > > As for the bug fix, please read up a bit more on what was fixed, and > what this is now exposing.? The fix is almost completely unrelated (it > fixed accidental changes to unrelated controls at the same level (ie. > siblings) due to cache sharing where one has had a programmatic > change, and the other didn't). This was caused by a CSS calculation > bug (calculation was skipped for all styleable properties that already > had a setter change, if they were encountered first by the CSS > system).? Now that this isn't the case anymore, set values are > overwritten with CSS styles more aggressively.? Normally those however > are only styles that originate from an AUTHOR stylesheet, so this can > be seen as expected by the user (after all, they WROTE that > stylesheet).? But because all styles that use a variable are being > promoted to AUTHOR level, this also includes all unseen styles in > Modena if you specify the variable in your AUTHOR stylesheet. > > > Nowhere did we **actualy** override -fx-text-fill " is not > technically correct since this color depends on -fx-base. > > That really depends on your view point.? Is overriding a variable the > same as defining all styles (in your AUTHOR stylesheet) that use that > variable?? If it was a pre-processor, that created a fully resolved > Modena.css, then this would not be the case.? But it is not > implemented as such. > > > And I would not want to change how it works currently because this > is the only way (short of overwriting the whole modena.css > styleshseet) for an application to effect a system-wide change like > reacting to changes in the user preferences or the platform theme. > > To be clear, I'm not proposing to change that at all. > > --John > > On 09/07/2024 20:00, Andy Goryachev wrote: >> >> 1) a buggy implementation coupled with lack of specification creates >> a certain expectation >> >> 2) bug gets fixed >> >> 3) people complain because the feature now works as it should? >> >> I think (and this is my personal opinion, in the absence of a formal >> specification) that this works as expected now.? The statement " >> Nowhere did we **actualy** override -fx-text-fill" is not technically >> correct since this color depends on -fx-base. >> >> And I would not want to change how it works currently because this is >> the only way (short of overwriting the whole modena.css styleshseet) >> for an application to effect a system-wide change like reacting to >> changes in the user preferences or the platform theme. >> >> -andy >> >> *From: *John Hendrikx >> *Date: *Tuesday, July 9, 2024 at 10:45 >> *To: *Andy Goryachev , openjfx-dev >> >> *Subject: *Re: [External] : Re: CSS Lookups and their origins >> (possible regression) >> >> Well, it is coming as a surprise to many. With the fix for the CSS >> caching bug since JavaFX 21, this "normal" behavior is becoming much >> more obvious. >> >> Let me repeat one more time: >> >> If I have a Label, and I manually set its text fill with a setter to >> YELLOW. In JavaFX 17, when I now add a stylesheet that is empty aside >> from `-fx-base: WHITE`, the label's text fill stays YELLOW. >> >> Now do this in JavaFX 21.? As soon as you add the stylesheet with >> `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even >> though technically this value for -fx-text-fill is defined by Modena >> (which should not be overriding set values).? Nowhere did we >> **actualy** override -fx-text-fill, yet the CSS subsystem now sees >> **all** values defined by Modena that are somehow linked to -fx-base >> as defined directly by the developer... >> >> The reason this didn't happen in JavaFX prior to 21 is because there >> was a bug where a CSS value was not fully calculated if the property >> it encountered was overridden via a set value. That was a bug however >> as cache entries are shared amongst similar styled nodes, and so not >> calculating it fully could have effects on other nodes that shared >> that cache entry but did NOT have a property set directly.? Now that >> this bug is fixed, this problem is odd behavior is popping up where >> simply specifying -fx-base in an empty stylesheet is somehow >> overriding a programmatically set text fill.? Users are confused by >> this, as nowhere in their stylesheet do they themselves override text >> fill. >> >> This entire mechanism is not specified by CSS, but is unique to FX.? >> The most similar mechanism in CSS (see Michael's answer) says the >> priority of a style should not be changed when it is using a reference. >> >> --John >> >> On 09/07/2024 17:43, Andy Goryachev wrote: >> >> > all styles used in Modena that rely on -fx-base directly or >> indirectly suddenly have a higher priority >> >> I think it works as designed (and as expected). >> >> -andy >> >> *From: *John Hendrikx >> >> *Date: *Tuesday, July 9, 2024 at 08:25 >> *To: *Andy Goryachev >> , openjfx-dev >> >> *Subject: *[External] : Re: CSS Lookups and their origins >> (possible regression) >> >> It's not that you can't use -fx-base, but that as it is currently >> that all styles used in Modena that rely on -fx-base directly or >> indirectly suddenly have a higher priority (above setters) even >> though you didn't specifically specify them in your own >> stylesheet.? All such styles are being elevated from USER_AGENT >> to AUTHOR level (which is above USER level which is used for >> setters). >> >> --John >> >> On 09/07/2024 17:03, Andy Goryachev wrote: >> >> I've used this feature in the past to change the colors in >> all the controls, so to me this is the expected behavior. >> >> So in your case (if I got it right), you need to set the >> direct style on the label (.setStyle("-fx-text-fill:yellow")) >> instead of setting the text fill programmatically. Right? >> >> -andy >> >> *From: *openjfx-dev >> on behalf of John >> Hendrikx >> >> *Date: *Monday, July 8, 2024 at 17:11 >> *To: *openjfx-dev >> >> *Subject: *Re: CSS Lookups and their origins (possible >> regression) >> >> I realized I worded the TLDR poorly. >> >> Let me try again: >> >> TLDR; should styles which use references (like -fx-base used >> in Modena) become AUTHOR level styles if -fx-base is >> specified in an AUTHOR stylesheet?? The act of simply >> specifying -fx-base in your own AUTHOR stylesheet elevates >> hundreds of styles from Modena to AUTHOR level, as if you >> specified them directly... >> >> --John >> >> On 09/07/2024 02:07, John Hendrikx wrote: >> >> Hi List, >> >> TLDR; should a CSS reference like -fx-base convert all >> styles that use this value (or derive from it) become >> AUTHOR level styles (higher priority than setters) ? >> >> Long version: >> >> In JavaFX 21, I did a fix (see #1072) to solve a problem >> where a CSS value could be reset on an unrelated control. >> >> This happened when the CSS engine encountered a stylable >> that is overridden by the user (with a setter), and >> decided NOT to proceed with the full CSS value >> calculation (as it could not override the user setting if >> that CSS value had lower priority).? However, not >> proceeding with the calculation meant that a "SKIP" was >> stored in a shared cache which was incorrect.? This is >> because when this "SKIP" is later encountered for an >> unrelated control (the cache entries are shared for >> controls with the same styles at the same level), they >> could get their values reset because they were assumed to >> be unstyled. >> >> However, this fix has exposed what seems to be a deeper >> bug or perhaps an unfortunate default: >> >> JavaFX has a special feature where you can refer to >> certain other styles by using a reference (which is >> resolved, recursively, to a final value).? This does not >> seem to be a CSS standard, but is a feature only FX has. >> >> It works by saying something like: >> >> ??? -fx-base: RED; >> >> And then using it like this: >> >> ??? -fx-text-fill: -fx-base; >> >> This feature works accross stylesheets of different >> origins, so an AUTHOR stylesheet can specify -fx-base, >> and when a USER_AGENT refers to -fx-base, the value comes >> from the AUTHOR stylesheet. >> >> JavaFX then changes the origin of the style to the >> highest priority encountered while resolving the >> reference.? This means that Modena can specify >> "-fx-text-fill: -fx-base", and when "-fx-base" is then >> part of the AUTHOR style sheet, that ALL Modena styles >> that use -fx-base will be considered AUTHOR level styles, >> as per this comment: >> >> // The origin of this parsed value is the greatest of >> >> // any of the resolved reference. If a resolved reference >> >> // comes from an inline style, for example, then the value >> >> // calculated from the resolved lookup should have inline >> >> // as its origin. Otherwise, an inline style could be >> >> // stored in shared cache. >> >> I feel that this is a really unfortunate choice.? The >> style after all was specified by Modena, only its value >> came from another (higher priority) style sheet.? I think >> a more logical choice would have been to not change the >> priority at all, unless a "-fx-text-fill" is explicitly >> made part of the AUTHOR stylesheet. >> >> A consequence of this (and which is much more visible >> after the fix) is that creating a Label with a >> setTextFill(Color.YELLOW) in its constructor will only >> result in a yellow text fill if the AUTHOR stylesheet did >> not override any of the Modena colors involved in >> calculating the Modena -fx-text-fill default. Overriding >> -fx-base in any way will result in the text fill of the >> label to be overridden (as the reference came from an >> AUTHOR stylesheet, which trumps a setter which is of a >> lower style origin). >> >> The comment also alludes to a potential problem.? If an >> inline style would specify "-fx-base", but would be >> treated as if it came from Modena (USER_AGENT level), >> then this value could get stored in the cache as >> everything except INLINE styles can be cached.? However, >> I feel that the changing of style origin level was then >> probably done to solve a CACHING problem, instead of what >> made logical sense for users.? If we agree that a >> resolved reference should not change the style origin >> level, then this would need to be addressed, by perhaps >> marking such a calculated value as uncacheable, instead >> of overloading the meaning of style origin. >> >> I'd like to hear your thoughts, and also how to proceed.? >> JavaFX versions before 21 seemingly allowed overriding >> reference without much consequence because if the user >> overrode the value manually, the cache entry would be set >> to "SKIP".? Now that this is no longer the case, JavaFX >> more aggressively overrides user set values if they >> happen to use a referenced value.? See code below. >> >> --John >> >> .root { >> >> -fx-base: #ff0000; >> >> } >> >> *package*app; >> >> *import*javafx.application.Application; >> >> *import*javafx.scene.Scene; >> >> *import*javafx.scene.control.Label; >> >> *import*javafx.scene.paint.Color; >> >> *import*javafx.stage.Stage; >> >> *public**class*TestApp *extends*Application { >> >> *public**static**void*main(String[] args) { >> >> /launch/(args); >> >> } >> >> @Override >> >> *public**void*start(Stage primaryStage) { >> >> Scene scene = *new*Scene(*new*MyLabel()); >> >> // See the difference with/without -fx-base in the >> _stylesheet_ >> >> scene.getStylesheets().add(TestApp.*class*.getResource("/style.css").toExternalForm()); >> >> primaryStage.setScene(scene); >> >> primaryStage.show(); >> >> } >> >> } >> >> *class*MyLabel *extends*Label { >> >> *public*MyLabel() { >> >> setTextFill(Color.YELLOW); >> >> setText("Hello world"); >> >> } >> >> } >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Tue Jul 9 21:32:32 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Jul 2024 22:32:32 +0100 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: References: Message-ID: Yes, you're right. Need to find time to file those issues. Though I want to finish the theme conversion to user agent stylesheets and then be sure it is a javafx bug. On Tue, Jul 9, 2024 at 8:34?PM Andy Goryachev wrote: > Thank you for clarification! > > > > Glad you were able to do what you wanted. But really, if there are bugs, > I would rather have them filed and fixed. > > > > -andy > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:26 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Perhaps I should have been clearer. I mentioned that example merely to > make a point on how having a stylesheet set as an AUTHOR stylesheet can be > a problem (Modena or a custom theme library like JMetro) :-) . > It wasn't actually to create a new separate discussion. > > > > As for the other discussion not exactly related to the one in this thread > (having custom themes be user agent stylesheets) I think I have found a way > to make multiple stylesheets be a user agent stylesheet. > > That was my main problem as JMetro is composed of more than 1 stylesheet. > I'm also doing it while still just using the javafx standard API. Thus far > it's working except for some minor bugs (which I'm inclined to think are > bugs in JavaFX itself). > > > > Thanks! > > > > On Tue, Jul 9, 2024 at 8:17?PM Andy Goryachev > wrote: > > If your stylesheet defines the necessary variables, the "users" should be > able to redefine them, correct? > > > > Or maybe allow for programmatic control of the stylesheet, similar to > > > https://github.com/andy-goryachev/AppFramework/blob/7f74f58ecd4de239be923c4384e10142e48ade7c/src/goryachev/fx/FxFramework.java#L31 > > > > https://github.com/andy-goryachev/AppFramework/blob/main/src/demo/appfw/Styles.java > > > > > Alternatively, we would need a new public API to allow you to do what you > want how you want. Perhaps if you could tell us about the problem you are > trying to solve, exactly, and the APIs that are missing. > > > > -andy > > > > > > > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 12:00 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > >> That's why now in the new theme I'm creating I'm setting everything > to be an user agent stylesheet. > > > > > and this is probably the right approach. > > > > Correct. That's why I agree with John and why the current behavior is > likely undesired. :-) > > > > On Tue, Jul 9, 2024 at 7:40?PM Andy Goryachev > wrote: > > > That's why now in the new theme I'm creating I'm setting everything to > be an user agent stylesheet. > > > > and this is probably the right approach. > > > > -andy > > > > > > > > *From: *openjfx-dev on behalf of Pedro > Duque Vieira > *Date: *Tuesday, July 9, 2024 at 11:28 > *To: *openjfx-dev at openjdk.org > *Subject: *Re: [External] : Re: CSS Lookups and their origins (possible > regression) > > Hi guys, > > > > I agree with John Hendrikx on this. > > > > The thing is not that you override the "css variable" value but that you > end up overriding the priority of the rules in Modena which the developer > won't likely want to. > > > > One other thing I'd add is that developers also like to use css > themselves. If modena rules suddenly start to have the priority of AUTHOR > this becomes much harder. They have to make their rules always more > specific than Modena's that now have increased priority besides the fact > that they need to be aware that this is actually happening and is the > problem (in my experience many developers won't know this). > > > > On a related note, I created a theme called JMetro. When implementing it I > made it so that it was composed of author stylesheets (there wasn't a way > to set it as a user agent stylesheet back when I started). That's also how > 90% of themes work. > > However this is an issue as developers wanting to override styles set by > JMetro will have a hard time figuring out how to make their rules > specificity in their CSS higher than JMetro's so they get overridden (I've > had complaints on this). That's why now in the new theme I'm creating I'm > setting everything to be an user agent stylesheet. > > > > Thanks, > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Tue Jul 9 22:04:18 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Jul 2024 23:04:18 +0100 Subject: UI elements sizing in Modena.css In-Reply-To: References: Message-ID: Andy, if I understand the suggestion correctly, you want to set the Modena sizes using variables that can be easily overridden. To that effect variables must first be able to hold numeric values as, as it stands today JavaFX only allows colors to be used for CSS variables. So, you're also suggesting adding the ability for CSS variables to define inset values, is that correct? I think that's a good idea. I would, however, generalize that to allow CSS variables to hold numeric values that could be used anywhere. Or at least, starting to pave the ground for that. I would go even further and start to pave ground to add the CSS variable spec into javafx css: https://codersblock.com/blog/what-can-you-put-in-a-css-variable/ Why use the css web spec? Because of the following reasons: 1 - Designers already know how to work with the css web spec 2 - there are already many tools available that work with the css web spec 3 - there are already many examples on the web using CSS so developers can just copy paste those examples 4 - Developers coming from the web can easily start using javafx css with no friction and no need to learn it Thanks On Tue, Jul 9, 2024 at 9:04?PM Andy Goryachev wrote: > Since we touched the modena.css, I would like to ask the group's opinion > on whether we should fix the way modena.css sizes UI elements. Please see > https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing > the font size also unexpectedly changed the scrollbar. > > > > What do you think about introducing a set of variables similar to -fx-base > but for sizing/padding, placing them early on to depend on the font size in > the .root selector instead of the font in the actual control? Something > along the lines of > > > > .root { > > -fx-size-3px: 0.25em; > > ... > > } > > > > .scroll-bar:horizontal > .increment-button > .increment-arrow { > > -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px; > > } > > > > instead of > > > > .scroll-bar:horizontal > .increment-button > .increment-arrow { > > -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */ > > } > > > > This way we still permit the UI components resize with the main font, > while keeping the sizes of all the control surfaces consistent? > > > > This will require a trivial change in InsetsConverter. > > > > What do you think? > > > > -andy > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.duquevieira at gmail.com Tue Jul 9 22:50:48 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Tue, 9 Jul 2024 23:50:48 +0100 Subject: UI elements sizing in Modena.css In-Reply-To: References: Message-ID: .. one more reason to use the CSS variable spec that I forgot to mention: 5 - It's a spec that has been thoroughly thought of before it was added to CSS and it has stood the test of time. On Tue, Jul 9, 2024 at 11:04?PM Pedro Duque Vieira < pedro.duquevieira at gmail.com> wrote: > Andy, if I understand the suggestion correctly, you want to set the Modena > sizes using variables that can be easily overridden. To that effect > variables must first be able to hold numeric values as, as it stands today > JavaFX only allows colors to be used for CSS variables. > So, you're also suggesting adding the ability for CSS variables to define > inset values, is that correct? > > I think that's a good idea. I would, however, generalize that to allow CSS > variables to hold numeric values that could be used anywhere. Or at least, > starting to pave the ground for that. > > I would go even further and start to pave ground to add the CSS > variable spec into javafx css: > https://codersblock.com/blog/what-can-you-put-in-a-css-variable/ > > Why use the css web spec? Because of the following reasons: > 1 - Designers already know how to work with the css web spec > 2 - there are already many tools available that work with the css web spec > 3 - there are already many examples on the web using CSS so developers can > just copy paste those examples > 4 - Developers coming from the web can easily start using javafx css with > no friction and no need to learn it > > Thanks > > > > > > On Tue, Jul 9, 2024 at 9:04?PM Andy Goryachev > wrote: > >> Since we touched the modena.css, I would like to ask the group's opinion >> on whether we should fix the way modena.css sizes UI elements. Please see >> https://bugs.openjdk.org/browse/JDK-8314683 for reference, where >> changing the font size also unexpectedly changed the scrollbar. >> >> >> >> What do you think about introducing a set of variables similar to >> -fx-base but for sizing/padding, placing them early on to depend on the >> font size in the .root selector instead of the font in the actual control? >> Something along the lines of >> >> >> >> .root { >> >> -fx-size-3px: 0.25em; >> >> ... >> >> } >> >> >> >> .scroll-bar:horizontal > .increment-button > .increment-arrow { >> >> -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px; >> >> } >> >> >> >> instead of >> >> >> >> .scroll-bar:horizontal > .increment-button > .increment-arrow { >> >> -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */ >> >> } >> >> >> >> This way we still permit the UI components resize with the main font, >> while keeping the sizes of all the control surfaces consistent? >> >> >> >> This will require a trivial change in InsetsConverter. >> >> >> >> What do you think? >> >> >> >> -andy >> > > > -- > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Jul 9 22:54:20 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 9 Jul 2024 22:54:20 +0000 Subject: [External] : Re: UI elements sizing in Modena.css In-Reply-To: References: Message-ID: Yeah, I thought that it might be possible to define properties for sizes similarly to colors, and some earlier attempts seemed to indicate that it might work. It does not, unless the sizes are fixed (e.g. -fx-size-1px: 1px; ) The real solution, as you mentioned, would be to add capability to add variables, though it is much more complex task. -andy From: Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 15:04 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: UI elements sizing in Modena.css Andy, if I understand the suggestion correctly, you want to set the Modena sizes using variables that can be easily overridden. To that effect variables must first be able to hold numeric values as, as it stands today JavaFX only allows colors to be used for CSS variables. So, you're also suggesting adding the ability for CSS variables to define inset values, is that correct? I think that's a good idea. I would, however, generalize that to allow CSS variables to hold numeric values that could be used anywhere. Or at least, starting to pave the ground for that. I would go even further and start to pave ground to add the CSS variable spec into javafx css: https://codersblock.com/blog/what-can-you-put-in-a-css-variable/ Why use the css web spec? Because of the following reasons: 1 - Designers already know how to work with the css web spec 2 - there are already many tools available that work with the css web spec 3 - there are already many examples on the web using CSS so developers can just copy paste those examples 4 - Developers coming from the web can easily start using javafx css with no friction and no need to learn it Thanks On Tue, Jul 9, 2024 at 9:04?PM Andy Goryachev > wrote: Since we touched the modena.css, I would like to ask the group's opinion on whether we should fix the way modena.css sizes UI elements. Please see https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing the font size also unexpectedly changed the scrollbar. What do you think about introducing a set of variables similar to -fx-base but for sizing/padding, placing them early on to depend on the font size in the .root selector instead of the font in the actual control? Something along the lines of .root { -fx-size-3px: 0.25em; ... } .scroll-bar:horizontal > .increment-button > .increment-arrow { -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px; } instead of .scroll-bar:horizontal > .increment-button > .increment-arrow { -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */ } This way we still permit the UI components resize with the main font, while keeping the sizes of all the control surfaces consistent? This will require a trivial change in InsetsConverter. What do you think? -andy -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Tue Jul 9 23:34:12 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Jul 2024 02:34:12 +0300 Subject: consistent naming for tests In-Reply-To: <56256338-811a-48bf-b328-543f8ab5ba55@oracle.com> References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <56256338-811a-48bf-b328-543f8ab5ba55@oracle.com> Message-ID: > > * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) > * in some cases, tests have a concise but somehow meaningful name (e.g. > `testScrollBarStaysVisible`) Prefixing 'test' was an old convention for testing frameworks. I have been dropping that prefix in my projects since I'm in a test class/package/source folder anyway, and it's not like there're methods in a test class that aren't used for testing. I also use long descriptive names, like 'newValueNotSetIfOldValueWasInvalid()' or, alternatively, 'doNotSetNewValueIfOldValueWasInvalid()'. John's nesting names are also good when nesting is appropriate. * in some cases, tests refer to JBS issues (e.g. testJDK8309935) * in some cases, the test is explained in comments. I don't like JBS numbers as names, but I like them as links in a comment. I prefer the name of the test and methods to be self-explanatory, like in non-test code, rather than comments. However, sometimes comments are needed because of tricky or non-trivial situations, which is part of what tests are for. On Tue, Jul 9, 2024 at 6:30?PM Kevin Rushforth wrote: > This might be a combination of Eclipse and eCryptfs. I agree that 143 > chars is very short for a max length. > > -- Kevin > > > On 7/9/2024 8:22 AM, John Hendrikx wrote: > > > On 09/07/2024 16:52, Andy Goryachev wrote: > > > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > > > I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), > and it only manifests itself in Eclipse and not in the gradle build - > perhaps Eclipse actually verifies the removal of files? > > > > Anyway, a suggestion - if you use @Nested, please keep the class names > *short*. > > This is not an Eclipse bug as I never encounter such issues. 143 > characters is rather short these days, but I suppose we could limit the > nesting a bit. Still, I'd look into a way to alleviate this problem in > your setup, sooner or later this is going to be a problem. > > --John > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlisker at gmail.com Tue Jul 9 23:45:55 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Jul 2024 02:45:55 +0300 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <7968d2a4-d5ea-92ad-7d0f-0840ed16d997@gmail.com> Message-ID: My Eclipse never had this long filename problem, and I reviewed the fluent bindings PR when it was written so I would have seen it. You can try the most basic version of Eclipse ( https://download.eclipse.org/eclipse/downloads/) to see if it still happens if you want to dig into it. On Tue, Jul 9, 2024 at 9:09?PM Andy Goryachev wrote: > I wonder what other filesystems do? I just want our code to compile in > Eclipse on Linux Mint. > > > > -andy > > > > > > > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 11:04 > *To: *Andy Goryachev , Johan Vos < > johan.vos at gluonhq.com>, openjfx-dev > *Subject: *Re: [External] : Re: consistent naming for tests > > Perhaps, and I guess we're lucky the classes don't fully overlap then... > if encfs just cuts off too long names when reading/writing, then as long as > the filename is still unique enough that is going to work. As soon as two > file names would overlap, they would overwrite each other and there's no > way that the code would still work then. > > I doubt however this is reasonable to fix in Eclipse; the filesystem is > not behaving correctly -- encfs should error out instead of silently > truncating too long names. > > --John > > On 09/07/2024 19:50, Andy Goryachev wrote: > > or gradle may not be verifying that the file is actually deleted. > > > > Eclipse allows for online replacement (? or whatever that feature is > called when it can recompile and replace classes in a running vm), so > perhaps it is more diligent when it comes to deleting. > > > > -andy > > > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 10:47 > *To: *Andy Goryachev > , Johan Vos > , openjfx-dev > > *Subject: *Re: [External] : Re: consistent naming for tests > > Then I can't explain why it doesn't fail on Gradle; it must be generating > similar named classes then, but perhaps at a different location (not on > encfs) ?. > > --John > > On 09/07/2024 19:35, Andy Goryachev wrote: > > Anonymous classes are named $1. Nested classes retain their name. > > > > From the ticket: > > > > https://bugs.openjdk.org/browse/JDK-8334497 > > > > Could not delete: > /home/ag/Projects/jfx-2/jfx/rt/modules/javafx.base/testbin/test/javafx/beans/value/ObservableValueFluentBindingsTest$When_flatMap_Called$WithNotNullReturns_ObservableValue_Which$WhenObservedForInvalidations$AndWhenUnobserved.class. > > > > -andy > > > > > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 10:31 > *To: *Andy Goryachev > , Johan Vos > , openjfx-dev > > *Subject: *Re: [External] : Re: consistent naming for tests > > Perhaps it is something Eclipse does differently. Normally nested classed > are numbered ($1, $2), so perhaps ecj is compiling these with differently > filenames. > > --John > > On 09/07/2024 17:37, Andy Goryachev wrote: > > Have you tried building in Eclipse on the latest Linux Mint? Or building > on an EncFS mount? > > > > I don't know why Mint decided to use EncFS knowing its issues, and I > suppose I can try fixing my setup (it's a default Mint installation), but I > was quite surprised myself and thought that it might be just as easy to fix > the tests... here is how the fix might look: > > > > https://github.com/andy-goryachev-oracle/jfx/pull/9 > > > > > -andy > > > > *From: *John Hendrikx > *Date: *Tuesday, July 9, 2024 at 08:22 > *To: *Andy Goryachev > , Johan Vos > , openjfx-dev > > *Subject: *[External] : Re: consistent naming for tests > > > > On 09/07/2024 16:52, Andy Goryachev wrote: > > > > Two test files consistently generate an error in Eclipse > > - ObservableValueFluentBindingsTest > - LazyObjectBindingTest > > > > I admit I have a weird setup (EncFS on Linux Mint running on MacBook Pro), > and it only manifests itself in Eclipse and not in the gradle build - > perhaps Eclipse actually verifies the removal of files? > > > > Anyway, a suggestion - if you use @Nested, please keep the class names > *short*. > > This is not an Eclipse bug as I never encounter such issues. 143 > characters is rather short these days, but I suppose we could limit the > nesting a bit. Still, I'd look into a way to alleviate this problem in > your setup, sooner or later this is going to be a problem. > > --John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Wed Jul 10 07:25:03 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 10 Jul 2024 09:25:03 +0200 Subject: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <56256338-811a-48bf-b328-543f8ab5ba55@oracle.com> Message-ID: Thanks all for commenting. What I have read so far seems that there is an agreement for this approach: * don't prefix tests with `test` anymore * use a (somehow) descriptive name * add a comment that refers to the JBS issue that this test is dealing with * (optional) in case the test or test scenario is complex, add a comment that briefly describes what is being tested. If that is in line with what most people want, I can create a PR to add this to the CONTRIBUTING.md file. - Johan On Wed, Jul 10, 2024 at 1:36?AM Nir Lisker wrote: > * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) >> * in some cases, tests have a concise but somehow meaningful name (e.g. >> `testScrollBarStaysVisible`) > > > Prefixing 'test' was an old convention for testing frameworks. I have been > dropping that prefix in my projects since I'm in a test > class/package/source folder anyway, and it's not like there're methods in a > test class that aren't used for testing. I also use long descriptive names, > like 'newValueNotSetIfOldValueWasInvalid()' or, alternatively, > 'doNotSetNewValueIfOldValueWasInvalid()'. John's nesting names are also > good when nesting is appropriate. > > * in some cases, tests refer to JBS issues (e.g. testJDK8309935) > > * in some cases, the test is explained in comments. > > > I don't like JBS numbers as names, but I like them as links in a comment. > I prefer the name of the test and methods to be self-explanatory, like in > non-test code, rather than comments. However, sometimes comments are needed > because of tricky or non-trivial situations, which is part of what tests > are for. > > > On Tue, Jul 9, 2024 at 6:30?PM Kevin Rushforth > wrote: > >> This might be a combination of Eclipse and eCryptfs. I agree that 143 >> chars is very short for a max length. >> >> -- Kevin >> >> >> On 7/9/2024 8:22 AM, John Hendrikx wrote: >> >> >> On 09/07/2024 16:52, Andy Goryachev wrote: >> >> >> >> Two test files consistently generate an error in Eclipse >> >> - ObservableValueFluentBindingsTest >> - LazyObjectBindingTest >> >> >> >> I admit I have a weird setup (EncFS on Linux Mint running on MacBook >> Pro), and it only manifests itself in Eclipse and not in the gradle build - >> perhaps Eclipse actually verifies the removal of files? >> >> >> >> Anyway, a suggestion - if you use @Nested, please keep the class names >> *short*. >> >> This is not an Eclipse bug as I never encounter such issues. 143 >> characters is rather short these days, but I suppose we could limit the >> nesting a bit. Still, I'd look into a way to alleviate this problem in >> your setup, sooner or later this is going to be a problem. >> >> --John >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Wed Jul 10 09:18:22 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Jul 2024 09:18:22 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 11:38:30 GMT, Kevin Rushforth wrote: >> Another possibility is the code that measures the time it takes to show the tooltip. >> >> The current code uses Util.waitForLatch(), L244 which was written for a different use case and actually introduces a small measurement error as it includes the time needed for the context switch. Perhaps a better solution would be to note the timestamp in L271 where the tooltip listener gets called (similar to the way the start moment is captured in L241) > > Good catch. Capturing the current time in the listener will be more accurate than doing it after the latch wait. Good catch indeed. Will test and report back accordingly. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1671923946 From mhanl at openjdk.org Wed Jul 10 09:30:29 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Jul 2024 09:30:29 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: <1fSQo-ECSvBRB9NvP3QJwmhnNfsAfCbKnNZcjC0-5zg=.1a37aba0-7a47-434f-b43b-44d17ce6aadf@github.com> Message-ID: On Mon, 8 Jul 2024 17:49:10 GMT, Andy Goryachev wrote: >> Thought about this well, didn't test yet > > see for example > https://github.com/openjdk/jfx/blob/72701e6cb4095b8f5042f54ae6bb2c0cec446bcf/modules/javafx.graphics/src/test/java/test/javafx/scene/Node_transition_Test.java#L142 Ah, looks good. Maybe in the future we can create a Utility function for this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1671941051 From mhanl at openjdk.org Wed Jul 10 09:42:57 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Jul 2024 09:42:57 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add many more unit tests for Tooltip The Tooltip timing looks much better now in the tests. I decided to use 80ms as a threshhold. In my testing, I got a maximum difference of ~35 ms. Also merged in master. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2220031951 From mhanl at openjdk.org Wed Jul 10 09:42:57 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Wed, 10 Jul 2024 09:42:57 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: Message-ID: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful and headless tests for the behaviour since there were none before. Marius Hanl 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 12 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css - Use Base64 encoder in tests - Improve time measurement and simplify test diff code - add many more unit tests for Tooltip - Use Helper class instead - Doc - Add a test for changing the stylesheet and always process CSS for that matter - Add more documentation and improve css stylesheet test threshold - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css - ... and 2 more: https://git.openjdk.org/jfx/compare/cd76c4fa...f917d18e ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/6abc47b1..f917d18e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=08-09 Stats: 25230 lines in 281 files changed: 23351 ins; 339 del; 1540 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From nlisker at gmail.com Wed Jul 10 12:08:12 2024 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Jul 2024 15:08:12 +0300 Subject: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <56256338-811a-48bf-b328-543f8ab5ba55@oracle.com> Message-ID: Sounds good. Maybe also add that junit 5 should be used and 4 is just legacy. Note that the wiki also has instructions related to tests, but I think it's just for running them. On Wed, Jul 10, 2024, 10:25 Johan Vos wrote: > Thanks all for commenting. > What I have read so far seems that there is an agreement for this approach: > * don't prefix tests with `test` anymore > * use a (somehow) descriptive name > * add a comment that refers to the JBS issue that this test is dealing with > * (optional) in case the test or test scenario is complex, add a comment > that briefly describes what is being tested. > > If that is in line with what most people want, I can create a PR to add > this to the CONTRIBUTING.md file. > > - Johan > > On Wed, Jul 10, 2024 at 1:36?AM Nir Lisker wrote: > >> * in some cases, tests are always prefixed with `test` (e.g. `testFoo()`) >>> * in some cases, tests have a concise but somehow meaningful name (e.g. >>> `testScrollBarStaysVisible`) >> >> >> Prefixing 'test' was an old convention for testing frameworks. I have >> been dropping that prefix in my projects since I'm in a test >> class/package/source folder anyway, and it's not like there're methods in a >> test class that aren't used for testing. I also use long descriptive names, >> like 'newValueNotSetIfOldValueWasInvalid()' or, alternatively, >> 'doNotSetNewValueIfOldValueWasInvalid()'. John's nesting names are also >> good when nesting is appropriate. >> >> * in some cases, tests refer to JBS issues (e.g. testJDK8309935) >> >> * in some cases, the test is explained in comments. >> >> >> I don't like JBS numbers as names, but I like them as links in a comment. >> I prefer the name of the test and methods to be self-explanatory, like in >> non-test code, rather than comments. However, sometimes comments are needed >> because of tricky or non-trivial situations, which is part of what tests >> are for. >> >> >> On Tue, Jul 9, 2024 at 6:30?PM Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> This might be a combination of Eclipse and eCryptfs. I agree that 143 >>> chars is very short for a max length. >>> >>> -- Kevin >>> >>> >>> On 7/9/2024 8:22 AM, John Hendrikx wrote: >>> >>> >>> On 09/07/2024 16:52, Andy Goryachev wrote: >>> >>> >>> >>> Two test files consistently generate an error in Eclipse >>> >>> - ObservableValueFluentBindingsTest >>> - LazyObjectBindingTest >>> >>> >>> >>> I admit I have a weird setup (EncFS on Linux Mint running on MacBook >>> Pro), and it only manifests itself in Eclipse and not in the gradle build - >>> perhaps Eclipse actually verifies the removal of files? >>> >>> >>> >>> Anyway, a suggestion - if you use @Nested, please keep the class names >>> *short*. >>> >>> This is not an Eclipse bug as I never encounter such issues. 143 >>> characters is rather short these days, but I suppose we could limit the >>> nesting a bit. Still, I'd look into a way to alleviate this problem in >>> your setup, sooner or later this is going to be a problem. >>> >>> --John >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Wed Jul 10 13:01:22 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 10 Jul 2024 15:01:22 +0200 Subject: [External] : Re: CSS Lookups and their origins (possible regression) In-Reply-To: <55d5f616-e801-438f-83b8-54f3d1997549@oracle.com> References: <3179a05e-d73f-f6cd-2e0b-d36e4b0247e7@gmail.com> <8936ba4d-0cec-e21d-d5b2-f006020835d3@gmail.com> <1dcc9b25-028e-ac3a-ae63-a2dd03d148b2@gmail.com> <22719829-feea-1556-5d1e-07e3d92b9805@gmail.com> <55d5f616-e801-438f-83b8-54f3d1997549@oracle.com> Message-ID: I'll file a bug for this, as I feel partly responsible for uncovering this behavior by fixing the other bug :) I also did a deeper dive into the code already, and the comment in the resolve lookup code seems to be misleading.? It claims that it must know the origin of the lookup so it doesn't accidentally get cached if it is INLINE (and potentially shared with other nodes that do not have a style defined with setStyle or a different one).? Yet, no effort is made in the calling code to exclude INLINE styles from the cache. As it turns out, a different sub-cache is used for Nodes with inline styles, which effectively separates the caches for nodes with certain inline styles and nodes with different or no inline styles. This means that most likely the style origin determination in resolveLookups can simply be removed, and also means that the fix can be kept limited in scope. --John On 09/07/2024 22:16, Kevin Rushforth wrote: > My reading of this is that the fix for the caching bug, JDK-8245919 > [1] via PR #1072 [2], has inadvertently exposed previously hidden > behavior that is at best an undesirable feature and at worst a bug > (I'd call it a bug). It seems quite unexpected to me that overriding a > variable defined in a user agent stylesheet in an? AUTHOR stylesheet > would elevate all properties derived from that variable to AUTHOR > stylesheet status. > > Assuming I'm not missing something, we ought to consider fixing this. > > -- Kevin > > [1] https://bugs.openjdk.org/browse/JDK-8245919 > [2] https://github.com/openjdk/jfx/pull/1072 > > > On 7/9/2024 11:21 AM, John Hendrikx wrote: >> >> Hi Andy, >> >> I'm confused, nowhere do I propose to remove or otherwise make the >> CSS reference system implemented by FX unusable. >> >> I'm first trying to ascertain if this would be expected behavior (it >> is indeed unspecified, and the default currently seems to have been >> chosen for implementation ease, not for user friendliness). >> >> **IF** we're considering this worth changing, the change would simply >> be that when you override a variable (like -fx-base) that this is >> done WITHOUT elevating all styles that use it to the level of an >> AUTHOR stylesheet (ie. they remain at USER_AGENT level as they're >> specified by Modena).? This is not a bad view, because in a sense, >> we're not really specifying a style, we're only overriding a >> variable.? The actual style is still specified in Modena, which is a >> USER_AGENT level stylesheet. >> >> As for the bug fix, please read up a bit more on what was fixed, and >> what this is now exposing.? The fix is almost completely unrelated >> (it fixed accidental changes to unrelated controls at the same level >> (ie. siblings) due to cache sharing where one has had a programmatic >> change, and the other didn't).? This was caused by a CSS calculation >> bug (calculation was skipped for all styleable properties that >> already had a setter change, if they were encountered first by the >> CSS system).? Now that this isn't the case anymore, set values are >> overwritten with CSS styles more aggressively. Normally those however >> are only styles that originate from an AUTHOR stylesheet, so this can >> be seen as expected by the user (after all, they WROTE that >> stylesheet).? But because all styles that use a variable are being >> promoted to AUTHOR level, this also includes all unseen styles in >> Modena if you specify the variable in your AUTHOR stylesheet. >> >> > Nowhere did we **actualy** override -fx-text-fill " is not >> technically correct since this color depends on -fx-base. >> >> That really depends on your view point.? Is overriding a variable the >> same as defining all styles (in your AUTHOR stylesheet) that use that >> variable?? If it was a pre-processor, that created a fully resolved >> Modena.css, then this would not be the case.? But it is not >> implemented as such. >> >> > And I would not want to change how it works currently because this >> is the only way (short of overwriting the whole modena.css >> styleshseet) for an application to effect a system-wide change like >> reacting to changes in the user preferences or the platform theme. >> >> To be clear, I'm not proposing to change that at all. >> >> --John >> >> On 09/07/2024 20:00, Andy Goryachev wrote: >>> >>> 1) a buggy implementation coupled with lack of specification creates >>> a certain expectation >>> >>> 2) bug gets fixed >>> >>> 3) people complain because the feature now works as it should? >>> >>> I think (and this is my personal opinion, in the absence of a formal >>> specification) that this works as expected now.? The statement " >>> Nowhere did we **actualy** override -fx-text-fill" is not >>> technically correct since this color depends on -fx-base. >>> >>> And I would not want to change how it works currently because this >>> is the only way (short of overwriting the whole modena.css >>> styleshseet) for an application to effect a system-wide change like >>> reacting to changes in the user preferences or the platform theme. >>> >>> -andy >>> >>> *From: *John Hendrikx >>> *Date: *Tuesday, July 9, 2024 at 10:45 >>> *To: *Andy Goryachev , openjfx-dev >>> >>> *Subject: *Re: [External] : Re: CSS Lookups and their origins >>> (possible regression) >>> >>> Well, it is coming as a surprise to many. With the fix for the CSS >>> caching bug since JavaFX 21, this "normal" behavior is becoming much >>> more obvious. >>> >>> Let me repeat one more time: >>> >>> If I have a Label, and I manually set its text fill with a setter to >>> YELLOW. In JavaFX 17, when I now add a stylesheet that is empty >>> aside from `-fx-base: WHITE`, the label's text fill stays YELLOW. >>> >>> Now do this in JavaFX 21.? As soon as you add the stylesheet with >>> `-fx-base: WHITE` in it, the set value to YELLOW is overridden, even >>> though technically this value for -fx-text-fill is defined by Modena >>> (which should not be overriding set values).? Nowhere did we >>> **actualy** override -fx-text-fill, yet the CSS subsystem now sees >>> **all** values defined by Modena that are somehow linked to -fx-base >>> as defined directly by the developer... >>> >>> The reason this didn't happen in JavaFX prior to 21 is because there >>> was a bug where a CSS value was not fully calculated if the property >>> it encountered was overridden via a set value. That was a bug >>> however as cache entries are shared amongst similar styled nodes, >>> and so not calculating it fully could have effects on other nodes >>> that shared that cache entry but did NOT have a property set >>> directly.? Now that this bug is fixed, this problem is odd behavior >>> is popping up where simply specifying -fx-base in an empty >>> stylesheet is somehow overriding a programmatically set text fill.? >>> Users are confused by this, as nowhere in their stylesheet do they >>> themselves override text fill. >>> >>> This entire mechanism is not specified by CSS, but is unique to FX.? >>> The most similar mechanism in CSS (see Michael's answer) says the >>> priority of a style should not be changed when it is using a reference. >>> >>> --John >>> >>> On 09/07/2024 17:43, Andy Goryachev wrote: >>> >>> > all styles used in Modena that rely on -fx-base directly or >>> indirectly suddenly have a higher priority >>> >>> I think it works as designed (and as expected). >>> >>> -andy >>> >>> *From: *John Hendrikx >>> >>> *Date: *Tuesday, July 9, 2024 at 08:25 >>> *To: *Andy Goryachev >>> , openjfx-dev >>> >>> *Subject: *[External] : Re: CSS Lookups and their origins >>> (possible regression) >>> >>> It's not that you can't use -fx-base, but that as it is >>> currently that all styles used in Modena that rely on -fx-base >>> directly or indirectly suddenly have a higher priority (above >>> setters) even though you didn't specifically specify them in >>> your own stylesheet.? All such styles are being elevated from >>> USER_AGENT to AUTHOR level (which is above USER level which is >>> used for setters). >>> >>> --John >>> >>> On 09/07/2024 17:03, Andy Goryachev wrote: >>> >>> I've used this feature in the past to change the colors in >>> all the controls, so to me this is the expected behavior. >>> >>> So in your case (if I got it right), you need to set the >>> direct style on the label >>> (.setStyle("-fx-text-fill:yellow")) instead of setting the >>> text fill programmatically.? Right? >>> >>> -andy >>> >>> *From: *openjfx-dev >>> on behalf of John >>> Hendrikx >>> >>> *Date: *Monday, July 8, 2024 at 17:11 >>> *To: *openjfx-dev >>> >>> *Subject: *Re: CSS Lookups and their origins (possible >>> regression) >>> >>> I realized I worded the TLDR poorly. >>> >>> Let me try again: >>> >>> TLDR; should styles which use references (like -fx-base used >>> in Modena) become AUTHOR level styles if -fx-base is >>> specified in an AUTHOR stylesheet?? The act of simply >>> specifying -fx-base in your own AUTHOR stylesheet elevates >>> hundreds of styles from Modena to AUTHOR level, as if you >>> specified them directly... >>> >>> --John >>> >>> On 09/07/2024 02:07, John Hendrikx wrote: >>> >>> Hi List, >>> >>> TLDR; should a CSS reference like -fx-base convert all >>> styles that use this value (or derive from it) become >>> AUTHOR level styles (higher priority than setters) ? >>> >>> Long version: >>> >>> In JavaFX 21, I did a fix (see #1072) to solve a problem >>> where a CSS value could be reset on an unrelated control. >>> >>> This happened when the CSS engine encountered a stylable >>> that is overridden by the user (with a setter), and >>> decided NOT to proceed with the full CSS value >>> calculation (as it could not override the user setting >>> if that CSS value had lower priority).? However, not >>> proceeding with the calculation meant that a "SKIP" was >>> stored in a shared cache which was incorrect.? This is >>> because when this "SKIP" is later encountered for an >>> unrelated control (the cache entries are shared for >>> controls with the same styles at the same level), they >>> could get their values reset because they were assumed >>> to be unstyled. >>> >>> However, this fix has exposed what seems to be a deeper >>> bug or perhaps an unfortunate default: >>> >>> JavaFX has a special feature where you can refer to >>> certain other styles by using a reference (which is >>> resolved, recursively, to a final value).? This does not >>> seem to be a CSS standard, but is a feature only FX has. >>> >>> It works by saying something like: >>> >>> ??? -fx-base: RED; >>> >>> And then using it like this: >>> >>> ??? -fx-text-fill: -fx-base; >>> >>> This feature works accross stylesheets of different >>> origins, so an AUTHOR stylesheet can specify -fx-base, >>> and when a USER_AGENT refers to -fx-base, the value >>> comes from the AUTHOR stylesheet. >>> >>> JavaFX then changes the origin of the style to the >>> highest priority encountered while resolving the >>> reference.? This means that Modena can specify >>> "-fx-text-fill: -fx-base", and when "-fx-base" is then >>> part of the AUTHOR style sheet, that ALL Modena styles >>> that use -fx-base will be considered AUTHOR level >>> styles, as per this comment: >>> >>> // The origin of this parsed value is the greatest of >>> >>> // any of the resolved reference. If a resolved reference >>> >>> // comes from an inline style, for example, then the value >>> >>> // calculated from the resolved lookup should have inline >>> >>> // as its origin. Otherwise, an inline style could be >>> >>> // stored in shared cache. >>> >>> I feel that this is a really unfortunate choice.? The >>> style after all was specified by Modena, only its value >>> came from another (higher priority) style sheet.? I >>> think a more logical choice would have been to not >>> change the priority at all, unless a "-fx-text-fill" is >>> explicitly made part of the AUTHOR stylesheet. >>> >>> A consequence of this (and which is much more visible >>> after the fix) is that creating a Label with a >>> setTextFill(Color.YELLOW) in its constructor will only >>> result in a yellow text fill if the AUTHOR stylesheet >>> did not override any of the Modena colors involved in >>> calculating the Modena -fx-text-fill default.? >>> Overriding -fx-base in any way will result in the text >>> fill of the label to be overridden (as the reference >>> came from an AUTHOR stylesheet, which trumps a setter >>> which is of a lower style origin). >>> >>> The comment also alludes to a potential problem.? If an >>> inline style would specify "-fx-base", but would be >>> treated as if it came from Modena (USER_AGENT level), >>> then this value could get stored in the cache as >>> everything except INLINE styles can be cached.? However, >>> I feel that the changing of style origin level was then >>> probably done to solve a CACHING problem, instead of >>> what made logical sense for users.? If we agree that a >>> resolved reference should not change the style origin >>> level, then this would need to be addressed, by perhaps >>> marking such a calculated value as uncacheable, instead >>> of overloading the meaning of style origin. >>> >>> I'd like to hear your thoughts, and also how to >>> proceed.? JavaFX versions before 21 seemingly allowed >>> overriding reference without much consequence because if >>> the user overrode the value manually, the cache entry >>> would be set to "SKIP". Now that this is no longer the >>> case, JavaFX more aggressively overrides user set values >>> if they happen to use a referenced value.? See code below. >>> >>> --John >>> >>> .root { >>> >>> -fx-base: #ff0000; >>> >>> } >>> >>> *package*app; >>> >>> *import*javafx.application.Application; >>> >>> *import*javafx.scene.Scene; >>> >>> *import*javafx.scene.control.Label; >>> >>> *import*javafx.scene.paint.Color; >>> >>> *import*javafx.stage.Stage; >>> >>> *public**class*TestApp *extends*Application { >>> >>> *public**static**void*main(String[] args) { >>> >>> /launch/(args); >>> >>> } >>> >>> @Override >>> >>> *public**void*start(Stage primaryStage) { >>> >>> Scene scene = *new*Scene(*new*MyLabel()); >>> >>> // See the difference with/without -fx-base in the >>> _stylesheet_ >>> >>> scene.getStylesheets().add(TestApp.*class*.getResource("/style.css").toExternalForm()); >>> >>> primaryStage.setScene(scene); >>> >>> primaryStage.show(); >>> >>> } >>> >>> } >>> >>> *class*MyLabel *extends*Label { >>> >>> *public*MyLabel() { >>> >>> setTextFill(Color.YELLOW); >>> >>> setText("Hello world"); >>> >>> } >>> >>> } >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Wed Jul 10 13:35:02 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jul 2024 06:35:02 -0700 Subject: [External] : Re: consistent naming for tests In-Reply-To: References: <83a1e1aa-5731-308e-3e1e-099ac510259e@gmail.com> <56256338-811a-48bf-b328-543f8ab5ba55@oracle.com> Message-ID: <0c5577be-8e9b-4a08-b6ed-31a1ab0dbffc@oracle.com> > If that is in line with what most people want, I can create a PR to > add this to the CONTRIBUTING.md file. All good from my point of view. That would be great, thank you. -- Kevin On 7/10/2024 12:25 AM, Johan Vos wrote: > Thanks all for commenting. > What I have read so far seems that there is an agreement for this > approach: > * don't prefix tests with `test` anymore > * use a (somehow) descriptive name > * add a comment that refers to the JBS issue that this test is dealing > with > * (optional) in case the test or test scenario is complex, add a > comment that briefly describes what is being tested. > > If that is in line with what most people want, I can create a PR to > add this to the CONTRIBUTING.md file. > > - Johan > > On Wed, Jul 10, 2024 at 1:36?AM Nir Lisker wrote: > > * in some cases, tests are always prefixed with `test` (e.g. > `testFoo()`) > * in some cases, tests have a concise but somehow > meaningful?name (e.g. `testScrollBarStaysVisible`) > > > Prefixing 'test' was an old convention for testing frameworks. I > have been dropping that prefix in my projects since I'm in a test > class/package/source folder anyway, and it's not like there're > methods in a test class that aren't used for testing. I also use > long descriptive names, like > 'newValueNotSetIfOldValueWasInvalid()' or, alternatively, > 'doNotSetNewValueIfOldValueWasInvalid()'. John's nesting names are > also good when nesting is appropriate. > > * in some cases, tests refer to JBS issues (e.g. testJDK8309935) > > * in some cases, the test is explained in comments. > > > I don't like JBS numbers as names, but I like them as links in a > comment. I prefer the name of the test and methods to be > self-explanatory, like in non-test code, rather than comments. > However, sometimes comments are needed because of tricky or > non-trivial situations, which is part of what tests are for. > > > On Tue, Jul 9, 2024 at 6:30?PM Kevin Rushforth > wrote: > > This might be a combination of Eclipse and eCryptfs. I agree > that 143 chars is very short for a max length. > > -- Kevin > > > On 7/9/2024 8:22 AM, John Hendrikx wrote: >> >> >> On 09/07/2024 16:52, Andy Goryachev wrote: >>> >>> Two test files consistently generate an error in Eclipse >>> >>> - ObservableValueFluentBindingsTest >>> - LazyObjectBindingTest >>> >>> I admit I have a weird setup (EncFS on Linux Mint running on >>> MacBook Pro), and it only manifests itself in Eclipse and >>> not in the gradle build - perhaps Eclipse actually verifies >>> the removal of files? >>> >>> Anyway, a suggestion - if you use @Nested, please keep the >>> class names /short/. >>> >> This is not an Eclipse bug as I never encounter such issues.? >> 143 characters is rather short these days, but I suppose we >> could limit the nesting a bit.? Still, I'd look into a way to >> alleviate this problem in your setup, sooner or later this is >> going to be a problem. >> >> --John >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Wed Jul 10 17:24:32 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 10 Jul 2024 17:24:32 +0000 Subject: [External] : Re: UI elements sizing in Modena.css In-Reply-To: References: Message-ID: I agree - having CSS variables will definitely help. Personally, I would rather see a better way to create stylesheets programmatically, bypassing the whole parsing routine, but I am sure a lot of people would be more comfortable if things were similar to web css. Enabling CSS variables seems to me like a lot of work though, but I could be mistaken. Any ideas how to add support for CSS variables to JavaFX? -andy From: Pedro Duque Vieira Date: Tuesday, July 9, 2024 at 15:51 To: Andy Goryachev Cc: openjfx-dev at openjdk.org Subject: [External] : Re: UI elements sizing in Modena.css .. one more reason to use the CSS variable spec that I forgot to mention: 5 - It's a spec that has been thoroughly thought of before it was added to CSS and it has stood the test of time. On Tue, Jul 9, 2024 at 11:04?PM Pedro Duque Vieira > wrote: Andy, if I understand the suggestion correctly, you want to set the Modena sizes using variables that can be easily overridden. To that effect variables must first be able to hold numeric values as, as it stands today JavaFX only allows colors to be used for CSS variables. So, you're also suggesting adding the ability for CSS variables to define inset values, is that correct? I think that's a good idea. I would, however, generalize that to allow CSS variables to hold numeric values that could be used anywhere. Or at least, starting to pave the ground for that. I would go even further and start to pave ground to add the CSS variable spec into javafx css: https://codersblock.com/blog/what-can-you-put-in-a-css-variable/ Why use the css web spec? Because of the following reasons: 1 - Designers already know how to work with the css web spec 2 - there are already many tools available that work with the css web spec 3 - there are already many examples on the web using CSS so developers can just copy paste those examples 4 - Developers coming from the web can easily start using javafx css with no friction and no need to learn it Thanks On Tue, Jul 9, 2024 at 9:04?PM Andy Goryachev > wrote: Since we touched the modena.css, I would like to ask the group's opinion on whether we should fix the way modena.css sizes UI elements. Please see https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing the font size also unexpectedly changed the scrollbar. What do you think about introducing a set of variables similar to -fx-base but for sizing/padding, placing them early on to depend on the font size in the .root selector instead of the font in the actual control? Something along the lines of .root { -fx-size-3px: 0.25em; ... } .scroll-bar:horizontal > .increment-button > .increment-arrow { -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px; } instead of .scroll-bar:horizontal > .increment-button > .increment-arrow { -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */ } This way we still permit the UI components resize with the main font, while keeping the sizes of all the control surfaces consistent? This will require a trivial change in InsetsConverter. What do you think? -andy -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Wed Jul 10 20:25:26 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 10 Jul 2024 20:25:26 GMT Subject: RFR: 8336110: Update copyright header for files modified in 2024 Message-ID: Update the copyright year in files modified in year 2024. ------------- Commit messages: - 8336110: Update copyright header for files modified in 2024 Changes: https://git.openjdk.org/jfx/pull/1500/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1500&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336110 Stats: 266 lines in 266 files changed: 0 ins; 0 del; 266 mod Patch: https://git.openjdk.org/jfx/pull/1500.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1500/head:pull/1500 PR: https://git.openjdk.org/jfx/pull/1500 From angorya at openjdk.org Wed Jul 10 20:26:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jul 2024 20:26:04 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> Message-ID: On Wed, 10 Jul 2024 15:00:31 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TooltipTest.java line 709: >> >>> 707: } >>> 708: >>> 709: private String toBase64(String css) { >> >> suggestion: >> >> private static String encode(String css) { >> return "data:base64," + Base64.getUrlEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8)); >> } > > I agree that it could be static, although I prefer the name `toBase64`. my comment was to avoid replicating "data:base64,", and with that, it is not base64 anymore, but base-64-encoded url. the best place for this method is probably in some utility class so it can be reused. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1672468522 From kcr at openjdk.org Wed Jul 10 20:26:12 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jul 2024 20:26:12 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> Message-ID: On Wed, 10 Jul 2024 15:03:56 GMT, Andy Goryachev wrote: > my comment was to avoid replicating "data:base64,", and with that, it is not base64 anymore, but base-64-encoded url. I see. > the best place for this method is probably in some utility class so it can be reused. Definitely, but let's do that in a follow-up testbug (and update the other test you pointed to at the same time). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1672492667 From kcr at openjdk.org Wed Jul 10 20:26:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jul 2024 20:26:04 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> References: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> Message-ID: On Wed, 10 Jul 2024 14:36:51 GMT, Andy Goryachev wrote: >> Marius Hanl 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 12 additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css >> - Use Base64 encoder in tests >> - Improve time measurement and simplify test diff code >> - add many more unit tests for Tooltip >> - Use Helper class instead >> - Doc >> - Add a test for changing the stylesheet and always process CSS for that matter >> - Add more documentation and improve css stylesheet test threshold >> - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css >> - ... and 2 more: https://git.openjdk.org/jfx/compare/5c7c8bae...f917d18e > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TooltipTest.java line 709: > >> 707: } >> 708: >> 709: private String toBase64(String css) { > > suggestion: > > private static String encode(String css) { > return "data:base64," + Base64.getUrlEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8)); > } I agree that it could be static, although I prefer the name `toBase64`. > tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 233: > >> 231: window.getX() + scene.getX() + button.getLayoutX() + button.getLayoutBounds().getWidth() / 2, >> 232: window.getY() + scene.getY() + button.getLayoutY() + button.getLayoutBounds().getHeight() / 2); >> 233: tooltipStartTime = System.currentTimeMillis(); > > it is better to use `System.nanoTime()` instead of `currentTimeMillis()` for this kind of measurements because it is not affected by the updates to the current time (such as time sync). > > (since there are plenty of other places where we use `currentTimeMillis()` it's probably ok - very unlikely for the test to hit this scenario) That seems like a good overall test cleanup that could be done in a follow-up issue. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1672460851 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1672494529 From kcr at openjdk.org Wed Jul 10 20:25:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jul 2024 20:25:42 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v9] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 09:40:03 GMT, Marius Hanl wrote: > The Tooltip timing looks much better now in the tests. I decided to use 80ms as a threshhold. In my testing, I got a maximum difference of ~35 ms. > > Also merged in master. Thanks. I'll test and re-review. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2220783068 From angorya at openjdk.org Wed Jul 10 20:26:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 10 Jul 2024 20:26:04 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: Message-ID: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> On Wed, 10 Jul 2024 09:42:57 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl 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 12 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css > - Use Base64 encoder in tests > - Improve time measurement and simplify test diff code > - add many more unit tests for Tooltip > - Use Helper class instead > - Doc > - Add a test for changing the stylesheet and always process CSS for that matter > - Add more documentation and improve css stylesheet test threshold > - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. > - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css > - ... and 2 more: https://git.openjdk.org/jfx/compare/5c7c8bae...f917d18e modules/javafx.controls/src/test/java/test/javafx/scene/control/TooltipTest.java line 709: > 707: } > 708: > 709: private String toBase64(String css) { suggestion: private static String encode(String css) { return "data:base64," + Base64.getUrlEncoder().encodeToString(css.getBytes(StandardCharsets.UTF_8)); } tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 233: > 231: window.getX() + scene.getX() + button.getLayoutX() + button.getLayoutBounds().getWidth() / 2, > 232: window.getY() + scene.getY() + button.getLayoutY() + button.getLayoutBounds().getHeight() / 2); > 233: tooltipStartTime = System.currentTimeMillis(); it is better to use `System.nanoTime()` instead of `currentTimeMillis()` for this kind of measurements because it is not affected by the updates to the current time (such as time sync). (since there are plenty of other places where we use `currentTimeMillis()` it's probably ok - very unlikely for the test to hit this scenario) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1672411983 PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1672429228 From kcr at openjdk.org Wed Jul 10 20:36:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jul 2024 20:36:15 GMT Subject: RFR: 8336110: Update copyright header for files modified in 2024 In-Reply-To: References: Message-ID: <0vWZPT8vrHU9n5BPWjAA-qoiY9j2tEa_pfO3owUgux0=.f2113551-7f8b-490d-a352-ba50bd03f355@github.com> On Wed, 10 Jul 2024 17:04:55 GMT, Ambarish Rapte wrote: > Update the copyright year in files modified in year 2024. Looks good. Given that we want to get this in before the `jfx23` fork, I approve integrating it tomorrow (Thursday) some time before 1600 UTC, even though that will be slightly less than 24 hours. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1500#pullrequestreview-2170220499 From pedro.duquevieira at gmail.com Wed Jul 10 22:03:46 2024 From: pedro.duquevieira at gmail.com (Pedro Duque Vieira) Date: Wed, 10 Jul 2024 23:03:46 +0100 Subject: [External] : Re: UI elements sizing in Modena.css In-Reply-To: References: Message-ID: I don't know the internals of the JavaFX CSS parser but regarding the CSS variable spec itself we could start by simply supporting numeric values as well as colors. This would already allow developers to use variables anywhere which would simplify and make managing stylesheets easier. On Wed, Jul 10, 2024 at 6:24?PM Andy Goryachev wrote: > I agree - having CSS variables will definitely help. Personally, I would > rather see a better way to create stylesheets programmatically, bypassing > the whole parsing routine, but I am sure a lot of people would be more > comfortable if things were similar to web css. > > > > Enabling CSS variables seems to me like a lot of work though, but I could > be mistaken. Any ideas how to add support for CSS variables to JavaFX? > > > > -andy > > > > *From: *Pedro Duque Vieira > *Date: *Tuesday, July 9, 2024 at 15:51 > *To: *Andy Goryachev > *Cc: *openjfx-dev at openjdk.org > *Subject: *[External] : Re: UI elements sizing in Modena.css > > .. one more reason to use the CSS variable spec that I forgot to mention: > > 5 - It's a spec that has been thoroughly thought of before it was added > to CSS and it has stood the test of time. > > > > On Tue, Jul 9, 2024 at 11:04?PM Pedro Duque Vieira < > pedro.duquevieira at gmail.com> wrote: > > Andy, if I understand the suggestion correctly, you want to set the Modena > sizes using variables that can be easily overridden. To that effect > variables must first be able to hold numeric values as, as it stands today > > JavaFX only allows colors to be used for CSS variables. > > So, you're also suggesting adding the ability for CSS variables to define > inset values, is that correct? > > > > I think that's a good idea. I would, however, generalize that to allow CSS > variables to hold numeric values that could be used anywhere. Or at least, > starting to pave the ground for that. > > > > I would go even further and start to pave ground to add the CSS > variable spec into javafx css: > https://codersblock.com/blog/what-can-you-put-in-a-css-variable/ > > > > > Why use the css web spec? Because of the following reasons: > > 1 - Designers already know how to work with the css web spec > > 2 - there are already many tools available that work with the css web spec > > 3 - there are already many examples on the web using CSS so developers can > just copy paste those examples > > 4 - Developers coming from the web can easily start using javafx css with > no friction and no need to learn it > > > > Thanks > > > > > > > > > > > > On Tue, Jul 9, 2024 at 9:04?PM Andy Goryachev > wrote: > > Since we touched the modena.css, I would like to ask the group's opinion > on whether we should fix the way modena.css sizes UI elements. Please see > https://bugs.openjdk.org/browse/JDK-8314683 for reference, where changing > the font size also unexpectedly changed the scrollbar. > > > > What do you think about introducing a set of variables similar to -fx-base > but for sizing/padding, placing them early on to depend on the font size in > the .root selector instead of the font in the actual control? Something > along the lines of > > > > .root { > > -fx-size-3px: 0.25em; > > ... > > } > > > > .scroll-bar:horizontal > .increment-button > .increment-arrow { > > -fx-padding: -fx-size-3px -fx-size-3px -fx-size-3px -fx-size-3px; > > } > > > > instead of > > > > .scroll-bar:horizontal > .increment-button > .increment-arrow { > > -fx-padding: 0.333em 0.167em 0.333em 0.167em; /* 4 2 4 2 */ > > } > > > > This way we still permit the UI components resize with the main font, > while keeping the sizes of all the control surfaces consistent? > > > > This will require a trivial change in InsetsConverter. > > > > What do you think? > > > > -andy > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > > > > > -- > > Pedro Duque Vieira (Duke) - https://www.pixelduke.com > > -- Pedro Duque Vieira (Duke) - https://www.pixelduke.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Wed Jul 10 23:15:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 10 Jul 2024 23:15:02 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 09:42:57 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl 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 12 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css > - Use Base64 encoder in tests > - Improve time measurement and simplify test diff code > - add many more unit tests for Tooltip > - Use Helper class instead > - Doc > - Add a test for changing the stylesheet and always process CSS for that matter > - Add more documentation and improve css stylesheet test threshold > - Implement applyStylesheetFromOwner(..) and use it instead to ensure correct CSS processing for the Tooltip Node. > - Merge branch 'master' of https://github.com/openjdk/jfx into 8296387-tooltip-css > - ... and 2 more: https://git.openjdk.org/jfx/compare/bb34dd85...f917d18e I ran it on our CI Linux and macOS systems and it passed on all of them. It also passed on my local Linux system. On my Windows machine I still get the following test failure almost every time I run it: TooltipTest > testShowDelayCssShowTooltipTwice() FAILED org.opentest4j.AssertionFailedError: 260 <= 180 ==> expected: but was: at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:40) at app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:210) at app//test.robot.javafx.scene.TooltipTest.assertTooltipShowDelay(TooltipTest.java:69) at app//test.robot.javafx.scene.TooltipTest.testShowDelayCssShowTooltipTwice(TooltipTest.java:202) I've seen the actual result as high as 390 one time. The other times were in the 200 - 260 range. Have you run it on Windows? If it's only my system, we could file a bug and look at it later. We might consider skipping that test on Windows using `@Ignore` and referencing that follow-on bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2221678986 From kevin.rushforth at oracle.com Wed Jul 10 23:21:58 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jul 2024 16:21:58 -0700 Subject: FINAL REMINDER: JavaFX 23 RDP1 starts tomorrow [was: Proposed schedule for JavaFX 23] In-Reply-To: <2afbe768-e977-4b60-a589-653b82b72959@oracle.com> References: <2afbe768-e977-4b60-a589-653b82b72959@oracle.com> Message-ID: <87345e00-e0e0-43ec-91ad-fd911ea7a62c@oracle.com> As a reminder, JavaFX 23 RDP1 starts tomorrow, July 11th. I will fork the 'jfx23' branch at 16:00 UTC. -- Kevin On 6/21/2024 12:08 PM, Kevin Rushforth wrote: > As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 23 starts on July > 11, 2024 at 16:00 UTC (09:00 Pacific time), a little less than three > weeks from now. > > Please allow sufficient time for any feature that needs a CSR. Given > that we are entering the summer holiday season, and with the upcoming > July 4th US holiday, there may be some delays. New features should be > far enough along in the review process that you can finalize the CSR > by Tuesday, July 2, or it is likely to miss the window for this > release, in which case it can be targeted for JavaFX 24. > > During rampdown of JavaFX 23, the "master" branch of the jfx repo will > be open for JavaFX 24 fixes, including enhancements. > > We will follow the same process as in previous releases for getting > fixes into JavaFX 23 during rampdown. I'll send a message with > detailed information when we fork, but candidates for fixing during > RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc > bugs of any priority. Some small enhancements might be considered > during RDP1, but they require explicit approval; the bar will be high > for such requests. > > -- Kevin > > On 5/8/2024 11:31 AM, Kevin Rushforth wrote: >> Here is the proposed schedule for JavaFX 23. >> >> RDP1: Jul 11, 2024 (aka ?feature freeze?) >> RDP2: Aug 1, 2024 >> Freeze: Aug 29, 2024 >> GA: Sep 17, 2024 >> >> We plan to fork a jfx23 stabilization branch at RDP1. >> >> 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 fkirmaier at openjdk.org Thu Jul 11 09:06:05 2024 From: fkirmaier at openjdk.org (Florian Kirmaier) Date: Thu, 11 Jul 2024 09:06:05 GMT Subject: Withdrawn: 8322619: Parts of SG no longer update during rendering - overlapping - culling - dirty In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 12:33:52 GMT, Florian Kirmaier wrote: > In some situations, a part of the SG is no longer rendered. > I created a test program that showcases this problem. > > Explanation: > > This can happen, when a part of the SG, is covered by another Node. > In this part, one node is totally covered, and the other node is visible. > > When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found. > Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean. > > In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen. > > In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early. > > This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself. > > Useful parameters for further investigations: > -Djavafx.pulseLogger=true > -Dprism.printrendergraph=true > -Djavafx.pulseLogger.threshold=0 > > PR: > This PR ensures the dirty flag is set to false of the tree when the culling is used. > It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it. > It would be great to have some feedback on this solution - maybe guiding me to a better solution. > > I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1310 From mhanl at openjdk.org Thu Jul 11 11:10:35 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 11:10:35 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v11] In-Reply-To: References: Message-ID: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful and headless tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Improve test code and change delta to 100 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/f917d18e..84f2faae Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=09-10 Stats: 18 lines in 1 file changed: 9 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Thu Jul 11 11:10:35 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 11:10:35 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 23:12:32 GMT, Kevin Rushforth wrote: > Have you run it on Windows? Yes, on Windows 10 and Windows 11. Executed the test multiple time now again, always around 110 - 140 ms for me. Weird. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2222646923 From kcr at openjdk.org Thu Jul 11 11:22:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 11:22:02 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v11] In-Reply-To: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> References: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> Message-ID: On Thu, 11 Jul 2024 11:10:35 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Improve test code and change delta to 100 With your latest change, the test now passes on my Windows 11 system. Maybe the resetting of `tooltipStartTime` and `tooltipShownTime` fixed it? I'll look more closely in a bit. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2222669449 From mhanl at openjdk.org Thu Jul 11 12:22:16 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 12:22:16 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v12] In-Reply-To: References: Message-ID: <5YaqtiIvNxszoPxV-1YS5aiIPQgwoFVBEsQewzUSPwA=.0bf02580-c6dc-4eab-a3bc-6fc23acdbe53@github.com> > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful and headless tests for the behaviour since there were none before. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: Change toBase64(..) to add the base64 part as well ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1394/files - new: https://git.openjdk.org/jfx/pull/1394/files/84f2faae..26ec665f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1394&range=10-11 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1394.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1394/head:pull/1394 PR: https://git.openjdk.org/jfx/pull/1394 From mhanl at openjdk.org Thu Jul 11 12:22:16 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 12:22:16 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v11] In-Reply-To: References: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> Message-ID: On Thu, 11 Jul 2024 11:19:36 GMT, Kevin Rushforth wrote: > With your latest change, the test now passes on my Windows 11 system. Maybe the resetting of `tooltipStartTime` and `tooltipShownTime` fixed it? I'll look more closely in a bit. I would not expect that, but maybe it has something to do with it. I did this change so that the test is more safe in case something is not triggered the way it should. But maybe it had a positive side effect, although not 100% sure. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2222787551 From kcr at openjdk.org Thu Jul 11 12:27:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 12:27:04 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v12] In-Reply-To: <5YaqtiIvNxszoPxV-1YS5aiIPQgwoFVBEsQewzUSPwA=.0bf02580-c6dc-4eab-a3bc-6fc23acdbe53@github.com> References: <5YaqtiIvNxszoPxV-1YS5aiIPQgwoFVBEsQewzUSPwA=.0bf02580-c6dc-4eab-a3bc-6fc23acdbe53@github.com> Message-ID: On Thu, 11 Jul 2024 12:22:16 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Change toBase64(..) to add the base64 part as well Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2171744334 From kcr at openjdk.org Thu Jul 11 12:27:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 12:27:05 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v11] In-Reply-To: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> References: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> Message-ID: <0la-mdajxN14x7BcLuaernnDNfKZlN3hMKqpx5eMFQk=.ba8c7415-e8a8-4372-a2ed-5d58abc1879b@github.com> On Thu, 11 Jul 2024 11:10:35 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Improve test code and change delta to 100 I looked at the code, and you're right, it doesn't seem like it would have mattered. Regardless, it now passes on my system reliably. I also reverted your fix and verified that the new test catches the failures. So all good from my point of view. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2222793814 From arapte at openjdk.org Thu Jul 11 12:58:03 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 11 Jul 2024 12:58:03 GMT Subject: Integrated: 8336110: Update copyright header for files modified in 2024 In-Reply-To: References: Message-ID: On Wed, 10 Jul 2024 17:04:55 GMT, Ambarish Rapte wrote: > Update the copyright year in files modified in year 2024. This pull request has now been integrated. Changeset: a41dcf3c Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/a41dcf3cb7259af0b5feac404aa94c3c1b247460 Stats: 266 lines in 266 files changed: 0 ins; 0 del; 266 mod 8336110: Update copyright header for files modified in 2024 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1500 From angorya at openjdk.org Thu Jul 11 14:33:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jul 2024 14:33:02 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v12] In-Reply-To: <5YaqtiIvNxszoPxV-1YS5aiIPQgwoFVBEsQewzUSPwA=.0bf02580-c6dc-4eab-a3bc-6fc23acdbe53@github.com> References: <5YaqtiIvNxszoPxV-1YS5aiIPQgwoFVBEsQewzUSPwA=.0bf02580-c6dc-4eab-a3bc-6fc23acdbe53@github.com> Message-ID: On Thu, 11 Jul 2024 12:22:16 GMT, Marius Hanl wrote: >> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the >> `-fx-show-delay` was set to another value. >> >> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. >> >> Added a bunch of headful and headless tests for the behaviour since there were none before. > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > Change toBase64(..) to add the base64 part as well lgtm. I'll create the tickets for creating utility methods that use base64 urls and system nano time. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1394#pullrequestreview-2172073269 From kcr at openjdk.org Thu Jul 11 15:32:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 15:32:03 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v11] In-Reply-To: References: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> Message-ID: On Thu, 11 Jul 2024 12:19:24 GMT, Marius Hanl wrote: >> With your latest change, the test now passes on my Windows 11 system. Maybe the resetting of `tooltipStartTime` and `tooltipShownTime` fixed it? I'll look more closely in a bit. > >> With your latest change, the test now passes on my Windows 11 system. Maybe the resetting of `tooltipStartTime` and `tooltipShownTime` fixed it? I'll look more closely in a bit. > > I would not expect that, but maybe it has something to do with it. > I did this change so that the test is more safe in case something is not triggered the way it should. But maybe it had a positive side effect, although not 100% sure. @Maran23 This is ready to integrate. If you can do it in the next 30 minutes, it will make JavaFX 23 before the RDP1 fork. If it is after the fork, it might be a candidate to backport to jfx23. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2223248806 From kcr at openjdk.org Thu Jul 11 16:05:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 16:05:00 GMT Subject: Integrated: 8335934: Change JavaFX release version to 24 In-Reply-To: References: Message-ID: On Mon, 8 Jul 2024 22:51:47 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 24. I will integrate this to `master` as part of forking the `jfx23` stabilization branch, which is scheduled for Thursday, July 11, 2024 at 16:00 UTC. This pull request has now been integrated. Changeset: 1c6ef363 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1c6ef3638057e05565d83c79acbfad83046b12c7 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8335934: Change JavaFX release version to 24 Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.org/jfx/pull/1499 From mhanl at openjdk.org Thu Jul 11 16:19:04 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 16:19:04 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v11] In-Reply-To: References: <8BtDBqEbcFwaW4gqa9tJMgTLqtxpwdwTKtgIYq_OhOo=.66697960-56e6-4cbb-ac2e-9d290571e53e@github.com> Message-ID: On Thu, 11 Jul 2024 15:29:01 GMT, Kevin Rushforth wrote: > If you can do it in the next 30 minutes, it will make JavaFX 23 before the RDP1 fork. If it is after the fork, it might be a candidate to backport to jfx23. Damn, missed the time. I will keep it open until tomorrow, in case someone else want to review or just check the PR. If we consider this a candidate for backporting, then I can certainly do the request after merging as well! :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2223349000 From kevin.rushforth at oracle.com Thu Jul 11 16:53:43 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Jul 2024 09:53:43 -0700 Subject: JavaFX 23 is in Rampdown Phase One (RDP1) Message-ID: JavaFX 23 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx23 branch [2] for stabilizing the JavaFX 23 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for jfx24. Almost all fixes will be integrated to master for 24, even those intended to be fixed in 23. - The jfx23 branch of the jfx repo is now open for integrating fixes for jfx23 that meet the RDP1 criteria as outlined below. As with the previous release, in this release we will integrate almost all stabilization changes via backports from the master branch [3]. ? * Almost all fixes intended for the jfx23 stabilization branch will also be applicable to the master branch. Integrate such a change into the master branch first. Then, after you have obtained any required approvals, backport it to the stabilization branch using the Skara `/backport` command or, if necessary, by manually opening a backport PR with the title `Backport $HASH`, where `$HASH` is the original commit hash.? (The JDK Developers? Guide contains more information on working with backports [4].) ? * Some fixes will be specific to the stabilization branch and not applicable to the master branch. Integrate such a change directly into the stabilization branch. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx23 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx23. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx23 branch. The master branch is open for all jfx24 fixes, including enhancements. As a reminder, we use a single openjdk/jfx GitHub repo with stabilization branches [5] rather than a separate stabilization repo. The jfx23 branch is used to stabilize the upcoming jfx23 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx23 to ensure that it doesn't contain any commits from master after the jfx23 fork date. What that means is that if you intend a PR to be for jfx23, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (JavaFX 24 as of today). This is usually what we want. A backport PR should be targeted to `jfx23` if, and only if, it is intended for JavaFX 23 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx23`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 24. Reviewers also need to be extra careful when reviewing PRs targeted to jfx23 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. This should be less of a problem for this release, since almost all PRs for jfx23 will be done as backport-style PRs, but it can still be a problem if the developer mistakenly merges master into their backport branch. We will use the same rules for RDP1 that the JDK uses [6], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 23 release. As an obvious choice, derived from the JBS fix version, we will use "jfx23-enhancement-request", "jfx23-enhancement-yes", "jfx23-enhancement-no" and "jfx23-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx23 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should only go into master for jfx24, since we do not want to risk anything that would destabilize the jfx23 release without a compelling reason. Also, we have only 3 weeks until RDP2 of jfx23 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for jfx23 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.org/pipermail/openjfx-dev/2024-May/046924.html [2] https://github.com/openjdk/jfx/tree/jfx23 [3] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements [4] https://openjdk.org/guide/#working-with-backports-in-jbs [5] https://github.com/openjdk/jfx/branches/all [6] http://openjdk.org/jeps/3 From mhanl at openjdk.org Thu Jul 11 17:15:14 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 17:15:14 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v3] In-Reply-To: References: Message-ID: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appears when I scroll and the clip RectBounds are somethi... Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java - Improve test - 8218745: TableView: visual glitch at borders on horizontal scrolling ------------- Changes: https://git.openjdk.org/jfx/pull/1462/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=02 Stats: 243 lines in 11 files changed: 166 ins; 56 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/1462.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1462/head:pull/1462 PR: https://git.openjdk.org/jfx/pull/1462 From angorya at openjdk.org Thu Jul 11 17:33:15 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 11 Jul 2024 17:33:15 GMT Subject: Integrated: 8335218: Eclipse Config: Remove Gradle Integration In-Reply-To: References: Message-ID: On Wed, 26 Jun 2024 21:23:34 GMT, Andy Goryachev wrote: > This might be controversial. I am proposing to remove the Gradle integration in the Eclipse config files. > > Problem > ======= > Eclipse Gradle integration (Buildship) cannot import the OpenJFX build.gradle cleanly. Every time the project is imported into a new workspace (or re-opened after being closed) it executes Gradle, creates and modifies a number of Eclipse .project and .classpath files, all of which need to be reverted for Eclipse workspace to become usable again. > > Solution > ====== > Remove Gradle nature from the Eclipse project files. This change only affects Eclipse config files and does not impact build.gradle or other IDEs. > > Advantages > ========= > 1. The multiple nested projects in the repo will get imported cleanly on the first attempt, will not require additional steps to clear the Buildship changes. > 2. completely removes the dependency on the Eclipse Buildship and its idiosyncrasies. > > NOTES: > - even though the reverse was done for IntelliJ, but its gradle import still does not import tests cleanly, see [JDK-8223373](https://bugs.openjdk.org/browse/JDK-8223373) > - this improvement contradicts [JDK-8223374](https://bugs.openjdk.org/browse/JDK-8223374) as without Eclipse files in the repo, it will be impossible to use Eclipse in a meaningful way without the fully functional Buildship support, and that is a big IF. > - once integrated, Eclipse users would only need to re-import the main project with 'search for nested projects' enabled This pull request has now been integrated. Changeset: 0ce4e6f9 Author: Andy Goryachev URL: https://git.openjdk.org/jfx/commit/0ce4e6f9540178ddf4761de21a86c769d57497fa Stats: 26 lines in 4 files changed: 0 ins; 26 del; 0 mod 8335218: Eclipse Config: Remove Gradle Integration Reviewed-by: nlisker, jhendrikx ------------- PR: https://git.openjdk.org/jfx/pull/1491 From kcr at openjdk.org Thu Jul 11 22:13:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 22:13:03 GMT Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage breaks the Window [v9] In-Reply-To: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> References: <7PjP8rbBqDalg64yn4y0unugTczOVncS9-ell1anPW8=.3c926957-27ea-4083-b726-19730475e1ac@github.com> Message-ID: <5HWn7INcC8MetfYmR-CxreeD3a5wHIqViCFlpZZgWvA=.82a0e234-6608-4996-813f-38a618b62699@github.com> On Thu, 27 Jun 2024 13:43:37 GMT, Marius Hanl wrote: >> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after. >> >> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. >> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > add delta for assertStageScreenBounds I'm not sure how we missed this in testing, but the full screen tests fail on Ubuntu 22.04 because a full screen window can be larger than the visual bounds. I started seeing nightly headful test failures after this was integrated, but didn't have time to look at it until now. I filed [JDK-8336272](https://bugs.openjdk.org/browse/JDK-8336272) to fix the test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1382#issuecomment-2224028466 From mhanl at openjdk.org Thu Jul 11 22:39:20 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 11 Jul 2024 22:39:20 GMT Subject: RFR: 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 Message-ID: <4wse4Ffh5_c2nxH6OrEIEXMX19gTU1BNFmr0DC4w_v8=.daa3df9b-be89-452b-8171-78d89e9a3702@github.com> Tests that the `Stage Size` is between the `Visual Screen bounds - 50 (delta)` and `Screen bounds + 50 (delta)`. -> `stageSize >= (visualBounds - 50)` & `stageSize <= (bounds + 50)`. Tested only on Windows 10 for now. ------------- Commit messages: - JDK-8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 Changes: https://git.openjdk.org/jfx/pull/1501/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336272 Stats: 14 lines in 1 file changed: 9 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1501.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1501/head:pull/1501 PR: https://git.openjdk.org/jfx/pull/1501 From kcr at openjdk.org Thu Jul 11 23:00:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 23:00:10 GMT Subject: [jfx23u] RFR: 8336035: Change JavaFX release version to 23.0.1 in jfx23u Message-ID: Updates for the beginning of the 23.0.1 release. ------------- Commit messages: - 8336035: Change JavaFX release version to 23.0.1 in jfx23u Changes: https://git.openjdk.org/jfx23u/pull/1/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=1&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336035 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx23u/pull/1.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/1/head:pull/1 PR: https://git.openjdk.org/jfx23u/pull/1 From kcr at openjdk.org Thu Jul 11 23:03:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 23:03:00 GMT Subject: [jfx23u] RFR: 8336035: Change JavaFX release version to 23.0.1 in jfx23u In-Reply-To: References: Message-ID: <1sI5Rb2GgSUKrsU5RZSSyaajmzV7rYcgAhMTWtHazNQ=.5e5ef5dd-197f-47b8-ba5a-fd2519970faa@github.com> On Thu, 11 Jul 2024 22:56:18 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 23.0.1 release. Reviewers: @johanvos or @arapte ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/1#issuecomment-2224089948 From kcr at openjdk.org Thu Jul 11 23:09:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 Jul 2024 23:09:00 GMT Subject: [jfx23u] RFR: 8336035: Change JavaFX release version to 23.0.1 in jfx23u In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 22:56:18 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 23.0.1 release. @johanvos In addition to reviewing this, can you add the needed maintainer approval, either using the Skara /approve command or directly in JBS? No hurry, since I do not plan to announce that this repo is open until some time next week. ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/1#issuecomment-2224094981 From hmeda at openjdk.org Fri Jul 12 09:59:09 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 12 Jul 2024 09:59:09 GMT Subject: RFR: 8328994 : Update WebKit to 619.1 Message-ID: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> This PR updates Webkit to v619.1. Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen. ------------- Commit messages: - whitespace correction - Update webkit to v619.1 Changes: https://git.openjdk.org/jfx/pull/1502/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8328994 Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod Patch: https://git.openjdk.org/jfx/pull/1502.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1502/head:pull/1502 PR: https://git.openjdk.org/jfx/pull/1502 From jhendrikx at openjdk.org Fri Jul 12 10:36:24 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Fri, 12 Jul 2024 10:36:24 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet Message-ID: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: if (hasInlineStyle) { Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); if (selector != null) selectors.add(selector); } ------------- Commit messages: - Remove origin determination from resolveLookups Changes: https://git.openjdk.org/jfx/pull/1503/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336097 Stats: 22 lines in 1 file changed: 0 ins; 16 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1503.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1503/head:pull/1503 PR: https://git.openjdk.org/jfx/pull/1503 From mhanl at openjdk.org Fri Jul 12 10:38:01 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 Jul 2024 10:38:01 GMT Subject: Integrated: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed In-Reply-To: References: Message-ID: On Fri, 8 Mar 2024 15:58:09 GMT, Marius Hanl wrote: > This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the > `-fx-show-delay` was set to another value. > > The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately. > > Added a bunch of headful and headless tests for the behaviour since there were none before. This pull request has now been integrated. Changeset: 5b448b8b Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/5b448b8bfddcfd062fb376132a48467e0d180a3c Stats: 568 lines in 9 files changed: 523 ins; 12 del; 33 mod 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1394 From kcr at openjdk.org Fri Jul 12 14:05:01 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jul 2024 14:05:01 GMT Subject: RFR: 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 In-Reply-To: <4wse4Ffh5_c2nxH6OrEIEXMX19gTU1BNFmr0DC4w_v8=.daa3df9b-be89-452b-8171-78d89e9a3702@github.com> References: <4wse4Ffh5_c2nxH6OrEIEXMX19gTU1BNFmr0DC4w_v8=.daa3df9b-be89-452b-8171-78d89e9a3702@github.com> Message-ID: On Thu, 11 Jul 2024 22:33:38 GMT, Marius Hanl wrote: > Tests that the `Stage Size` is between the `Visual Screen bounds - 50 (delta)` and `Screen bounds + 50 (delta)`. > -> `stageSize >= (visualBounds - 50)` & `stageSize <= (bounds + 50)`. > > Tested only on Windows 10 for now. Looks good. The test now passes everywhere I tried in, including my local Ubuntu 22.04 VM and our CI headful test platforms. Once integrated, please also backport this fix to the `jfx23` stabilization branch (using the `/backport :jfx23` command, either in this PR or in the eventual commit). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1501#pullrequestreview-2174973144 PR Comment: https://git.openjdk.org/jfx/pull/1501#issuecomment-2225653652 From angorya at openjdk.org Fri Jul 12 14:57:06 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jul 2024 14:57:06 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet In-Reply-To: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 12 Jul 2024 10:25:57 GMT, John Hendrikx wrote: > This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. > > Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: > > if (hasInlineStyle) { > Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); > if (selector != null) selectors.add(selector); > } Would it be possible to create a set of tests that verify _all_ the possible combinations of priorities and stylesheets (as well as Application/Scene/Parent/inline/code)? Also, do you think cssref.html should be updated to clarify the behavior in "Scene, Parent and SubScene Stylesheets" section? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2225766801 From mhanl at openjdk.org Fri Jul 12 15:15:59 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 Jul 2024 15:15:59 GMT Subject: Integrated: 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 In-Reply-To: <4wse4Ffh5_c2nxH6OrEIEXMX19gTU1BNFmr0DC4w_v8=.daa3df9b-be89-452b-8171-78d89e9a3702@github.com> References: <4wse4Ffh5_c2nxH6OrEIEXMX19gTU1BNFmr0DC4w_v8=.daa3df9b-be89-452b-8171-78d89e9a3702@github.com> Message-ID: <-X6_evEXluSrGlvF6MqFx0ozHlX2UTwaAls6Ay_h3MI=.5558228b-e4ef-4a90-8f92-1ac92356bb58@github.com> On Thu, 11 Jul 2024 22:33:38 GMT, Marius Hanl wrote: > Tests that the `Stage Size` is between the `Visual Screen bounds - 50 (delta)` and `Screen bounds + 50 (delta)`. > -> `stageSize >= (visualBounds - 50)` & `stageSize <= (bounds + 50)`. > > Tested only on Windows 10 for now. This pull request has now been integrated. Changeset: e3c15957 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/e3c15957488256ec53c5fb9978e336c59b69d65e Stats: 14 lines in 1 file changed: 9 ins; 1 del; 4 mod 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1501 From kcr at openjdk.org Fri Jul 12 15:17:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jul 2024 15:17:03 GMT Subject: RFR: 8328994 : Update WebKit to 619.1 In-Reply-To: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> References: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> Message-ID: On Fri, 12 Jul 2024 08:29:34 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v619.1. > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen. Reviewers: @kevinrushforth and @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1502#issuecomment-2225804482 From mhanl at openjdk.org Fri Jul 12 15:19:26 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 Jul 2024 15:19:26 GMT Subject: [jfx23] RFR: 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 Message-ID: <3KOLPC_RVJA5mJ-5LdH7XD_XCuD6rJJOt9QcGymi94g=.666c2fd1-e0af-4194-94e9-3a83000019e8@github.com> This pull request contains a backport of commit e3c15957 from the openjdk/jfx repository. ------------- Commit messages: - Backport e3c15957488256ec53c5fb9978e336c59b69d65e Changes: https://git.openjdk.org/jfx/pull/1504/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1504&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336272 Stats: 14 lines in 1 file changed: 9 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1504.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1504/head:pull/1504 PR: https://git.openjdk.org/jfx/pull/1504 From kcr at openjdk.org Fri Jul 12 15:19:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jul 2024 15:19:58 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data In-Reply-To: References: Message-ID: On Mon, 24 Jun 2024 22:10:38 GMT, Markus Mack wrote: > This PR is a fix for another IOOBE that I discovered while working on #1476. > > The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. > As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. > > Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. > > Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. > > Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. > Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. @drmarmac You need to merge the latest upstream master and fix the merge conflicts before this can proceed. Reviewers: @andy-goryachev-oracle @mstr2 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2225810187 From kcr at openjdk.org Fri Jul 12 15:35:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 Jul 2024 15:35:04 GMT Subject: [jfx23] RFR: 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 In-Reply-To: <3KOLPC_RVJA5mJ-5LdH7XD_XCuD6rJJOt9QcGymi94g=.666c2fd1-e0af-4194-94e9-3a83000019e8@github.com> References: <3KOLPC_RVJA5mJ-5LdH7XD_XCuD6rJJOt9QcGymi94g=.666c2fd1-e0af-4194-94e9-3a83000019e8@github.com> Message-ID: On Fri, 12 Jul 2024 15:14:47 GMT, Marius Hanl wrote: > This pull request contains a backport of commit e3c15957 from the openjdk/jfx repository. LGTM ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1504#pullrequestreview-2175198760 From mmack at openjdk.org Fri Jul 12 15:54:24 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 12 Jul 2024 15:54:24 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v2] In-Reply-To: References: Message-ID: > This PR is a fix for another IOOBE that I discovered while working on #1476. > > The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. > As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. > > Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. > > Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. > > Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. > Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java - BarChart: Fix adding non-empty series - BarChart: Add styleClass "negative" for added data ------------- Changes: https://git.openjdk.org/jfx/pull/1488/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1488&range=01 Stats: 83 lines in 2 files changed: 58 ins; 22 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1488.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1488/head:pull/1488 PR: https://git.openjdk.org/jfx/pull/1488 From mmack at openjdk.org Fri Jul 12 15:54:24 2024 From: mmack at openjdk.org (Markus Mack) Date: Fri, 12 Jul 2024 15:54:24 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data In-Reply-To: References: Message-ID: <0vGyV1S45X4INDsSLrQ3_bj6He8k2lHRmrOGxjZJuns=.b563fd97-d691-45f2-84ce-2c2dcdb6b180@github.com> On Mon, 24 Jun 2024 22:10:38 GMT, Markus Mack wrote: > This PR is a fix for another IOOBE that I discovered while working on #1476. > > The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. > As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. > > Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. > > Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. > > Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. > Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. I've updated to the current master branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2225869595 From angorya at openjdk.org Fri Jul 12 16:23:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jul 2024 16:23:57 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 15:54:24 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java > - BarChart: Fix adding non-empty series > - BarChart: Add styleClass "negative" for added data I don't see the 'negative' style added to negative bars. I do see BarChart:261 being hit, but nothing in the scene graph. Tested with the Monkey Tester and double checked with Scenic View 11.0.2: ![Screenshot 2024-07-12 at 09 18 36](https://github.com/user-attachments/assets/9f7d3a23-cce2-4d36-91e0-e84f24e0fd49) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2225917257 From mhanl at openjdk.org Fri Jul 12 17:55:56 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Fri, 12 Jul 2024 17:55:56 GMT Subject: [jfx23] Integrated: 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 In-Reply-To: <3KOLPC_RVJA5mJ-5LdH7XD_XCuD6rJJOt9QcGymi94g=.666c2fd1-e0af-4194-94e9-3a83000019e8@github.com> References: <3KOLPC_RVJA5mJ-5LdH7XD_XCuD6rJJOt9QcGymi94g=.666c2fd1-e0af-4194-94e9-3a83000019e8@github.com> Message-ID: On Fri, 12 Jul 2024 15:14:47 GMT, Marius Hanl wrote: > This pull request contains a backport of commit e3c15957 from the openjdk/jfx repository. This pull request has now been integrated. Changeset: e89443de Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/e89443dedc8b754f6a33bec6fa682b90cf43daf5 Stats: 14 lines in 1 file changed: 9 ins; 1 del; 4 mod 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 Reviewed-by: kcr Backport-of: e3c15957488256ec53c5fb9978e336c59b69d65e ------------- PR: https://git.openjdk.org/jfx/pull/1504 From angorya at openjdk.org Fri Jul 12 20:10:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jul 2024 20:10:03 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> Message-ID: On Wed, 10 Jul 2024 15:15:33 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/scene/TooltipTest.java line 233: >> >>> 231: window.getX() + scene.getX() + button.getLayoutX() + button.getLayoutBounds().getWidth() / 2, >>> 232: window.getY() + scene.getY() + button.getLayoutY() + button.getLayoutBounds().getHeight() / 2); >>> 233: tooltipStartTime = System.currentTimeMillis(); >> >> it is better to use `System.nanoTime()` instead of `currentTimeMillis()` for this kind of measurements because it is not affected by the updates to the current time (such as time sync). >> >> (since there are plenty of other places where we use `currentTimeMillis()` it's probably ok - very unlikely for the test to hit this scenario) > > That seems like a good overall test cleanup that could be done in a follow-up issue. created https://bugs.openjdk.org/browse/JDK-8336333 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1676413143 From angorya at openjdk.org Fri Jul 12 20:19:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 12 Jul 2024 20:19:00 GMT Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the first tooltip that is shown before it is displayed [v10] In-Reply-To: References: <5bCNwxcIYZMdT-HP9FZocNm4j723_br_O_WawHfO3X0=.83702995-19b8-4c8d-8866-f26ac7d2e395@github.com> Message-ID: <9YhXEHhaAuayVXeeUOJ9YpGxtEQzPteIUI0-JtI6KHo=.db049cc0-3423-4fbf-ac71-bbffb7f292c2@github.com> On Wed, 10 Jul 2024 15:14:42 GMT, Kevin Rushforth wrote: >> my comment was to avoid replicating "data:base64,", and with that, it is not base64 anymore, but base-64-encoded url. >> >> the best place for this method is probably in some utility class so it can be reused. > >> my comment was to avoid replicating "data:base64,", and with that, it is not base64 anymore, but base-64-encoded url. > > I see. > >> the best place for this method is probably in some utility class so it can be reused. > > Definitely, but let's do that in a follow-up testbug (and update the other test you pointed to at the same time). created https://bugs.openjdk.org/browse/JDK-8336334 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1676419856 From mmack at openjdk.org Sat Jul 13 10:00:31 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 13 Jul 2024 10:00:31 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: References: Message-ID: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> > This PR is a fix for another IOOBE that I discovered while working on #1476. > > The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. > As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. > > Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. > > Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. > > Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. > Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. Markus Mack has updated the pull request incrementally with one additional commit since the last revision: fix "negative" style class when series is changed ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1488/files - new: https://git.openjdk.org/jfx/pull/1488/files/a93a2036..4306eb75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1488&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1488&range=01-02 Stats: 34 lines in 2 files changed: 22 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1488.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1488/head:pull/1488 PR: https://git.openjdk.org/jfx/pull/1488 From mmack at openjdk.org Sat Jul 13 10:00:32 2024 From: mmack at openjdk.org (Markus Mack) Date: Sat, 13 Jul 2024 10:00:32 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v2] In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 15:54:24 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'refs/remotes/origin/master' into fixes/bar-chart-add-nonempty-series > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java > - BarChart: Fix adding non-empty series > - BarChart: Add styleClass "negative" for added data good catch, that was another situation where the "negative" style class was not added when adding a series that already contains data (which is the situation when the IOOBE occured). I fixed this in the relevant place, did some more code deduplication, and added another unit test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2226842131 From kcr at openjdk.org Sat Jul 13 14:27:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 13 Jul 2024 14:27:57 GMT Subject: RFR: 8328994 : Update WebKit to 619.1 In-Reply-To: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> References: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> Message-ID: <263SHGYu9jeg1dzH7eDCqUMdPpTTEbGB0RgP5sebxUw=.add3925c-c2b5-4fc1-997d-836adc058e8c@github.com> On Fri, 12 Jul 2024 08:29:34 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v619.1. > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen. Everything looks good. I'll finish my testing and approve on Monday. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1502#issuecomment-2226929112 From mstrauss at openjdk.org Sun Jul 14 05:47:03 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 14 Jul 2024 05:47:03 GMT Subject: RFR: 8332895: Support interpolation for backgrounds and borders [v3] In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 19:40:57 GMT, Michael Strau? wrote: >> This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. >> >> `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: >> >> >> Background { >> fills = [ >> BackgroundFill { >> fill = Color.RED >> } >> ] >> } >> >> >> Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. >> >> Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. >> >> More specifically, the following types will now implement `Interpolatable`. >> >> - `Insets` >> - `Background` >> - `BackgroundFill` >> - `BackgroundImage` >> - `BackgroundPosition` >> - `BackgroundSize` >> - `Border` >> - `BorderImage` >> - `BorderStroke` >> - `BorderWidths` >> - `CornerRadii` >> - `ImagePattern` >> - `LinearGradient` >> - `RadialGradient` >> - `Stop` >> >> ## Interpolation of composite objects >> >> As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". >> >> Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: >> >> | Interpolation type | Description | >> |---|---| >> | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | >> | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | >> | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | >> | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target li... > > 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 13 additional commits since the last revision: > > - fix line separators > - add documentation to Point2D/3D > - change documentation > - add specification > - add exports > - revert change > - revert change > - added more tests > - added specification and tests > - Merge branch 'master' into feature/interpolatable > - ... and 3 more: https://git.openjdk.org/jfx/compare/2b1d13d2...08ed751b As proposed, this enhancement doesn't cover some edge cases. Back to the drawing board. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1471#issuecomment-2227203783 From mstrauss at openjdk.org Sun Jul 14 05:47:04 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sun, 14 Jul 2024 05:47:04 GMT Subject: Withdrawn: 8332895: Support interpolation for backgrounds and borders In-Reply-To: References: Message-ID: On Sun, 2 Jun 2024 18:50:20 GMT, Michael Strau? wrote: > This PR completes the CSS Transitions story (see #870) by adding interpolation support for backgrounds and borders, making them targetable by transitions. > > `Background` and `Border` objects are deeply immutable, but not interpolatable. Consider the following `Background`, which describes the background of a `Region`: > > > Background { > fills = [ > BackgroundFill { > fill = Color.RED > } > ] > } > > > Since backgrounds are deeply immutable, changing the region's background to another color requires the construction of a new `Background`, containing a new `BackgroundFill`, containing the new `Color`. > > Animating the background color using a CSS transition therefore requires the entire Background object graph to be interpolatable in order to generate intermediate backgrounds. > > More specifically, the following types will now implement `Interpolatable`. > > - `Insets` > - `Background` > - `BackgroundFill` > - `BackgroundImage` > - `BackgroundPosition` > - `BackgroundSize` > - `Border` > - `BorderImage` > - `BorderStroke` > - `BorderWidths` > - `CornerRadii` > - `ImagePattern` > - `LinearGradient` > - `RadialGradient` > - `Stop` > > ## Interpolation of composite objects > > As of now, only `Color`, `Point2D`, and `Point3D` are interpolatable. Each of these classes is an aggregate of `double` values, which are combined using linear interpolation. However, many of the new interpolatable classes comprise of not only `double` values, but a whole range of other types. This requires us to more precisely define what we mean by "interpolation". > > Mirroring the CSS specification, the `Interpolatable` interface defines several types of component interpolation: > > | Interpolation type | Description | > |---|---| > | default | Component types that implement `Interpolatable` are interpolated by calling the `interpolate(Object, double)}` method. | > | linear | Two components are combined by linear interpolation such that `t = 0` produces the start value, and `t = 1` produces the end value. This interpolation type is usually applicable for numeric components. | > | discrete | If two components cannot be meaningfully combined, the intermediate component value is equal to the start value for `t < 0.5` and equal to the end value for `t >= 0.5`. | > | pairwise | Two lists are combined by pairwise interpolation. If the start list has fewer elements than the target list, the missing elements are copied from the target list. If the start list has more elements than the target list, the excess elements are discarded.... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1471 From jvos at openjdk.org Sun Jul 14 14:01:57 2024 From: jvos at openjdk.org (Johan Vos) Date: Sun, 14 Jul 2024 14:01:57 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: <-qRnaXQG_AU9r-NvPxF4fzlIgc0qrxJjAIjbDa_9qIk=.b12ef325-c1d9-47c3-b86a-17e80ddb6ea7@github.com> On Tue, 9 Jul 2024 14:50:08 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/com/sun/javafx/tk/quantum/SystemMenuBarTest.java line 321: >> >>> 319: Stage stage = new Stage(); >>> 320: stage.setScene(new Scene(root)); >>> 321: stage.show(); >> >> I think, a CountDownLatch should be added to make sure that stage is shown before proceeding. > > One correction: `Stage.show` is not a blocking call. I haven't looked at it closely, but perhaps what @arapte meant was to suggest that the test wait on a latch that is triggered when the Stage::showing event is delivered? Many of our headful tests do that, but I don't know whether that would be applicable here or not. Right, it wasn't correct to call it a "blocking call". However, before Stage.show() returns, the contents of the stage are created and their layoutChildren method is invoked (before the WINDOW_SHOWN is fired). All Runnables that are scheduled during this method will be executed before the content in the next Util.runAndWait() is executed, so I'm not sure what we should be waiting for? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1677141136 From arapte at openjdk.org Mon Jul 15 05:18:01 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 15 Jul 2024 05:18:01 GMT Subject: [jfx23u] RFR: 8336035: Change JavaFX release version to 23.0.1 in jfx23u In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 22:56:18 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 23.0.1 release. Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/1#pullrequestreview-2176869193 From jhendrikx at openjdk.org Mon Jul 15 12:10:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 12:10:01 GMT Subject: RFR: 8290310: ChangeListener events are incorrect or misleading when a nested change occurs In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com> Message-ID: On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote: > This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics. > > # Behavior > > |Listener...|ExpressionHelper|ListenerManager| > |---|---|---| > |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)| > |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting| > |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting| > > ## Nested notifications: > > | |ExpressionHelper|ListenerManager| > |---|---|---| > |Type|Depth first (call stack increases for each nested level)|(same)| > |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes| > |Vetoing Possible?|No|Yes| > |Old Value correctness|Only for listeners called before listeners making nested changes|Always| > > # Performance > > |Listener|ExpressionHelper|ListenerManager| > |---|---|---| > |Addition|Array based, append in empty slot, resize as needed|(same)| > |Removal|Array based, shift array, resize as needed|(same)| > |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes| > |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)| > |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed| > |Notifying Invalidation Listeners|1 ns each|(same)| > |Notifying Change Listeners|1 ns each (*)|2-3 ns each| > > (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values > > # Memory Use > > Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops. > > |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager| > |---|---|---|---| > |No Listeners|none|none|none| > |Single InvalidationListener|16 bytes overhead|none|none| > |Single ChangeListener|20 bytes overhead|none|16 bytes overhead| > |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)| > > # About nested changes > > Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This... Keep this open... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2228348243 From jhendrikx at openjdk.org Mon Jul 15 12:10:27 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 12:10:27 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: > This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. > > Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: > > if (hasInlineStyle) { > Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); > if (selector != null) selectors.add(selector); > } John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add test case ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1503/files - new: https://git.openjdk.org/jfx/pull/1503/files/8b989e83..73b910af Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=00-01 Stats: 114 lines in 1 file changed: 103 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1503.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1503/head:pull/1503 PR: https://git.openjdk.org/jfx/pull/1503 From jhendrikx at openjdk.org Mon Jul 15 12:13:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 12:13:59 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 12 Jul 2024 14:54:28 GMT, Andy Goryachev wrote: > Would it be possible to create a set of tests that verify _all_ the possible combinations of priorities and stylesheets (as well as Application/Scene/Parent/inline/code)? > > Also, do you think cssref.html should be updated to clarify the behavior in "Scene, Parent and SubScene Stylesheets" section? @andy-goryachev-oracle I've added a test for the specific fix I did. Without my fix, cases 5 and 6 (`PROPERTY_OVERRIDES_USER_AGENT_VARIABLE_SET_IN_AUTHOR` and `PROPERTY_OVERRIDES_USER_AGENT_VARIABLE_SET_INLINE`) fail. With my fix, they pass. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2228355168 From jhendrikx at openjdk.org Mon Jul 15 12:32:59 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 12:32:59 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:11:03 GMT, John Hendrikx wrote: > Also, do you think cssref.html should be updated to clarify the behavior in "Scene, Parent and SubScene Stylesheets" section? @andy-goryachev-oracle That section is about cascading rules, and doesn't even mention lookups. In fact, the whole CSS reference does not mention lookups (aside from mentioning that JavaFX has a "property lookup" feature, and an indirect mention in the form of "looked-up-color"). There is no mention how property look ups work (and what types it supports), how they should be named (any name is allowed as long as it is not a supported color name), or how they cascade (before this fix, they gave styles a new priority, after this fix, the priority of the style is unchanged). As this is quite some work, I think documenting this feature calls for a separate task to avoid delaying this fix. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2228390544 From jhendrikx at openjdk.org Mon Jul 15 13:00:00 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 13:00:00 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:10:27 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case As a side note, there is a bug in the loop detection code in `resolveLookups`. A `Set` is used to track what `ParsedValue`s have been visited before, but in a few places this set is cleared. If this happens in a recursive call, and the caller has to do another lookup replacement, it has lost what `ParsedValue`s it visited before. I'll file another issue for that as I already have a test case that results in a `StackOverflowError`: @Test public void infiniteLoop() throws IOException { Stylesheet stylesheet = new CssParser().parse("userAgentStylSheet", """ .root { -fx-base-fill: ladder(-fx-base, white 49%, black 50%); -fx-base: ladder(-fx-base-fill, white 49%, black 50%); } .pane { -fx-background-color: -fx-base; } """); StyleManager.getInstance().setDefaultUserAgentStylesheet(stylesheet); Pane a = new Pane(); a.getStyleClass().add("pane"); root.getChildren().addAll(a); stage.show(); Toolkit.getToolkit().firePulse(); } ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2228444299 From kcr at openjdk.org Mon Jul 15 13:16:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jul 2024 13:16:59 GMT Subject: RFR: 8328994 : Update WebKit to 619.1 In-Reply-To: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> References: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> Message-ID: On Fri, 12 Jul 2024 08:29:34 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v619.1. > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen. Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1502#pullrequestreview-2177683926 From jhendrikx at openjdk.org Mon Jul 15 13:26:24 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 13:26:24 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups Message-ID: Fixes an infinite loop that can occur while resolving lookups. There were 2 bugs: - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). ------------- Commit messages: - Fix loop detection in resolveLookups Changes: https://git.openjdk.org/jfx/pull/1505/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336389 Stats: 63 lines in 2 files changed: 49 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From jhendrikx at openjdk.org Mon Jul 15 13:30:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 15 Jul 2024 13:30:13 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: Message-ID: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fix formatting and spelling ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1505/files - new: https://git.openjdk.org/jfx/pull/1505/files/864ef9b2..5f949e32 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=00-01 Stats: 27 lines in 1 file changed: 6 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From angorya at openjdk.org Mon Jul 15 16:36:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Jul 2024 16:36:00 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> References: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> Message-ID: On Sat, 13 Jul 2024 10:00:31 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > fix "negative" style class when series is changed modules/javafx.controls/src/test/java/test/javafx/scene/chart/BarChartTest.java line 305: > 303: BarChart chart = new BarChart<>(new CategoryAxis(), new NumberAxis()); > 304: XYChart.Series series = new XYChart.Series<>(); > 305: chart.getData().add(series); speaking of negative values - could we check **all** the possible ways where the 'negative' class is added? or removed? I think it might be possible to add a check to the exiting tests, to reuse the setup. Lastly, I think we also need to test the case when the data point becomes non-negative after explicit XYChart.Data.setValue(), do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1488#discussion_r1678109067 From angorya at openjdk.org Mon Jul 15 16:44:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Jul 2024 16:44:57 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> References: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> Message-ID: On Sat, 13 Jul 2024 10:00:31 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > fix "negative" style class when series is changed I am going to ask this question - unrelated to this PR, but in the context of this PR. Consider the case of a context menu, where the application needs to know the data point from the screen/local coordinates. Currently, we can get the Node from the Data instance (XYChart.Data.node property), but not the other way around - that is, given the chart, and given the PickResult of a MouseEvent, it is impossible to get the data point corresponding to a Node. In other words, we have the model->view path but not the view->model one. In theory, the app developer could monitor the `node` property of Data and use `Node.getProperties()` map to set the Data instance on the node, or they could iterate through all the visible data points, matching the node with the data point, so it is not a big issue. I am interested in your opinion. What do you think? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1488#issuecomment-2228944603 From angorya at openjdk.org Mon Jul 15 17:01:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Jul 2024 17:01:58 GMT Subject: RFR: 8334900: IOOBE when adding data to a Series of a BarChart that already contains data [v3] In-Reply-To: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> References: <4cVDMTgIWuLJHRGF7UNW5M3gLLxHWm2E3t399VFe-Yw=.4d13d68c-6579-4a7d-a8ca-550cb580c5f7@github.com> Message-ID: On Sat, 13 Jul 2024 10:00:31 GMT, Markus Mack wrote: >> This PR is a fix for another IOOBE that I discovered while working on #1476. >> >> The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. >> As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact. >> >> Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added. >> >> Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart. >> >> Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0. >> Without this change `testSeriesRemoveAnimatedStyleClasses` would fail because it counts the number of plot children, where the duplicates are now removed. > > Markus Mack has updated the pull request incrementally with one additional commit since the last revision: > > fix "negative" style class when series is changed The changes look good. I think it would be nice to test all possible ways the `negative` class is added or removed as part of this PR. What do you think? ------------- PR Review: https://git.openjdk.org/jfx/pull/1488#pullrequestreview-2178241074 From mstrauss at openjdk.org Mon Jul 15 19:08:57 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 15 Jul 2024 19:08:57 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 15 Jul 2024 13:30:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting and spelling A new `HashSet` is created for every base call to `resolveLookups`, but it is only used for state tracking. We could re-use the instance for subsequent calls. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2229194479 From kcr at openjdk.org Mon Jul 15 19:42:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jul 2024 19:42:26 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 Message-ID: This PR solves two related bugs that are caused by events being delivered while the FX runtime is in the process of shutting down. These bugs are related enough that I think they need to be addressed at the same time. While debugging and developing the test, I saw one or the other or both in various test runs. The system test included with this program verifies that there is no crash and no exception, so will catch either failure mode. This can happen when there is a full-screen window showing during shutdown on macOS, since full screen enter / exit uses a nested event loop that affects the order of operation. This could theoretically happen in other cases, thus the fix does not involve checking whether we are in full-screen or whether there is a nested event loop. The fix does the following: 1. `GlassWindow+Overrides.m`: Check that the JVM is still running before calling the Java notification method in `windowDidResignKey` and `windowShouldClose`. This matches what is already done for other similar methods in this class. This is the fix for JDK-8335630. 2. `Window.java` and `View.java`: Check whether the Application instance is null in the event notification callbacks, and skip handling the event if it is. This is the fix for JDK-8299738. Note that the fix for 2 is in platform-independent code. This should be fine, since we would want to skip the event handling callback on any other platform if it were done during shutdown, in order to avoid the ISE. I have included a system test that passes on all platforms. On macOS, the test will fail without the fix and pass with the fix. Details of the fix are below: `Platform::exit` is called by the application to shutdown the JavaFX toolkit. The implementation of `Platform::exit` calls `Toolkit::exit` on the JavaFX Application thread, which in turn calls glass `Application::terminate` to shut it down. `Application::terminate` will close all the native windows, and call `finishTerminating` to terminate the native event loop and detach the thread from the JVM. This is asynchronous, at least on macOS, and will schedule the termination by posting a native event to the event loop. on macOS 13, and sometimes on macOS 14, a Window or View event handler can be called between `Toolkit::exit`/`Application::terminate` (which sets the Toolkit's cached thread to null and the glass Application instance to null) and the JVM shutdown. This will make a JNI upcall to the appropriate Window or View `handleXxxxx` method, which will deliver it to the registered event handler. Because the Toolkit thread has been set to null, the "are we on the JavaFX Application thread" check will fail and it will throw an ISE. Since it can't usefully do anything anyway, we just want to skip handling it. On macOS 14, `windowDidResignKey` can be called after the JVM is shutdown, causing an assertion print statement and then a crash when it tries to call a JNI method using a NULL `env` pointer. We need to use the `GET_MAIN_JENV_NOWARN` flavor of the macro to get the JNI `env`, and then check `env` for non-null. NOTE: I intend to backport this to the `jfx23` stabilization branch for JavaFX 23 after it is integrated into mainline. ------------- Commit messages: - Revert "Debug prints" - Debug prints - 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 Changes: https://git.openjdk.org/jfx/pull/1506/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1506&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335630 Stats: 157 lines in 4 files changed: 130 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1506.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1506/head:pull/1506 PR: https://git.openjdk.org/jfx/pull/1506 From kizune at openjdk.org Mon Jul 15 21:17:09 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Mon, 15 Jul 2024 21:17:09 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol Message-ID: Initial implementation of the protocol. ------------- Commit messages: - 8336031: Create implementation of NSAccessibilityStaticText protocol Changes: https://git.openjdk.org/jfx/pull/1507/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336031 Stats: 112 lines in 3 files changed: 110 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1507.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1507/head:pull/1507 PR: https://git.openjdk.org/jfx/pull/1507 From angorya at openjdk.org Mon Jul 15 22:12:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Jul 2024 22:12:54 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:36:43 GMT, Kevin Rushforth wrote: > This PR solves two related bugs that are caused by events being delivered while the FX runtime is in the process of shutting down. These bugs are related enough that I think they need to be addressed at the same time. While debugging and developing the test, I saw one or the other or both in various test runs. The system test included with this program verifies that there is no crash and no exception, so will catch either failure mode. > > This can happen when there is a full-screen window showing during shutdown on macOS, since full screen enter / exit uses a nested event loop that affects the order of operation. This could theoretically happen in other cases, thus the fix does not involve checking whether we are in full-screen or whether there is a nested event loop. > > The fix does the following: > > 1. `GlassWindow+Overrides.m`: Check that the JVM is still running before calling the Java notification method in `windowDidResignKey` and `windowShouldClose`. This matches what is already done for other similar methods in this class. This is the fix for JDK-8335630. > 2. `Window.java` and `View.java`: Check whether the Application instance is null in the event notification callbacks, and skip handling the event if it is. This is the fix for JDK-8299738. > > Note that the fix for 2 is in platform-independent code. This should be fine, since we would want to skip the event handling callback on any other platform if it were done during shutdown, in order to avoid the ISE. > > I have included a system test that passes on all platforms. On macOS, the test will fail without the fix and pass with the fix. > > Details of the fix are below: > > `Platform::exit` is called by the application to shutdown the JavaFX toolkit. The implementation of `Platform::exit` calls `Toolkit::exit` on the JavaFX Application thread, which in turn calls glass `Application::terminate` to shut it down. `Application::terminate` will close all the native windows, and call `finishTerminating` to terminate the native event loop and detach the thread from the JVM. This is asynchronous, at least on macOS, and will schedule the termination by posting a native event to the event loop. > > on macOS 13, and sometimes on macOS 14, a Window or View event handler can be called between `Toolkit::exit`/`Application::terminate` (which sets the Toolkit's cached thread to null and the glass Application instance to null) and the JVM shutdown. This will make a JNI upcall to the appropriate Window or View `handleXxxxx` method, which... The fix produces no exception and no crash on macOS 14.5 running on M1. modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 533: > 531: private boolean shouldHandleEvent() { > 532: // Don't send any more events if the application has shutdown > 533: if (Application.GetApplication() == null) { Should we declare `Application.application` field as volatile? I see interleaved multi-threaded access pattern: thread=JavaFX-Launcher CREATE thread=JavaFX-Launcher thread=JavaFX-Launcher thread=Thread-2 thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX-Launcher thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX-Launcher thread=JavaFX Application Thread thread=PulseTimer-CVDisplayLink thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=QuantumRenderer-0 thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=PulseTimer-CVDisplayLink thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX-Launcher thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX-Launcher thread=JavaFX-Launcher thread=JavaFX-Launcher thread=QuantumRenderer-0 thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread thread=JavaFX Application Thread FINISH thread=JavaFX Application Thread It might be ok though, since both creation and setting to null is done by the FX App thread. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1506#pullrequestreview-2178760909 PR Review Comment: https://git.openjdk.org/jfx/pull/1506#discussion_r1678448367 From mstrauss at openjdk.org Mon Jul 15 22:36:55 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 15 Jul 2024 22:36:55 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 22:08:12 GMT, Andy Goryachev wrote: >> This PR solves two related bugs that are caused by events being delivered while the FX runtime is in the process of shutting down. These bugs are related enough that I think they need to be addressed at the same time. While debugging and developing the test, I saw one or the other or both in various test runs. The system test included with this program verifies that there is no crash and no exception, so will catch either failure mode. >> >> This can happen when there is a full-screen window showing during shutdown on macOS, since full screen enter / exit uses a nested event loop that affects the order of operation. This could theoretically happen in other cases, thus the fix does not involve checking whether we are in full-screen or whether there is a nested event loop. >> >> The fix does the following: >> >> 1. `GlassWindow+Overrides.m`: Check that the JVM is still running before calling the Java notification method in `windowDidResignKey` and `windowShouldClose`. This matches what is already done for other similar methods in this class. This is the fix for JDK-8335630. >> 2. `Window.java` and `View.java`: Check whether the Application instance is null in the event notification callbacks, and skip handling the event if it is. This is the fix for JDK-8299738. >> >> Note that the fix for 2 is in platform-independent code. This should be fine, since we would want to skip the event handling callback on any other platform if it were done during shutdown, in order to avoid the ISE. >> >> I have included a system test that passes on all platforms. On macOS, the test will fail without the fix and pass with the fix. >> >> Details of the fix are below: >> >> `Platform::exit` is called by the application to shutdown the JavaFX toolkit. The implementation of `Platform::exit` calls `Toolkit::exit` on the JavaFX Application thread, which in turn calls glass `Application::terminate` to shut it down. `Application::terminate` will close all the native windows, and call `finishTerminating` to terminate the native event loop and detach the thread from the JVM. This is asynchronous, at least on macOS, and will schedule the termination by posting a native event to the event loop. >> >> on macOS 13, and sometimes on macOS 14, a Window or View event handler can be called between `Toolkit::exit`/`Application::terminate` (which sets the Toolkit's cached thread to null and the glass Application instance to null) and the JVM shutdown. This will make a JNI upcall to the appropriate Window... > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 533: > >> 531: private boolean shouldHandleEvent() { >> 532: // Don't send any more events if the application has shutdown >> 533: if (Application.GetApplication() == null) { > > Should we declare `Application.application` field as volatile? > > I see interleaved multi-threaded access pattern: > > > thread=JavaFX-Launcher > CREATE thread=JavaFX-Launcher > thread=JavaFX-Launcher > thread=Thread-2 > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX-Launcher > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX-Launcher > thread=JavaFX Application Thread > thread=PulseTimer-CVDisplayLink thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=QuantumRenderer-0 > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=PulseTimer-CVDisplayLink thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX-Launcher > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=JavaFX Application Thread > thread=Java... Other threads may still not see the current value of the `Application.application` field. Is it safe for other threads to use the `Application` instance after the field has been set to `null`? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1506#discussion_r1678465264 From kcr at openjdk.org Mon Jul 15 22:56:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jul 2024 22:56:56 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 22:34:27 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/glass/ui/View.java line 533: >> >>> 531: private boolean shouldHandleEvent() { >>> 532: // Don't send any more events if the application has shutdown >>> 533: if (Application.GetApplication() == null) { >> >> Should we declare `Application.application` field as volatile? >> >> I see interleaved multi-threaded access pattern: >> >> >> thread=JavaFX-Launcher >> CREATE thread=JavaFX-Launcher >> thread=JavaFX-Launcher >> thread=Thread-2 >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX-Launcher >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX-Launcher >> thread=JavaFX Application Thread >> thread=PulseTimer-CVDisplayLink thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=QuantumRenderer-0 >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=PulseTimer-CVDisplayLink thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Application Thread >> thread=JavaFX Applicati... > > Other threads may still not see the current value of the `Application.application` field. Is it safe for other threads to use the `Application` instance after the field has been set to `null`? This is unrelated to the current bug, since all accesses are happening on the FX app thread, so I'd like to file a follow-up to look into this. To answer the question, there might be a potential problem with other threads not seeing that the `Application.application` field has been set to null. Other threads do not access the glass Application directly. Most methods requires the app to be on the application thread, and will correctly detect and fail whether they see the old or new value of `Application.application`, so those operations will be fine. One scenario that should be examined is `Platform.runLater`, which could call into glass and see the old value of application. There are related fields in `Tooklit` (e.g., the `fxUserThread` variable) that ought to be examined at the same time. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1506#discussion_r1678482756 From angorya at openjdk.org Mon Jul 15 23:05:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 15 Jul 2024 23:05:56 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: <36VKZp_5p7fwI5Y3aTnU7COOYq1MMpl558G8BEo7RJ8=.6a780925-f303-4eec-a354-821fdd0e4454@github.com> On Mon, 15 Jul 2024 22:53:52 GMT, Kevin Rushforth wrote: > since all accesses are happening on the FX app thread Not quite right: the following threads access the field, apart from JavaFX Application Thread: thread=JavaFX-Launcher thread=Thread-2 thread=PulseTimer-CVDisplayLink thread thread=QuantumRenderer-0 The output above logs thread names that access `Application.application` field, running the reproducer attached to both tickets. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1506#discussion_r1678487838 From kcr at openjdk.org Mon Jul 15 23:33:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 15 Jul 2024 23:33:55 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: <36VKZp_5p7fwI5Y3aTnU7COOYq1MMpl558G8BEo7RJ8=.6a780925-f303-4eec-a354-821fdd0e4454@github.com> References: <36VKZp_5p7fwI5Y3aTnU7COOYq1MMpl558G8BEo7RJ8=.6a780925-f303-4eec-a354-821fdd0e4454@github.com> Message-ID: On Mon, 15 Jul 2024 23:03:10 GMT, Andy Goryachev wrote: >> This is unrelated to the current bug, since all accesses are happening on the FX app thread, so I'd like to file a follow-up to look into this. >> >> To answer the question, there might be a potential problem with other threads not seeing that the `Application.application` field has been set to null. >> >> Other threads do not access the glass Application directly. Most methods requires the app to be on the application thread, and will correctly detect and fail whether they see the old or new value of `Application.application`, so those operations will be fine. >> >> One scenario that should be examined is `Platform.runLater`, which could call into glass and see the old value of application. There are related fields in `Tooklit` (e.g., the `fxUserThread` variable) that ought to be examined at the same time. > >> since all accesses are happening on the FX app thread > > Not quite right: the following threads access the field, apart from JavaFX Application Thread: > > > thread=JavaFX-Launcher > thread=Thread-2 > thread=PulseTimer-CVDisplayLink thread > thread=QuantumRenderer-0 > > > The output above logs thread names that access `Application.application` field, running the reproducer attached to both tickets. To clarify, I'm talking about the accesses that have anything to do with this bug, and specifically, the methods that I modified. Those are all on the FX application thread. Unrelated to this bug, there are plenty of calls to Platform.runLater on other threads, which will indeed access the `Application.application` field from that other thread. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1506#discussion_r1678502901 From gidi.gal at gmail.com Tue Jul 16 08:09:11 2024 From: gidi.gal at gmail.com (Gidi Gal) Date: Tue, 16 Jul 2024 11:09:11 +0300 Subject: Creating javafx-sdk-independent jar file Message-ID: Hello, I have a small intellij project which uses javafx through the pom.xml (maven) file. I'd like to create a runnable and independent jar file for it. "Independent", means that I don't want my users to need to install javafx sdk on their machine. I have tried using maven-shade-plugin, but when I try to call the jar file it keeps outputting the error message "Error: JavaFX runtime components are missing, and are required to run this application". If you have any link with an example how this can be done, I'll be grateful if you could share it. Thanks, Gidi -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Jul 16 11:19:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 11:19:24 GMT Subject: [jfx22u] RFR: 8336327: Create release notes for JavaFX 22.0.2 Message-ID: Release notes for JavaFX 22.0.2. Notes to reviewers: I used the following filter to pick the issues: https://bugs.openjdk.org/issues/?filter=45846 The original filter, with the backport IDs, is here: https://bugs.openjdk.org/issues/?filter=45845 As usual, I excluded test bugs, cleanup bugs, etc. NOTE: Once the CPU release ships on 2024-07-16, I will add any security bugs and make this PR `rfr`. ------------- Commit messages: - No security content - 8336327: Create release notes for JavaFX 22.0.2 Changes: https://git.openjdk.org/jfx22u/pull/33/files Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=33&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336327 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/33.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/33/head:pull/33 PR: https://git.openjdk.org/jfx22u/pull/33 From duke at openjdk.org Tue Jul 16 11:19:24 2024 From: duke at openjdk.org (Abhinay Agarwal) Date: Tue, 16 Jul 2024 11:19:24 GMT Subject: [jfx22u] RFR: 8336327: Create release notes for JavaFX 22.0.2 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 18:44:15 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 22.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45846 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45845 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2024-07-16, I will add any security bugs and make this PR `rfr`. Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/33#pullrequestreview-2179945329 From kcr at openjdk.org Tue Jul 16 11:19:24 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 11:19:24 GMT Subject: [jfx22u] RFR: 8336327: Create release notes for JavaFX 22.0.2 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 18:44:15 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 22.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45846 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45845 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2024-07-16, I will add any security bugs and make this PR `rfr`. Reviewers: @johanvos @abhinayagarwal @johanvos @abhinayagarwal There is no security content for this release, so this is now ready for review. Johan: in addition to reviewing it, can you add maintainer approval (either using the `/approve yes` command or directly in JBS)? ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/33#issuecomment-2226173931 PR Comment: https://git.openjdk.org/jfx22u/pull/33#issuecomment-2230635873 From kcr at openjdk.org Tue Jul 16 11:23:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 11:23:58 GMT Subject: [jfx22u] RFR: Merge b2c7b485d9ebf3c773693c4310f31d90aec6f7d6 Message-ID: Clean merge of July CPU content into `jfx22u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits. There are no changes to the contents of this repo. ------------- Commit messages: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - ... and 3 more: https://git.openjdk.org/jfx22u/compare/f0c3e88a...b2c7b485 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx22u/pull/34/files Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/34.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/34/head:pull/34 PR: https://git.openjdk.org/jfx22u/pull/34 From kcr at openjdk.org Tue Jul 16 11:23:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 11:23:59 GMT Subject: [jfx22u] RFR: Merge b2c7b485d9ebf3c773693c4310f31d90aec6f7d6 In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 11:18:34 GMT, Kevin Rushforth wrote: > Clean merge of July CPU content into `jfx22u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits. There are no changes to the contents of this repo. Reviewer: @johanvos or @arapte ------------- PR Comment: https://git.openjdk.org/jfx22u/pull/34#issuecomment-2230644344 From jvos at openjdk.org Tue Jul 16 11:46:57 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jul 2024 11:46:57 GMT Subject: [jfx22u] RFR: 8336327: Create release notes for JavaFX 22.0.2 In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 18:44:15 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 22.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45846 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45845 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2024-07-16, I will add any security bugs and make this PR `rfr`. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/33#pullrequestreview-2179998494 From kcr at openjdk.org Tue Jul 16 11:58:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 11:58:58 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: <36VKZp_5p7fwI5Y3aTnU7COOYq1MMpl558G8BEo7RJ8=.6a780925-f303-4eec-a354-821fdd0e4454@github.com> Message-ID: On Mon, 15 Jul 2024 23:31:43 GMT, Kevin Rushforth wrote: >>> since all accesses are happening on the FX app thread >> >> Not quite right: the following threads access the field, apart from JavaFX Application Thread: >> >> >> thread=JavaFX-Launcher >> thread=Thread-2 >> thread=PulseTimer-CVDisplayLink thread >> thread=QuantumRenderer-0 >> >> >> The output above logs thread names that access `Application.application` field, running the reproducer attached to both tickets. > > To clarify, I'm talking about the accesses that have anything to do with this bug, and specifically, the methods that I modified. Those are all on the FX application thread. Unrelated to this bug, there are plenty of calls to Platform.runLater on other threads, which will indeed access the `Application.application` field from that other thread. I filed [JDK-8336476](https://bugs.openjdk.org/browse/JDK-8336476) as a follow-up bug to address the race condition. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1506#discussion_r1679261056 From jvos at openjdk.org Tue Jul 16 13:05:59 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 16 Jul 2024 13:05:59 GMT Subject: [jfx22u] RFR: Merge b2c7b485d9ebf3c773693c4310f31d90aec6f7d6 In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 11:18:34 GMT, Kevin Rushforth wrote: > Clean merge of July CPU content into `jfx22u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits. There are no changes to the contents of this repo. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx22u/pull/34#pullrequestreview-2180173572 From sykora at openjdk.org Tue Jul 16 13:12:59 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Tue, 16 Jul 2024 13:12:59 GMT Subject: RFR: 8328994 : Update WebKit to 619.1 In-Reply-To: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> References: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> Message-ID: On Fri, 12 Jul 2024 08:29:34 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v619.1. > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen. All builds succeeded. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1502#pullrequestreview-2180192559 From hmeda at openjdk.org Tue Jul 16 14:08:03 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Tue, 16 Jul 2024 14:08:03 GMT Subject: Integrated: 8328994 : Update WebKit to 619.1 In-Reply-To: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> References: <5CqU02rIyp8L2YEiMLXewo9hOOzPDwKgsC1MjnaoIqM=.ac56fe30-b4e2-412d-b580-7c6ebd8b63ce@github.com> Message-ID: On Fri, 12 Jul 2024 08:29:34 GMT, Hima Bindu Meda wrote: > This PR updates Webkit to v619.1. > Build is verified in mac , windows and linux. Sanity testing looks fine. No issues seen. This pull request has now been integrated. Changeset: 34bbf853 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx/commit/34bbf85362fae946c6306eb52a8478aa2ca3ef5f Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod 8328994: Update WebKit to 619.1 Co-authored-by: Jay Bhaskar Reviewed-by: kcr, sykora ------------- PR: https://git.openjdk.org/jfx/pull/1502 From kcr at openjdk.org Tue Jul 16 14:36:14 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 14:36:14 GMT Subject: [jfx22u] RFR: Merge b2c7b485d9ebf3c773693c4310f31d90aec6f7d6 [v2] In-Reply-To: References: Message-ID: <561jzvDKlt5btC3oCTOUU9TLb2dIwF_fouvLXBznSV0=.0961cddb-f73d-4a07-a6ea-345804a49b8c@github.com> > Clean merge of July CPU content into `jfx22u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits. There are no changes to the contents of this repo. Kevin Rushforth 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. ------------- Changes: - all: https://git.openjdk.org/jfx22u/pull/34/files - new: https://git.openjdk.org/jfx22u/pull/34/files/b2c7b485..b2c7b485 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx22u&pr=34&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx22u&pr=34&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx22u/pull/34.diff Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/34/head:pull/34 PR: https://git.openjdk.org/jfx22u/pull/34 From kcr at openjdk.org Tue Jul 16 14:36:15 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 14:36:15 GMT Subject: [jfx22u] Integrated: Merge b2c7b485d9ebf3c773693c4310f31d90aec6f7d6 In-Reply-To: References: Message-ID: On Tue, 16 Jul 2024 11:18:34 GMT, Kevin Rushforth wrote: > Clean merge of July CPU content into `jfx22u:master`. Note that this is a no-op merge, since there is no security content for this release. The only content is some identity merge commits. There are no changes to the contents of this repo. This pull request has now been integrated. Changeset: 04a7dbc3 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/04a7dbc3cc24a15085b59b63cc337c5a9484604a Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Merge Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx22u/pull/34 From kcr at openjdk.org Tue Jul 16 14:38:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 14:38:02 GMT Subject: [jfx22u] Integrated: 8336327: Create release notes for JavaFX 22.0.2 In-Reply-To: References: Message-ID: <4WqALLhoUw-D2g59QfKUkFD20PTzSzdO1aDk2E538Qs=.8844fec2-c941-4e65-92d5-ceaa053bca09@github.com> On Fri, 12 Jul 2024 18:44:15 GMT, Kevin Rushforth wrote: > Release notes for JavaFX 22.0.2. > > Notes to reviewers: > > I used the following filter to pick the issues: > > https://bugs.openjdk.org/issues/?filter=45846 > > The original filter, with the backport IDs, is here: > > https://bugs.openjdk.org/issues/?filter=45845 > > As usual, I excluded test bugs, cleanup bugs, etc. > > NOTE: Once the CPU release ships on 2024-07-16, I will add any security bugs and make this PR `rfr`. This pull request has now been integrated. Changeset: 7cc98721 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx22u/commit/7cc98721b51b86d83c11b753b2513c7def2a8690 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod 8336327: Create release notes for JavaFX 22.0.2 Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx22u/pull/33 From duke at openjdk.org Tue Jul 16 16:11:01 2024 From: duke at openjdk.org (duke) Date: Tue, 16 Jul 2024 16:11:01 GMT Subject: Withdrawn: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout In-Reply-To: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: <7_-fr6MvtGw1g-_-rSVin1RfxIR0JIAG1qgk6AlyWyQ=.64c00560-4947-4ac0-9f78-f6ce11e7cc1f@github.com> On Tue, 20 Feb 2024 18:07:43 GMT, Martin Fox wrote: > On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. > > This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. > > (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) > > This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1373 From angorya at openjdk.org Tue Jul 16 16:28:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 16:28:02 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: On Tue, 14 May 2024 22:29:18 GMT, Martin Fox wrote: >> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. >> >> This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. >> >> (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) >> >> This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Comment fixes > - Consistency in naming conventions and comment cleanup. > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Expanded robot lookup table, general cleanup > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Resolving duplicates for Robot, fallback for getKeyCodeForChar > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - KeyCharacterCombination fixes on Linux I think this PR should be reopened. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2231346432 From angorya at openjdk.org Tue Jul 16 16:53:00 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 16:53:00 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 15 Jul 2024 19:06:30 GMT, Michael Strau? wrote: > We could re-use the instance for subsequent calls. I would recommend against this suggestion: creating and destroying an object quickly is fairly cheap, but introducing a regression into a fairly complicated code is not. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2231389610 From angorya at openjdk.org Tue Jul 16 17:03:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 17:03:57 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 15 Jul 2024 13:30:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting and spelling This might be unrelated, but every time the CssParser gets recompiled in Eclipse I get a bunch of errors (and the errors get cleared after a clean/rebuild): Description Resource Type Path Location Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 2927 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3117 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3170 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3185 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3510 Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3554 even though it's a perfectly correct code. Any ideas? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2231406801 From angorya at openjdk.org Tue Jul 16 17:10:03 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 17:10:03 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 15 Jul 2024 13:30:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting and spelling LGTM. The fix does not cause SOE but instead detects the loop, outputting the explanation to stderr: Jul 16, 2024 10:05:52 AM javafx.scene.CssStyleHelper resolveLookups WARNING: Loop detected in *.root{ -fx-base-fill: -fx-base null 49.0% null 0xffffffff null StopConverter 50.0% null 0x000000ff null StopConverter LadderConverter -fx-base: -fx-base-fill null 49.0% null 0xffffffff null StopConverter 50.0% null 0x000000ff null StopConverter LadderConverter } while resolving '-fx-base' Jul 16, 2024 10:05:52 AM javafx.scene.CssStyleHelper calculateValue WARNING: Caught java.lang.IllegalArgumentException: Loop detected in *.root{ -fx-base-fill: -fx-base null 49.0% null 0xffffffff null StopConverter 50.0% null 0x000000ff null StopConverter LadderConverter -fx-base: -fx-base-fill null 49.0% null 0xffffffff null StopConverter 50.0% null 0x000000ff null StopConverter LadderConverter } while resolving '-fx-base'' while calculating value for '-fx-background-color' from style '*.pane { -fx-background-color: -fx-base null Paint.SequenceConverter } ' Also added a reproducer to the ticket, which goes through the code path normally used by the application. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 691: > 689: @Test > 690: public void shouldDetectNestedInfiniteLoop() throws IOException { > 691: Stylesheet stylesheet = new CssParser().parse( `CssParser.parse(String,String)` is used only in tests, why are we using it? Shouldn't we use `CssParser.parse(String)` instead? Also, why do we need `CssParser.parse(String,String)` in the first place? ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2180820690 PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679759718 From kcr at openjdk.org Tue Jul 16 17:36:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 17:36:56 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 21:12:35 GMT, Alexander Zuev wrote: > Initial implementation of the protocol. Reviewers: @arapte @andy-goryachev-oracle ------------- PR Comment: https://git.openjdk.org/jfx/pull/1507#issuecomment-2231461141 From angorya at openjdk.org Tue Jul 16 17:47:59 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 17:47:59 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 21:12:35 GMT, Alexander Zuev wrote: > Initial implementation of the protocol. modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 53: > 51: [rolesMap setObject:@"JFXCheckboxAccessibility" forKey:@"CHECK_BOX"]; > 52: [rolesMap setObject:@"JFXCheckboxAccessibility" forKey:@"TOGGLE_BUTTON"]; > 53: [rolesMap setObject:@"JFXStaticTextAccessibility" forKey:@"TEXT"]; are these keys mapped to AccessibleRole.java enum? if so, 1. should we add a comment stating that (and possibly add a comment in AccessibleRole as well? 2. are we going to keep adding roles to this block as we go along? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1507#discussion_r1679810873 From angorya at openjdk.org Tue Jul 16 17:50:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 17:50:04 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:29:18 GMT, John Hendrikx wrote: > As this is quite some work, I think documenting this feature calls for a separate task to avoid delaying this fix. Yes, it's just a question - I don't want to delay this PR. I asked because you do write good docs. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231481506 From kcr at openjdk.org Tue Jul 16 18:05:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 18:05:00 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> On Mon, 15 Jul 2024 13:30:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting and spelling The fix looks good. The test will verify that it no longer goes into an infinite loop, although it now mixes JUnit 5 and JUnit 4. Is it possible to also check that a parsing error is reported in that case, using `CssParser::errorsProperty`? modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 43: > 41: import static org.junit.Assert.assertFalse; > 42: import static org.junit.Assert.assertTrue; > 43: import static org.junit.jupiter.api.Assertions.assertDoesNotThrow; We have a general "best practice" to not mix JUnit 4 and JUnit 5 calls in the same test class. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 686: > 684: root.getChildren().addAll(a); > 685: > 686: assertDoesNotThrow(() -> stage.show()); // This should not result in a StackOverflowError Since this is still a JUnit 4 test, perhaps replace this with a try/catch and call `Assert.fail` in the `catch` block? ------------- PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2180914588 PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679817453 PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679820286 From angorya at openjdk.org Tue Jul 16 18:09:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 18:09:58 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> Message-ID: <2WlfZkQDy6rJQ_wljOoiKq3QMN-eRBRl4UfASBFDoos=.bd6a99c4-9ddc-4e47-8311-fcbc78205ba8@github.com> On Tue, 16 Jul 2024 17:47:11 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix formatting and spelling > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 43: > >> 41: import static org.junit.Assert.assertFalse; >> 42: import static org.junit.Assert.assertTrue; >> 43: import static org.junit.jupiter.api.Assertions.assertDoesNotThrow; > > We have a general "best practice" to not mix JUnit 4 and JUnit 5 calls in the same test class. how did I miss that??? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679838717 From kcr at openjdk.org Tue Jul 16 18:15:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 18:15:56 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <2WlfZkQDy6rJQ_wljOoiKq3QMN-eRBRl4UfASBFDoos=.bd6a99c4-9ddc-4e47-8311-fcbc78205ba8@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> <2WlfZkQDy6rJQ_wljOoiKq3QMN-eRBRl4UfASBFDoos=.bd6a99c4-9ddc-4e47-8311-fcbc78205ba8@github.com> Message-ID: On Tue, 16 Jul 2024 18:06:54 GMT, Andy Goryachev wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 43: >> >>> 41: import static org.junit.Assert.assertFalse; >>> 42: import static org.junit.Assert.assertTrue; >>> 43: import static org.junit.jupiter.api.Assertions.assertDoesNotThrow; >> >> We have a general "best practice" to not mix JUnit 4 and JUnit 5 calls in the same test class. > > how did I miss that??? Worth noting is that PR #1503 also uses JUnit 5 for its new tests, and in a non-trivial manner (not easy to replace). Maybe the best thing to do is to convert this test class to JUnit 5? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679845670 From angorya at openjdk.org Tue Jul 16 18:20:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 18:20:56 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> <2WlfZkQDy6rJQ_wljOoiKq3QMN-eRBRl4UfASBFDoos=.bd6a99c4-9ddc-4e47-8311-fcbc78205ba8@github.com> Message-ID: On Tue, 16 Jul 2024 18:13:37 GMT, Kevin Rushforth wrote: >> how did I miss that??? > > Worth noting is that PR #1503 also uses JUnit 5 for its new tests, and in a non-trivial manner (not easy to replace). Maybe the best thing to do is to convert this test class to JUnit 5? Maybe we should ask people to convert to junit5 every time they modify a test. I know we usually ask not to combine different issues in one PR, but given the fact that we are changing the tests there is no (or little) associated risk of regression or merge conflicts. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679850304 From kcr at openjdk.org Tue Jul 16 18:38:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 18:38:56 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:10:27 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case The fix looks good, presuming that you are correct, and that the comment about needing to set the origin of the parsed value to the greatest of any resolved reference in order to avoid storing an inline style in the shared cache is in fact wrong. Testing should help catch any potential problems. The new unit test looks like it covers all the cases. As with PR #1505, this PR mixes JUnit 4 and JUnit 5, which we really don't want to do in the same test class. Consider converting the entire class to JUnit 5, perhaps in #1505. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231564853 From kcr at openjdk.org Tue Jul 16 18:50:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 18:50:56 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> <2WlfZkQDy6rJQ_wljOoiKq3QMN-eRBRl4UfASBFDoos=.bd6a99c4-9ddc-4e47-8311-fcbc78205ba8@github.com> Message-ID: <0hfsFzwuONIRPYw5Iuf3FYmbDvxO-0IhM24m3bYCjF0=.c5355194-8dc8-4410-b90b-ef9d806995f7@github.com> On Tue, 16 Jul 2024 18:18:15 GMT, Andy Goryachev wrote: >> Worth noting is that PR #1503 also uses JUnit 5 for its new tests, and in a non-trivial manner (not easy to replace). Maybe the best thing to do is to convert this test class to JUnit 5? > > Maybe we should ask people to convert to junit5 every time they modify a test. > > I know we usually ask not to combine different issues in one PR, but given the fact that we are changing the tests there is no (or little) associated risk of regression or merge conflicts. What do you think? Not as a general policy, but perhaps in some cases. I only suggested it for this class because there are two PRs adding JUnit 5 tests to this class that would benefit from such a conversion, but now that I look at that class more closely, I don't think I'd want to see it as part of either PR. In general, I don't want to see a JUnit 5 conversions as part of a simple PR that adds a test method to a class with dozens of existing test methods, and this PR falls into that use case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679912562 From kcr at openjdk.org Tue Jul 16 19:01:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 19:01:55 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Tue, 16 Jul 2024 18:36:07 GMT, Kevin Rushforth wrote: > The new unit test looks like it covers all the cases. As with PR #1505, this PR mixes JUnit 4 and JUnit 5, which we really don't want to do in the same test class. Consider converting the entire class to JUnit 5, perhaps in #1505. On closer look, it's probably best to not do that as part of #1505 since that PR only adds a couple test methods to an existing class with many preexisting tests. Similarly, this PR only adds one new test method. So I think the best options are: 1. File a new test bug and PR that converts this class to JUnit 5, that new bug would block both of the other bugs 2. Stick with JUnit 4 for both of the existing PRs Comments? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231626454 From jhendrikx at openjdk.org Tue Jul 16 19:24:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:24:58 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Tue, 16 Jul 2024 18:59:00 GMT, Kevin Rushforth wrote: > > The new unit test looks like it covers all the cases. As with PR #1505, this PR mixes JUnit 4 and JUnit 5, which we really don't want to do in the same test class. Consider converting the entire class to JUnit 5, perhaps in #1505. > > On closer look, it's probably best to not do that as part of #1505 since that PR only adds a couple test methods to an existing class with many preexisting tests. Similarly, this PR only adds one new test method. > > So I think the best options are: > > 1. File a new test bug and PR that converts this class to JUnit 5, that new bug would block both of the other bugs > 2. Stick with JUnit 4 for both of the existing PRs > > Comments? Perhaps: 3. Put the JUnit 5 code in a separate test? About mixing asserts; I meant to upgrade all of them in this PR, but I missed a few. Mixing asserts however is technically not an issue as both frameworks will work with each others asserts (ie. JUnit 4 can use JUnit 5 asserts, or even asserts from a 3rd party library like AssertJ). What you can't mix is the annotations. You must use all JUnit 4 or JUnit 5 annotations (and this I did do correctly). I would personally prefer not to write more "old" JUnit 4 code than necessary, especially for parameterized cases or testing exceptions (JUnit 4 just is showing its age there), so if full conversion to JUnit 5 is not an option, I'll file a ticket to first convert it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231673097 From jhendrikx at openjdk.org Tue Jul 16 19:31:01 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:31:01 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Tue, 16 Jul 2024 18:36:07 GMT, Kevin Rushforth wrote: > The fix looks good, presuming that you are correct, and that the comment about needing to set the origin of the parsed value to the greatest of any resolved reference in order to avoid storing an inline style in the shared cache is in fact wrong. Testing should help catch any potential problems. I did some local testing as well regarding this (before I wrote the test cases) to first see if this fix would not break anything. I couldn't get inline styles that mess with `-fx-base` to "poison" each other. I also went through the caching logic, and found that any difference in inline styles results in a separate cache space -- this makes sense, because if inline styles were not taken into account when selecting the cache, then any inline style for two otherwise equal nodes could poison the other -- in other words, inline styles would not work correctly when cached if these were not taken into account, lookups or not. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231682096 From jhendrikx at openjdk.org Tue Jul 16 19:35:04 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:35:04 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> Message-ID: On Tue, 16 Jul 2024 17:49:26 GMT, Kevin Rushforth wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix formatting and spelling > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 686: > >> 684: root.getChildren().addAll(a); >> 685: >> 686: assertDoesNotThrow(() -> stage.show()); // This should not result in a StackOverflowError > > Since this is still a JUnit 4 test, perhaps replace this with a try/catch and call `Assert.fail` in the `catch` block? Yeah, I can change that, I was hoping this (less important) PR would probably be integrated after #1503 ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679970140 From jhendrikx at openjdk.org Tue Jul 16 19:35:05 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:35:05 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Tue, 16 Jul 2024 16:58:35 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix formatting and spelling > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 691: > >> 689: @Test >> 690: public void shouldDetectNestedInfiniteLoop() throws IOException { >> 691: Stylesheet stylesheet = new CssParser().parse( > > `CssParser.parse(String,String)` is used only in tests, why are we using it? Shouldn't we use `CssParser.parse(String)` instead? > > Also, why do we need `CssParser.parse(String,String)` in the first place? I can change it; I just followed what was done in this file already. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679972902 From angorya at openjdk.org Tue Jul 16 19:35:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 19:35:58 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:10:27 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case I know it might be quite a bit of work, but I think it might be worth going through an exercise to enumerate all possible scenarios in a test. As a reviewer, I cannot begin to figure out the possible consequences of the change in this PR without documenting the rules first. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231689927 From jhendrikx at openjdk.org Tue Jul 16 19:41:55 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:41:55 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Tue, 16 Jul 2024 17:01:08 GMT, Andy Goryachev wrote: > This might be unrelated, but every time the CssParser gets recompiled in Eclipse I get a bunch of errors (and the errors get cleared after a clean/rebuild): > > ``` > Description Resource Type Path Location > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 2927 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3117 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3170 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3185 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3510 > Cannot infer type arguments for ParsedValueImpl<> CssParser.java Java Problem /graphics/src/main/java/javafx/css line 3554 > ``` > > even though it's a perfectly correct code. Any ideas? This is one of those subtle differences between the `ecj` compiler and `javac`. I've seen these as well, and just ignore them. However, I can't remember seeing them recently so it may have been fixed. Are you on the latest Eclipse? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2231693859 From angorya at openjdk.org Tue Jul 16 19:41:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 16 Jul 2024 19:41:56 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Tue, 16 Jul 2024 19:35:46 GMT, John Hendrikx wrote: > Are you on the latest Eclipse? yes, 2024-06 (4.32.0) they recently fixed a bug with collections in the Variables view... >> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 691: >> >>> 689: @Test >>> 690: public void shouldDetectNestedInfiniteLoop() throws IOException { >>> 691: Stylesheet stylesheet = new CssParser().parse( >> >> `CssParser.parse(String,String)` is used only in tests, why are we using it? Shouldn't we use `CssParser.parse(String)` instead? >> >> Also, why do we need `CssParser.parse(String,String)` in the first place? > > I can change it; I just followed what was done in this file already. that's fine; it might be a case of the dead code being left from some earlier iteration. it's a public API not used by the platform, it seems. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2231698678 PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1679977068 From jhendrikx at openjdk.org Tue Jul 16 19:48:56 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:48:56 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 15 Jul 2024 19:06:30 GMT, Michael Strau? wrote: > A new `HashSet` is created for every base call to `resolveLookups`, but it is only used for state tracking. We could re-use the instance for subsequent calls. It's a bit of waste, and as the code is single threaded, it could be shared. However, CSS calculations are cached already, and so this probably won't do anything. Keeping this PR focused on the fix seems better. If we're gonna optimize, I think it would be better to do some measurements first to see if there is at least 1 ms or more to win anywhere. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2231708680 From jhendrikx at openjdk.org Tue Jul 16 19:51:58 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 19:51:58 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Tue, 16 Jul 2024 19:39:09 GMT, Andy Goryachev wrote: > > Are you on the latest Eclipse? > > yes, 2024-06 (4.32.0) they recently fixed a bug with collections in the Variables view... I'll check again, but rest assured, I've seen those as well, so it's not you. I've seen more subtle differences between the two compilers, sometimes this is because the Java spec is unclear or a bit ambiguous, and the compilers have different solutions (the Eclipse compiler implements the specification, and does not blindly copy the behavior of `javac`). Often there is a way to write the code in such a way that both compilers have no complaints :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2231713093 From mstrauss at openjdk.org Tue Jul 16 21:14:58 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 16 Jul 2024 21:14:58 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:36:43 GMT, Kevin Rushforth wrote: > This PR solves two related bugs that are caused by events being delivered while the FX runtime is in the process of shutting down. These bugs are related enough that I think they need to be addressed at the same time. While debugging and developing the test, I saw one or the other or both in various test runs. The system test included with this program verifies that there is no crash and no exception, so will catch either failure mode. > > This can happen when there is a full-screen window showing during shutdown on macOS, since full screen enter / exit uses a nested event loop that affects the order of operation. This could theoretically happen in other cases, thus the fix does not involve checking whether we are in full-screen or whether there is a nested event loop. > > The fix does the following: > > 1. `GlassWindow+Overrides.m`: Check that the JVM is still running before calling the Java notification method in `windowDidResignKey` and `windowShouldClose`. This matches what is already done for other similar methods in this class. This is the fix for JDK-8335630. > 2. `Window.java` and `View.java`: Check whether the Application instance is null in the event notification callbacks, and skip handling the event if it is. This is the fix for JDK-8299738. > > Note that the fix for 2 is in platform-independent code. This should be fine, since we would want to skip the event handling callback on any other platform if it were done during shutdown, in order to avoid the ISE. > > I have included a system test that passes on all platforms. On macOS, the test will fail without the fix and pass with the fix. > > Details of the fix are below: > > `Platform::exit` is called by the application to shutdown the JavaFX toolkit. The implementation of `Platform::exit` calls `Toolkit::exit` on the JavaFX Application thread, which in turn calls glass `Application::terminate` to shut it down. `Application::terminate` will close all the native windows, and call `finishTerminating` to terminate the native event loop and detach the thread from the JVM. This is asynchronous, at least on macOS, and will schedule the termination by posting a native event to the event loop. > > on macOS 13, and sometimes on macOS 14, a Window or View event handler can be called between `Toolkit::exit`/`Application::terminate` (which sets the Toolkit's cached thread to null and the glass Application instance to null) and the JVM shutdown. This will make a JNI upcall to the appropriate Window or View `handleXxxxx` method, which... The fix looks good for the intended single-threaded usage. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1506#pullrequestreview-2181319339 From jhendrikx at openjdk.org Tue Jul 16 22:01:03 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 16 Jul 2024 22:01:03 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Tue, 16 Jul 2024 19:33:10 GMT, Andy Goryachev wrote: > I know it might be quite a bit of work, but I think it might be worth going through an exercise to enumerate all possible scenarios in a test. > > As a reviewer, I cannot begin to figure out the possible consequences of the change in this PR without documenting the rules first. The CSS rules, or the rules surrounding lookups? For lookups: **Before** If a style used a variable, and that variable was overridden in a stylesheet with a higher priority `StyleOrigin`, then the original style would be modified to have this higher priority as well. If there was a chain of references (ie. `-fx-fill-color` refers to `-fx-base`) then the highest priority encountered while resolving the variable would be used. It is possible that an inline style overrides a variable like `-fx-base`, which would be the highest `StyleOrigin` priority, and so the original style would get `INLINE` priority. There was a worry that this would badly interact with caching (as inline styles are supposed to be local to the `Node` and so by definition, can't be shared with any other nodes), however, such a separation in caches was already present (out of necessity) was this would apply to any inline style (like `-fx-text-fill: red`), whether or not it used a lookup. The separation is therefore always present when an inline style is present, irrespective of the ent ire variable lookup system. **After** A lookup variable does not alter the priority of the style referring the variable in any way. This both simplifies the code, as well as the reasoning about your style priorities. **Potential Consequences** First realize that this is limited in scope to that variable lookups in JavaFX allow. They only allow color replacements. Also realize that the combination of setting some colors with a setter, while adjusting others by changing style sheet variables like `-fx-base` is a rare one. Most often projects will mandate it is one or the other (ie. specify all colors in stylesheets, or don't use stylesheets at all). 1. Leaving it as-is: versions of JavaFX prior to 21 behaved differently in this matter (due to a bug), and people have noticed that in 21+ FX is now overriding color setters as if some styles are originating from higher priority stylesheets. This is limited in scope to colors, but could get worse if the system is extending to allow for other uses of variables. 2. Modifying the (undocumented) behavior to be more in line with what one would expect: due to a seemingly unrelated bug, versions before JavaFX 21 often didn't override setter values (all of them, in specific situations, not just colors). This was mostly expected as both the call to the setter and the (higher priority) author stylesheets are under control of the developer, and so if there was any conflict, it could be solved by the developer. In other words, developers could fix their own mistake, even though it may have been a bug on our side. TLDR; modifying the behavior will make JavaFX operate more like it did prior to JavaFX 21. None of them however will work exactly the same in all situations (ie. JavaFX 20 works differently from 21, and a future version where this PR merged will work differently again. However, that future version will work closer to how JavaFX behaved before version 21. Maybe a table will help... First, the order form highest to lowest priority is: `INLINE` (using `Node::setStyle`), `AUTHOR` (from user set stylesheets), `USER` (for setters) and then `USER_AGENT` (a stylesheet like Modena set by FX itself). | Action \ Version |<21|21+|With Fix| |---|---|---|---| |Setting a color|Not overridden by anything(*)|Overridden by AUTHOR and INLINE styles, and by any USER_AGENT styles if they use a variable and that variable was specified in an AUTHOR or INLINE style|Only overridden by AUTHOR or INLINE styles (as documented)| |Setting a non-color|Not overridden by anything(*)|Only overriden by AUTHOR or INLINE styles (as documented)|Same as 21+| |Using `-fx-base` in AUTHOR stylesheet, as well as some direct styles|Both USER_AGENT styles that use `-fx-base` and AUTHOR styles that apply things directly would be in competition who is the most specific|Same as before 21|USER_AGENT styles that use `-fx-base` are not in direct competition with AUTHOR styles unless more specific per CSS rules| (*) most of the time, the situation is a bit complicated due to cache sharing ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2231892066 From kcr at openjdk.org Tue Jul 16 22:45:33 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 16 Jul 2024 22:45:33 GMT Subject: RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 [v2] In-Reply-To: References: Message-ID: > This PR solves two related bugs that are caused by events being delivered while the FX runtime is in the process of shutting down. These bugs are related enough that I think they need to be addressed at the same time. While debugging and developing the test, I saw one or the other or both in various test runs. The system test included with this program verifies that there is no crash and no exception, so will catch either failure mode. > > This can happen when there is a full-screen window showing during shutdown on macOS, since full screen enter / exit uses a nested event loop that affects the order of operation. This could theoretically happen in other cases, thus the fix does not involve checking whether we are in full-screen or whether there is a nested event loop. > > The fix does the following: > > 1. `GlassWindow+Overrides.m`: Check that the JVM is still running before calling the Java notification method in `windowDidResignKey` and `windowShouldClose`. This matches what is already done for other similar methods in this class. This is the fix for JDK-8335630. > 2. `Window.java` and `View.java`: Check whether the Application instance is null in the event notification callbacks, and skip handling the event if it is. This is the fix for JDK-8299738. > > Note that the fix for 2 is in platform-independent code. This should be fine, since we would want to skip the event handling callback on any other platform if it were done during shutdown, in order to avoid the ISE. > > I have included a system test that passes on all platforms. On macOS, the test will fail without the fix and pass with the fix. > > Details of the fix are below: > > `Platform::exit` is called by the application to shutdown the JavaFX toolkit. The implementation of `Platform::exit` calls `Toolkit::exit` on the JavaFX Application thread, which in turn calls glass `Application::terminate` to shut it down. `Application::terminate` will close all the native windows, and call `finishTerminating` to terminate the native event loop and detach the thread from the JVM. This is asynchronous, at least on macOS, and will schedule the termination by posting a native event to the event loop. > > on macOS 13, and sometimes on macOS 14, a Window or View event handler can be called between `Toolkit::exit`/`Application::terminate` (which sets the Toolkit's cached thread to null and the glass Application instance to null) and the JVM shutdown. This will make a JNI upcall to the appropriate Window or View `handleXxxxx` method, which... Kevin Rushforth 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: - Merge remote-tracking branch 'upstream/master' into 8335630-exit-fullscreen - Revert "Debug prints" This reverts commit 0e634b7a14da19175c2b30e17a64e96e37451af2. - Debug prints - 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 8299738: ISE if Platform::exit called with fullScreen Stage on macOS 13 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1506/files - new: https://git.openjdk.org/jfx/pull/1506/files/43448703..ee7841f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1506&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1506&range=00-01 Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod Patch: https://git.openjdk.org/jfx/pull/1506.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1506/head:pull/1506 PR: https://git.openjdk.org/jfx/pull/1506 From kizune at openjdk.org Wed Jul 17 04:58:03 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 Jul 2024 04:58:03 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol In-Reply-To: References: Message-ID: <-cMhb2qBo3kJ_c5WeJl-9TipPz0fc8uAvl1J3-a_1hk=.ff11f3af-9e7b-4213-bb06-685e03d03d7f@github.com> On Tue, 16 Jul 2024 17:41:18 GMT, Andy Goryachev wrote: >> Initial implementation of the protocol. > > modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 53: > >> 51: [rolesMap setObject:@"JFXCheckboxAccessibility" forKey:@"CHECK_BOX"]; >> 52: [rolesMap setObject:@"JFXCheckboxAccessibility" forKey:@"TOGGLE_BUTTON"]; >> 53: [rolesMap setObject:@"JFXStaticTextAccessibility" forKey:@"TEXT"]; > > are these keys mapped to AccessibleRole.java enum? if so, > 1. should we add a comment stating that (and possibly add a comment in AccessibleRole as well? > 2. are we going to keep adding roles to this block as we go along? 1. Yes, these are linked to the JFX accessible roles defined in that enum. I can add comment here - not sure about the AccessibleRole, it is a definition that might be used for more than one platform so linking platform specific implementation from there sound incorrect; 2. Yes, as we are converting more and more functionality to the new API we are going to add roles implementations to this block until we have no roles not covered with the new API. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1507#discussion_r1680405200 From duke at openjdk.org Wed Jul 17 05:27:11 2024 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 17 Jul 2024 05:27:11 GMT Subject: RFR: 8336592: Wrong type in documentation for TreeTableView Message-ID: Hello, There is a typo in TreeTableView.java documentation. TreeTableColumns is used instead of TreeTableColumn. I have updated the below lines: TreeTableColumn fileNameCol = new TreeTableColumn<>("Filename"); TreeTableColumn sizeCol = new TreeTableColumn<>("Size"); Please review. ------------- Commit messages: - Update documentation for TreeTableView.java Changes: https://git.openjdk.org/jfx/pull/1509/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336592 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1509.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1509/head:pull/1509 PR: https://git.openjdk.org/jfx/pull/1509 From kizune at openjdk.org Wed Jul 17 05:34:31 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Wed, 17 Jul 2024 05:34:31 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v2] In-Reply-To: References: Message-ID: > Initial implementation of the protocol. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Add comment about AccessibleRole enuM ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1507/files - new: https://git.openjdk.org/jfx/pull/1507/files/07c70037..ce4cc10b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1507&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1507.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1507/head:pull/1507 PR: https://git.openjdk.org/jfx/pull/1507 From duke at openjdk.org Wed Jul 17 05:48:57 2024 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 17 Jul 2024 05:48:57 GMT Subject: Withdrawn: 8336592: Wrong type in documentation for TreeTableView In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 05:21:21 GMT, ANUPAM DEV wrote: > Hello, > > There is a typo in TreeTableView.java documentation. TreeTableColumns is used instead of TreeTableColumn. > I have updated the below lines: > > TreeTableColumn fileNameCol = new TreeTableColumn<>("Filename"); > TreeTableColumn sizeCol = new TreeTableColumn<>("Size"); > > Please review. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1509 From duke at openjdk.org Wed Jul 17 05:58:20 2024 From: duke at openjdk.org (ANUPAM DEV) Date: Wed, 17 Jul 2024 05:58:20 GMT Subject: RFR: 8336592: Wrong type in documentation for TreeTableView Message-ID: Hello, There was a typo in the documentation of TreeTableView. I have changed TreeTableColumns to TreeTableColumn Please review. Regards, Anupam ------------- Commit messages: - Update TreeTableView.java Changes: https://git.openjdk.org/jfx/pull/1510/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1510&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336592 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1510.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1510/head:pull/1510 PR: https://git.openjdk.org/jfx/pull/1510 From kcr at openjdk.org Wed Jul 17 12:17:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Jul 2024 12:17:58 GMT Subject: Integrated: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Mon, 15 Jul 2024 19:36:43 GMT, Kevin Rushforth wrote: > This PR solves two related bugs that are caused by events being delivered while the FX runtime is in the process of shutting down. These bugs are related enough that I think they need to be addressed at the same time. While debugging and developing the test, I saw one or the other or both in various test runs. The system test included with this program verifies that there is no crash and no exception, so will catch either failure mode. > > This can happen when there is a full-screen window showing during shutdown on macOS, since full screen enter / exit uses a nested event loop that affects the order of operation. This could theoretically happen in other cases, thus the fix does not involve checking whether we are in full-screen or whether there is a nested event loop. > > The fix does the following: > > 1. `GlassWindow+Overrides.m`: Check that the JVM is still running before calling the Java notification method in `windowDidResignKey` and `windowShouldClose`. This matches what is already done for other similar methods in this class. This is the fix for JDK-8335630. > 2. `Window.java` and `View.java`: Check whether the Application instance is null in the event notification callbacks, and skip handling the event if it is. This is the fix for JDK-8299738. > > Note that the fix for 2 is in platform-independent code. This should be fine, since we would want to skip the event handling callback on any other platform if it were done during shutdown, in order to avoid the ISE. > > I have included a system test that passes on all platforms. On macOS, the test will fail without the fix and pass with the fix. > > Details of the fix are below: > > `Platform::exit` is called by the application to shutdown the JavaFX toolkit. The implementation of `Platform::exit` calls `Toolkit::exit` on the JavaFX Application thread, which in turn calls glass `Application::terminate` to shut it down. `Application::terminate` will close all the native windows, and call `finishTerminating` to terminate the native event loop and detach the thread from the JVM. This is asynchronous, at least on macOS, and will schedule the termination by posting a native event to the event loop. > > on macOS 13, and sometimes on macOS 14, a Window or View event handler can be called between `Toolkit::exit`/`Application::terminate` (which sets the Toolkit's cached thread to null and the glass Application instance to null) and the JVM shutdown. This will make a JNI upcall to the appropriate Window or View `handleXxxxx` method, which... This pull request has now been integrated. Changeset: 81f11c4a Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/81f11c4a39eb505d17c57a49c5e084f75a169856 Stats: 157 lines in 4 files changed: 130 ins; 0 del; 27 mod 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 8299738: ISE if Platform::exit called with fullScreen Stage on macOS 13 Reviewed-by: angorya, mstrauss ------------- PR: https://git.openjdk.org/jfx/pull/1506 From kcr at openjdk.org Wed Jul 17 12:26:26 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Jul 2024 12:26:26 GMT Subject: [jfx23] RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 Message-ID: Clean backport of this crash-on-exit fix to the `jfx23` stabilization branch. ------------- Commit messages: - Backport 81f11c4a39eb505d17c57a49c5e084f75a169856 Changes: https://git.openjdk.org/jfx/pull/1511/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1511&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335630 Stats: 157 lines in 4 files changed: 130 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1511.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1511/head:pull/1511 PR: https://git.openjdk.org/jfx/pull/1511 From angorya at openjdk.org Wed Jul 17 14:44:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jul 2024 14:44:58 GMT Subject: RFR: 8336592: Wrong type in documentation for TreeTableView In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 05:53:45 GMT, ANUPAM DEV wrote: > Hello, > > There was a typo in the documentation of TreeTableView. > I have changed TreeTableColumns to TreeTableColumn > > Please review. > > Regards, > Anupam thank you for finding and fixing this documentation issue! you may want to configure github actions for this repository - see https://wiki.openjdk.org/display/SKARA/Testing ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1510#pullrequestreview-2183140178 PR Comment: https://git.openjdk.org/jfx/pull/1510#issuecomment-2233498052 From angorya at openjdk.org Wed Jul 17 14:48:57 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jul 2024 14:48:57 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v2] In-Reply-To: References: Message-ID: <8zyq7xMsxiIyNtVD6p9h5ys95OQqa5WKYWXkgse3b3w=.c508470d-113c-431c-9e81-bcbcbb99ce92@github.com> On Wed, 17 Jul 2024 05:34:31 GMT, Alexander Zuev wrote: >> Initial implementation of the protocol. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Add comment about AccessibleRole enuM lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1507#pullrequestreview-2183159028 From angorya at openjdk.org Wed Jul 17 14:48:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jul 2024 14:48:58 GMT Subject: RFR: 8336031: Create implementation of NSAccessibilityStaticText protocol [v2] In-Reply-To: <-cMhb2qBo3kJ_c5WeJl-9TipPz0fc8uAvl1J3-a_1hk=.ff11f3af-9e7b-4213-bb06-685e03d03d7f@github.com> References: <-cMhb2qBo3kJ_c5WeJl-9TipPz0fc8uAvl1J3-a_1hk=.ff11f3af-9e7b-4213-bb06-685e03d03d7f@github.com> Message-ID: On Wed, 17 Jul 2024 04:55:25 GMT, Alexander Zuev wrote: >> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 53: >> >>> 51: [rolesMap setObject:@"JFXCheckboxAccessibility" forKey:@"CHECK_BOX"]; >>> 52: [rolesMap setObject:@"JFXCheckboxAccessibility" forKey:@"TOGGLE_BUTTON"]; >>> 53: [rolesMap setObject:@"JFXStaticTextAccessibility" forKey:@"TEXT"]; >> >> are these keys mapped to AccessibleRole.java enum? if so, >> 1. should we add a comment stating that (and possibly add a comment in AccessibleRole as well? >> 2. are we going to keep adding roles to this block as we go along? > > 1. Yes, these are linked to the JFX accessible roles defined in that enum. I can add comment here - not sure about the AccessibleRole, it is a definition that might be used for more than one platform so linking platform specific implementation from there sound incorrect; > 2. Yes, as we are converting more and more functionality to the new API we are going to add roles implementations to this block until we have no roles not covered with the new API. thank you for clarifying. fully agree with #1, referencing from platform specific to the common should be sufficient. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1507#discussion_r1681191348 From angorya at openjdk.org Wed Jul 17 20:40:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jul 2024 20:40:40 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: <0utqf3JtktutkcCqvw5kmMsGKhg6-Ozge-2TUrtsShA=.fbef9587-5c09-4888-83d3-2437f4ef4d39@github.com> On Tue, 16 Jul 2024 21:57:30 GMT, John Hendrikx wrote: > First, the order from highest to lowest priority is: `INLINE` (using `Node::setStyle`), `AUTHOR` (from user set stylesheets), `USER` (for setters) and then `USER_AGENT` (a stylesheet like Modena set by FX itself). What are the priorities between - system stylesheet (modena.css) set via `StyleManager.getInstance().setUserAgentStylesheets()` - user agent stylesheet added via `Application.setUserAgentStylesheet()` - user agent stylesheet added via `Scene.setUserAgentStylesheet()` - user agent stylesheet added via `SubScene.setUserAgentStylesheet()` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2234238494 From kcr at openjdk.org Wed Jul 17 20:49:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 17 Jul 2024 20:49:35 GMT Subject: [jfx23] RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 12:21:59 GMT, Kevin Rushforth wrote: > Clean backport of this crash-on-exit fix to the `jfx23` stabilization branch. Reviewer: @andy-goryachev-oracle (as it is a clean backport, a single Reviewer will suffiice) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1511#issuecomment-2234252342 From angorya at openjdk.org Wed Jul 17 20:56:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jul 2024 20:56:36 GMT Subject: [jfx23] RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: <0ki2o6aAb8aQIxLDWffFtT1S4O6ynlIGHmAqFjkn44Q=.b7b28137-66bb-463a-8760-50ccc421f4bb@github.com> On Wed, 17 Jul 2024 12:21:59 GMT, Kevin Rushforth wrote: > Clean backport of this crash-on-exit fix to the `jfx23` stabilization branch. lgtm ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1511#pullrequestreview-2184019091 From angorya at openjdk.org Wed Jul 17 22:02:37 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 17 Jul 2024 22:02:37 GMT Subject: [jfx23] RFR: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 12:21:59 GMT, Kevin Rushforth wrote: > Clean backport of this crash-on-exit fix to the `jfx23` stabilization branch. forgot to mention: checked the target branch is jfx23 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1511#issuecomment-2234396795 From arapte at openjdk.org Thu Jul 18 01:20:42 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 18 Jul 2024 01:20:42 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v18] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 14:48:30 GMT, Kevin Rushforth wrote: >> I manually reverted the add/remove part, and replaced it with `git mv`. I assume/hope that by squashing the commits, the add/remove will not be part of the change. > > git doesn't actually track renames and copies, so there is ultimately no difference between a "git mv" and "git rm; git add", at least not when done as part of a single commit. What git does is a heuristic when presenting diffs based on how similar the two files are. My intention to use git mv was to retain history on the file. I tried below locally but it did not retain the history. git mv < modify the file content > git add git commit -m "commit message" git log --follow -> expected to see old commits in log but it showed only one log. What am I missing here ! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1283#discussion_r1681953047 From duke at openjdk.org Thu Jul 18 01:25:38 2024 From: duke at openjdk.org (madprops) Date: Thu, 18 Jul 2024 01:25:38 GMT Subject: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage [v3] In-Reply-To: <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> References: <5LNb2T9UaMd3Tsxaxe-ljj8n7WfRLXKvfoR6CO42gBo=.bd5bf72f-d431-4457-90c7-426cec4f8830@github.com> <1VkSTO2CbxgRluwUCnYv-vZQDn98ZoWkxSUi_LhfmFg=.ae36cef9-44b0-47d3-9d05-486e12a8fbad@github.com> Message-ID: On Thu, 23 May 2024 10:53:36 GMT, Thiago Milczarek Sayao wrote: >> This fixes two bugs appointed on the JBS issue: >> >> 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. >> >> This seems to happen on newer versions of linux distros. >> >> 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'refs/heads/master' into 8332222 > - Should still report location > - Fix > - Teste > - Teste > - Teste > - Fix 8332222 I can confirm the bug happens on linux + x11 + awesomewm This one: https://bugs.openjdk.org/browse/JDK-8332222 (I haven't tried the patches) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2235043977 From arapte at openjdk.org Thu Jul 18 02:06:42 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 18 Jul 2024 02:06:42 GMT Subject: RFR: 8319779: SystemMenu: memory leak due to listener never being removed [v21] In-Reply-To: References: Message-ID: On Tue, 9 Jul 2024 09:06:58 GMT, Johan Vos wrote: >> A listener was added but never removed. >> This patch removes the listener when the menu it links to is cleared. Fix for https://bugs.openjdk.org/browse/JDK-8319779 > > Johan Vos has updated the pull request incrementally with one additional commit since the last revision: > > Allow scheduled runnables to be executed on the FX App Thread before checking for exceptions. lgtm ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1283#pullrequestreview-2184442846 From duke at openjdk.org Thu Jul 18 03:04:38 2024 From: duke at openjdk.org (ANUPAM DEV) Date: Thu, 18 Jul 2024 03:04:38 GMT Subject: RFR: 8336592: Wrong type in documentation for TreeTableView In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 14:42:43 GMT, Andy Goryachev wrote: >> Hello, >> >> There was a typo in the documentation of TreeTableView. >> I have changed TreeTableColumns to TreeTableColumn >> >> Please review. >> >> Regards, >> Anupam > > you may want to configure github actions for this repository - see > https://wiki.openjdk.org/display/SKARA/Testing Thankyou @andy-goryachev-oracle . I have configured the github actions. The tests have passed. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1510#issuecomment-2235215861 From duke at openjdk.org Thu Jul 18 05:46:43 2024 From: duke at openjdk.org (robbiezl) Date: Thu, 18 Jul 2024 05:46:43 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec This issue is very important for all non-English users and we sincerely hope that this PR can be reviewed and added to the master branch as soon as possible ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2235557086 From jvos at openjdk.org Thu Jul 18 07:00:45 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 07:00:45 GMT Subject: [jfx23u] RFR: 8336035: Change JavaFX release version to 23.0.1 in jfx23u In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 22:56:18 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 23.0.1 release. Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/1#pullrequestreview-2184887758 From jvos at openjdk.org Thu Jul 18 08:43:21 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 08:43:21 GMT Subject: [jfx17u] RFR: 8336730: Change JavaFX release version to 17.0.13 in jfx17u Message-ID: <5nqyT3YT2Fx-qn4gscqF1kN9VSqj8J3lGeRJASpgxsQ=.ffd5b0f6-d316-4472-abac-3b9b227da419@github.com> Start work on 17.0.13 ------------- Commit messages: - Start work on 17.0.13 Changes: https://git.openjdk.org/jfx17u/pull/196/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336730 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx17u/pull/196.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/196/head:pull/196 PR: https://git.openjdk.org/jfx17u/pull/196 From jvos at openjdk.org Thu Jul 18 08:43:17 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 08:43:17 GMT Subject: [jfx21u] RFR: 8336733: Change JavaFX release version to 21.0.5 in jfx21u Message-ID: Start work on 21.0.5 ------------- Commit messages: - Start work on 21.0.5 Changes: https://git.openjdk.org/jfx21u/pull/62/files Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=62&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336733 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx21u/pull/62.diff Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/62/head:pull/62 PR: https://git.openjdk.org/jfx21u/pull/62 From jvos at openjdk.org Thu Jul 18 08:43:18 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 08:43:18 GMT Subject: [jfx21u] RFR: 8336733: Change JavaFX release version to 21.0.5 in jfx21u In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 08:34:10 GMT, Johan Vos wrote: > Start work on 21.0.5 start work on 21.0.5 ------------- PR Comment: https://git.openjdk.org/jfx21u/pull/62#issuecomment-2235947269 From jpereda at openjdk.org Thu Jul 18 09:48:39 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 18 Jul 2024 09:48:39 GMT Subject: [jfx17u] RFR: 8336730: Change JavaFX release version to 17.0.13 in jfx17u In-Reply-To: <5nqyT3YT2Fx-qn4gscqF1kN9VSqj8J3lGeRJASpgxsQ=.ffd5b0f6-d316-4472-abac-3b9b227da419@github.com> References: <5nqyT3YT2Fx-qn4gscqF1kN9VSqj8J3lGeRJASpgxsQ=.ffd5b0f6-d316-4472-abac-3b9b227da419@github.com> Message-ID: On Thu, 18 Jul 2024 08:31:42 GMT, Johan Vos wrote: > Start work on 17.0.13 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/196#pullrequestreview-2185280186 From jpereda at openjdk.org Thu Jul 18 09:48:39 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 18 Jul 2024 09:48:39 GMT Subject: [jfx21u] RFR: 8336733: Change JavaFX release version to 21.0.5 in jfx21u In-Reply-To: References: Message-ID: <-ZyxV_qS5J7s6a75F-ZArOfUnb3UpxaGuOWc3FRneWo=.94ee54ae-56c1-4502-9e01-7443d77b0b92@github.com> On Thu, 18 Jul 2024 08:34:10 GMT, Johan Vos wrote: > Start work on 21.0.5 Marked as reviewed by jpereda (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx21u/pull/62#pullrequestreview-2185280653 From kcr at openjdk.org Thu Jul 18 11:21:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 11:21:42 GMT Subject: [jfx23u] Integrated: 8336035: Change JavaFX release version to 23.0.1 in jfx23u In-Reply-To: References: Message-ID: On Thu, 11 Jul 2024 22:56:18 GMT, Kevin Rushforth wrote: > Updates for the beginning of the 23.0.1 release. This pull request has now been integrated. Changeset: 377989ef Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/377989efe0193f44e5fa1742002dcd3479de20fc Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8336035: Change JavaFX release version to 23.0.1 in jfx23u Reviewed-by: arapte, jvos ------------- PR: https://git.openjdk.org/jfx23u/pull/1 From kevin.rushforth at oracle.com Thu Jul 18 11:49:20 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jul 2024 04:49:20 -0700 Subject: jfx23u open for JavaFX 23.0.1 backports Message-ID: All, The jfx23u repo [1] is now open for JavaFX 23.0.1 backports (the October 2024 CPU release), with prior approval. The general criteria is that we want to backport fixes for regressions introduced in JavaFX 23, third-party library updates, and a limited number of other important bug fixes. In most cases we'd like to see the fix "bake" in the mainline for a while before being backported to jfx23u. NOTE: Only those fixes that will NOT be backported to the jfx23 [2] stabilization branch are candidates for backporting to jfx23u. A backport intended for the JavaFX 23 code line will go into either the jfx23 branch or the jfx23u repo, not both. We use a similar procedure for making the request and noting the approval as is used by the JDK updates releases -- by using JBS labels to request a backport and indicate approval or rejection. Here is the procedure: 1. A developer makes the request by adding the "jfx23u-fix-request" label to the main bug in JBS (not the backport record, even presuming one exists), with a comment indicating that you would like to backport it, along with a justification and risk assessment, if needed. 2. One of the JavaFX projects leads, either Johan Vos or myself, will add a "jfx23u-fix-yes" label to approve or "jfx23u-fix-no" label to reject the request, along with a comment. In either case, the jfx23u-request label is left in place. 3. Create the backport PR for jfx23u, either manually or using the "/backport" command. If you have good reason to believe that that this bug is a good candidate for jfx23u, then you can do this step first and use Skara's "/approval" command to request approval. Let Johan or me know if you have any questions. Thanks. -- Kevin [1] https://github.com/openjdk/jfx23u [2] https://github.com/openjdk/jfx/tree/jfx23 From jhendrikx at openjdk.org Thu Jul 18 11:54:43 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 18 Jul 2024 11:54:43 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: <0utqf3JtktutkcCqvw5kmMsGKhg6-Ozge-2TUrtsShA=.fbef9587-5c09-4888-83d3-2437f4ef4d39@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> <0utqf3JtktutkcCqvw5kmMsGKhg6-Ozge-2TUrtsShA=.fbef9587-5c09-4888-83d3-2437f4ef4d39@github.com> Message-ID: On Wed, 17 Jul 2024 20:38:03 GMT, Andy Goryachev wrote: > > First, the order from highest to lowest priority is: `INLINE` (using `Node::setStyle`), `AUTHOR` (from user set stylesheets), `USER` (for setters) and then `USER_AGENT` (a stylesheet like Modena set by FX itself). > > What are the priorities between > > * system stylesheet (modena.css) set via `StyleManager.getInstance().setUserAgentStylesheets()` > * user agent stylesheet added via `Application.setUserAgentStylesheet()` > * user agent stylesheet added via `Scene.setUserAgentStylesheet()` > * user agent stylesheet added via `SubScene.setUserAgentStylesheet()` Here is the order that stylesheets are added to a style map, from how `StyleManager::findMatchingStyles` works. The order is from lowest to highest precedence: ## Primary user agent stylesheet: One of these (only one, first one wins): - `SubScene` user agent stylesheet - `Scene` user agent stylesheet (**only** if there was no `SubScene` user agent stylesheet) - Application user agent stylesheet **only** if there was no `SubScene` or `Scene` user agent stylesheet (in other words, `Scene` and `SubScene` user agent stylesheets will completely replace modena) ## Additional `Region` user agent stylesheet Regions can provide a user agent stylesheet by overriding `Region::getUserAgentStyleSheet`. Only one is added, from the nearest parent, and it does **not** replace the primary user agent stylesheet. ## Author stylesheets, from lowest to highest precedence: - From `Scene` - If a Scene has multiple stylesheets, the first/last stylesheet in the list has lowest/highest precedence respectively. - Then `Parent` stylesheets - The least specific parent's stylesheets (closest to the root) have lowest precedence - If a Parent has multiple stylesheets, the first/last stylesheet in the list has lowest/highest precedence respectively. # Style selection Styles are grouped per style origin, from lowest to highest precedence: - User Agent - Author - Inline A style from within a higher precedence group will always be applied first. Styles within the same style origin group will use specificity (how specific the style is) to determine which should be applied first, with the most specific style taking precedence. If there are styles with the same specificity, then the style from the nearest `Node`, `Parent` or `Scene` takes precedence (this is determined by the order the stylesheets are managed by `StyleManager` explained in the first part). If there is still a conflict (ie. two styles with the same precedence, both coming from the same `Node`) then the latest stylesheet added takes precedence. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2236307850 From kcr at openjdk.org Thu Jul 18 12:22:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 12:22:09 GMT Subject: [jfx23u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Message-ID: This is a copy of the jfx22u README and CONTRIBUTING docs, changing 22 to 23, with one additional change to add the word "Updates" after "23" in one place where it was missing (the current wording could mislead developers into thinking that JavaFX 23 fixes should be done here). I'll take this out of Draft once PR #1 is integrated (that PR _must_ be integrated ahead of anything else and before I announce that the repo is open for pull requests). ------------- Commit messages: - Clarify that PRs are for 23 'Updates' (not 23) - Update README.md and CONTRIBUTING.md for jfx update repos Changes: https://git.openjdk.org/jfx23u/pull/2/files Webrev: https://webrevs.openjdk.org/?repo=jfx23u&pr=2&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304008 Stats: 269 lines in 2 files changed: 1 ins; 256 del; 12 mod Patch: https://git.openjdk.org/jfx23u/pull/2.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/2/head:pull/2 PR: https://git.openjdk.org/jfx23u/pull/2 From jvos at openjdk.org Thu Jul 18 12:22:09 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 12:22:09 GMT Subject: [jfx23u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 14:41:27 GMT, Kevin Rushforth wrote: > This is a copy of the jfx22u README and CONTRIBUTING docs, changing 22 to 23, with one additional change to add the word "Updates" after "23" in one place where it was missing (the current wording could mislead developers into thinking that JavaFX 23 fixes should be done here). > > I'll take this out of Draft once PR #1 is integrated (that PR _must_ be integrated ahead of anything else and before I announce that the repo is open for pull requests). Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx23u/pull/2#pullrequestreview-2185642838 From kcr at openjdk.org Thu Jul 18 12:22:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 12:22:09 GMT Subject: [jfx23u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: On Fri, 12 Jul 2024 14:41:27 GMT, Kevin Rushforth wrote: > This is a copy of the jfx22u README and CONTRIBUTING docs, changing 22 to 23, with one additional change to add the word "Updates" after "23" in one place where it was missing (the current wording could mislead developers into thinking that JavaFX 23 fixes should be done here). > > I'll take this out of Draft once PR #1 is integrated (that PR _must_ be integrated ahead of anything else and before I announce that the repo is open for pull requests). Reviewer: @johanvos ------------- PR Comment: https://git.openjdk.org/jfx23u/pull/2#issuecomment-2236344398 From kcr at openjdk.org Thu Jul 18 12:22:09 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 12:22:09 GMT Subject: [jfx23u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for jfx update repos In-Reply-To: References: Message-ID: <3YmFPpbelVU3Z7wTWGWwXkaU6-9MSvVIeGW0hMwHVN8=.b08b243b-3b90-4494-96a8-8e5f2ba97b5a@github.com> On Fri, 12 Jul 2024 14:41:27 GMT, Kevin Rushforth wrote: > This is a copy of the jfx22u README and CONTRIBUTING docs, changing 22 to 23, with one additional change to add the word "Updates" after "23" in one place where it was missing (the current wording could mislead developers into thinking that JavaFX 23 fixes should be done here). > > I'll take this out of Draft once PR #1 is integrated (that PR _must_ be integrated ahead of anything else and before I announce that the repo is open for pull requests). This pull request has now been integrated. Changeset: 20ead5a1 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/20ead5a13e2666e33b6871bd3b8ff97f020c8ea8 Stats: 269 lines in 2 files changed: 1 ins; 256 del; 12 mod 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Reviewed-by: jvos Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6 ------------- PR: https://git.openjdk.org/jfx23u/pull/2 From kcr at openjdk.org Thu Jul 18 12:24:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 12:24:41 GMT Subject: RFR: 8336592: Wrong type in documentation for TreeTableView In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 03:02:06 GMT, ANUPAM DEV wrote: >> you may want to configure github actions for this repository - see >> https://wiki.openjdk.org/display/SKARA/Testing > > Thankyou @andy-goryachev-oracle . > I have configured the github actions. > The tests have passed. @anupamdev20 This PR is ready for you to `/integrate` now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1510#issuecomment-2236360014 From kcr at openjdk.org Thu Jul 18 12:27:40 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 12:27:40 GMT Subject: [jfx23] Integrated: 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 12:21:59 GMT, Kevin Rushforth wrote: > Clean backport of this crash-on-exit fix to the `jfx23` stabilization branch. This pull request has now been integrated. Changeset: d9780548 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/d9780548f42047cd7cd06d20c1350fa955a9dc9a Stats: 157 lines in 4 files changed: 130 ins; 0 del; 27 mod 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 8299738: ISE if Platform::exit called with fullScreen Stage on macOS 13 Reviewed-by: angorya Backport-of: 81f11c4a39eb505d17c57a49c5e084f75a169856 ------------- PR: https://git.openjdk.org/jfx/pull/1511 From angorya at openjdk.org Thu Jul 18 15:29:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Jul 2024 15:29:39 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:10:27 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case Thank you for the detailed writeup! I did not know about `Region.getUserAgentStylesheet()`, especially about its doc "Some JavaFX CSS implementations may choose to cache this response for an indefinite period of time, and therefore there should be no expectation around when this method is called." How are we supposed to implement dynamically changing styles?? Do I understand you correctly that `Scene.setUserAgentStylesheet()` completely replaces modena.css for that Scene? And then Scene.getStylesheets() will lay on top of that, having higher priority? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2236860652 From angorya at openjdk.org Thu Jul 18 17:40:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Jul 2024 17:40:42 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v22] In-Reply-To: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> References: <6VS5xsgR34tZcmDmUXL2z1_UTG1yQCEPBigsks42qPs=.32ac018d-93b9-4134-8ff7-231c5dc5411d@github.com> Message-ID: On Sun, 9 Jun 2024 12:56:32 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 96 commits: > > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'refs/heads/master' into new_ime > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > > # Conflicts: > # modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not officially supported) > - Unref pango attr list > - Merge branch 'master' into new_ime > - ... and 86 more: https://git.openjdk.org/jfx/compare/c8b96e4e...d6230dec I agree - let's get this in. @aghaisas could you please take a look? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2237144860 From jvos at openjdk.org Thu Jul 18 18:07:42 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 18:07:42 GMT Subject: [jfx17u] Integrated: 8336730: Change JavaFX release version to 17.0.13 in jfx17u In-Reply-To: <5nqyT3YT2Fx-qn4gscqF1kN9VSqj8J3lGeRJASpgxsQ=.ffd5b0f6-d316-4472-abac-3b9b227da419@github.com> References: <5nqyT3YT2Fx-qn4gscqF1kN9VSqj8J3lGeRJASpgxsQ=.ffd5b0f6-d316-4472-abac-3b9b227da419@github.com> Message-ID: On Thu, 18 Jul 2024 08:31:42 GMT, Johan Vos wrote: > Start work on 17.0.13 This pull request has now been integrated. Changeset: e2b18b1d Author: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/e2b18b1d30074406cca1541c195d8cb369d18935 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8336730: Change JavaFX release version to 17.0.13 in jfx17u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx17u/pull/196 From jvos at openjdk.org Thu Jul 18 18:08:39 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 18:08:39 GMT Subject: [jfx17u] RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 08:21:54 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [a118d333](https://github.com/openjdk/jfx/commit/a118d33314a363336134d31c45b50329594e5a24) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Phil Race on 20 Oct 2021 and was reviewed by Kevin Rushforth and Pankaj Bansal. > > Thanks! Marked as reviewed by jvos (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx17u/pull/195#pullrequestreview-2186539236 From jvos at openjdk.org Thu Jul 18 18:09:37 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 18 Jul 2024 18:09:37 GMT Subject: [jfx21u] Integrated: 8336733: Change JavaFX release version to 21.0.5 in jfx21u In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 08:34:10 GMT, Johan Vos wrote: > Start work on 21.0.5 This pull request has now been integrated. Changeset: c1ddcf8b Author: Johan Vos URL: https://git.openjdk.org/jfx21u/commit/c1ddcf8ba5ae3c81366ad7935e45450177b9ba9d Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8336733: Change JavaFX release version to 21.0.5 in jfx21u Reviewed-by: jpereda ------------- PR: https://git.openjdk.org/jfx21u/pull/62 From angorya at openjdk.org Thu Jul 18 19:07:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 18 Jul 2024 19:07:48 GMT Subject: RFR: 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole Message-ID: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> Minor clarifications in Javadoc **AccessibleAttribute**: - Point2D and Bound values uses screen coordinates. Example: `BOUNDS`, `BOUNDS_FOR_RANGE`, `OFFSET_AT_POINT`, ... - clarified the meaning of `SELECTION_END`, `SELECTION_START` **Accessible Role**: - missing accessible action `SHOW_TEXT_RANGE` This will be a minor clarification, so no CSR is required. ------------- Commit messages: - 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole Changes: https://git.openjdk.org/jfx/pull/1512/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1512&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336331 Stats: 12 lines in 2 files changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1512.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1512/head:pull/1512 PR: https://git.openjdk.org/jfx/pull/1512 From jhendrikx at openjdk.org Thu Jul 18 19:34:39 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Thu, 18 Jul 2024 19:34:39 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Thu, 18 Jul 2024 15:26:59 GMT, Andy Goryachev wrote: > Thank you for the detailed writeup! I did not know about `Region.getUserAgentStylesheet()`, especially about its doc "Some JavaFX CSS implementations may choose to cache this response for an indefinite period of time, and therefore there should be no expectation around when this method is called." How are we supposed to implement dynamically changing styles?? The `Region` based system doesn't look well thought out, but I suppose you can force a reload of all styles by changing something at a higher level (like `Scene`). I didn't know it existed either, and it seems to behave differently to other user agent stylesheets (with Application / Scene / SubScene, only one applies, while `Region` can complement it further...) -- I'm guessing this is intended for 3rd parties, so they can style their controls without those styles competing at the same level as author stylesheets (ie. they're sort of "extending" modena). As for dynamically changing styles, it depends on who wants those. If it is the control developer, they can ensure their stylesheet has multiple variants and use a top level selector for changing between one or the other (for example between light and dark). If it is the user of the control, they can do so normally by just replacing stylesheets (or preferably, also using a selector, as that's much faster). > Do I understand you correctly that `Scene.setUserAgentStylesheet()` completely replaces modena.css for that Scene? And then Scene.getStylesheets() will lay on top of that, having higher priority? Yes, that's correct. The code will not use the platform user agent stylesheet when there is either a scene or subscene user agent stylesheet available. This seems to make it possible to say have a Scene in modena style, and another Scene in caspian style without the Application stylesheet potentially interfering. And yes, Scene.getStylesheets layers on top of all that (but those are author stylesheets, so they overrule the user agent stylesheets anyway). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2237377760 From kcr at openjdk.org Thu Jul 18 19:55:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 19:55:38 GMT Subject: [jfx23u] RFR: Merge jfx:jfx23 Message-ID: Clean merge from `jfx:jfx23` to `jfx23u:master`. ------------- Commit messages: - Merge remote-tracking branch 'jfx/jfx23' into merge-jfx-jfx23-to-master-2024-07-18 - 8335630: Crash if Platform::exit called with fullScreen Stage on macOS 14 - 8336272: SizeToSceneTest: fullScreen tests fail on Ubuntu 22.04 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jfx23u/pull/3/files Stats: 171 lines in 5 files changed: 139 ins; 1 del; 31 mod Patch: https://git.openjdk.org/jfx23u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx23u/pull/3 From jpereda at openjdk.org Thu Jul 18 20:52:43 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Thu, 18 Jul 2024 20:52:43 GMT Subject: [jfx17u] Integrated: 8236689: macOS 10.15 Catalina: LCD text renders badly In-Reply-To: References: Message-ID: On Tue, 2 Jul 2024 08:21:54 GMT, Jose Pereda wrote: > Hi all, > > This pull request contains a clean backport of commit [a118d333](https://github.com/openjdk/jfx/commit/a118d33314a363336134d31c45b50329594e5a24) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository. > > The commit being backported was authored by Phil Race on 20 Oct 2021 and was reviewed by Kevin Rushforth and Pankaj Bansal. > > Thanks! This pull request has now been integrated. Changeset: 59c4e81f Author: Jose Pereda URL: https://git.openjdk.org/jfx17u/commit/59c4e81f13dcf5b40cacc6983d219f76ba710f6c Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8236689: macOS 10.15 Catalina: LCD text renders badly Reviewed-by: jvos Backport-of: a118d33314a363336134d31c45b50329594e5a24 ------------- PR: https://git.openjdk.org/jfx17u/pull/195 From duke at openjdk.org Thu Jul 18 21:31:41 2024 From: duke at openjdk.org (duke) Date: Thu, 18 Jul 2024 21:31:41 GMT Subject: Withdrawn: 8285893: Hiding dialog and showing new one causes dialog to be frozen In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 21:45:33 GMT, Marius Hanl wrote: > This PR fixes the dialog freeze problem once and for all. > > This one is a bit tricky to understand, here is how it works: > This bug happens on every platform, although the implementation of nested event loops differs on every platform. > E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. > > Funny enough, the reason why this bug happens is always the same: Timing. > > 1. When we hide a dialog, `_leaveNestedEventLoop` is called. > 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. > 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. > 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. > > So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. > > I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. > There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). > ~Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called.~ > See below for more information. To recover the UI (and in general nested nested event loops ;) we need to set a flag for the `InvokeLaterDispatcher`. > > Lets see if this is the right approach (for all platforms). > Testing appreciated. > # > - [x] Tested on Windows > - [x] Tested on Linux > - [x] Tested on Mac > - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) > - [x] Adjust copyright > - [x] Write Systemtest > - [x] Document the new behaviour - in general, there should be more information what to expect This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1324 From kcr at openjdk.org Thu Jul 18 22:42:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 22:42:08 GMT Subject: [jfx23u] RFR: Merge jfx:jfx23 [v2] In-Reply-To: References: Message-ID: > Clean merge from `jfx:jfx23` to `jfx23u:master`. Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'jfx/jfx23' into merge-jfx-jfx23-to-master-2024-07-18 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos Reviewed-by: jvos Backport-of: 632792d4e7a6399c156df99b1cf69faba476a8c6 - 8336035: Change JavaFX release version to 23.0.1 in jfx23u Reviewed-by: arapte, jvos ------------- Changes: - all: https://git.openjdk.org/jfx23u/pull/3/files - new: https://git.openjdk.org/jfx23u/pull/3/files/2d4c31f6..2d4c31f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx23u&pr=3&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx23u&pr=3&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx23u/pull/3.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/3/head:pull/3 PR: https://git.openjdk.org/jfx23u/pull/3 From kcr at openjdk.org Thu Jul 18 22:42:08 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 18 Jul 2024 22:42:08 GMT Subject: [jfx23u] Integrated: Merge jfx:jfx23 In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 19:50:25 GMT, Kevin Rushforth wrote: > Clean merge from `jfx:jfx23` to `jfx23u:master`. This pull request has now been integrated. Changeset: fa1b4f91 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx23u/commit/fa1b4f91ef76a521fd941b87881f79b3ddd291b1 Stats: 171 lines in 5 files changed: 139 ins; 1 del; 31 mod Merge ------------- PR: https://git.openjdk.org/jfx23u/pull/3 From hmeda at openjdk.org Fri Jul 19 05:33:05 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 19 Jul 2024 05:33:05 GMT Subject: [jfx23u] RFR: 8328994: Update WebKit to 619.1 Message-ID: Clean Backport ------------- Commit messages: - Backport 34bbf85362fae946c6306eb52a8478aa2ca3ef5f Changes: https://git.openjdk.org/jfx23u/pull/4/files Webrev: Webrev is not available because diff is too large Issue: https://bugs.openjdk.org/browse/JDK-8328994 Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod Patch: https://git.openjdk.org/jfx23u/pull/4.diff Fetch: git fetch https://git.openjdk.org/jfx23u.git pull/4/head:pull/4 PR: https://git.openjdk.org/jfx23u/pull/4 From duke at openjdk.org Fri Jul 19 05:39:39 2024 From: duke at openjdk.org (duke) Date: Fri, 19 Jul 2024 05:39:39 GMT Subject: RFR: 8336592: Wrong type in documentation for TreeTableView In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 05:53:45 GMT, ANUPAM DEV wrote: > Hello, > > There was a typo in the documentation of TreeTableView. > I have changed TreeTableColumns to TreeTableColumn > > Please review. > > Regards, > Anupam @anupamdev20 Your change (at version 61ae9ca55d73d5b4e72c4e5d414310a1c2b328a2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1510#issuecomment-2238237251 From hmeda at openjdk.org Fri Jul 19 05:39:41 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 19 Jul 2024 05:39:41 GMT Subject: [jfx23u] Integrated: 8328994: Update WebKit to 619.1 In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 05:25:48 GMT, Hima Bindu Meda wrote: > Clean Backport This pull request has now been integrated. Changeset: eec590a3 Author: Hima Bindu Meda URL: https://git.openjdk.org/jfx23u/commit/eec590a377e7f7b2f91d075008352cc53b2e1240 Stats: 349763 lines in 7157 files changed: 184133 ins; 107646 del; 57984 mod 8328994: Update WebKit to 619.1 Backport-of: 34bbf85362fae946c6306eb52a8478aa2ca3ef5f ------------- PR: https://git.openjdk.org/jfx23u/pull/4 From jbhaskar at openjdk.org Fri Jul 19 06:57:06 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jul 2024 06:57:06 GMT Subject: RFR: 8335548: testCookieEnabled fails with WebKit 619.1 Message-ID: Issue : CookieEnable method returns false when WebView url is empty Solution: Use a dummy file URI in WebView before testing cookie. ------------- Commit messages: - 8335548: testCookieEnabled fails with WebKit 619.1 Changes: https://git.openjdk.org/jfx/pull/1513/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335548 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1513.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1513/head:pull/1513 PR: https://git.openjdk.org/jfx/pull/1513 From jbhaskar at openjdk.org Fri Jul 19 06:57:10 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jul 2024 06:57:10 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 Message-ID: Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. ------------- Commit messages: - 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 - 8335548: testCookieEnabled fails with WebKit 619.1 Changes: https://git.openjdk.org/jfx/pull/1514/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336798 Stats: 196 lines in 4 files changed: 193 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1514.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/jfx/pull/1514 From jbhaskar at openjdk.org Fri Jul 19 06:57:06 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jul 2024 06:57:06 GMT Subject: RFR: 8335548: testCookieEnabled fails with WebKit 619.1 In-Reply-To: References: Message-ID: <04eqFuSvO6HhkskTDE82ZvMBJGRFBIx7lkUHBiztOlI=.e18f52e2-8c5a-40d9-8ac8-8d4a333fd1ff@github.com> On Fri, 19 Jul 2024 01:11:24 GMT, Jay Bhaskar wrote: > Issue : CookieEnable method returns false when WebView url is empty > Solution: Use a dummy file URI in WebView before testing cookie. making this a public bug ------------- PR Comment: https://git.openjdk.org/jfx/pull/1513#issuecomment-2238487507 From kcr at openjdk.org Fri Jul 19 12:04:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jul 2024 12:04:42 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 06:53:16 GMT, Jay Bhaskar wrote: > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. Reviewers: @HimaBinduMeda @kevinrushforth ------------- PR Comment: https://git.openjdk.org/jfx/pull/1514#issuecomment-2238993126 From duke at openjdk.org Fri Jul 19 12:05:39 2024 From: duke at openjdk.org (ANUPAM DEV) Date: Fri, 19 Jul 2024 12:05:39 GMT Subject: Integrated: 8336592: Wrong type in documentation for TreeTableView In-Reply-To: References: Message-ID: On Wed, 17 Jul 2024 05:53:45 GMT, ANUPAM DEV wrote: > Hello, > > There was a typo in the documentation of TreeTableView. > I have changed TreeTableColumns to TreeTableColumn > > Please review. > > Regards, > Anupam This pull request has now been integrated. Changeset: 1117c15e Author: ANUPAM DEV Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/1117c15ea1c6038f708e59ca8d9af2837db73153 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8336592: Wrong type in documentation for TreeTableView Reviewed-by: angorya ------------- PR: https://git.openjdk.org/jfx/pull/1510 From hmeda at openjdk.org Fri Jul 19 13:28:41 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Fri, 19 Jul 2024 13:28:41 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 06:53:16 GMT, Jay Bhaskar wrote: > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. As the changes in MiscellaneousTest.java and cookie.html are not related to this PR, these files should be removed from this PR. ------------- PR Review: https://git.openjdk.org/jfx/pull/1514#pullrequestreview-2188243310 From jbhaskar at openjdk.org Fri Jul 19 13:47:53 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jul 2024 13:47:53 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v2] In-Reply-To: References: Message-ID: <_JK5FhdXhQZfHnS8Bb3BJzVgoqDwRRAOWLcX2r9lXBc=.e33effa1-2d5f-42e8-a2b1-be86230cbac3@github.com> > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove extra files checked in by mistake ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1514/files - new: https://git.openjdk.org/jfx/pull/1514/files/c88cc5c1..d166caef Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=00-01 Stats: 517 lines in 2 files changed: 0 ins; 517 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1514.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/jfx/pull/1514 From jbhaskar at openjdk.org Fri Jul 19 13:53:08 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Fri, 19 Jul 2024 13:53:08 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v3] In-Reply-To: References: Message-ID: > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: restore master file ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1514/files - new: https://git.openjdk.org/jfx/pull/1514/files/d166caef..0813acc4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=01-02 Stats: 502 lines in 1 file changed: 502 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1514.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/jfx/pull/1514 From kcr at openjdk.org Fri Jul 19 17:46:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jul 2024 17:46:37 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v3] In-Reply-To: References: Message-ID: <7alxu1oG6ky5ZQ5AUYlNEpkc_F6dD_4e1CWOVOrN0eA=.8e18f4f1-1b85-4a8f-a84f-0c7f150d2c14@github.com> On Fri, 19 Jul 2024 13:53:08 GMT, Jay Bhaskar wrote: >> Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. >> Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > restore master file The fix looks good. So does the test (with minor comments). I confirm that the test fails without the fix and passes with the fix. I left mostly minor suggestions on the test, but will approve it as is. If you choose to make the changes, I'll reapprove. Otherwise, please file a follow-up bug to convert the test to JUnit 5; you can do the rest of the suggested cleanup as part of that. tests/system/src/test/java/test/javafx/scene/web/CSSRoundingTest.java line 41: > 39: import org.junit.Before; > 40: import org.junit.BeforeClass; > 41: import org.junit.Test; Since this is a new standalone test, it would be good to use JUnit 5 rather than 4. This could be done as a follow-up if you prefer. tests/system/src/test/java/test/javafx/scene/web/CSSRoundingTest.java line 84: > 82: Scene scene = new Scene(webView, 150, 100); > 83: cssRoundingTestApp.primaryStage.setScene(scene); > 84: cssRoundingTestApp.primaryStage.show(); Suggestion: move all of this to the application `start()` method, then add the following to trigger the `launchLatch`: primaryStage.setOnShown(e -> Platform.runLater(launchLatch::countDown)); See [FullScreenExitTest.java : line 73](https://github.com/openjdk/jfx/blob/master/tests/system/src/test/java/test/javafx/stage/FullScreenExitTest.java#L73C1) tests/system/src/test/java/test/javafx/scene/web/CSSRoundingTest.java line 88: > 86: } > 87: > 88: @Test public void testCSSroundingForLinearLayout() { Minor: move the `@Test` annotation to its own line. tests/system/src/test/java/test/javafx/scene/web/CSSRoundingTest.java line 154: > 152: assertTrue("Timeout when waiting for focus change ", Util.await(webViewStateLatch)); > 153: //introduce sleep , so that web contents would be loaded , then take snapshot for testing > 154: Util.sleep(1000); The sleep may or may not be needed, but OK to leave it. The comment is wrong, though, since you aren't taking a snapshot. tests/system/src/test/java/test/javafx/scene/web/CSSRoundingTest.java line 170: > 168: assertEquals(31, topBottom); > 169: assertEquals(31, bottomTop); > 170: Minor: you can remove the extra blank line here. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1514#pullrequestreview-2188742017 PR Review Comment: https://git.openjdk.org/jfx/pull/1514#discussion_r1684676870 PR Review Comment: https://git.openjdk.org/jfx/pull/1514#discussion_r1684684385 PR Review Comment: https://git.openjdk.org/jfx/pull/1514#discussion_r1684685106 PR Review Comment: https://git.openjdk.org/jfx/pull/1514#discussion_r1684687295 PR Review Comment: https://git.openjdk.org/jfx/pull/1514#discussion_r1684688326 From kcr at openjdk.org Fri Jul 19 18:28:39 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jul 2024 18:28:39 GMT Subject: RFR: 8335548: testCookieEnabled fails with WebKit 619.1 In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 01:11:24 GMT, Jay Bhaskar wrote: > Issue : CookieEnable method returns false when WebView url is empty > Solution: Use a dummy file URI in WebView before testing cookie. I confirm that the test now passes. I left one comment on the html file you added and will reapprove if you change it. modules/javafx.web/src/test/resources/test/html/cookie.html line 4: > 2: > 3: > 4: The redirect to another html file seems unnecessary. Is there a reason you added it? If I locally remove the `...` block the still passes. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1513#pullrequestreview-2188920799 PR Review Comment: https://git.openjdk.org/jfx/pull/1513#discussion_r1684800629 From angorya at openjdk.org Fri Jul 19 21:53:52 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jul 2024 21:53:52 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:10:27 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case thanks for the writeup! these are quite helpful. since this PR changes the way CSS is resolved, I wonder if we need a CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2240268605 From kcr at openjdk.org Fri Jul 19 22:44:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 19 Jul 2024 22:44:48 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 19 Jul 2024 21:51:27 GMT, Andy Goryachev wrote: > since this PR changes the way CSS is resolved, I wonder if we need a CSR. That's a good question. My take is that we don't, since this is a bug fix that restores the behavior to what it was before a previous bug fix exposed the bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1503#issuecomment-2240449675 From angorya at openjdk.org Fri Jul 19 23:29:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jul 2024 23:29:38 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 15 Jul 2024 12:10:27 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add test case Thank you for all the explanations! I did a quick test with the Monkey Tester, setting various styles. Haven't found any issues. Left a few comments inline. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 73: > 71: } > 72: > 73: @BeforeEach since we are now creating Stage every time, shouldn't we `hide()` it each time? modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 696: > 694: AUTHOR_OVERRIDES_USER_AGENT(RED_STYLESHEET, null, GRAY_STYLESHEET, null), > 695: AUTHOR_OVERRIDES_INDIRECT_USER_AGENT(RED_INDIRECT_STYLESHEET, null, GRAY_STYLESHEET, null), > 696: AUTHOR_OVERRIDES_PROPERTY(RED_STYLESHEET, Color.BLUE, GRAY_STYLESHEET, null), should another one be added here: `AUTHOR_OVERRIDES_PROPERTY2(RED_INDIRECT_STYLESHEET, Color.BLUE, GRAY_STYLESHEET, null),` and also `AUTHOR_OVERRIDES_PROPERTY(RED_INDIRECT_STYLESHEET, Color.BLUE, GRAY_STYLESHEET, "-fx-base: yellow"),` modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 705: > 703: INLINE_OVERRIDES_USER_AGENT(RED_STYLESHEET, null, null, "-fx-background-color: #808080"), > 704: INLINE_OVERRIDES_PROPERTY(RED_STYLESHEET, Color.BLUE, null, "-fx-background-color: #808080"), > 705: INLINE_OVERRIDES_AUTHOR(RED_STYLESHEET, null, RED_STYLESHEET, "-fx-background-color: #808080"), Should we add other combinations: (R,B,R,.. (RED_INDIRECT,.. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 710: > 708: INLINE_VARIABLE_OVERRIDES_USER_AGENT_VARIABLE(RED_INDIRECT_STYLESHEET, null, null, "-fx-base: #808080"), > 709: INLINE_VARIABLE_OVERRIDES_AUTHOR_VARIABLE(RED_INDIRECT_STYLESHEET, null, FX_BASE_GREEN_STYLESHEET, "-fx-base: #808080"); > 710: also, would it make sense to add tests for null/empty userAgentStylesheet, for completeness sake? ------------- PR Review: https://git.openjdk.org/jfx/pull/1503#pullrequestreview-2189475186 PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1685117648 PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1685082283 PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1685085547 PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1685086065 From angorya at openjdk.org Fri Jul 19 23:29:39 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 19 Jul 2024 23:29:39 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 19 Jul 2024 22:54:23 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 710: > >> 708: INLINE_VARIABLE_OVERRIDES_USER_AGENT_VARIABLE(RED_INDIRECT_STYLESHEET, null, null, "-fx-base: #808080"), >> 709: INLINE_VARIABLE_OVERRIDES_AUTHOR_VARIABLE(RED_INDIRECT_STYLESHEET, null, FX_BASE_GREEN_STYLESHEET, "-fx-base: #808080"); >> 710: > > also, would it make sense to add tests for null/empty userAgentStylesheet, for completeness sake? Another question: do we want to go through all the cases of Scene/SubScene/Parent/Region user agent style sheet, for completeness sake, or would that be a different test file? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1685087427 From jbhaskar at openjdk.org Sat Jul 20 00:36:04 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 20 Jul 2024 00:36:04 GMT Subject: RFR: 8335548: testCookieEnabled fails with WebKit 619.1 [v2] In-Reply-To: References: Message-ID: > Issue : CookieEnable method returns false when WebView url is empty > Solution: Use a dummy file URI in WebView before testing cookie. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: remove un-needed redirection from html ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1513/files - new: https://git.openjdk.org/jfx/pull/1513/files/556e2295..ef2610c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1513&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1513&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1513.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1513/head:pull/1513 PR: https://git.openjdk.org/jfx/pull/1513 From jbhaskar at openjdk.org Sat Jul 20 05:46:15 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 20 Jul 2024 05:46:15 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v4] In-Reply-To: References: Message-ID: <-sEY0MqxmcqinxKgIvXGZUaMQxg1neAmDiPlO2XzweU=.a42351c0-8d0f-465e-bba5-b1b25b782e9a@github.com> > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: make test as JNUIT5 and apply review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1514/files - new: https://git.openjdk.org/jfx/pull/1514/files/0813acc4..ee9fcce1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=02-03 Stats: 54 lines in 1 file changed: 11 ins; 17 del; 26 mod Patch: https://git.openjdk.org/jfx/pull/1514.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/jfx/pull/1514 From jbhaskar at openjdk.org Sat Jul 20 05:46:15 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sat, 20 Jul 2024 05:46:15 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v3] In-Reply-To: <7alxu1oG6ky5ZQ5AUYlNEpkc_F6dD_4e1CWOVOrN0eA=.8e18f4f1-1b85-4a8f-a84f-0c7f150d2c14@github.com> References: <7alxu1oG6ky5ZQ5AUYlNEpkc_F6dD_4e1CWOVOrN0eA=.8e18f4f1-1b85-4a8f-a84f-0c7f150d2c14@github.com> Message-ID: On Fri, 19 Jul 2024 17:20:32 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> restore master file > > tests/system/src/test/java/test/javafx/scene/web/CSSRoundingTest.java line 88: > >> 86: } >> 87: >> 88: @Test public void testCSSroundingForLinearLayout() { > > Minor: move the `@Test` annotation to its own line. done ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1514#discussion_r1685265193 From kcr at openjdk.org Sat Jul 20 13:09:35 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 20 Jul 2024 13:09:35 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v4] In-Reply-To: <-sEY0MqxmcqinxKgIvXGZUaMQxg1neAmDiPlO2XzweU=.a42351c0-8d0f-465e-bba5-b1b25b782e9a@github.com> References: <-sEY0MqxmcqinxKgIvXGZUaMQxg1neAmDiPlO2XzweU=.a42351c0-8d0f-465e-bba5-b1b25b782e9a@github.com> Message-ID: On Sat, 20 Jul 2024 05:46:15 GMT, Jay Bhaskar wrote: >> Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. >> Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > make test as JNUIT5 and apply review comments Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1514#pullrequestreview-2189981104 From kcr at openjdk.org Sat Jul 20 13:10:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 20 Jul 2024 13:10:37 GMT Subject: RFR: 8335548: testCookieEnabled fails with WebKit 619.1 [v2] In-Reply-To: References: Message-ID: On Sat, 20 Jul 2024 00:36:04 GMT, Jay Bhaskar wrote: >> Issue : CookieEnable method returns false when WebView url is empty >> Solution: Use a dummy file URI in WebView before testing cookie. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > remove un-needed redirection from html Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1513#pullrequestreview-2189981210 From jbhaskar at openjdk.org Sun Jul 21 04:23:39 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 21 Jul 2024 04:23:39 GMT Subject: Integrated: 8335548: testCookieEnabled fails with WebKit 619.1 In-Reply-To: References: Message-ID: <1bmtCZq6uGJJ2ILlB2e5MEcwbIYLH0KTkZN6Er7pkHI=.8fe109f6-731a-4e64-9f6f-8ae898eb7d60@github.com> On Fri, 19 Jul 2024 01:11:24 GMT, Jay Bhaskar wrote: > Issue : CookieEnable method returns false when WebView url is empty > Solution: Use a dummy file URI in WebView before testing cookie. This pull request has now been integrated. Changeset: 33d82c04 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/33d82c04dd8c4c3fa9188da5c263e0f406a2c920 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod 8335548: testCookieEnabled fails with WebKit 619.1 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1513 From jbhaskar at openjdk.org Sun Jul 21 07:03:11 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Sun, 21 Jul 2024 07:03:11 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v5] In-Reply-To: References: Message-ID: > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge remote-tracking branch 'upstream/master' into 8336798 - make test as JNUIT5 and apply review comments - restore master file - remove extra files checked in by mistake - 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 - 8335548: testCookieEnabled fails with WebKit 619.1 ------------- Changes: https://git.openjdk.org/jfx/pull/1514/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1514&range=04 Stats: 173 lines in 2 files changed: 172 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1514.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/jfx/pull/1514 From hmeda at openjdk.org Mon Jul 22 05:27:40 2024 From: hmeda at openjdk.org (Hima Bindu Meda) Date: Mon, 22 Jul 2024 05:27:40 GMT Subject: RFR: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 [v5] In-Reply-To: References: Message-ID: On Sun, 21 Jul 2024 07:03:11 GMT, Jay Bhaskar wrote: >> Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. >> Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. > > Jay Bhaskar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'upstream/master' into 8336798 > - make test as JNUIT5 and apply review comments > - restore master file > - remove extra files checked in by mistake > - 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 > - 8335548: testCookieEnabled fails with WebKit 619.1 Verified that the test is now successful. Changes look fine ------------- Marked as reviewed by hmeda (Committer). PR Review: https://git.openjdk.org/jfx/pull/1514#pullrequestreview-2190650467 From jbhaskar at openjdk.org Mon Jul 22 05:48:43 2024 From: jbhaskar at openjdk.org (Jay Bhaskar) Date: Mon, 22 Jul 2024 05:48:43 GMT Subject: Integrated: 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 In-Reply-To: References: Message-ID: On Fri, 19 Jul 2024 06:53:16 GMT, Jay Bhaskar wrote: > Issue: CSSRounding.html DRT Test fails due sub pixel layout. The fractional value adds up to 1px extra height. > Solution: The Prefer height calculation should do flooring of fractional values. This is valid for Linear Layout which is a legacy support to most of the browsers. This pull request has now been integrated. Changeset: 06ac1678 Author: Jay Bhaskar URL: https://git.openjdk.org/jfx/commit/06ac16789f071ec6aca55697c139789ca3218c0d Stats: 173 lines in 2 files changed: 172 ins; 0 del; 1 mod 8336798: DRT test cssrounding.html test for linear layout fails with WebKit 619.1 Reviewed-by: hmeda, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1514 From jhendrikx at openjdk.org Mon Jul 22 09:49:48 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 09:49:48 GMT Subject: RFR: 8336882: Convert CssStyleHelperTest to use JUnit 5 Message-ID: Conversion of the CssStyleHelperTest to JUnit 5 for PR's #1503 and #1505 ------------- Commit messages: - Convert CssStyleHelperTest to JUnit 5 test Changes: https://git.openjdk.org/jfx/pull/1515/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1515&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336882 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jfx/pull/1515.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1515/head:pull/1515 PR: https://git.openjdk.org/jfx/pull/1515 From jhendrikx at openjdk.org Mon Jul 22 09:59:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 09:59:40 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 19 Jul 2024 23:23:45 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 73: > >> 71: } >> 72: >> 73: @BeforeEach > > since we are now creating Stage every time, shouldn't we `hide()` it each time? This was already done each time, it has not changed, only the annotation. The semantics of `@Before` in JUnit 4 and `@BeforeEach` in JUnit 5 are the same. However, see #1515 as I'll remove these changes from this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686294085 From jhendrikx at openjdk.org Mon Jul 22 10:04:42 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 10:04:42 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> On Fri, 19 Jul 2024 22:56:22 GMT, Andy Goryachev wrote: > Another question: do we want to go through all the cases of Scene/SubScene/Parent/Region user agent style sheet, for completeness sake, or would that be a different test file? In my opinion, this does seem a bit of out of scope for this change. It would not add any new coverage to the code that was changed. Also the origin of the user agent stylesheet is not a factor in the resolution of lookups. The user agent stylesheets, their replacement (via Scene/Subscene) or addition (via Region) should (already?) be tested elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686300569 From jhendrikx at openjdk.org Mon Jul 22 10:07:36 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 10:07:36 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 09:56:41 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 73: >> >>> 71: } >>> 72: >>> 73: @BeforeEach >> >> since we are now creating Stage every time, shouldn't we `hide()` it each time? > > This was already done each time, it has not changed, only the annotation. The semantics of `@Before` in JUnit 4 and `@BeforeEach` in JUnit 5 are the same. However, see #1515 as I'll remove these changes from this PR. I'm not entirely sure on the semantics of `Stage` when it is run with the stub toolkit; I suspect they won't stick around when no longer referenced, or this test would have been an issue when it was created years ago already. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686304866 From mstrauss at openjdk.org Mon Jul 22 10:32:38 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 22 Jul 2024 10:32:38 GMT Subject: RFR: 8336882: Convert CssStyleHelperTest to use JUnit 5 In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 09:45:38 GMT, John Hendrikx wrote: > Conversion of the CssStyleHelperTest to JUnit 5 for PR's #1503 and #1505 Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1515#pullrequestreview-2191214920 From mhanl at openjdk.org Mon Jul 22 11:02:41 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 22 Jul 2024 11:02:41 GMT Subject: RFR: 8336882: Convert CssStyleHelperTest to use JUnit 5 In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 09:45:38 GMT, John Hendrikx wrote: > Conversion of the CssStyleHelperTest to JUnit 5 for PR's #1503 and #1505 Marked as reviewed by mhanl (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1515#pullrequestreview-2191270417 From kcr at openjdk.org Mon Jul 22 12:28:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 12:28:43 GMT Subject: RFR: 8336882: Convert CssStyleHelperTest to use JUnit 5 In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 09:45:38 GMT, John Hendrikx wrote: > Conversion of the CssStyleHelperTest to JUnit 5 for PR's #1503 and #1505 Looks good. This is a simple enough test-only fix that you can integrate it without waiting for 1 day, if you want. Also, this would be reasonable to backport to jfx23 if you intend to target either of the two fixes that depend on it to jfx23. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1515#pullrequestreview-2191428909 PR Comment: https://git.openjdk.org/jfx/pull/1515#issuecomment-2242832336 From jhendrikx at openjdk.org Mon Jul 22 13:12:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 13:12:37 GMT Subject: Integrated: 8336882: Convert CssStyleHelperTest to use JUnit 5 In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 09:45:38 GMT, John Hendrikx wrote: > Conversion of the CssStyleHelperTest to JUnit 5 for PR's #1503 and #1505 This pull request has now been integrated. Changeset: d538c318 Author: John Hendrikx URL: https://git.openjdk.org/jfx/commit/d538c318fbef5198b7b0ea86df826cf4fe1adc5a Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod 8336882: Convert CssStyleHelperTest to use JUnit 5 Reviewed-by: mstrauss, mhanl, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1515 From jhendrikx at openjdk.org Mon Jul 22 13:23:52 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 13:23:52 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v3] In-Reply-To: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: <-JdM-sVWpQfnqqBAgc_cJAIlhvxFwBU9D5Kxbc9nsZU=.3391e9f1-37c3-4bdd-a3fd-f00c50167f6f@github.com> > This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. > > Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: > > if (hasInlineStyle) { > Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); > if (selector != null) selectors.add(selector); > } John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' of https://git.openjdk.org/jfx into feature/remove-origin-priority-change-while-resolving - Add test case - Remove origin determination from resolveLookups ------------- Changes: https://git.openjdk.org/jfx/pull/1503/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=02 Stats: 116 lines in 2 files changed: 93 ins; 17 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1503.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1503/head:pull/1503 PR: https://git.openjdk.org/jfx/pull/1503 From jhendrikx at openjdk.org Mon Jul 22 14:10:56 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 14:10:56 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v4] In-Reply-To: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: > This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. > > Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: > > if (hasInlineStyle) { > Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); > if (selector != null) selectors.add(selector); > } John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1503/files - new: https://git.openjdk.org/jfx/pull/1503/files/f918e2fa..b882be04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=02-03 Stats: 27 lines in 1 file changed: 9 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jfx/pull/1503.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1503/head:pull/1503 PR: https://git.openjdk.org/jfx/pull/1503 From jhendrikx at openjdk.org Mon Jul 22 14:10:57 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 14:10:57 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 19 Jul 2024 22:53:36 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 705: > >> 703: INLINE_OVERRIDES_USER_AGENT(RED_STYLESHEET, null, null, "-fx-background-color: #808080"), >> 704: INLINE_OVERRIDES_PROPERTY(RED_STYLESHEET, Color.BLUE, null, "-fx-background-color: #808080"), >> 705: INLINE_OVERRIDES_AUTHOR(RED_STYLESHEET, null, RED_STYLESHEET, "-fx-background-color: #808080"), > > Should we add other combinations: > (R,B,R,.. > (RED_INDIRECT,.. I've added cases where user agent stylesheet is `null`, but I've not added all combinations -- I feel there is no point to check if an inline style will override all combinations of user agent, property and author styles when there are already 3 cases that check if the inline style will override user agent, property and author styles individually. That said, I've added a few cases where ALL competing options are set (ie. for inline, a case where UA, property and author are set, and see if inline still wins). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686618843 From jhendrikx at openjdk.org Mon Jul 22 14:13:38 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 14:13:38 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Fri, 19 Jul 2024 22:49:02 GMT, Andy Goryachev wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 696: > >> 694: AUTHOR_OVERRIDES_USER_AGENT(RED_STYLESHEET, null, GRAY_STYLESHEET, null), >> 695: AUTHOR_OVERRIDES_INDIRECT_USER_AGENT(RED_INDIRECT_STYLESHEET, null, GRAY_STYLESHEET, null), >> 696: AUTHOR_OVERRIDES_PROPERTY(RED_STYLESHEET, Color.BLUE, GRAY_STYLESHEET, null), > > should another one be added here: > `AUTHOR_OVERRIDES_PROPERTY2(RED_INDIRECT_STYLESHEET, Color.BLUE, GRAY_STYLESHEET, null),` > > and also > `AUTHOR_OVERRIDES_PROPERTY(RED_INDIRECT_STYLESHEET, Color.BLUE, GRAY_STYLESHEET, "-fx-base: yellow"),` I've added the indirect cases in a separate blocks. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686623573 From jhendrikx at openjdk.org Mon Jul 22 14:16:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 14:16:37 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> Message-ID: On Mon, 22 Jul 2024 10:01:44 GMT, John Hendrikx wrote: >> Another question: >> do we want to go through all the cases of Scene/SubScene/Parent/Region user agent style sheet, for completeness sake, or would that be a different test file? > >> Another question: do we want to go through all the cases of Scene/SubScene/Parent/Region user agent style sheet, for completeness sake, or would that be a different test file? > > In my opinion, this does seem a bit of out of scope for this change. It would not add any new coverage to the code that was changed. Also the origin of the user agent stylesheet is not a factor in the resolution of lookups. The user agent stylesheets, their replacement (via Scene/Subscene) or addition (via Region) should (already?) be tested elsewhere. I added a few cases where user agent is `null`. I've not added all combinations as that would lead to 20-30 extra cases that add little of value. If I already verified that INLINE will override the lower priority sources individually, then it's safe to say that all possible other combinations of those lower priority sources will also get overridden. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686628470 From jhendrikx at openjdk.org Mon Jul 22 14:21:37 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 14:21:37 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 10:05:07 GMT, John Hendrikx wrote: >> This was already done each time, it has not changed, only the annotation. The semantics of `@Before` in JUnit 4 and `@BeforeEach` in JUnit 5 are the same. However, see #1515 as I'll remove these changes from this PR. > > I'm not entirely sure on the semantics of `Stage` when it is run with the stub toolkit; I suspect they won't stick around when no longer referenced, or this test would have been an issue when it was created years ago already. The annotation changes have now been removed from this PR now that #1515 has been integrated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686635581 From mstrauss at openjdk.org Mon Jul 22 14:42:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 22 Jul 2024 14:42:42 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v4] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: <_6h5KqOaQiXwpYpr1DJDBL5x0iQiNhZSYIFmSSJf1bs=.c115ff22-a9a8-4cef-8f10-1d3cfbae1c3f@github.com> On Mon, 22 Jul 2024 14:10:56 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I've tested a few cases, which work as expected. This patch looks good to go. ------------- Marked as reviewed by mstrauss (Committer). PR Review: https://git.openjdk.org/jfx/pull/1503#pullrequestreview-2191777429 From angorya at openjdk.org Mon Jul 22 14:53:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jul 2024 14:53:42 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> Message-ID: On Mon, 22 Jul 2024 14:14:28 GMT, John Hendrikx wrote: >>> Another question: do we want to go through all the cases of Scene/SubScene/Parent/Region user agent style sheet, for completeness sake, or would that be a different test file? >> >> In my opinion, this does seem a bit of out of scope for this change. It would not add any new coverage to the code that was changed. Also the origin of the user agent stylesheet is not a factor in the resolution of lookups. The user agent stylesheets, their replacement (via Scene/Subscene) or addition (via Region) should (already?) be tested elsewhere. > > I added a few cases where user agent is `null`. I've not added all combinations as that would lead to 20-30 extra cases that add little of value. If I already verified that INLINE will override the lower priority sources individually, then it's safe to say that all possible other combinations of those lower priority sources will also get overridden. I still think there is a value in providing exhaustive coverage, especially since the number of combination is relatively low. The added value, for instance, is to guard against regressions introduced by other people. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686688812 From kcr at openjdk.org Mon Jul 22 15:03:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 15:03:41 GMT Subject: RFR: 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole In-Reply-To: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> References: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> Message-ID: On Thu, 18 Jul 2024 19:00:06 GMT, Andy Goryachev wrote: > Minor clarifications in Javadoc > > **AccessibleAttribute**: > - Point2D and Bound values uses screen coordinates. Example: `BOUNDS`, `BOUNDS_FOR_RANGE`, `OFFSET_AT_POINT`, ... > - clarified the meaning of `SELECTION_END`, `SELECTION_START` > > **Accessible Role**: > - missing accessible action `SHOW_TEXT_RANGE` > > This will be a minor clarification, so no CSR is required. Reviewer: @arapte ------------- PR Comment: https://git.openjdk.org/jfx/pull/1512#issuecomment-2243178723 From angorya at openjdk.org Mon Jul 22 15:08:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jul 2024 15:08:44 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 14:18:57 GMT, John Hendrikx wrote: >> I'm not entirely sure on the semantics of `Stage` when it is run with the stub toolkit; I suspect they won't stick around when no longer referenced, or this test would have been an issue when it was created years ago already. > > The annotation changes have now been removed from this PR now that #1515 has been integrated. This question may not relate to this PR as it does not change the existing logic. I wonder if the lingering Stages affect the test(s) in some way. Is FX subsystem getting shut down after each test class? Does anyone know? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686711142 From mstrauss at openjdk.org Mon Jul 22 15:08:45 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 22 Jul 2024 15:08:45 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v4] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 14:10:56 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Review comments modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 689: > 687: PROPERTY_OVERRIDES_INDIRECT_UA(RED_INDIRECT_STYLESHEET, Color.web("#808080"), null, null), > 688: > 689: // Property wins even if indirectly overridden by author or inline style (resolving of a lookup does not change priority of the user agent style):: You might want to remove the double colon at the end of the sentence. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686712452 From kcr at openjdk.org Mon Jul 22 15:10:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 15:10:41 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> <90PD1j7i6AP-xrwhY4TkvBeHhS53Tjs7-eB1PiKhLdQ=.144272fa-1d45-44ec-a3c8-c2ca8b37cf63@github.com> Message-ID: On Tue, 16 Jul 2024 19:30:04 GMT, John Hendrikx wrote: >> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 686: >> >>> 684: root.getChildren().addAll(a); >>> 685: >>> 686: assertDoesNotThrow(() -> stage.show()); // This should not result in a StackOverflowError >> >> Since this is still a JUnit 4 test, perhaps replace this with a try/catch and call `Assert.fail` in the `catch` block? > > Yeah, I can change that, I was hoping this (less important) PR would probably be integrated after #1503 Now that PR #1515 is integrated, this is fine. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1686714538 From kcr at openjdk.org Mon Jul 22 15:13:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 15:13:41 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 15 Jul 2024 13:30:13 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fix formatting and spelling I'll approve it as-is and reapprove if you are able to add a check for `CssParser::errorsProperty`. You might want to merge in the latest upstream master to pick up the JUnit 5 change (also, Skara doesn't report a conflict, but GitHub does). ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2191859524 PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2243201764 From kcr at openjdk.org Mon Jul 22 15:17:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 15:17:38 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> Message-ID: On Mon, 22 Jul 2024 14:50:33 GMT, Andy Goryachev wrote: >> I added a few cases where user agent is `null`. I've not added all combinations as that would lead to 20-30 extra cases that add little of value. If I already verified that INLINE will override the lower priority sources individually, then it's safe to say that all possible other combinations of those lower priority sources will also get overridden. > > I still think there is a value in providing exhaustive coverage, especially since the number of combination is relatively low. The added value, for instance, is to guard against regressions introduced by other people. Hmm. I think an exhaustive set is probably overkill in this case, although I don't feel strongly one way or the other. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686725469 From kcr at openjdk.org Mon Jul 22 15:20:37 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 15:20:37 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 22 Jul 2024 15:11:15 GMT, Kevin Rushforth wrote: > You might want to merge in the latest upstream master to pick up the JUnit 5 change (also, Skara doesn't report a conflict, but GitHub does). Skara woke up and reported the merge conflict, so you will need to merge master anyway. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2243216046 From jhendrikx at openjdk.org Mon Jul 22 16:01:12 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 16:01:12 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v5] In-Reply-To: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: > This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. > > Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: > > if (hasInlineStyle) { > Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); > if (selector != null) selectors.add(selector); > } John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Fixed comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1503/files - new: https://git.openjdk.org/jfx/pull/1503/files/b882be04..3ac758f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1503&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1503.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1503/head:pull/1503 PR: https://git.openjdk.org/jfx/pull/1503 From jhendrikx at openjdk.org Mon Jul 22 16:01:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 16:01:13 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> Message-ID: On Mon, 22 Jul 2024 14:50:33 GMT, Andy Goryachev wrote: >> I added a few cases where user agent is `null`. I've not added all combinations as that would lead to 20-30 extra cases that add little of value. If I already verified that INLINE will override the lower priority sources individually, then it's safe to say that all possible other combinations of those lower priority sources will also get overridden. > > I still think there is a value in providing exhaustive coverage, especially since the number of combination is relatively low. The added value, for instance, is to guard against regressions introduced by other people. @andy-goryachev-oracle Could you be more specific which cases (related to this change and lookups) are currently not being adequately covered? I'm of the opinion that the tests are more than sufficient for the changes involved, I don't think it is the responsibility of this PR to add coverage in areas unrelated to it. The cases you are requesting IMHO check cascading rules, which should already be verified elsewhere (and if not, is certainly not something that should be part of this PR). The tests I added include 19(!) new cases (versus the 13 that existed before), but don't add **any** new coverage (lookups were already covered by for example `removingThenAddingNodeToDifferentBranchGetsIneritableStyle`) -- they're only adding assertions specifically for this change. One might even say I overdid it here, as half of the tests don't even deal with lookups (ie. all the cases where no "indirect" variant is involved). Making these test cases exhaustive for something that has 4 variables and 3-4 options each would result in 80+ cases. So adding further tests does not seem to serve any purpose from where I stand; most of the requested additional cases would not even involve lookups, or would just confirm existing cascading rules (if an inline style overrides a property **or** author style, then it would also override property **and** author style). And none of them would extra coverage... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686779185 From jhendrikx at openjdk.org Mon Jul 22 16:01:13 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 16:01:13 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v4] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 15:06:24 GMT, Michael Strau? wrote: >> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 689: > >> 687: PROPERTY_OVERRIDES_INDIRECT_UA(RED_INDIRECT_STYLESHEET, Color.web("#808080"), null, null), >> 688: >> 689: // Property wins even if indirectly overridden by author or inline style (resolving of a lookup does not change priority of the user agent style):: > > You might want to remove the double colon at the end of the sentence. Fixed, thanks ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686782371 From jhendrikx at openjdk.org Mon Jul 22 16:04:53 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 16:04:53 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v3] In-Reply-To: References: Message-ID: > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' of https://git.openjdk.org/jfx into feature/fix-stackoverflow-in-resolve-lookups - Fix formatting and spelling - Fix loop detection in resolveLookups ------------- Changes: https://git.openjdk.org/jfx/pull/1505/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=02 Stats: 68 lines in 2 files changed: 55 ins; 9 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From kcr at openjdk.org Mon Jul 22 16:19:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 16:19:38 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v3] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 16:04:53 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' of https://git.openjdk.org/jfx into > feature/fix-stackoverflow-in-resolve-lookups > - Fix formatting and spelling > - Fix loop detection in resolveLookups Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2192003916 From mstrauss at openjdk.org Mon Jul 22 16:29:40 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 22 Jul 2024 16:29:40 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v5] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 16:01:12 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comments Marked as reviewed by mstrauss (Committer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1503#pullrequestreview-2192030458 From angorya at openjdk.org Mon Jul 22 16:49:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jul 2024 16:49:38 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v5] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 16:01:12 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comments Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1503#pullrequestreview-2192068990 From angorya at openjdk.org Mon Jul 22 16:49:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jul 2024 16:49:38 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v2] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> <9exHeska1gouqBBI36SLd47SUAbqrrNsdoGl3j8qhg0=.412cba24-350e-408e-b74c-4ef25e4a87f2@github.com> Message-ID: On Mon, 22 Jul 2024 15:54:18 GMT, John Hendrikx wrote: >> I still think there is a value in providing exhaustive coverage, especially since the number of combination is relatively low. The added value, for instance, is to guard against regressions introduced by other people. > > @andy-goryachev-oracle > > Could you be more specific which cases (related to this change and lookups) are currently not being adequately covered? > > I'm of the opinion that the tests are more than sufficient for the changes involved, I don't think it is the responsibility of this PR to add coverage in areas unrelated to it. The cases you are requesting IMHO check cascading rules, which should already be verified elsewhere (and if not, is certainly not something that should be part of this PR). > > The tests I added include 19(!) new cases (versus the 13 that existed before), but don't add **any** new coverage (lookups were already covered by for example `removingThenAddingNodeToDifferentBranchGetsIneritableStyle`) -- they're only adding assertions specifically for this change. One might even say I overdid it here, as half of the tests don't even deal with lookups (ie. all the cases where no "indirect" variant is involved). Making these test cases exhaustive for something that has 4 variables and 3-4 options each would result in 80+ cases. > > So adding further tests does not seem to serve any purpose from where I stand; most of the requested additional cases would not even involve lookups, or would just confirm existing cascading rules (if an inline style overrides a property **or** author style, then it would also override property **and** author style). And none of them would extra coverage... fine ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1503#discussion_r1686847995 From angorya at openjdk.org Mon Jul 22 17:19:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jul 2024 17:19:41 GMT Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US QWERTY keyboard layout [v2] In-Reply-To: References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com> Message-ID: On Tue, 14 May 2024 22:29:18 GMT, Martin Fox wrote: >> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work. >> >> This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard. >> >> (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.) >> >> This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level. > > Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Comment fixes > - Consistency in naming conventions and comment cleanup. > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Expanded robot lookup table, general cleanup > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - Resolving duplicates for Robot, fallback for getKeyCodeForChar > - Merge remote-tracking branch 'upstream/master' into linuxcharcombo > - KeyCharacterCombination fixes on Linux @kevinrushforth please review ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1373#pullrequestreview-2192126620 From kcr at openjdk.org Mon Jul 22 19:53:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 19:53:44 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v5] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 16:01:12 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comments Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1503#pullrequestreview-2192432475 From jhendrikx at openjdk.org Mon Jul 22 20:25:09 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 20:25:09 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v4] In-Reply-To: References: Message-ID: > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add check on errorProperty ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1505/files - new: https://git.openjdk.org/jfx/pull/1505/files/ddfd0cf6..6c5b7717 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=02-03 Stats: 100 lines in 1 file changed: 100 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From jhendrikx at openjdk.org Mon Jul 22 20:33:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 20:33:40 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v2] In-Reply-To: References: <2-HwUXAQaNTTIOJWZmlGm2as_s6mKMKB2V2gvV6e9FE=.7f3b9d27-4972-4598-aaae-38f37fc5945c@github.com> Message-ID: On Mon, 22 Jul 2024 15:17:43 GMT, Kevin Rushforth wrote: >> You might want to merge in the latest upstream master to pick up the JUnit 5 change (also, Skara doesn't report a conflict, but GitHub does). > >> You might want to merge in the latest upstream master to pick up the JUnit 5 change (also, Skara doesn't report a conflict, but GitHub does). > > Skara woke up and reported the merge conflict, so you will need to merge master anyway. @kevinrushforth > I'll approve it as-is and reapprove if you are able to add a check for `CssParser::errorsProperty`. So, I added a check there, but must say the error system seems a bit unfinished/unpolished... this took way longer than it should have for the following reasons: - The `errorsProperty` will simply **not** be filled at all if you didn't access it first at least once. This is undocumented. - The strings produced uses a mix of line-endings on Windows (sometimes `\r\n`, sometimes `\n`), which isn't at all apparent when logging them to the console and trying to match them - The produced strings are hard to read; it's some kind of text/xml/json hybrid - Value is sometimes `value` sometimes `Value` - The word `value` seems a bit overused, a part of the output: 50.0% - Sometimes the produced string contains "indents" that are not preceded by a newline... - Indents use a mix of tabs and spaces In the PR you can see the strings it produces... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1505#issuecomment-2243762206 From jhendrikx at openjdk.org Mon Jul 22 20:46:08 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Mon, 22 Jul 2024 20:46:08 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5] In-Reply-To: References: Message-ID: > Fixes an infinite loop that can occur while resolving lookups. > > There were 2 bugs: > - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates > - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far > > Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Add lines I forgot to commit ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1505/files - new: https://git.openjdk.org/jfx/pull/1505/files/6c5b7717..404dafb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1505&range=03-04 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1505.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1505/head:pull/1505 PR: https://git.openjdk.org/jfx/pull/1505 From mfox at openjdk.org Mon Jul 22 22:22:19 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 22 Jul 2024 22:22:19 GMT Subject: RFR: 8285893: Hiding dialog and showing new one causes dialog to be frozen [v2] In-Reply-To: References: Message-ID: > This PR is based on a discussion that happened over in PR #1324. Some of this explanation is copied from that thread. > > When `exitNestedEventLoop` is called on the innermost loop the invokeLaterDispatcher suspends operation until the loop finishes. But if you immediately start a new event loop the previous one won't finish and the dispatcher will jam up and stop dispatching indefinitely. > > When the invokeLaterDispatcher is told that the innermost loop is exiting it sets `leavingNestedEventLoop` to true expecting it to be set to false when the loop actually exits. When the dispatcher is told that a new event loop has started it is not clearing `leavingNestedEventLoop` which is causing the jam. Basically it should follow the same logic used in glass; leaving the innermost loop updates a boolean indicating that the loop should exit but if a new loop is started the boolean is set back to a running state since it now applies to the new loop, not the previous one. > > I suspect the invokeLaterDispatcher exists in part to deal with the specifics of how deferred runnables are handled on the Mac. I investigated this a bit and wrote up some comments in the Mac glass code. Martin Fox 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 five additional commits since the last revision: - Linux leaveNestedEventLoop now behaves like Mac and Windows - Merge remote-tracking branch 'upstream/master' into eventloopjam - Merge remote-tracking branch 'upstream/master' into eventloopjam - Background information on how Mac Glass handles invokeLater runnables - Unblock invokeLater runnables when entering new loop just after exiting current one ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1449/files - new: https://git.openjdk.org/jfx/pull/1449/files/12267ce2..7f7574a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1449&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1449&range=00-01 Stats: 431796 lines in 7768 files changed: 237877 ins; 122608 del; 71311 mod Patch: https://git.openjdk.org/jfx/pull/1449.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1449/head:pull/1449 PR: https://git.openjdk.org/jfx/pull/1449 From kcr at openjdk.org Mon Jul 22 22:33:38 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 22 Jul 2024 22:33:38 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:46:08 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add lines I forgot to commit Thanks for adding the test. Unfortunate that it was such a pain. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2192650980 From angorya at openjdk.org Mon Jul 22 22:45:36 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 22 Jul 2024 22:45:36 GMT Subject: RFR: 8336389: Infinite loop occurs while resolving lookups [v5] In-Reply-To: References: Message-ID: On Mon, 22 Jul 2024 20:46:08 GMT, John Hendrikx wrote: >> Fixes an infinite loop that can occur while resolving lookups. >> >> There were 2 bugs: >> - A `contains` check was done on some value X, but then a value Y was added to the set used to track duplicates >> - The `Set` to track duplicates was cleared in some recursive calls, meaning that the caller (which may be processing multiple values in a loop) would end up with an empty set, losing track of what was visited so far >> >> Also removed a redundant `null` check (an NPE would have occurred before it could reach that code). > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Add lines I forgot to commit lgtm, with a couple of very minor comments. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 33: > 31: import javafx.css.CssParser; > 32: import javafx.css.CssParser.ParseError; > 33: import javafx.css.CssParser.ParseError.PropertySetError; very minor: I would have used `ParseError.PropertySetError` in the code instead of static import, removes the guesswork when looking at the code. modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java line 699: > 697: > 698: // Note: on Windows, the message is using inconsistent line endings (sometimes Windows, sometimes Linux) > 699: // so I've stripped it. would looking for substrings be a better solution? for example: contains("Caught java.lang.IllegalArgumentException: Loop detected in *.root{") && contains("while resolving '-fx-base'' while calculating value for '-fx-background-color' from rule '*.pane' in stylesheet" ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1505#pullrequestreview-2192657068 PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1687212293 PR Review Comment: https://git.openjdk.org/jfx/pull/1505#discussion_r1687210456 From duke at openjdk.org Mon Jul 22 23:37:38 2024 From: duke at openjdk.org (Jahin9999) Date: Mon, 22 Jul 2024 23:37:38 GMT Subject: RFR: 8336097: UserAgent Styles using lookups are promoted to Author level if look-up is defined in Author stylesheet [v5] In-Reply-To: References: <_TRRXSFjfEQY0kfJz_D_exZb_07yoKPl-E7SLX4YvXo=.9afdd91d-60bb-45b6-a2c0-66d2bef4779f@github.com> Message-ID: On Mon, 22 Jul 2024 16:01:12 GMT, John Hendrikx wrote: >> This change removes the origin determination from `resolveLookups`. Instead, the origin from the style is used. >> >> Although a comment in the code alluded that this may cause problem with `INLINE` styles, this is not the case. Whenever a `Node` is associated with a `CssStyleHelper`, a suitable shared cache is determined for its use. This already takes into account the presence of an inline style, and only nodes with the same inline style can share such a cache. See `Cache#getStyleMap` and specifically this fragment where an additional selector is added for the inline style: >> >> if (hasInlineStyle) { >> Selector selector = cacheContainer.getInlineStyleSelector(inlineStyle); >> if (selector != null) selectors.add(selector); >> } > > John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comments Marked as reviewed by Jahin9999 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jfx/pull/1503#pullrequestreview-2192705859 From arapte at openjdk.org Tue Jul 23 05:28:37 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 23 Jul 2024 05:28:37 GMT Subject: RFR: 8336331: Doc: Clarification in AccessibleAttribute, AccessibleRole In-Reply-To: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> References: <-DD-lEzW3m7gJZ38ngAV0F7u2YeeIb3E0uJ9cwx9DnU=.1ae5007a-adfa-4a20-941b-11feeff3461a@github.com> Message-ID: On Thu, 18 Jul 2024 19:00:06 GMT, Andy Goryachev wrote: > Minor clarifications in Javadoc > > **AccessibleAttribute**: > - Point2D and Bound values uses screen coordinates. Example: `BOUNDS`, `BOUNDS_FOR_RANGE`, `OFFSET_AT_POINT`, ... > - clarified the meaning of `SELECTION_END`, `SELECTION_START` > > **Accessible Role**: > - missing acces