From kcr at openjdk.org  Wed Mar  1 13:31:18 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 13:31:18 GMT
Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes
 memory leak [v2]
In-Reply-To: <xJOow0QDp8_HIGVaw1uodHGnnBCBg2W8WMuLADfH0KI=.a335dff9-101e-4247-8325-1726977bc545@github.com>
References: <hPuKbGSe0q2PZDMTzqEGHrzRXGombvb_ohQ3bGrPrMI=.2abcef6e-7cfb-43a5-a77b-61fffc3fcced@github.com>
 <cjOjDIi4VqsegL8YwMItFA4bYiwEVV-NPow1KSyLanw=.e5604d84-1c9d-462d-998d-c25d821c3a20@github.com>
 <T4GY0BowHYfGYxSJqPMfBlMyW66INLy73utvzpTY1Dc=.f66598a9-e23c-4e7c-9b36-0b31aa247b48@github.com>
 <Sb7kYl3UbdrL5-r9MdZXXfUkEP1IFBBHYJ6tof2i7l0=.8475dc14-b58a-40aa-b678-4fc805b1a935@github.com>
 <xJOow0QDp8_HIGVaw1uodHGnnBCBg2W8WMuLADfH0KI=.a335dff9-101e-4247-8325-1726977bc545@github.com>
Message-ID: <eHENYyk5yvWzhL2BH8FLr5Gmwy9n01PC0oIJUeWhCEc=.a2822b23-a691-4a91-96ac-0b5bd43b0d8a@github.com>

On Fri, 24 Feb 2023 19:09:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I've been working on changes for a possible follow-up PR which address more bugs. For adding accelerators, there are 3 public methods, for removing there are currently 4.
>> 
>> I've looked at it, and it can/should be made to have 3 public remove methods that exactly mirror the public add methods (if you use a specific one to add then use the corresponding one to remove).
>> 
>> Further, for every private addAcceleratorsFromScene method and doAcceleratorInstall method I believe there should be a private corresponding method which reverses it. I had to rename a couple private removeAcceleratorsFromScene to doAcceleratorUninstall.
>> 
>> So yes, this is a very confusing class. Pairing up the add/remove methods make sense to me. Once that's done, we might want to rename some of the private ones just so it's easier to understand what each one is doing, but the public ones are fine I think.
>
> I just want to avoid confusion when we have public and non-public methods with the same name.  but it's a minor comment, especially if there will be subsequent rework later.

We use this pattern of having methods with the same name and overloaded args, some of which are not public, in many places. In general this seems fine. In specific cases where it might help alleviate confusion, using "Impl" as a suffix is OK (and better than "Private" since we might make some impl methods package scope).

-------------

PR: https://git.openjdk.org/jfx/pull/1037

From kcr at openjdk.org  Wed Mar  1 13:35:22 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 13:35:22 GMT
Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes
 memory leak [v2]
In-Reply-To: <_720CWybUlufadQLT8ztq0mKmJSqSagc_9PMG81CLPo=.34fc51c9-4c39-4d40-8755-e14602e238bb@github.com>
References: <hPuKbGSe0q2PZDMTzqEGHrzRXGombvb_ohQ3bGrPrMI=.2abcef6e-7cfb-43a5-a77b-61fffc3fcced@github.com>
 <cjOjDIi4VqsegL8YwMItFA4bYiwEVV-NPow1KSyLanw=.e5604d84-1c9d-462d-998d-c25d821c3a20@github.com>
 <xomqGTK99A9rIqHIDJKBwJb18CgZcxstAYvlGgVdfKw=.c74941b8-5480-4598-98f4-d0449f96ce7b@github.com>
 <_720CWybUlufadQLT8ztq0mKmJSqSagc_9PMG81CLPo=.34fc51c9-4c39-4d40-8755-e14602e238bb@github.com>
Message-ID: <arp8bv0qmxIB0s1dis1UxMgSbXr_fSh_91Mi0EH4k44=.25535e62-53ae-4b7f-92a4-d860a8d6c2c1@github.com>

On Fri, 24 Feb 2023 19:02:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> In general should we use new syntax like that instanceof syntax? JavaFX requires Java 17 now, but if changes were to be backported then using the new syntax makes it a bit more difficult.
>
> that will be "SEP" (someone else's problem) ;-)
> 
> fx requires jdk17 as a boot jdk per JDK-8276144

Right. For newly added or modified code, it's fine to use JDK 17 language constructs and API, unless you know that the code will be backported right away. In particular, we have been using pattern-matching `instanceof` in other places.

-------------

PR: https://git.openjdk.org/jfx/pull/1037

From kcr at openjdk.org  Wed Mar  1 13:39:21 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 13:39:21 GMT
Subject: RFR: 8283551: ControlAcceleratorSupport menu items listener causes
 memory leak [v2]
In-Reply-To: <xh_TqO_5L4hoVK_tG4ieCM0YMrLD_9wcHpYyHV84XY0=.20ce788b-055c-420a-9f41-cf501aa37ded@github.com>
References: <hPuKbGSe0q2PZDMTzqEGHrzRXGombvb_ohQ3bGrPrMI=.2abcef6e-7cfb-43a5-a77b-61fffc3fcced@github.com>
 <xh_TqO_5L4hoVK_tG4ieCM0YMrLD_9wcHpYyHV84XY0=.20ce788b-055c-420a-9f41-cf501aa37ded@github.com>
Message-ID: <-EO0_ALVkCo1LxR72uB5U__Lpd9NYOzrrsIc9HXPsM4=.77e4d3f5-56ca-4716-b66f-2e5517196abc@github.com>

On Fri, 24 Feb 2023 10:04:48 GMT, Dean Wookey <dwookey at openjdk.org> wrote:

>> Each time a menu would change scenes, a new set of ListChangeListeners would be added to the items in the menu. The bigger problem however is that these list change listeners have a strong reference to the scene which is potentially a much bigger leak.
>> 
>> The first commit was more straightforward, but there are 2 things that might be of concern:
>> 
>> 1. The method removeAcceleratorsFromScene takes in a scene parameter, but it'll remove all the ListChangeListeners attached to it, regardless of which scene was passed in. Something similar happens with changeListenerMap already, so I think it's fine.
>> 2. I made the remove method public so that external calls from skins to remove the accelerators would remove the ListChangeListener and also because all the remove methods are public. 
>> 
>> After I wrote more tests I realised using the ObservableLists as keys in the WeakHashMaps was a bad idea. If Java had a WeakIdentityHashMap the fix would be simple. The fix is in the second commit.
>> 
>> There are still more issues that stem from the fact that for each anchor there could be multiple menus and the current code doesn't account for that. For example, swapping context menus on a tab doesn't register change listeners on the new context menu because the TabPane itself had a scene change listener already. These other issues could relate to JDK-8268374 https://bugs.openjdk.org/browse/JDK-8268374 and JDK-8283449 https://bugs.openjdk.org/browse/JDK-8283449. One of the issues is related to the fact that there's no logic to remove listeners when Tab/TableColumn's are removed from their associated control (TabPane, TableView, TreeTableView).
>> 
>> I'm looking at these issues, but I think they're dependent on this fix. Either I can add to this PR or I can wait to see what comes out of this and fix them subsequently.
>
> Dean Wookey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more comments and fixed IdentityWrapper hashcode.

@arapte can you be the second reviewer?

-------------

PR: https://git.openjdk.org/jfx/pull/1037

From kcr at openjdk.org  Wed Mar  1 15:00:52 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 15:00:52 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v6]
In-Reply-To: <O_LrSOLpXLOwQb-x-rzU0jKRgI7BA8WDMVzUIPYVA24=.9c831743-b10d-45d7-8c9e-a336db25b19b@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <O_LrSOLpXLOwQb-x-rzU0jKRgI7BA8WDMVzUIPYVA24=.9c831743-b10d-45d7-8c9e-a336db25b19b@github.com>
Message-ID: <wSdTf4xJjCSRq4AnJIQX7eowoISePr9QhqAvKsgLqP4=.9dbf7c47-6222-44ae-bb16-03943227c561@github.com>

On Thu, 23 Feb 2023 05:21:37 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
>> 
>> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
>> 
>> Added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

The fix seems fine. The test is not completely stable, though. I ran it several times and it fails occasionally. I left a comment pointing to a problem in the test (sleeping on the wrong thread) that might explain it. Even if not, that needs to be fixed. I left a couple minor comments as well.

tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 40:

> 38: import javafx.scene.control.skin.ChoiceBoxSkin;
> 39: import javafx.scene.control.skin.ChoiceBoxSkinNodesShim;
> 40: import javafx.scene.control.skin.ContextMenuSkin;

Minor: unused import can be removed

tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 73:

> 71: public class ChoiceBoxScrollUpOnCollectionChangeTest {
> 72:     static CountDownLatch startupLatch = new CountDownLatch(1);
> 73:     static CountDownLatch scrollLatch = new CountDownLatch(1);

Minor: unused field can be removed

tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 101:

> 99:             }
> 100: 
> 101:             Util.sleep(400); // Wait for up arrow to get loaded in UI

Sleeping on the JavaFX application thread is both ineffective and undesirable. If the sleep is needed, then split this into two invocations of `runAndWait` (before and after the sleep), and do the sleep on the test thread.

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kcr at openjdk.org  Wed Mar  1 15:14:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 15:14:35 GMT
Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0
 [v4]
In-Reply-To: <4eZKC6XwnSZKny4XOPkirbwG_JMNRDXrLbCXjaRNP-w=.84f27394-76eb-4cdd-9f58-e79734cf4b2b@github.com>
References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com>
 <4eZKC6XwnSZKny4XOPkirbwG_JMNRDXrLbCXjaRNP-w=.84f27394-76eb-4cdd-9f58-e79734cf4b2b@github.com>
Message-ID: <dByRoL_R3uj4YB5TXj80VLwli3nHJnSo3Yc6hQJybbs=.81e03779-d2ad-4f6a-875b-5f8e1765adab@github.com>

On Fri, 24 Feb 2023 00:14:03 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero.
>> 
>> Here's whats happening:
>> 
>> We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with  `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN).
>> 
>> When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0.
>> 
>> The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename var

I haven't tested this, but I left a couple questions.

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 390:

> 388:         if (gdk_window_get_events(gdk_window) & GDK_SMOOTH_SCROLL_MASK) {
> 389:             is_smooth = true;
> 390:             if (event->direction == GDK_SCROLL_SMOOTH) {

When would `GDK_SMOOTH_SCROLL_MASK` be set with direction not equal to `GDK_SCROLL_SMOOTH`? In this case, you will use a dx and dy value of 0 (which will at least now be ignored with your fix). Is this correct?

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 419:

> 417:         // Note: For gtk negatives values means UP/LEFT, JavaFx is opposite
> 418:         dx = (dx != 0) ? dx * -1 : 0;
> 419:         dy = (dy != 0) ? dy * -1 : 0;

Is avoiding a possible negative 0 is really necessary? If not, this could simplify to `dx *= -1;` and `dy *= -1;`

-------------

PR: https://git.openjdk.org/jfx/pull/1044

From kcr at openjdk.org  Wed Mar  1 15:19:03 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 15:19:03 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v55]
In-Reply-To: <z0MQkr3osSLNGJ9y7c9SUEwGAPTLoWQSwdslkMctMz4=.f3cd92c9-f9c2-419a-a5c6-f90f91705934@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <z0MQkr3osSLNGJ9y7c9SUEwGAPTLoWQSwdslkMctMz4=.f3cd92c9-f9c2-419a-a5c6-f90f91705934@github.com>
Message-ID: <AwmaOgzaAjiCgwIzezUCSEnzDO4NGW6Ukh6mhHAca48=.8f366a40-b7dd-4dd9-82b1-c23843d174c9@github.com>

On Mon, 27 Feb 2023 00:13:40 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This cleans size and positioning code, reducing special cases, code complexity and size.
>> 
>> Changes:
>> 
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
>> - window geometry, min/max size are centralized in `update_window_constraints`;
>> - Frame extents (the window decoration size used for "total window size"):
>>     - frame extents are received in `process_property_notify`;
>>     - removed quirks in java code;
>>     - When received, call `set_bounds` again to adjust the size (to account decorations later received);
>> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it.
>> - `ensure_window_size` was a quirk - removed;
>> - `requested_bounds` removed - not used anymore;
>> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`;
>> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point)
>> - `restack` split in `to_front()` and `to_back()` to conform to managed code;
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug when window starts maximized and restores to wrong size

I can confirm that this fixes the window order test without introducing new test failures. It looks ready for final testing and review.

-------------

PR: https://git.openjdk.org/jfx/pull/915

From kcr at openjdk.org  Wed Mar  1 15:51:24 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 15:51:24 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
In-Reply-To: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
Message-ID: <iuoIDb9ZvgZdexyRIF9ksgsv_1CBdqj6SOIJ2n9TlS8=.12c8fe67-ee1c-4a09-b7e4-189a01a92e89@github.com>

On Mon, 20 Feb 2023 14:15:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
> 
> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
> 
> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
> 
> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
> ...
> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
> ...
> 
> when `File::exists` is evaluated over an image bundled in a jar.

I confirm that this does allow an HTML color-picker to load (good), I note that the exception still occurs later on, but at a point where it is treated as a warning instead of an error.


WARNING: Error loading image: jar:file:///.../build/sdk/lib/javafx.controls.jar!/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png


We have other known problems loading some built-in resources when using the security manager, such as [JDK-8177284](https://bugs.openjdk.org/browse/JDK-8177284). Since it is deprecated, we aren't likely to spend any time on them, so this PR might be a reasonable solution to the failure.

Can you provide a test case?

Also, I'd like @mstr2 to comment on the check that you propose to remove.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From tsayao at openjdk.org  Wed Mar  1 16:06:30 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 1 Mar 2023 16:06:30 GMT
Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0
 [v4]
In-Reply-To: <dByRoL_R3uj4YB5TXj80VLwli3nHJnSo3Yc6hQJybbs=.81e03779-d2ad-4f6a-875b-5f8e1765adab@github.com>
References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com>
 <4eZKC6XwnSZKny4XOPkirbwG_JMNRDXrLbCXjaRNP-w=.84f27394-76eb-4cdd-9f58-e79734cf4b2b@github.com>
 <dByRoL_R3uj4YB5TXj80VLwli3nHJnSo3Yc6hQJybbs=.81e03779-d2ad-4f6a-875b-5f8e1765adab@github.com>
Message-ID: <2V8QPQSLqzUEhdQfET7c_bilf7po_0TA17POFmv3qIM=.eafe90f6-8bc1-43e1-9bc2-7cd4e7d38b70@github.com>

On Wed, 1 Mar 2023 15:07:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename var
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 390:
> 
>> 388:         if (gdk_window_get_events(gdk_window) & GDK_SMOOTH_SCROLL_MASK) {
>> 389:             is_smooth = true;
>> 390:             if (event->direction == GDK_SCROLL_SMOOTH) {
> 
> When would `GDK_SMOOTH_SCROLL_MASK` be set with direction not equal to `GDK_SCROLL_SMOOTH`? In this case, you will use a dx and dy value of 0 (which will at least now be ignored with your fix). Is this correct?

Correct.

`direction`:
The direction to scroll to (one of `GDK_SCROLL_UP`, `GDK_SCROLL_DOWN`, `GDK_SCROLL_LEFT`, `GDK_SCROLL_RIGHT ` or `GDK_SCROLL_SMOOTH`).

If the device supports it and if event mask is set to contain `GDK_SMOOTH_SCROLL_MASK `, gdk will send `GDK_SCROLL_SMOOTH` with the deltas equivalent to the device sensor. But it will also send the others for compatibilty (I guess).

We set to receive all events. When gtk3 introduced `GDK_SMOOTH_SCROLL_MASK` (*) we started receiving it but not accounting it, so resulting in deltas = `0`.

(*) It's set on `WindowContextTop` constructor.

> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 419:
> 
>> 417:         // Note: For gtk negatives values means UP/LEFT, JavaFx is opposite
>> 418:         dx = (dx != 0) ? dx * -1 : 0;
>> 419:         dy = (dy != 0) ? dy * -1 : 0;
> 
> Is avoiding a possible negative 0 is really necessary? If not, this could simplify to `dx *= -1;` and `dy *= -1;`

Will double check it, but I think I spaced out.

-------------

PR: https://git.openjdk.org/jfx/pull/1044

From angorya at openjdk.org  Wed Mar  1 16:14:29 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 1 Mar 2023 16:14:29 GMT
Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0
 [v4]
In-Reply-To: <2V8QPQSLqzUEhdQfET7c_bilf7po_0TA17POFmv3qIM=.eafe90f6-8bc1-43e1-9bc2-7cd4e7d38b70@github.com>
References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com>
 <4eZKC6XwnSZKny4XOPkirbwG_JMNRDXrLbCXjaRNP-w=.84f27394-76eb-4cdd-9f58-e79734cf4b2b@github.com>
 <dByRoL_R3uj4YB5TXj80VLwli3nHJnSo3Yc6hQJybbs=.81e03779-d2ad-4f6a-875b-5f8e1765adab@github.com>
 <2V8QPQSLqzUEhdQfET7c_bilf7po_0TA17POFmv3qIM=.eafe90f6-8bc1-43e1-9bc2-7cd4e7d38b70@github.com>
Message-ID: <4oYz-qhypbvfsHTaFxQ7JZtGIhc-w2n8LCaGwtRL4No=.1c6a592a-0f1b-42e8-a0c7-291ccc5e04ae@github.com>

On Wed, 1 Mar 2023 16:03:06 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 419:
>> 
>>> 417:         // Note: For gtk negatives values means UP/LEFT, JavaFx is opposite
>>> 418:         dx = (dx != 0) ? dx * -1 : 0;
>>> 419:         dy = (dy != 0) ? dy * -1 : 0;
>> 
>> Is avoiding a possible negative 0 is really necessary? If not, this could simplify to `dx *= -1;` and `dy *= -1;`
>
> Will double check it, but I think I spaced out.

dx = (dx != 0) ? -dx : 0;

also, is jdouble a floating point type?  if so, would that work correctly if dx/dy are very small?

-------------

PR: https://git.openjdk.org/jfx/pull/1044

From jpereda at openjdk.org  Wed Mar  1 17:47:16 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 1 Mar 2023 17:47:16 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
In-Reply-To: <iuoIDb9ZvgZdexyRIF9ksgsv_1CBdqj6SOIJ2n9TlS8=.12c8fe67-ee1c-4a09-b7e4-189a01a92e89@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
 <iuoIDb9ZvgZdexyRIF9ksgsv_1CBdqj6SOIJ2n9TlS8=.12c8fe67-ee1c-4a09-b7e4-189a01a92e89@github.com>
Message-ID: <g2-CsPIaLpcIVO-NojYSxsO9jBj3pyjYfPjU1bCsuUw=.3dfdb040-8211-486f-83ba-fe59acf899da@github.com>

On Wed, 1 Mar 2023 15:48:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
>> 
>> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
>> 
>> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
>> 
>> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
>> ...
>> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
>> ...
>> 
>> when `File::exists` is evaluated over an image bundled in a jar.
>
> I confirm that this does allow an HTML color-picker to load (good), I note that the exception still occurs later on, but at a point where it is treated as a warning instead of an error.
> 
> 
> WARNING: Error loading image: jar:file:///.../build/sdk/lib/javafx.controls.jar!/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png
> 
> 
> We have other known problems loading some built-in resources when using the security manager, such as [JDK-8177284](https://bugs.openjdk.org/browse/JDK-8177284). Since it is deprecated, we aren't likely to spend any time on them, so this PR might be a reasonable solution to the failure.
> 
> Can you provide a test case?
> 
> Also, I'd like @mstr2 to comment on the check that you propose to remove.

@kevinrushforth Do you mean a system test case with a custom policy file? I just noticed that `Util::createApplicationLaunchCommand` allows such case.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From kcr at openjdk.org  Wed Mar  1 18:10:18 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 1 Mar 2023 18:10:18 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
In-Reply-To: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
Message-ID: <q32yzvAt4-g0wI4lESAP3qLjt0PEvd7Zt9c-2f3vfsg=.51bd41d2-c205-4f48-8576-aea87984e775@github.com>

On Mon, 20 Feb 2023 14:15:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
> 
> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
> 
> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
> 
> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
> ...
> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
> ...
> 
> when `File::exists` is evaluated over an image bundled in a jar.

Ideally, yes. You could add it to the existing `SandboxAppTest` if you like.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From tsayao at openjdk.org  Wed Mar  1 22:40:53 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 1 Mar 2023 22:40:53 GMT
Subject: RFR: 8303038: Glass gtk3 sends scroll events with delta(x, y) = 0
 [v5]
In-Reply-To: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com>
References: <9H9NFSADpb1CL6zwN-Q8kdJUnId5CcSUo1KlBnTnP0Q=.41ca5b87-ae78-4ef9-89ac-c867a2517533@github.com>
Message-ID: <h5IzxTnmCO_MJD1qYivrH-LAIGv7CLu-gHrMHMDzXzI=.71b3f1e6-95a0-4bf8-ba24-30877c8bf69d@github.com>

> Simple fix to get the scroll deltas from GDK_SCROLL_SMOOTH. If we ignore this scroll event type, deltas are sent to java with the value equal to zero.
> 
> Here's whats happening:
> 
> We include all event masks, so when using gtk3 (>= 3.4.0) it includes `GDK_SMOOTH_SCROLL_MASK` meaning we receive duplicated events, one with  `direction = GDK_SMOOTH_SCROLL_MASK` and other with "legacy" direction (UP/DOWN).
> 
> When receiving the event corresponding to `GDK_SMOOTH_SCROLL_MASK` we ignored it causing it to send deltas (x,y) = 0.
> 
> The fix now checks if `GDK_SMOOTH_SCROLL_MASK` is supported and uses it, also adding smooth scroll functionality.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Improve direction

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1044/files
  - new: https://git.openjdk.org/jfx/pull/1044/files/88620461..a3975da3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1044&range=03-04

  Stats: 20 lines in 1 file changed: 6 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1044.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1044/head:pull/1044

PR: https://git.openjdk.org/jfx/pull/1044

From tsayao at openjdk.org  Wed Mar  1 23:28:00 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 1 Mar 2023 23:28:00 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v9]
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>

> Simple PR to remove gtk2 library compilation and loading.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Throw exception if unsupported or invalid version specified.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/999/files
  - new: https://git.openjdk.org/jfx/pull/999/files/8624dd27..9f8b60ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=07-08

  Stats: 270 lines in 5 files changed: 60 ins; 200 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/999/head:pull/999

PR: https://git.openjdk.org/jfx/pull/999

From tsayao at openjdk.org  Wed Mar  1 23:28:04 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 1 Mar 2023 23:28:04 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v8]
In-Reply-To: <o4Oju0xgWzuoobBEdlVQCj3HHyyv6i-wn1l9G1FAI00=.ec34d7bf-c0d9-40bb-83c2-4be6fd3f2551@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <o4Oju0xgWzuoobBEdlVQCj3HHyyv6i-wn1l9G1FAI00=.ec34d7bf-c0d9-40bb-83c2-4be6fd3f2551@github.com>
Message-ID: <XDHsKvzTtWJ_CbPsa5igkYdRVvERlftmkmbU2myqQvY=.605806e0-bbda-419e-b957-db33c264a36c@github.com>

On Fri, 24 Feb 2023 00:24:56 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review changes

Did I get it right?

-------------

PR: https://git.openjdk.org/jfx/pull/999

From mstrauss at openjdk.org  Thu Mar  2 03:13:16 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 2 Mar 2023 03:13:16 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
In-Reply-To: <iuoIDb9ZvgZdexyRIF9ksgsv_1CBdqj6SOIJ2n9TlS8=.12c8fe67-ee1c-4a09-b7e4-189a01a92e89@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
 <iuoIDb9ZvgZdexyRIF9ksgsv_1CBdqj6SOIJ2n9TlS8=.12c8fe67-ee1c-4a09-b7e4-189a01a92e89@github.com>
Message-ID: <ObCQY-6qhg9OzrfwziQkxO6Kwl4g_9kF--M-3AvhOTY=.03c90407-0407-457b-ad92-43a8fa45cb96@github.com>

On Wed, 1 Mar 2023 15:48:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Also, I'd like @mstr2 to comment on the check that you propose to remove.

I?ll get around to doing that next week.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From arapte at openjdk.org  Thu Mar  2 09:29:15 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 2 Mar 2023 09:29:15 GMT
Subject: RFR: 8303026: [TextField] IOOBE on setting text with control
 characters that replaces existing text [v2]
In-Reply-To: <YRGgGRsWyzxYTxH3pbQvsNBd-3rkQhD5ASjnwRtCu4o=.aa9d8abe-01d2-4268-bcd7-fbc64379a664@github.com>
References: <CiGkdWf4Dj9Cl7Ye-o7EvT8tOelLyaqiCl2BW7tP_IM=.79010737-65e5-4da3-8d38-0f09dff22b61@github.com>
 <YRGgGRsWyzxYTxH3pbQvsNBd-3rkQhD5ASjnwRtCu4o=.aa9d8abe-01d2-4268-bcd7-fbc64379a664@github.com>
Message-ID: <OPgpE2XVD7jOFBcDg47JcPzsjcf4q90zjx-lAZyk_d4=.7508ad69-90b4-43d0-9690-f266db305093@github.com>

On Wed, 22 Feb 2023 11:08:14 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR fixes a regression after [JDK-8212102](https://bugs.openjdk.org/browse/JDK-8212102).
>> 
>> When a TextField control has some previous content, and new text with only invalid characters (0x7F, new line, tabs, <0x20) is set, `TextInputControl::filterInput` is used to strip them out, and the new text has length 0.
>> 
>> During the refactoring in JDK-8212102, the checks:
>> 
>> int length = txt.length();
>> if (end > start + length) end = length;
>> if (start > length-1) start = end = 0;
>> 
>> were removed. 
>> 
>> In this particular case, when the new filtered text has length 0, we need those checks, so start and end are set to 0, and txt.substring(start, end) doesn't throw the IOOBE anymore.
>> 
>> A test is added to verify this scenario. It fails with the proposed patch, passes with it.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add curly braces

Marked as reviewed by arapte (Reviewer).

The regression bug-id mentioned in PR description is incorrect: [JDK-8212102](https://bugs.openjdk.org/browse/JDK-8212102) is a similar bug. and, [JDK-8176270](https://bugs.openjdk.org/browse/JDK-8176270) is the regression causing bug, which correctly mentioned in JBS. I would recommend to correct the description for correct record.

The fix itself looks good.

-------------

PR: https://git.openjdk.org/jfx/pull/1043

From kcr at openjdk.org  Thu Mar  2 13:08:43 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 2 Mar 2023 13:08:43 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v9]
In-Reply-To: <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>
Message-ID: <-gZhwLQZWL1b8HlCpC9aDYwOyIVsdWxIyJGErTykhDY=.7f992279-8a28-45ec-abe3-b7bc0970e94f@github.com>

On Wed, 1 Mar 2023 23:28:00 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw exception if unsupported or invalid version specified.

You misunderstood Johan's suggestion. He wasn't asking for any changes to the logic. Just a slight change to the warning message when `-Djdk.gtk.version=2` is used, making it clear that GTK 3 will be used. Here is a possible suggestion:


WARNING: A command line option tried to select the GTK 2 library, which was removed from JavaFX.
WARNING: The GTK 3 library will be used instead.

-------------

PR: https://git.openjdk.org/jfx/pull/999

From tsayao at openjdk.org  Thu Mar  2 13:40:25 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 2 Mar 2023 13:40:25 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v9]
In-Reply-To: <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>
Message-ID: <ni37UCo3fIhexPPKw7HUEj0cd43JZ1FJQhzif3PVt5c=.ce147d78-bdb2-490b-9d52-3c91e68c1270@github.com>

On Wed, 1 Mar 2023 23:28:00 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw exception if unsupported or invalid version specified.

Sorry, I've read it many times and still got It wrong. Will update tonight (probably).

-------------

PR: https://git.openjdk.org/jfx/pull/999

From jpereda at openjdk.org  Thu Mar  2 14:30:12 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 2 Mar 2023 14:30:12 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context [v2]
In-Reply-To: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
Message-ID: <Jw7qpzluPKuiR_gzoSl08r64QrLcvZU8IKid4kAJ0l0=.055c4079-7c2c-4fcb-90db-a1d1aff02740@github.com>

> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
> 
> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
> 
> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
> 
> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
> ...
> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
> ...
> 
> when `File::exists` is evaluated over an image bundled in a jar.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Add system test

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1042/files
  - new: https://git.openjdk.org/jfx/pull/1042/files/1cc9c761..ba7aef23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1042&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1042&range=00-01

  Stats: 199 lines in 4 files changed: 194 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1042.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1042/head:pull/1042

PR: https://git.openjdk.org/jfx/pull/1042

From jpereda at openjdk.org  Thu Mar  2 14:32:22 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 2 Mar 2023 14:32:22 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
In-Reply-To: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
Message-ID: <cn3TwSeeQeQGl17IFGdRlCqmVK83spcVM51AlWgpXTw=.39436d46-066c-47ba-9388-65a6bc6c6ddf@github.com>

On Mon, 20 Feb 2023 14:15:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
> 
> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
> 
> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
> 
> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
> ...
> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
> ...
> 
> when `File::exists` is evaluated over an image bundled in a jar.

I've added a system test, that passes with the proposed fix and fails without it.

Without the fix, the AccessControlException exception prevents the color chooser dialog from showing up, but its window still reports onShowing true and the color can be still changed programmatically. There is an exception logged, but to make the test actually fail, I had to check for the window dimensions.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From jvos at openjdk.org  Thu Mar  2 14:34:08 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 2 Mar 2023 14:34:08 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v9]
In-Reply-To: <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <HKjENKMIU1A_ppmlm97qvgiUuNhBWHb9RkvGlS7OoOc=.e79b22c3-aaf7-48d7-ab51-2798a8a12876@github.com>
Message-ID: <b7V7D0T8pxKwG62XE4O0VI_E4-QUMfq9Uj6AQlzJ-Z0=.4ed45a19-0619-499c-b8a2-1b2b664dfa49@github.com>

On Wed, 1 Mar 2023 23:28:00 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw exception if unsupported or invalid version specified.

I was probably a bit too verbose in my comment. Kevin is correct, I only recommended a change (addition) in the text for the warning. Hence, if you revert your latest commit and then apply the textual diff Kevin recommends, we're good.

-------------

PR: https://git.openjdk.org/jfx/pull/999

From jpereda at openjdk.org  Thu Mar  2 15:54:22 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 2 Mar 2023 15:54:22 GMT
Subject: Integrated: 8303026: [TextField] IOOBE on setting text with control
 characters that replaces existing text
In-Reply-To: <CiGkdWf4Dj9Cl7Ye-o7EvT8tOelLyaqiCl2BW7tP_IM=.79010737-65e5-4da3-8d38-0f09dff22b61@github.com>
References: <CiGkdWf4Dj9Cl7Ye-o7EvT8tOelLyaqiCl2BW7tP_IM=.79010737-65e5-4da3-8d38-0f09dff22b61@github.com>
Message-ID: <p3JDqyHVOh1Ib25VeLsl6gvf8pC5IW85RFeERhBV0tw=.a15ab954-07e2-4eff-93e6-bdfb19a1732c@github.com>

On Tue, 21 Feb 2023 23:11:52 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes a regression after [JDK-8212102](https://bugs.openjdk.org/browse/JDK-8212102).
> 
> When a TextField control has some previous content, and new text with only invalid characters (0x7F, new line, tabs, <0x20) is set, `TextInputControl::filterInput` is used to strip them out, and the new text has length 0.
> 
> During the refactoring in JDK-8212102, the checks:
> 
> int length = txt.length();
> if (end > start + length) end = length;
> if (start > length-1) start = end = 0;
> 
> were removed. 
> 
> In this particular case, when the new filtered text has length 0, we need those checks, so start and end are set to 0, and txt.substring(start, end) doesn't throw the IOOBE anymore.
> 
> A test is added to verify this scenario. It fails with the proposed patch, passes with it.

This pull request has now been integrated.

Changeset: 9df6039a
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/9df6039a27a78f40a929b5ba4de0e38ce233a6fc
Stats:     16 lines in 2 files changed: 14 ins; 0 del; 2 mod

8303026: [TextField] IOOBE on setting text with control characters that replaces existing text

Reviewed-by: angorya, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/1043

From tsayao at openjdk.org  Thu Mar  2 17:01:02 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 2 Mar 2023 17:01:02 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>

> Simple PR to remove gtk2 library compilation and loading.

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Rollback + Change Warnings
 - Revert "Throw exception if unsupported or invalid version specified."
   
   This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/999/files
  - new: https://git.openjdk.org/jfx/pull/999/files/9f8b60ff..c5ab9ba3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=08-09

  Stats: 267 lines in 5 files changed: 201 ins; 59 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/999/head:pull/999

PR: https://git.openjdk.org/jfx/pull/999

From kcr at openjdk.org  Thu Mar  2 20:43:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 2 Mar 2023 20:43:33 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
Message-ID: <RlefZ-yakkYg0q9xf2U4-AZQ_QM3myx6dNFAmqNNTuI=.611426da-edd1-4019-9931-97f704bcc72b@github.com>

On Thu, 2 Mar 2023 17:01:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/999

From jvos at openjdk.org  Thu Mar  2 21:00:23 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 2 Mar 2023 21:00:23 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
Message-ID: <XrgtE1R4opolCgYmzOttuauhq8-_b8sDonsFCnyO7ss=.56954eb2-062d-40d6-aa16-3930d6679998@github.com>

On Thu, 2 Mar 2023 17:01:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

All good now.

-------------

Marked as reviewed by jvos (Reviewer).

PR: https://git.openjdk.org/jfx/pull/999

From tsayao at openjdk.org  Thu Mar  2 21:28:26 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 2 Mar 2023 21:28:26 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
Message-ID: <TefXKgsT58K2xmi6e2rsIhAF3vnI_kUSX_YeD684SMY=.2ed6f18e-dcb8-4458-9aa2-575595da173c@github.com>

On Thu, 2 Mar 2023 17:01:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

I'll update the CSR

-------------

PR: https://git.openjdk.org/jfx/pull/999

From tsayao at openjdk.org  Thu Mar  2 23:41:17 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 2 Mar 2023 23:41:17 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
Message-ID: <5e9ja5-5_2-bGPvSkSam5H2tp4lu3Fok6JgKuIrad0I=.efa1653a-d8bb-4016-aac3-704fe8c6a335@github.com>

On Thu, 2 Mar 2023 17:01:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

CSR: https://bugs.openjdk.org/browse/JDK-8303493

-------------

PR: https://git.openjdk.org/jfx/pull/999

From tsayao at openjdk.org  Fri Mar  3 00:40:51 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 3 Mar 2023 00:40:51 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository [v4]
In-Reply-To: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
Message-ID: <gvbm0mGI_VRF5oRZwz6l2tobj8_SlDfyaQDNMUY1HHc=.d858553d-fa5d-4125-85b3-483794002853@github.com>

> This PR does:
> 
> - Remove specific Idea files and let it be imported from gradle;
> - Adds checkstyle (to use with checkstyle plugin - it will let you know style mistakes);
> - Configures auto-format to sun style (with the changes mentioned in [Code Style Rules](https://wiki.openjdk.org/display/OpenJFX/Code+Style+Rules));
> - Automatically sets Copyright notice (updates year too);
> - Run configurations for samples/toys and builds.

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 50 additional commits since the last revision:

 - Do not change gradle files
   MissingJavadocMethod is too annoying
 - Merge branch 'master' into jfx_intellij_idea
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Use java 17 by default
 - Review changes
 - Allow 20 parameters and _methods()
 - Add UI folder
 - Add manual tests
 - ... and 40 more: https://git.openjdk.org/jfx/compare/4d9d2fda...896552a9

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1009/files
  - new: https://git.openjdk.org/jfx/pull/1009/files/56b256cc..896552a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1009&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1009&range=02-03

  Stats: 198289 lines in 5614 files changed: 117261 ins; 42908 del; 38120 mod
  Patch: https://git.openjdk.org/jfx/pull/1009.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1009/head:pull/1009

PR: https://git.openjdk.org/jfx/pull/1009

From tsayao at openjdk.org  Fri Mar  3 01:13:49 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 3 Mar 2023 01:13:49 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository [v5]
In-Reply-To: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
Message-ID: <3zCUdkkbxcB1NMO9-VFrOgALNGa4k2vC0yXoyqYSbyQ=.596e4f9c-9101-4548-9d7e-134f06d1770c@github.com>

> This PR does:
> 
> - Remove specific Idea files and let it be imported from gradle;
> - Adds checkstyle (to use with checkstyle plugin - it will let you know style mistakes);
> - Configures auto-format to sun style (with the changes mentioned in [Code Style Rules](https://wiki.openjdk.org/display/OpenJFX/Code+Style+Rules));
> - Automatically sets Copyright notice (updates year too);
> - Run configurations for samples/toys and builds.

Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Make intellij see :systemTests dependecies"
   
   This reverts commit dca7eab24958e1214147b7d291f0faf52ea27ddf.
 - Make intellij see :systemTests dependecies

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1009/files
  - new: https://git.openjdk.org/jfx/pull/1009/files/896552a9..e4c7b4ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1009&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1009&range=03-04

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1009.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1009/head:pull/1009

PR: https://git.openjdk.org/jfx/pull/1009

From tsayao at openjdk.org  Fri Mar  3 01:24:15 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 3 Mar 2023 01:24:15 GMT
Subject: RFR: JDK-8223373: Remove IntelliJ IDEA specific files from the
 source code repository [v5]
In-Reply-To: <3zCUdkkbxcB1NMO9-VFrOgALNGa4k2vC0yXoyqYSbyQ=.596e4f9c-9101-4548-9d7e-134f06d1770c@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
 <3zCUdkkbxcB1NMO9-VFrOgALNGa4k2vC0yXoyqYSbyQ=.596e4f9c-9101-4548-9d7e-134f06d1770c@github.com>
Message-ID: <M39o2Q7HdkRklw5Biu7Nrq4kLVbyWrPrOcGz32FIC5k=.6468b4e0-9027-4841-bdca-9d74bfe4dcf3@github.com>

On Fri, 3 Mar 2023 01:13:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This PR does:
>> 
>> - Remove specific Idea files and let it be imported from gradle;
>> - Adds checkstyle (to use with checkstyle plugin - it will let you know style mistakes);
>> - Configures auto-format to sun style (with the changes mentioned in [Code Style Rules](https://wiki.openjdk.org/display/OpenJFX/Code+Style+Rules));
>> - Automatically sets Copyright notice (updates year too);
>> - Run configurations for samples/toys and builds.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Make intellij see :systemTests dependecies"
>    
>    This reverts commit dca7eab24958e1214147b7d291f0faf52ea27ddf.
>  - Make intellij see :systemTests dependecies

Intellij Ideas does not see the dependencies:

dependencies {
        testImplementation project(":graphics").sourceSets.test.output
        testImplementation project(":base").sourceSets.test.output
        testImplementation project(":controls").sourceSets.test.output
        testImplementation project(":swing").sourceSets.test.output
}


How do I rewrite it?

-------------

PR: https://git.openjdk.org/jfx/pull/1009

From kpk at openjdk.org  Fri Mar  3 07:28:48 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 3 Mar 2023 07:28:48 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v7]
In-Reply-To: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
Message-ID: <L4wU2O54gtNcYsGxvVIMkLfnZKKawzWJAp5DugB5JoM=.8336a750-32b5-4995-b52c-9d053a5dcec9@github.com>

> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
> 
> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
> 
> Added system test to validate the fix.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Stabilizing test

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1039/files
  - new: https://git.openjdk.org/jfx/pull/1039/files/2996fd08..47552cff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1039&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1039&range=05-06

  Stats: 19 lines in 2 files changed: 15 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1039.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1039/head:pull/1039

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Fri Mar  3 07:28:52 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 3 Mar 2023 07:28:52 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v6]
In-Reply-To: <wSdTf4xJjCSRq4AnJIQX7eowoISePr9QhqAvKsgLqP4=.9dbf7c47-6222-44ae-bb16-03943227c561@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <O_LrSOLpXLOwQb-x-rzU0jKRgI7BA8WDMVzUIPYVA24=.9c831743-b10d-45d7-8c9e-a336db25b19b@github.com>
 <wSdTf4xJjCSRq4AnJIQX7eowoISePr9QhqAvKsgLqP4=.9dbf7c47-6222-44ae-bb16-03943227c561@github.com>
Message-ID: <7vHH1Ta1ah1emJ1HyqcETMk14bbgzCWB9kjNtTbB_uo=.f55b4dc1-adb8-4579-9196-3efaef4ade80@github.com>

On Wed, 1 Mar 2023 13:57:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 73:
> 
>> 71: public class ChoiceBoxScrollUpOnCollectionChangeTest {
>> 72:     static CountDownLatch startupLatch = new CountDownLatch(1);
>> 73:     static CountDownLatch scrollLatch = new CountDownLatch(1);
> 
> Minor: unused field can be removed

Used this latch now while stabilizing the test

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Fri Mar  3 07:37:20 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 3 Mar 2023 07:37:20 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v6]
In-Reply-To: <wSdTf4xJjCSRq4AnJIQX7eowoISePr9QhqAvKsgLqP4=.9dbf7c47-6222-44ae-bb16-03943227c561@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <O_LrSOLpXLOwQb-x-rzU0jKRgI7BA8WDMVzUIPYVA24=.9c831743-b10d-45d7-8c9e-a336db25b19b@github.com>
 <wSdTf4xJjCSRq4AnJIQX7eowoISePr9QhqAvKsgLqP4=.9dbf7c47-6222-44ae-bb16-03943227c561@github.com>
Message-ID: <Q8FboKEuvluu1Fm19NcJj_TCWBp8pJLbvKeawOdFnkE=.bc5776e8-25fc-46fa-a3f1-96a9084585ae@github.com>

On Wed, 1 Mar 2023 13:59:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 101:
> 
>> 99:             }
>> 100: 
>> 101:             Util.sleep(400); // Wait for up arrow to get loaded in UI
> 
> Sleeping on the JavaFX application thread is both ineffective and undesirable. If the sleep is needed, then split this into two invocations of `runAndWait` (before and after the sleep), and do the sleep on the test thread.

Updated the code to sleep on the test thread.
Along with this, scrolling fixed amount (75) was also causing the occasional failures as the scroll event was getting triggered continuously and choice box was scrolling to the end making the down arrow getting hidden.
Made changes in code to scroll only required amount to make both up and down arrow visible based on the screen size and row height of choice box items.
Ran the test several times (around 15-20 times) in different screen sizes. Did not see failures now.

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kcr at openjdk.org  Fri Mar  3 16:35:01 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Mar 2023 16:35:01 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context [v2]
In-Reply-To: <Jw7qpzluPKuiR_gzoSl08r64QrLcvZU8IKid4kAJ0l0=.055c4079-7c2c-4fcb-90db-a1d1aff02740@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
 <Jw7qpzluPKuiR_gzoSl08r64QrLcvZU8IKid4kAJ0l0=.055c4079-7c2c-4fcb-90db-a1d1aff02740@github.com>
Message-ID: <rMoEURxboI5V-XhE39eeb96mfnDueY2V9Bc6DbzXAmo=.fd096eef-3743-4f90-8eb3-87859711cb9f@github.com>

On Thu, 2 Mar 2023 14:30:12 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
>> 
>> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
>> 
>> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
>> 
>> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
>> ...
>> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
>> ...
>> 
>> when `File::exists` is evaluated over an image bundled in a jar.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add system test

Looks good. I left two minor suggestions for changes to the comments in the new policy file.

tests/system/src/test/resources/test/sandbox/empty.policy line 2:

> 1: // Policy file for sandbox tests
> 2: // Use as follows: -Djava.security.policy=test.policy

Minor: should be `empty.policy`

tests/system/src/test/resources/test/sandbox/empty.policy line 4:

> 2: // Use as follows: -Djava.security.policy=test.policy
> 3: 
> 4: // No permissions to read resource files are granted

Minor: maybe also say that all FX permissions are granted?

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1042

From kevin.rushforth at oracle.com  Fri Mar  3 16:39:37 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 3 Mar 2023 08:39:37 -0800
Subject: Result: New OpenJFX Reviewer: Jose Pereda
Message-ID: <6b20e44d-2920-5ea3-322c-706ed7b9bb3f@oracle.com>

Voting for Jose Pereda [1] to OpenJFX Reviewer [2]? [3] is now closed.

Yes: 6
Veto: 0
Abstain: 0

According to the Bylaws definition of Three-Vote Consensus, this is 
sufficient to approve the nomination.

-- Kevin

[1] https://openjdk.org/census#jpereda
[2] https://mail.openjdk.org/pipermail/openjfx-dev/2023-February/038776.html
[3] Note that there was one invalid vote cast by a non-Reviewer that was 
not included in the vote total.


From jpereda at openjdk.org  Fri Mar  3 19:22:04 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 3 Mar 2023 19:22:04 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context [v3]
In-Reply-To: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
Message-ID: <NUBuS1AKj0Cw3L5QGgo2r8uIQkP3Dk7_ujWTeaP4qZU=.edea5c7d-8669-406f-8651-a5c693881ec7@github.com>

> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
> 
> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
> 
> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
> 
> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
> ...
> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
> ...
> 
> when `File::exists` is evaluated over an image bundled in a jar.

Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:

  Address feedback

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1042/files
  - new: https://git.openjdk.org/jfx/pull/1042/files/ba7aef23..51108c4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1042&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1042&range=01-02

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1042.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1042/head:pull/1042

PR: https://git.openjdk.org/jfx/pull/1042

From jpereda at openjdk.org  Fri Mar  3 19:22:08 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 3 Mar 2023 19:22:08 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context [v2]
In-Reply-To: <rMoEURxboI5V-XhE39eeb96mfnDueY2V9Bc6DbzXAmo=.fd096eef-3743-4f90-8eb3-87859711cb9f@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
 <Jw7qpzluPKuiR_gzoSl08r64QrLcvZU8IKid4kAJ0l0=.055c4079-7c2c-4fcb-90db-a1d1aff02740@github.com>
 <rMoEURxboI5V-XhE39eeb96mfnDueY2V9Bc6DbzXAmo=.fd096eef-3743-4f90-8eb3-87859711cb9f@github.com>
Message-ID: <TqFLqcFH8MYQuhaNQ0qqilKQVJZTQieoLjHfNiKEkgw=.ea280f36-8d7a-4b0e-b8ab-105bb2a8f6d0@github.com>

On Fri, 3 Mar 2023 14:00:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add system test
>
> tests/system/src/test/resources/test/sandbox/empty.policy line 2:
> 
>> 1: // Policy file for sandbox tests
>> 2: // Use as follows: -Djava.security.policy=test.policy
> 
> Minor: should be `empty.policy`

Done

> tests/system/src/test/resources/test/sandbox/empty.policy line 4:
> 
>> 2: // Use as follows: -Djava.security.policy=test.policy
>> 3: 
>> 4: // No permissions to read resource files are granted
> 
> Minor: maybe also say that all FX permissions are granted?

Right, I've added only the required permission for the test.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From kcr at openjdk.org  Fri Mar  3 20:50:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 3 Mar 2023 20:50:14 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context [v3]
In-Reply-To: <NUBuS1AKj0Cw3L5QGgo2r8uIQkP3Dk7_ujWTeaP4qZU=.edea5c7d-8669-406f-8651-a5c693881ec7@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
 <NUBuS1AKj0Cw3L5QGgo2r8uIQkP3Dk7_ujWTeaP4qZU=.edea5c7d-8669-406f-8651-a5c693881ec7@github.com>
Message-ID: <6wpadBihkKhSxpPO2daR_SGMLBWAqZOG06VFm7a7NjQ=.ef4a7c5a-3f35-4d95-a652-9cc0829f798e@github.com>

On Fri, 3 Mar 2023 19:22:04 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
>> 
>> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
>> 
>> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
>> 
>> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
>> ...
>> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
>> ...
>> 
>> when `File::exists` is evaluated over an image bundled in a jar.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From mstrauss at openjdk.org  Sun Mar  5 04:07:18 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 5 Mar 2023 04:07:18 GMT
Subject: RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context [v3]
In-Reply-To: <NUBuS1AKj0Cw3L5QGgo2r8uIQkP3Dk7_ujWTeaP4qZU=.edea5c7d-8669-406f-8651-a5c693881ec7@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
 <NUBuS1AKj0Cw3L5QGgo2r8uIQkP3Dk7_ujWTeaP4qZU=.edea5c7d-8669-406f-8651-a5c693881ec7@github.com>
Message-ID: <Rx5_0ZSg71D5oNwIBPl-g0jMyL3wMla-G2ry7ZA38Gg=.d0b291c8-78ca-4f3b-a9be-6ada73244d43@github.com>

On Fri, 3 Mar 2023 19:22:04 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
>> 
>> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
>> 
>> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
>> 
>> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
>> ...
>> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
>> ...
>> 
>> when `File::exists` is evaluated over an image bundled in a jar.
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback

Marked as reviewed by mstrauss (Committer).

I think that I added the call to `File.exists` to quickly detect whether a URL refers to a file on disk, but that seems unnecessary in retrospect.

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From kodosaru at gmail.com  Sun Mar  5 08:36:50 2023
From: kodosaru at gmail.com (Don Johnson)
Date: Sun, 5 Mar 2023 03:36:50 -0500
Subject: Swing works, but OpenJFX applications not working with screen readers
Message-ID: <1be324c6-f275-3fa6-0296-4872d8096ad9@gmail.com>

Hi All,

This is accessibility API question. Swing applications like IntelliJ 
IDEA appear in the utilities jaccesswalker, jaccessinspector (JDK/bin) 
and access-bridge-explorer (.NET app at 
https://github.com/google/access-bridge-explorer.git). However, no scene 
graph or accessibility messages in these utilities appear for any 
OpenJFX application I have written. A screen reader needs both to know 
the scene graph and be able to send and receive accessibility messages 
to perform automation and read control descriptions.

I have put these values in the "accessibility.properties" file in the 
JDK lib folder:

 ??? assistive_technologies=com.sun.java.accessibility.AccessBridge
 ??? screen_magnifier_present=true
 ??? screen_reader_present=true

In different test OpenJFX applications running on Windows machines, with 
the screen reader JAWS running, the 
Platform.accessibilityActiveProperty() is "true." When JAWS is not 
running, the value is "false." However, the screen reader cannot 
communicate with the OpenJFX applications.

Why are the OpenJFX applications not communicating across the 
communication channel facilitated by the WindowsAccessBridge-64.dll and 
JavaAccessBridge.dll? Incidentally, the Java Access Bridge is enabled 
with jabswitch.exe. There is some type of Windows IPC used by the bridge 
(COM?) once it is enabled. This bridge facilitates communication between 
the screen reader and a Java application running inside of a JVM.

I've also tried explicitly setting roles etc. even though OpenJFX 
graphical object already have default values. For example in the 
"bouncing ball" sample program I set,

 ??????? setAccessibleRole(AccessibleRole.BUTTON);
 ??????? setAccessibleRoleDescription("Bouncing Ball");
 ??????? setAccessibleText("I'm a bouncing ball");
 ??????? setAccessibleHelp("This is bouncing ball, use the primary 
action to start animation");

Does anyone have an OpenJFX sample program the shows up in the 
jaccesswalker and jaccessinspector utilities and works with a screen 
reader like JAWS or NVDA? This YouTube presentation implies 
accessibility is already built into OpenJFX, but I can't get it to work, 
see https://youtu.be/iUPPEkD9H1I "The New JavaFX Accessibility API." My 
applications must comply with Section 508 of the Rehabilitation Act of 
1973 but cannot so far because of this OpenJFX accessibility problem.

Thanks,
Don

From philip.race at oracle.com  Sun Mar  5 17:16:41 2023
From: philip.race at oracle.com (Philip Race)
Date: Sun, 5 Mar 2023 09:16:41 -0800
Subject: Swing works, but OpenJFX applications not working with screen
 readers
In-Reply-To: <1be324c6-f275-3fa6-0296-4872d8096ad9@gmail.com>
References: <1be324c6-f275-3fa6-0296-4872d8096ad9@gmail.com>
Message-ID: <3d41c260-6483-849c-cf43-73280e3aeef2@oracle.com>

Those tools as I think you've worked out are Windows-only tools which 
use the Windows-only
Java Access Bridge API that ships with JDK.
AccessBridge was designed and built 25 years ago (!) to enable Assistive 
Technologies to
work for Swing applications at a time when no platform could do this.
ATs like JAWS (and others) implemented support for AccessBridge and 
still provide it today
(we still get bug reports from customers using it)
So Java + Swing was a long way ahead of the platforms.

But JavaFX does not use AccessBridge.
By the time it was developed platforms were starting to add AT APIs.
So instead JavaFX implements support for the platform accessibility APIs 
meaning
Narrator on Windows and VoiceOver on macOS.

Therefore JavaFX will not work with those JDK tools which are tied to 
AccessBridge.

 > with the screen reader JAWS running, the 
Platform.accessibilityActiveProperty() is "true

I guess this is because JAWS registers itself with windows as the active AT.
Whether JAWS interjects itself into Narrator APIs would depend on 
whether Windows
supports that. If it doesn't then JAWS probably has to do old-fashioned 
screen scraping
and I don't know how well that would work.

A11Y is usually tested at the application level - whereas JavaFX and 
Swing are both
toolkits with which to build applications - but we do try to make things 
work well
with the ATs that each of them use, so Narrator is supposed to work for 
JavaFX
applications on Windows.


-phil.

On 3/5/23 12:36 AM, Don Johnson wrote:
> Hi All,
>
> This is accessibility API question. Swing applications like IntelliJ 
> IDEA appear in the utilities jaccesswalker, jaccessinspector (JDK/bin) 
> and access-bridge-explorer (.NET app at 
> https://github.com/google/access-bridge-explorer.git). However, no 
> scene graph or accessibility messages in these utilities appear for 
> any OpenJFX application I have written. A screen reader needs both to 
> know the scene graph and be able to send and receive accessibility 
> messages to perform automation and read control descriptions.
>
> I have put these values in the "accessibility.properties" file in the 
> JDK lib folder:
>
> ??? assistive_technologies=com.sun.java.accessibility.AccessBridge
> ??? screen_magnifier_present=true
> ??? screen_reader_present=true
>
> In different test OpenJFX applications running on Windows machines, 
> with the screen reader JAWS running, the 
> Platform.accessibilityActiveProperty() is "true." When JAWS is not 
> running, the value is "false." However, the screen reader cannot 
> communicate with the OpenJFX applications.
>
> Why are the OpenJFX applications not communicating across the 
> communication channel facilitated by the WindowsAccessBridge-64.dll 
> and JavaAccessBridge.dll? Incidentally, the Java Access Bridge is 
> enabled with jabswitch.exe. There is some type of Windows IPC used by 
> the bridge (COM?) once it is enabled. This bridge facilitates 
> communication between the screen reader and a Java application running 
> inside of a JVM.
>
> I've also tried explicitly setting roles etc. even though OpenJFX 
> graphical object already have default values. For example in the 
> "bouncing ball" sample program I set,
>
> ??????? setAccessibleRole(AccessibleRole.BUTTON);
> ??????? setAccessibleRoleDescription("Bouncing Ball");
> ??????? setAccessibleText("I'm a bouncing ball");
> ??????? setAccessibleHelp("This is bouncing ball, use the primary 
> action to start animation");
>
> Does anyone have an OpenJFX sample program the shows up in the 
> jaccesswalker and jaccessinspector utilities and works with a screen 
> reader like JAWS or NVDA? This YouTube presentation implies 
> accessibility is already built into OpenJFX, but I can't get it to 
> work, see https://youtu.be/iUPPEkD9H1I "The New JavaFX Accessibility 
> API." My applications must comply with Section 508 of the 
> Rehabilitation Act of 1973 but cannot so far because of this OpenJFX 
> accessibility problem.
>
> Thanks,
> Don


From jpereda at openjdk.org  Sun Mar  5 20:45:15 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Sun, 5 Mar 2023 20:45:15 GMT
Subject: Integrated: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
In-Reply-To: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
References: <j6wspAMGmYf36s8Wy1BTTQONaZG8RujIJ-RGsYe7APw=.10645290-cf69-4904-8adc-a0579e157406@github.com>
Message-ID: <3eQnvUBR2OS75qsEqDCJmD4VZgQV28eCLxSxzF4Yyw8=.af7874cd-0aa2-45a5-ac6f-83611e864157@github.com>

On Mon, 20 Feb 2023 14:15:07 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR removes an unnecessary check that was added as part of [JDK-8267551](https://bugs.openjdk.org/browse/JDK-8267551).
> 
> As commented in the [issue](https://bugs.openjdk.org/browse/JDK-8300872), there were no failing/passing tests before/after these lines were added, and there are no actual tests that get into the case.
> 
> The mentioned check caused, as a side effect, the JDK-8300872 issue, as running under a (deprecated) security manager fails with:
> 
> java.security.AccessControlException: access denied ("java.io.FilePermission" "jrt:/javafx.controls/com/sun/javafx/scene/control/skin/modena/pattern-transparent.png" "read")
> ...
> at javafx.graphics/javafx.scene.image.Image.validateUrl(Image.java:1127)
> ...
> 
> when `File::exists` is evaluated over an image bundled in a jar.

This pull request has now been integrated.

Changeset: b2134505
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b2134505cc0c89637019ce746d5fac6ab708d4e2
Stats:     207 lines in 5 files changed: 196 ins; 5 del; 6 mod

8300872: WebView's ColorChooser fails to initialize when running in security context

Reviewed-by: kcr, mstrauss

-------------

PR: https://git.openjdk.org/jfx/pull/1042

From jbhaskar at openjdk.org  Mon Mar  6 10:38:43 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 6 Mar 2023 10:38:43 GMT
Subject: RFR: 8303217: Webview loaded webpage is not showing play,
 volume related buttons for embeded Audio/Video elements [v8]
In-Reply-To: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
References: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
Message-ID: <1Ba442-4qSf42TcTLVOpYbFG3dVE3MhXavOiwmww28U=.e381de06-ed86-4298-9255-20c10f819156@github.com>

> Issue: default html5 video element not showing media controls
> Details: Media control design has been refactored in the current Webkit Gtk port. The CSS id 
>                 and properties related to media buttons, and slider have been removed, due to which the 
>                 media style mediaControlsAdwaita.css values are not being applied.
> Solution: restored media control keywords and mapped to CSS keywords values.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  resolve thumb rendering issue

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1049/files
  - new: https://git.openjdk.org/jfx/pull/1049/files/ec0d8304..d9ca3aac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1049&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1049&range=06-07

  Stats: 156 lines in 7 files changed: 155 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1049.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1049/head:pull/1049

PR: https://git.openjdk.org/jfx/pull/1049

From kpk at openjdk.org  Mon Mar  6 10:51:21 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 6 Mar 2023 10:51:21 GMT
Subject: RFR: 8178368: Right alignment of text fields and alignment of
 prompt text works incorrectly [v8]
In-Reply-To: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
Message-ID: <I_bcpZiS0JMQpxyRDUwbyS_1DnhkThmDIJYQqLN-ygA=.a2f7a4ca-4e6e-4e0a-979d-db68df95349d@github.com>

> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
> 
> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
> 
> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.

Karthik P K has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into textfield_issue_fix
 - Fix text scroll issue when right aligned
 - Updating the code according to review comments
 - Fix text and prompt alignment issue
 - Merge branch 'openjdk:master' into textfield_issue_fix
 - Update comments
 - Fix textfield right and center alignment issues
 - Fix for TextField right alignement issue

-------------

Changes: https://git.openjdk.org/jfx/pull/980/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=980&range=07
  Stats: 129 lines in 2 files changed: 87 ins; 27 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/980.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/980/head:pull/980

PR: https://git.openjdk.org/jfx/pull/980

From jbhaskar at openjdk.org  Mon Mar  6 12:55:51 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 6 Mar 2023 12:55:51 GMT
Subject: RFR: 8303217: Webview loaded webpage is not showing play,
 volume related buttons for embeded Audio/Video elements [v9]
In-Reply-To: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
References: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
Message-ID: <cVkI0TufNSkMMkrHJwwasJFlNc-Xr3C_8f2bBsF6sY8=.4601c60c-7ad7-4a6e-9910-ec275bafbe4a@github.com>

> Issue: default html5 video element not showing media controls
> Details: Media control design has been refactored in the current Webkit Gtk port. The CSS id 
>                 and properties related to media buttons, and slider have been removed, due to which the 
>                 media style mediaControlsAdwaita.css values are not being applied.
> Solution: restored media control keywords and mapped to CSS keywords values.

Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:

  cleaning trailing whitespace error skara

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1049/files
  - new: https://git.openjdk.org/jfx/pull/1049/files/d9ca3aac..441ec421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1049&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1049&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1049.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1049/head:pull/1049

PR: https://git.openjdk.org/jfx/pull/1049

From kpk at openjdk.org  Mon Mar  6 13:12:05 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 6 Mar 2023 13:12:05 GMT
Subject: RFR: 8178368: Right alignment of text fields and alignment of
 prompt text works incorrectly [v9]
In-Reply-To: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
Message-ID: <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>

> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
> 
> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
> 
> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Removing white space

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/980/files
  - new: https://git.openjdk.org/jfx/pull/980/files/ba29a810..640c67de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=980&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=980&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/980.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/980/head:pull/980

PR: https://git.openjdk.org/jfx/pull/980

From kcr at openjdk.org  Mon Mar  6 15:36:22 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 15:36:22 GMT
Subject: RFR: 8303217: Webview loaded webpage is not showing play,
 volume related buttons for embeded Audio/Video elements [v9]
In-Reply-To: <cVkI0TufNSkMMkrHJwwasJFlNc-Xr3C_8f2bBsF6sY8=.4601c60c-7ad7-4a6e-9910-ec275bafbe4a@github.com>
References: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
 <cVkI0TufNSkMMkrHJwwasJFlNc-Xr3C_8f2bBsF6sY8=.4601c60c-7ad7-4a6e-9910-ec275bafbe4a@github.com>
Message-ID: <byKDoIX2sBfHccwGdQtLgZnsBkCWxqWpV-aoMr67c28=.ce5a25e6-a0c0-4868-8811-5e278d02179c@github.com>

On Mon, 6 Mar 2023 12:55:51 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Issue: default html5 video element not showing media controls
>> Details: Media control design has been refactored in the current Webkit Gtk port. The CSS id 
>>                 and properties related to media buttons, and slider have been removed, due to which the 
>>                 media style mediaControlsAdwaita.css values are not being applied.
>> Solution: restored media control keywords and mapped to CSS keywords values.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaning trailing whitespace error skara

Looks good. I've tested this on macOS and Windows and confirm that both bugs are fixed.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1049

From kpk at openjdk.org  Mon Mar  6 15:41:29 2023
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 6 Mar 2023 15:41:29 GMT
Subject: RFR: 8178368: Right alignment of text fields and alignment of
 prompt text works incorrectly [v9]
In-Reply-To: <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>
Message-ID: <vrQJWHH7P9sIJR9ZVq6zmjASOcxsamzqG4WjRgKGh9I=.d3c38070-ae31-4c87-9474-f874c3b11100@github.com>

On Mon, 6 Mar 2023 13:12:05 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
>> 
>> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
>> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
>> 
>> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing white space

Resolved the merge conflict. Please review.

-------------

PR: https://git.openjdk.org/jfx/pull/980

From hmeda at openjdk.org  Mon Mar  6 15:51:45 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Mon, 6 Mar 2023 15:51:45 GMT
Subject: RFR: 8303217: Webview loaded webpage is not showing play,
 volume related buttons for embeded Audio/Video elements [v9]
In-Reply-To: <cVkI0TufNSkMMkrHJwwasJFlNc-Xr3C_8f2bBsF6sY8=.4601c60c-7ad7-4a6e-9910-ec275bafbe4a@github.com>
References: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
 <cVkI0TufNSkMMkrHJwwasJFlNc-Xr3C_8f2bBsF6sY8=.4601c60c-7ad7-4a6e-9910-ec275bafbe4a@github.com>
Message-ID: <k0nBAj-TEGJFoWvA6WGJWMHRXA6WIalNUQ0w_qHzKoA=.f7e60a45-edd0-4a71-980f-cc4028ddafcd@github.com>

On Mon, 6 Mar 2023 12:55:51 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Issue: default html5 video element not showing media controls
>> Details: Media control design has been refactored in the current Webkit Gtk port. The CSS id 
>>                 and properties related to media buttons, and slider have been removed, due to which the 
>>                 media style mediaControlsAdwaita.css values are not being applied.
>> Solution: restored media control keywords and mapped to CSS keywords values.
>
> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleaning trailing whitespace error skara

Marked as reviewed by hmeda (Committer).

Looks good. I have verified unit tests and drt tests on mac and windows.
No issue seen.Slider and media controls are rendered properly.

-------------

PR: https://git.openjdk.org/jfx/pull/1049

From jbhaskar at openjdk.org  Mon Mar  6 16:03:22 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 6 Mar 2023 16:03:22 GMT
Subject: Integrated: 8303217: Webview loaded webpage is not showing play,
 volume related buttons for embeded Audio/Video elements
In-Reply-To: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
References: <06m8dBV7OKlKdF8oiiFIUx-a32XT0u0cJEJNT5UqEv4=.0bed7d32-0241-43c6-a816-b0264ff085c5@github.com>
Message-ID: <mZv4MBi8NXnPuVfi306ykisiYpb7tM39SPEEzEFOBSk=.d9b2caf4-4713-4bb3-8849-3331b227fd6b@github.com>

On Sun, 26 Feb 2023 16:47:23 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: default html5 video element not showing media controls
> Details: Media control design has been refactored in the current Webkit Gtk port. The CSS id 
>                 and properties related to media buttons, and slider have been removed, due to which the 
>                 media style mediaControlsAdwaita.css values are not being applied.
> Solution: restored media control keywords and mapped to CSS keywords values.

This pull request has now been integrated.

Changeset: bbdc5998
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/bbdc59984a7f6427a5ad8b8ad39aa93ee3b4abbe
Stats:     400 lines in 18 files changed: 396 ins; 3 del; 1 mod

8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements
8300954: HTML default Range input control not rendered

Co-authored-by: Hima Bindu Meda <hmeda at openjdk.org>
Reviewed-by: kcr, hmeda

-------------

PR: https://git.openjdk.org/jfx/pull/1049

From florian.kirmaier at gmail.com  Mon Mar  6 16:07:18 2023
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Mon, 6 Mar 2023 17:07:18 +0100
Subject: RFR - Virtual Flow Freeze
Message-ID: <CA+4mSqZcrCxPqfAHRmrN7TaZ-KXytQA7gQ-fspk2PPG8OphkyQ@mail.gmail.com>

Hi Everyone,

Found a bug that can cause the VirtualFlow to no longer scroll,
So I've implemented a fix and a test for it.

https://github.com/openjdk/jfx/pull/1052

Florian Kirmaier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230306/2eb712c3/attachment-0001.htm>

From fkirmaier at openjdk.org  Mon Mar  6 16:10:38 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Mon, 6 Mar 2023 16:10:38 GMT
Subject: RFR: JDK-8303680 VirtualFlow freeze
Message-ID: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>

Possible fix for VirtualFlow freeze.

I encountered the problem when experimenting with VirtualFlow.

Guess @johanvos should take a look.
All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

-------------

Commit messages:
 - JDK-8303680
 - JDK-8303680

Changes: https://git.openjdk.org/jfx/pull/1052/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303680
  Stats: 43 lines in 2 files changed: 42 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1052.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1052/head:pull/1052

PR: https://git.openjdk.org/jfx/pull/1052

From kcr at openjdk.org  Mon Mar  6 16:15:08 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 16:15:08 GMT
Subject: RFR: 8303680 VirtualFlow freeze
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <ssSnmM2IIREsn5K97gAbetUT3z5rtVh1A_2xh0uVVSk=.4182f46e-a91e-4a77-a36e-f44a4ef8abe7@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

You will need to modify the title of this PR to match the JBS bug title (which I slightly modified to change "crashed" to "freezes" to better reflect the problem).

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From angorya at openjdk.org  Mon Mar  6 16:17:05 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 6 Mar 2023 16:17:05 GMT
Subject: RFR: 8178368: Right alignment of text fields and alignment of
 prompt text works incorrectly [v9]
In-Reply-To: <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>
Message-ID: <hFfzpI2tqQQ9Y9O4KKXv_4kjyYhAp0bGc0J4zsNXlMI=.13f15050-4103-4196-ad1d-6d92c2658666@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 6 Mar 2023 13:12:05 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
>> 
>> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
>> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
>> 
>> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing white space

lgtm

-------------

Marked as reviewed by angorya (Committer).

PR: https://git.openjdk.org/jfx/pull/980

From angorya at openjdk.org  Mon Mar  6 16:42:24 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 6 Mar 2023 16:42:24 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2540:

> 2538:         // scroll to 50 and scroll 1 pixel
> 2539:         vf.scrollTo(50);
> 2540:         vf.scrollPixels(1);

this is a rather artificial test.  
is it possible to reproduce the condition using control's public APIs?

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From kcr at openjdk.org  Mon Mar  6 17:11:10 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 17:11:10 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v55]
In-Reply-To: <z0MQkr3osSLNGJ9y7c9SUEwGAPTLoWQSwdslkMctMz4=.f3cd92c9-f9c2-419a-a5c6-f90f91705934@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <z0MQkr3osSLNGJ9y7c9SUEwGAPTLoWQSwdslkMctMz4=.f3cd92c9-f9c2-419a-a5c6-f90f91705934@github.com>
Message-ID: <U0gAm_dI-seNbCTu0y3Zl29kgrULOSUROSFc-z6CoVE=.b0763583-554b-4995-8a57-b23b55bf44a7@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 27 Feb 2023 00:13:40 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This cleans size and positioning code, reducing special cases, code complexity and size.
>> 
>> Changes:
>> 
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
>> - window geometry, min/max size are centralized in `update_window_constraints`;
>> - Frame extents (the window decoration size used for "total window size"):
>>     - frame extents are received in `process_property_notify`;
>>     - removed quirks in java code;
>>     - When received, call `set_bounds` again to adjust the size (to account decorations later received);
>> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it.
>> - `ensure_window_size` was a quirk - removed;
>> - `requested_bounds` removed - not used anymore;
>> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`;
>> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point)
>> - `restack` split in `to_front()` and `to_back()` to conform to managed code;
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug when window starts maximized and restores to wrong size

I have finished my testing. All looks good, with one problem seen on Ubuntu 16.04 that warrants a P4 follow-up bug (which we may or may not care to fix).


The following test fails consistently on Ubuntu 16.04 with this patch:


DeiconifiedWithChildTest > testDeiconifiedPosition FAILED
    java.lang.AssertionError: Child window was moved expected:<343.0> but was:<333.0>
        at org.junit.Assert.fail(Assert.java:89)
        at org.junit.Assert.failNotEquals(Assert.java:835)
        at org.junit.Assert.assertEquals(Assert.java:555)
        at test.javafx.stage.DeiconifiedWithChildTest.testDeiconifiedPosition(DeiconifiedWithChildTest.java:99)


I also reviewed the code changes, and they look good (although I did leave one question for you to consider).

modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 819:

> 817: void WindowContextTop::request_frame_extents() {
> 818:     Display *display = GDK_DISPLAY_XDISPLAY(gdk_window_get_display(gdk_window));
> 819:     static Atom rfeAtom = XInternAtom(display, "_NET_REQUEST_FRAME_EXTENTS", False);

If display could be different for two Windows, then making this static would not be the right thing to do. I don't think it can, so this is probably OK.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/915

From kcr at openjdk.org  Mon Mar  6 19:34:43 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 19:34:43 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <5e9ja5-5_2-bGPvSkSam5H2tp4lu3Fok6JgKuIrad0I=.efa1653a-d8bb-4016-aac3-704fe8c6a335@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
 <5e9ja5-5_2-bGPvSkSam5H2tp4lu3Fok6JgKuIrad0I=.efa1653a-d8bb-4016-aac3-704fe8c6a335@github.com>
Message-ID: <oicxlUlYTxx8w6tvS9wGdLjqObuC4QQAjDlGjz3-ANQ=.68202470-6df3-4100-ad25-805e90e664d8@github.com>

On Thu, 2 Mar 2023 23:38:20 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> CSR: https://bugs.openjdk.org/browse/JDK-8303493

This is ready to move to "Proposed" now. I left a couple minor comments that will need to be addressed before I formally review it and before it is "Finalized".

-------------

PR: https://git.openjdk.org/jfx/pull/999

From fkirmaier at openjdk.org  Mon Mar  6 20:53:19 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Mon, 6 Mar 2023 20:53:19 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
Message-ID: <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 6 Mar 2023 16:39:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Possible fix for VirtualFlow freeze.
>> 
>> I encountered the problem when experimenting with VirtualFlow.
>> 
>> Guess @johanvos should take a look.
>> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2540:
> 
>> 2538:         // scroll to 50 and scroll 1 pixel
>> 2539:         vf.scrollTo(50);
>> 2540:         vf.scrollPixels(1);
> 
> this is a rather artificial test.  
> is it possible to reproduce the condition using control's public APIs?

This is the public API of VirtualFlow. I don't know whether it's possible with the API of the Control - But the API of the VirtualFlow should be stable too, right?

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From angorya at openjdk.org  Mon Mar  6 20:57:18 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 6 Mar 2023 20:57:18 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
 <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>
Message-ID: <DJnU3w1t11AtPvEyk_O8TnNYidRVpwzwOHOnX3YI4zA=.cd2cb86b-aeff-4fb4-997d-d76ebc6799ee@github.com>

On Mon, 6 Mar 2023 20:50:15 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 2540:
>> 
>>> 2538:         // scroll to 50 and scroll 1 pixel
>>> 2539:         vf.scrollTo(50);
>>> 2540:         vf.scrollPixels(1);
>> 
>> this is a rather artificial test.  
>> is it possible to reproduce the condition using control's public APIs?
>
> This is the public API of VirtualFlow. I don't know whether it's possible with the API of the Control - But the API of the VirtualFlow should be stable too, right?

You are right, it is public API.  One can't get directly to it, but it is possible to subclass the ListView and use the protected `getVirtualFlow()` method.

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From kcr at openjdk.org  Mon Mar  6 21:11:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 21:11:17 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <BeSr3Jw3bxdEATUJ7JySWmbiqEUZa1E8c0W-YGzI2r0=.d800ca24-8a70-4d38-a917-056b9bac2e4d@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

I'll let others do the formal review of this, but I would like to see an evaluation of what the root cause is, why this is the right fix, and whether there are any side effects. As it is, all I see is a removed line with no explanation of the problem or the solution.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1718:

> 1716:         // Finally, update the scroll bars
> 1717:         updateScrollBarsAndCells(false);
> 1718:         lastPosition = getPosition();

This is not a formal review -- I'll let Andy and Johan do that -- but can you explain why this is the right fix? Presumably there was at least some reasoning behind updating `lastPosition`. Are there any side effects of not doing that?

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From kcr at openjdk.org  Mon Mar  6 21:11:20 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 6 Mar 2023 21:11:20 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <DJnU3w1t11AtPvEyk_O8TnNYidRVpwzwOHOnX3YI4zA=.cd2cb86b-aeff-4fb4-997d-d76ebc6799ee@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
 <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>
 <DJnU3w1t11AtPvEyk_O8TnNYidRVpwzwOHOnX3YI4zA=.cd2cb86b-aeff-4fb4-997d-d76ebc6799ee@github.com>
Message-ID: <oBk4U1RlNAWTT3WOzsz1MS4v9ZSs3iUXHrOaxomiAxE=.b35caf24-1ad8-4dca-92d2-7fbd38338f4a@github.com>

On Mon, 6 Mar 2023 20:54:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is the public API of VirtualFlow. I don't know whether it's possible with the API of the Control - But the API of the VirtualFlow should be stable too, right?
>
> You are right, it is public API.  One can't get directly to it, but it is possible to subclass the ListView and use the protected `getVirtualFlow()` method.

We have many tests that access VirtualFlow, so that seems ok.

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From angorya at openjdk.org  Mon Mar  6 21:11:21 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 6 Mar 2023 21:11:21 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <oBk4U1RlNAWTT3WOzsz1MS4v9ZSs3iUXHrOaxomiAxE=.b35caf24-1ad8-4dca-92d2-7fbd38338f4a@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
 <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>
 <DJnU3w1t11AtPvEyk_O8TnNYidRVpwzwOHOnX3YI4zA=.cd2cb86b-aeff-4fb4-997d-d76ebc6799ee@github.com>
 <oBk4U1RlNAWTT3WOzsz1MS4v9ZSs3iUXHrOaxomiAxE=.b35caf24-1ad8-4dca-92d2-7fbd38338f4a@github.com>
Message-ID: <kT7fpCtOjoKyynVfzP4OoWTizEPRtFBFdMznprPdO0U=.e595207c-be24-4e80-a619-8d68d6913a6b@github.com>

On Mon, 6 Mar 2023 21:01:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> You are right, it is public API.  One can't get directly to it, but it is possible to subclass the ListView and use the protected `getVirtualFlow()` method.
>
> We have many tests that access VirtualFlow, so that seems ok.

would it be possible to update the JBS ticket with a valid code example?

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From tsayao at openjdk.org  Mon Mar  6 23:18:29 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 6 Mar 2023 23:18:29 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v55]
In-Reply-To: <U0gAm_dI-seNbCTu0y3Zl29kgrULOSUROSFc-z6CoVE=.b0763583-554b-4995-8a57-b23b55bf44a7@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <z0MQkr3osSLNGJ9y7c9SUEwGAPTLoWQSwdslkMctMz4=.f3cd92c9-f9c2-419a-a5c6-f90f91705934@github.com>
 <U0gAm_dI-seNbCTu0y3Zl29kgrULOSUROSFc-z6CoVE=.b0763583-554b-4995-8a57-b23b55bf44a7@github.com>
Message-ID: <8w6xSeCH_EEZhq9uUx3SksyJFntCJ3ubrQv_UzlmiEM=.dab054a5-9c63-46e0-9c00-b3bc83b75e46@github.com>

On Sat, 4 Mar 2023 17:45:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug when window starts maximized and restores to wrong size
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 819:
> 
>> 817: void WindowContextTop::request_frame_extents() {
>> 818:     Display *display = GDK_DISPLAY_XDISPLAY(gdk_window_get_display(gdk_window));
>> 819:     static Atom rfeAtom = XInternAtom(display, "_NET_REQUEST_FRAME_EXTENTS", False);
> 
> If display could be different for two Windows, then making this static would not be the right thing to do. I don't think it can, so this is probably OK.

Atoms are per server, so I also think it's ok.

-------------

PR: https://git.openjdk.org/jfx/pull/915

From tsayao at openjdk.org  Mon Mar  6 23:50:21 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 6 Mar 2023 23:50:21 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
Message-ID: <BqHthkyEu-fXihddKXYvJ_CcxW3jKjIfFZ2TWcYHOPI=.8b669a58-08b4-409d-93c7-cc603c016828@github.com>

On Thu, 2 Mar 2023 17:01:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

Will do it in a few days.

-------------

PR: https://git.openjdk.org/jfx/pull/999

From kcr at openjdk.org  Tue Mar  7 00:03:16 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 00:03:16 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <kT7fpCtOjoKyynVfzP4OoWTizEPRtFBFdMznprPdO0U=.e595207c-be24-4e80-a619-8d68d6913a6b@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
 <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>
 <DJnU3w1t11AtPvEyk_O8TnNYidRVpwzwOHOnX3YI4zA=.cd2cb86b-aeff-4fb4-997d-d76ebc6799ee@github.com>
 <oBk4U1RlNAWTT3WOzsz1MS4v9ZSs3iUXHrOaxomiAxE=.b35caf24-1ad8-4dca-92d2-7fbd38338f4a@github.com>
 <kT7fpCtOjoKyynVfzP4OoWTizEPRtFBFdMznprPdO0U=.e595207c-be24-4e80-a619-8d68d6913a6b@github.com>
Message-ID: <HpJW1__kpYrgPKbicUbj2rBPjy9qDgSvuLra9cM6kL4=.79d7bb17-ac9e-470b-9249-5146dff5db4a@github.com>

On Mon, 6 Mar 2023 21:08:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> We have many tests that access VirtualFlow, so that seems ok.
>
> would it be possible to update the JBS ticket with a valid code example?

That would be very helpful.

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From kcr at openjdk.org  Tue Mar  7 00:26:20 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 00:26:20 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v7]
In-Reply-To: <L4wU2O54gtNcYsGxvVIMkLfnZKKawzWJAp5DugB5JoM=.8336a750-32b5-4995-b52c-9d053a5dcec9@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <L4wU2O54gtNcYsGxvVIMkLfnZKKawzWJAp5DugB5JoM=.8336a750-32b5-4995-b52c-9d053a5dcec9@github.com>
Message-ID: <3Zb344ZZ5wyQ6pgZPIJT8Bm7Lsl2zJFmujceE9kSrCU=.9a563971-601f-4966-b4ce-276d3b2713c5@github.com>

On Fri, 3 Mar 2023 07:28:48 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
>> 
>> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
>> 
>> Added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stabilizing test

The updated test seems stable now. I did leave a couple suggestions.

Have you run the test this on all platforms?

tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 62:

> 60:  * There is 1 test in this file.
> 61:  * Steps for testChoicBoxScrollOnCollectionChange()
> 62:  * 1. Create a ChoiceBox and add 50 items to it.

Minor: the comment is wrong now (you add 150 items).

tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 143:

> 141: 
> 142:         double rowHeight = ContextMenuContentShim.getContextMenuRowHeight(popup);
> 143:         double screenHeight = Screen.getPrimary().getBounds().getHeight();

I think using `getVisualBounds()` would be better.

tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 144:

> 142:         double rowHeight = ContextMenuContentShim.getContextMenuRowHeight(popup);
> 143:         double screenHeight = Screen.getPrimary().getBounds().getHeight();
> 144:         scrollChoiceBox((int) (screenHeight / rowHeight));

This seems to work, but it might be more robust to use `Math.ceil()` before casting to int, especially if you make the change to use the visual bounds.

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Tue Mar  7 07:22:41 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 7 Mar 2023 07:22:41 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v8]
In-Reply-To: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
Message-ID: <OqT3iMq552j8YrBErUfWHc98GuQDgfq8e7YBJ9hMZvU=.79df903b-beb6-414b-a816-65d61b63e66b@github.com>

> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
> 
> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
> 
> Added system test to validate the fix.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1039/files
  - new: https://git.openjdk.org/jfx/pull/1039/files/47552cff..18b8d74a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1039&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1039&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1039.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1039/head:pull/1039

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Tue Mar  7 07:22:41 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 7 Mar 2023 07:22:41 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v7]
In-Reply-To: <3Zb344ZZ5wyQ6pgZPIJT8Bm7Lsl2zJFmujceE9kSrCU=.9a563971-601f-4966-b4ce-276d3b2713c5@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <L4wU2O54gtNcYsGxvVIMkLfnZKKawzWJAp5DugB5JoM=.8336a750-32b5-4995-b52c-9d053a5dcec9@github.com>
 <3Zb344ZZ5wyQ6pgZPIJT8Bm7Lsl2zJFmujceE9kSrCU=.9a563971-601f-4966-b4ce-276d3b2713c5@github.com>
Message-ID: <yGtTQCGMady0MC-JrCFlE8zhf1xnlrp3bYdAWb6kGII=.9e8cd6b9-3495-4805-bf36-226f15c52b61@github.com>

On Tue, 7 Mar 2023 00:23:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Have you run the test this on all platforms?

I have run the test in Mac and Windows multiple times. No failures found.

> tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 62:
> 
>> 60:  * There is 1 test in this file.
>> 61:  * Steps for testChoicBoxScrollOnCollectionChange()
>> 62:  * 1. Create a ChoiceBox and add 50 items to it.
> 
> Minor: the comment is wrong now (you add 150 items).

Updated comment

> tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 143:
> 
>> 141: 
>> 142:         double rowHeight = ContextMenuContentShim.getContextMenuRowHeight(popup);
>> 143:         double screenHeight = Screen.getPrimary().getBounds().getHeight();
> 
> I think using `getVisualBounds()` would be better.

Updated code to use `getVisualBounds()`

> tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 144:
> 
>> 142:         double rowHeight = ContextMenuContentShim.getContextMenuRowHeight(popup);
>> 143:         double screenHeight = Screen.getPrimary().getBounds().getHeight();
>> 144:         scrollChoiceBox((int) (screenHeight / rowHeight));
> 
> This seems to work, but it might be more robust to use `Math.ceil()` before casting to int, especially if you make the change to use the visual bounds.

Updated code to use `Math.ceil()`

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From fkirmaier at openjdk.org  Tue Mar  7 09:16:27 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 7 Mar 2023 09:16:27 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <-FMafozAlGz7Kcpjpy7Glc58QCpQlLq8rIXsRSWc2ag=.b29e0008-a709-42d7-9e0a-46c4553c40f4@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

Some explanation:

The layout method contains logic, to skip the layouting.


            if (width == lastWidth &&
                height == lastHeight &&
                cellCount == lastCellCount &&
                isVertical == lastVertical &&
                position == lastPosition &&
                ! cellSizeChanged)
            {
                // TODO this happens to work around the problem tested by
                // testCellLayout_LayoutWithoutChangingThingsUsesCellsInSameOrderAsBefore
                // but isn't a proper solution. Really what we need to do is, when
                // laying out cells, we need to make sure that if a cell is pressed
                // AND we are doing a full rebuild then we need to make sure we
                // use that cell in the same physical location as before so that
                // it gets the mouse release event.
                return;
            }


So, when the position is changed, then the content should be layout again.
But when we reset the oldPosition, to the current position, somewhere else in the contain - then we interfere with this logic.
This has the effect, that the layout is skipped.
For that reason, it seems wrong to me, to change the "last-something" values outside of this method.

So I removed the resetting of the lastPosition in the scrollPixels method.
`lastPosition = getPosition();`
I also don't see a reason, why the lastPosition should be set anyways.

But I have to admit, that I don't understand the class well enough to ensure this is correct based on logic. This fixes the unit test and doesn't seem to break tests or something obvious in applications according to my tests.

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From john.hendrikx at gmail.com  Tue Mar  7 09:24:43 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 7 Mar 2023 10:24:43 +0100
Subject: Promote addEventHandler/removeEventHandler to EventTarget
 interface
In-Reply-To: <CAJEpuXT+rfh4yWR_snjiNmR-2fFO83UtMmFtiYro4-_sufAjrg@mail.gmail.com>
References: <CAJEpuXT+rfh4yWR_snjiNmR-2fFO83UtMmFtiYro4-_sufAjrg@mail.gmail.com>
Message-ID: <f734637c-6768-9352-d10a-fe2b2a396e4a@gmail.com>

Hi Michael,

Did you file a JIRA issue for this one?

I've recently also been doing some rewriting to use the Event system 
more.? I'm removing custom Scene walking code (and looking at 
Node.getProperties) to do "event handling", and I've now discovered that 
it could be done quite a bit nicer by using the provided event mechanism.

I've encountered a few things that annoy me about the event system:

1) I'm making use of Presentation classes (Models) that only associate 
with things in javafx.base (Event, EventTarget, Properties). These 
presentations need to register event handlers at some point, but this 
can only be done on Nodes; having this logic close to the Presentation 
code makes sense, but it would make them dependent on javafx.graphics; 
if I could do this via EventTarget, the dependency would not be needed.

2) When you fire an event (via Node.fireEvent for example), there is no 
feedback you can obtain whether the event was consumed or not as the 
final event is not returned to check `isConsumed` on (internal calls do 
have this information, but it is not exposed at the last step).

3) Related to 2), I think EventTarget could also have a method to 
dispatch events (so you can dispatch an event easily to any target, not 
just via the convenience method Node#fireEvent).? See this ticket: 
https://bugs.openjdk.org/browse/JDK-8303209

Perhaps we can work together on this, or if you're not currently working 
on it I could take a stab at solving all of these issues.

--John

On 17/03/2022 21:01, Michael Strau? wrote:
> I'm working on an application that uses the JavaFX event system
> extensively, and I'm finding it quite hard to use common code for
> event handler registrations.
>
> The problem is that the `EventTarget` interface contains no
> addEventHandler/removeEventHandler methods, and as a consequence of
> that, code that uses `EventTarget` ends up requiring lots of brittle
> instanceof tests to call these methods on all the different
> implementations of `EventTarget`.
>
> There are three buckets of `EventTarget` implementations:
>
> 1) Implementations that declare the following methods:
>      <T extends Event> void addEventHandler(EventType<T>,
> EventHandler<? super T>);
>      <T extends Event> void removeEventHandler(EventType<T>,
> EventHandler<? super T>);
>      <T extends Event> void addEventFilter(EventType<T>, EventHandler<?
> super T>);
>      <T extends Event> void removeEventFilter(EventType<T>,
> EventHandler<? super T>);
> --> Node, Scene, Window, Transform, Task, Service
>
> 2) Implementations that declare the following methods:
>      <T extends Event> void addEventHandler(EventType<T>, EventHandler<T>);
>      <T extends Event> void removeEventHandler(EventType<T>, EventHandler<T>);
> --> MenuItem, TreeItem, TableColumnBase
>
> (Note that the EventHandler argument ist parameterized as
> EventHandler<T>, not EventHandler<? super T> as in the first set of
> methods.)
>
> 3) Implementations that don't declare any methods to add or remove
> event handlers:
> --> Dialog, Tab
>
>
> I think the situation can be improved by promoting the bucket 1
> methods to the `EventTarget` interface, so they can be used
> consistently across all implementations of `EventTarget`.
>
> This works seamlessly for bucket 1 and bucket 3 implementations.
>
> With bucket 2, there's the problem that, inconsistently, the
> EventHandler<T> argument is not a lower-bounded wildcard.
> Unfortunately, a method with an EventHandler<T> parameter cannot
> implement an interface method that expects EventHandler<? super T>.
>
> However, since the erasure of the method remains the same, changing
> the method signature would technically be a binary-compatible change.
>
> Do you think this is a useful improvement?

From fkirmaier at openjdk.org  Tue Mar  7 09:50:16 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 7 Mar 2023 09:50:16 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <BeSr3Jw3bxdEATUJ7JySWmbiqEUZa1E8c0W-YGzI2r0=.d800ca24-8a70-4d38-a917-056b9bac2e4d@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <BeSr3Jw3bxdEATUJ7JySWmbiqEUZa1E8c0W-YGzI2r0=.d800ca24-8a70-4d38-a917-056b9bac2e4d@github.com>
Message-ID: <EftA-Edw_QOKaXJ9pRxx8oQ2dY1hgrGHZk45W4t_-7E=.e8dd5545-f980-4907-9973-9bc7ad1ff820@github.com>

On Mon, 6 Mar 2023 21:02:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Possible fix for VirtualFlow freeze.
>> 
>> I encountered the problem when experimenting with VirtualFlow.
>> 
>> Guess @johanvos should take a look.
>> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1718:
> 
>> 1716:         // Finally, update the scroll bars
>> 1717:         updateScrollBarsAndCells(false);
>> 1718:         lastPosition = getPosition();
> 
> This is not a formal review -- I'll let Andy and Johan do that -- but can you explain why this is the right fix? Presumably there was at least some reasoning behind updating `lastPosition`. Are there any side effects of not doing that?

I've written more about the explanation below. Actually, it's a good question whether there is reasoning behind updating lastPosition. Wouldn't be surprised, if it is just an artifact of some bug-fixing attempt.

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From fkirmaier at openjdk.org  Tue Mar  7 09:58:49 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 7 Mar 2023 09:58:49 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <HpJW1__kpYrgPKbicUbj2rBPjy9qDgSvuLra9cM6kL4=.79d7bb17-ac9e-470b-9249-5146dff5db4a@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <7jhVNuHiz7o4P6PFZiZd24T9VFpnPzAQ1hWqw_g_5OQ=.6029be74-0c3d-4503-9214-c76118b6c6e5@github.com>
 <ncnkfYgqfb7xz09IEWwF09IT-W7OviAXAlJ54_ofURU=.3fc910d9-01f3-401f-97c0-e72c4facbc37@github.com>
 <DJnU3w1t11AtPvEyk_O8TnNYidRVpwzwOHOnX3YI4zA=.cd2cb86b-aeff-4fb4-997d-d76ebc6799ee@github.com>
 <oBk4U1RlNAWTT3WOzsz1MS4v9ZSs3iUXHrOaxomiAxE=.b35caf24-1ad8-4dca-92d2-7fbd38338f4a@github.com>
 <kT7fpCtOjoKyynVfzP4OoWTizEPRtFBFdMznprPdO0U=.e595207c-be24-4e80-a619-8d68d6913a6b@github.com>
 <HpJW1__kpYrgPKbicUbj2rBPjy9qDgSvuLra9cM6kL4=.79d7bb17-ac9e-470b-9249-5146dff5db4a@github.com>
Message-ID: <rLCboIQ_Gj1PrXq6qlc8tZI1TTiqsk9FDH9qTGcaQqc=.6889410b-b3cf-4698-9915-5473d0f22b60@github.com>

On Tue, 7 Mar 2023 00:00:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> would it be possible to update the JBS ticket with a valid code example?
>
> That would be very helpful.

Oh, I didn't notice that I did upload the wrong file.
I've now uploaded the correct test application!

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From fkirmaier at openjdk.org  Tue Mar  7 12:05:35 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 7 Mar 2023 12:05:35 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
Message-ID: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>

When an exception is logged in JavaFX, then the exception is kept in a reference.
This way, always the last logged exception is retained.

This is a memory-leak.
This was done to write unit-tests to ensure certain error-cases are logged.

A simple fix is, to add a flag, to enable/disable retaining the exception.

-------------

Commit messages:
 - JDK-8303740

Changes: https://git.openjdk.org/jfx/pull/1053/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303740
  Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1053.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1053/head:pull/1053

PR: https://git.openjdk.org/jfx/pull/1053

From john.hendrikx at gmail.com  Tue Mar  7 12:44:04 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 7 Mar 2023 13:44:04 +0100
Subject: Promote addEventHandler/removeEventHandler to EventTarget
 interface
In-Reply-To: <f734637c-6768-9352-d10a-fe2b2a396e4a@gmail.com>
References: <CAJEpuXT+rfh4yWR_snjiNmR-2fFO83UtMmFtiYro4-_sufAjrg@mail.gmail.com>
 <f734637c-6768-9352-d10a-fe2b2a396e4a@gmail.com>
Message-ID: <ac18d677-fe12-38f1-ed8f-d1c412126362@gmail.com>

Hi Michael,


Did you file a JIRA issue for this one?

I've recently also been doing some rewriting to use the Event system 
more.? I'm removing custom Scene walking code (and looking at 
Node.getProperties) to do "event handling", and I've now discovered that 
it could be done quite a bit nicer by using the provided event mechanism.

I've encountered a few things that annoy me about the event system:

1) I'm making use of Presentation classes (Models) that only associate 
with things in javafx.base (Event, EventTarget, Properties). These 
presentations need to register event handlers at some point, but this 
can only be done on Nodes; having this logic close to the Presentation 
code makes sense, but it would make them dependent on javafx.graphics; 
if I could do this via EventTarget, the dependency would not be needed.

2) When you fire an event (via Node.fireEvent for example), there is no 
feedback you can obtain whether the event was consumed or not as the 
final event is not returned to check `isConsumed` on (internal calls do 
have this information, but it is not exposed at the last step).

3) Related to 2), I think EventTarget could also have a method to 
dispatch events (so you can dispatch an event easily to any target, not 
just via the convenience method Node#fireEvent).? See this ticket: 
https://bugs.openjdk.org/browse/JDK-8303209

Perhaps we can work together on this, or if you're not currently working 
on it I could take a stab at solving all of these issues.

--John
On 07/03/2023 10:24, John Hendrikx wrote:
> Hi Michael,
>
> Did you file a JIRA issue for this one?
>
> I've recently also been doing some rewriting to use the Event system 
> more.? I'm removing custom Scene walking code (and looking at 
> Node.getProperties) to do "event handling", and I've now discovered 
> that it could be done quite a bit nicer by using the provided event 
> mechanism.
>
> I've encountered a few things that annoy me about the event system:
>
> 1) I'm making use of Presentation classes (Models) that only associate 
> with things in javafx.base (Event, EventTarget, Properties). These 
> presentations need to register event handlers at some point, but this 
> can only be done on Nodes; having this logic close to the Presentation 
> code makes sense, but it would make them dependent on javafx.graphics; 
> if I could do this via EventTarget, the dependency would not be needed.
>
> 2) When you fire an event (via Node.fireEvent for example), there is 
> no feedback you can obtain whether the event was consumed or not as 
> the final event is not returned to check `isConsumed` on (internal 
> calls do have this information, but it is not exposed at the last step).
>
> 3) Related to 2), I think EventTarget could also have a method to 
> dispatch events (so you can dispatch an event easily to any target, 
> not just via the convenience method Node#fireEvent).? See this ticket: 
> https://bugs.openjdk.org/browse/JDK-8303209
>
> Perhaps we can work together on this, or if you're not currently 
> working on it I could take a stab at solving all of these issues.
>
> --John
>
> On 17/03/2022 21:01, Michael Strau? wrote:
>> I'm working on an application that uses the JavaFX event system
>> extensively, and I'm finding it quite hard to use common code for
>> event handler registrations.
>>
>> The problem is that the `EventTarget` interface contains no
>> addEventHandler/removeEventHandler methods, and as a consequence of
>> that, code that uses `EventTarget` ends up requiring lots of brittle
>> instanceof tests to call these methods on all the different
>> implementations of `EventTarget`.
>>
>> There are three buckets of `EventTarget` implementations:
>>
>> 1) Implementations that declare the following methods:
>> ???? <T extends Event> void addEventHandler(EventType<T>,
>> EventHandler<? super T>);
>> ???? <T extends Event> void removeEventHandler(EventType<T>,
>> EventHandler<? super T>);
>> ???? <T extends Event> void addEventFilter(EventType<T>, EventHandler<?
>> super T>);
>> ???? <T extends Event> void removeEventFilter(EventType<T>,
>> EventHandler<? super T>);
>> --> Node, Scene, Window, Transform, Task, Service
>>
>> 2) Implementations that declare the following methods:
>> ???? <T extends Event> void addEventHandler(EventType<T>, 
>> EventHandler<T>);
>> ???? <T extends Event> void removeEventHandler(EventType<T>, 
>> EventHandler<T>);
>> --> MenuItem, TreeItem, TableColumnBase
>>
>> (Note that the EventHandler argument ist parameterized as
>> EventHandler<T>, not EventHandler<? super T> as in the first set of
>> methods.)
>>
>> 3) Implementations that don't declare any methods to add or remove
>> event handlers:
>> --> Dialog, Tab
>>
>>
>> I think the situation can be improved by promoting the bucket 1
>> methods to the `EventTarget` interface, so they can be used
>> consistently across all implementations of `EventTarget`.
>>
>> This works seamlessly for bucket 1 and bucket 3 implementations.
>>
>> With bucket 2, there's the problem that, inconsistently, the
>> EventHandler<T> argument is not a lower-bounded wildcard.
>> Unfortunately, a method with an EventHandler<T> parameter cannot
>> implement an interface method that expects EventHandler<? super T>.
>>
>> However, since the erasure of the method remains the same, changing
>> the method signature would technically be a binary-compatible change.
>>
>> Do you think this is a useful improvement?

From jhendrikx at openjdk.org  Tue Mar  7 13:22:10 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 7 Mar 2023 13:22:10 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <uVJDWUaxZpa7WsbwR6Lozd781QcW1dAexVpODENOMQk=.5142cc5b-c6ca-498f-84fc-a92df90c6a10@github.com>

On Tue, 7 Mar 2023 11:59:20 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

Well...  I'm quite surprised to see code testing for log messages -- its a very bad practice.  The side effects should be testable with or without the message (ie, if something throws NPE, the old value is restored or not modified, etc).  I doubt the log messages are part of any contract that JavaFX specifies.  But anyway...

I noticed though that the `check` method only checks the class, yet the entire exception is stored.  Storing only the class would also alleviate this issue, although it could still prevent class unloading then.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From fkirmaier at openjdk.org  Tue Mar  7 13:35:25 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Tue, 7 Mar 2023 13:35:25 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <0mcF9dowbEVBXUHar8Q3UCqgk0NVz4belh7UcY8I398=.1d28259d-369c-4bb8-b915-7174c8b4ee7f@github.com>

On Tue, 7 Mar 2023 11:59:20 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

Storing the class is, in my opinion also wrong.
Especially OSGI and other multi-classloader environments suffer from this issue. 

IMO it's okay to test things this way - but I guess that doesn't matter because I only want to fix this big.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From kcr at openjdk.org  Tue Mar  7 13:36:40 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 13:36:40 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v7]
In-Reply-To: <yGtTQCGMady0MC-JrCFlE8zhf1xnlrp3bYdAWb6kGII=.9e8cd6b9-3495-4805-bf36-226f15c52b61@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <L4wU2O54gtNcYsGxvVIMkLfnZKKawzWJAp5DugB5JoM=.8336a750-32b5-4995-b52c-9d053a5dcec9@github.com>
 <3Zb344ZZ5wyQ6pgZPIJT8Bm7Lsl2zJFmujceE9kSrCU=.9a563971-601f-4966-b4ce-276d3b2713c5@github.com>
 <yGtTQCGMady0MC-JrCFlE8zhf1xnlrp3bYdAWb6kGII=.9e8cd6b9-3495-4805-bf36-226f15c52b61@github.com>
Message-ID: <8bY9YV9S8ycMIGYO58O4nHeiWqVYhfpE9dXzS23ngAU=.839830c3-8058-4c6e-a5cc-d42e9714d551@github.com>

On Tue, 7 Mar 2023 07:18:07 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/scene/ChoiceBoxScrollUpOnCollectionChangeTest.java line 144:
>> 
>>> 142:         double rowHeight = ContextMenuContentShim.getContextMenuRowHeight(popup);
>>> 143:         double screenHeight = Screen.getPrimary().getBounds().getHeight();
>>> 144:         scrollChoiceBox((int) (screenHeight / rowHeight));
>> 
>> This seems to work, but it might be more robust to use `Math.ceil()` before casting to int, especially if you make the change to use the visual bounds.
>
> Updated code to use `Math.ceil()`

The `Math.ceil` is in the wrong place. It's the result of the division that will generate the fractional result that needs it:


        double screenHeight = Screen.getPrimary().getVisualBounds().getHeight();
        scrollChoiceBox((int) Math.ceil(screenHeight / rowHeight));

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Tue Mar  7 14:09:38 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 7 Mar 2023 14:09:38 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v9]
In-Reply-To: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
Message-ID: <sNya5Sb-ec5lpqramWfXgteUfUK53j8ALJK_sBhSNN8=.bc1c41b2-bf2d-44fe-b71c-b5904b7b5438@github.com>

> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
> 
> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
> 
> Added system test to validate the fix.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1039/files
  - new: https://git.openjdk.org/jfx/pull/1039/files/18b8d74a..492e7708

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1039&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1039&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1039.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1039/head:pull/1039

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Tue Mar  7 14:09:41 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 7 Mar 2023 14:09:41 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v7]
In-Reply-To: <8bY9YV9S8ycMIGYO58O4nHeiWqVYhfpE9dXzS23ngAU=.839830c3-8058-4c6e-a5cc-d42e9714d551@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <L4wU2O54gtNcYsGxvVIMkLfnZKKawzWJAp5DugB5JoM=.8336a750-32b5-4995-b52c-9d053a5dcec9@github.com>
 <3Zb344ZZ5wyQ6pgZPIJT8Bm7Lsl2zJFmujceE9kSrCU=.9a563971-601f-4966-b4ce-276d3b2713c5@github.com>
 <yGtTQCGMady0MC-JrCFlE8zhf1xnlrp3bYdAWb6kGII=.9e8cd6b9-3495-4805-bf36-226f15c52b61@github.com>
 <8bY9YV9S8ycMIGYO58O4nHeiWqVYhfpE9dXzS23ngAU=.839830c3-8058-4c6e-a5cc-d42e9714d551@github.com>
Message-ID: <72axGeiT9adq92NM4O6ybzySPvg_W5If4_pt6WhW4IU=.7681576d-2963-422e-a90f-5d79b5bf8264@github.com>

On Tue, 7 Mar 2023 13:33:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Updated code to use `Math.ceil()`
>
> The `Math.ceil` is in the wrong place. It's the result of the division that will generate the fractional result that needs it:
> 
> 
>         double screenHeight = Screen.getPrimary().getVisualBounds().getHeight();
>         scrollChoiceBox((int) Math.ceil(screenHeight / rowHeight));

Updated code to use `Math.ceil` for the result of division. Please check.

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kcr at openjdk.org  Tue Mar  7 14:16:48 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 14:16:48 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v9]
In-Reply-To: <sNya5Sb-ec5lpqramWfXgteUfUK53j8ALJK_sBhSNN8=.bc1c41b2-bf2d-44fe-b71c-b5904b7b5438@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <sNya5Sb-ec5lpqramWfXgteUfUK53j8ALJK_sBhSNN8=.bc1c41b2-bf2d-44fe-b71c-b5904b7b5438@github.com>
Message-ID: <6xUajoGEoJZP_NSM7VWsQaGArI1rFhlOvmOOOoDUsYM=.28851d81-24e2-4510-9c17-9a35c33f9bcb@github.com>

On Tue, 7 Mar 2023 14:09:38 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
>> 
>> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
>> 
>> Added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1039

From kcr at openjdk.org  Tue Mar  7 14:27:42 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 14:27:42 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v6]
In-Reply-To: <MIqgBmu4OOd6WTaHwPmUpM31kGrLBR0JL6c8R1W0U2o=.f07dd359-574f-4f64-9b24-0ba5be7ad020@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <O_LrSOLpXLOwQb-x-rzU0jKRgI7BA8WDMVzUIPYVA24=.9c831743-b10d-45d7-8c9e-a336db25b19b@github.com>
 <MIqgBmu4OOd6WTaHwPmUpM31kGrLBR0JL6c8R1W0U2o=.f07dd359-574f-4f64-9b24-0ba5be7ad020@github.com>
Message-ID: <xP2DF8Fn012AkvY1ZWXfDJmBRvtt6DQKLFBQRVD44LM=.75970767-3bda-473f-8121-6f5a0317f801@github.com>

On Thu, 23 Feb 2023 17:48:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> Noticed a minor behavior issue, on Mac with multiple monitors.  The secondary monitor (scale=1) is positioned above the primary retina screen (scale=2).  When showing a popup in the case of 100 elements, the down arrow at the bottom cannot be seen.
> 
> In the attached screenshot, one can see the popup clipped at the secondary monitor bottom edge, the gray bar is the top of the primary screen:
> 
> ![Screenshot 2023-02-23 at 09 44 11](https://user-images.githubusercontent.com/107069028/220988460-2939820c-108a-4000-9bf9-fc9145dfd68a.png)
> 
> Perhaps the wrong Screen is used in computation, or not accounting for getVisualBounds()?
> 
> Since this control is designed to work with a few items, I'd suggest addressing this issue in a separate PR.  Karthik, would you please create a new bug?

@andy-goryachev-oracle can you re-review?

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kevin.rushforth at oracle.com  Tue Mar  7 14:34:51 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 7 Mar 2023 06:34:51 -0800
Subject: Promote addEventHandler/removeEventHandler to EventTarget
 interface
In-Reply-To: <f734637c-6768-9352-d10a-fe2b2a396e4a@gmail.com>
References: <CAJEpuXT+rfh4yWR_snjiNmR-2fFO83UtMmFtiYro4-_sufAjrg@mail.gmail.com>
 <f734637c-6768-9352-d10a-fe2b2a396e4a@gmail.com>
Message-ID: <d79e96c0-5e92-86d4-4a17-46e8845637b6@oracle.com>

An incompatible change in a fundamental interface such as EventTarget is 
not something we would want to do, so any proposed changes will need to 
retain compatibility (both binary and source). At a minimum, this means 
that any newly added methods would need to have a default 
implementation, and we would need to look closely at other aspects of 
compatibility.

-- Kevin


On 3/7/2023 1:24 AM, John Hendrikx wrote:
> Hi Michael,
>
> Did you file a JIRA issue for this one?
>
> I've recently also been doing some rewriting to use the Event system 
> more.? I'm removing custom Scene walking code (and looking at 
> Node.getProperties) to do "event handling", and I've now discovered 
> that it could be done quite a bit nicer by using the provided event 
> mechanism.
>
> I've encountered a few things that annoy me about the event system:
>
> 1) I'm making use of Presentation classes (Models) that only associate 
> with things in javafx.base (Event, EventTarget, Properties). These 
> presentations need to register event handlers at some point, but this 
> can only be done on Nodes; having this logic close to the Presentation 
> code makes sense, but it would make them dependent on javafx.graphics; 
> if I could do this via EventTarget, the dependency would not be needed.
>
> 2) When you fire an event (via Node.fireEvent for example), there is 
> no feedback you can obtain whether the event was consumed or not as 
> the final event is not returned to check `isConsumed` on (internal 
> calls do have this information, but it is not exposed at the last step).
>
> 3) Related to 2), I think EventTarget could also have a method to 
> dispatch events (so you can dispatch an event easily to any target, 
> not just via the convenience method Node#fireEvent).? See this ticket: 
> https://bugs.openjdk.org/browse/JDK-8303209
>
> Perhaps we can work together on this, or if you're not currently 
> working on it I could take a stab at solving all of these issues.
>
> --John
>
> On 17/03/2022 21:01, Michael Strau? wrote:
>> I'm working on an application that uses the JavaFX event system
>> extensively, and I'm finding it quite hard to use common code for
>> event handler registrations.
>>
>> The problem is that the `EventTarget` interface contains no
>> addEventHandler/removeEventHandler methods, and as a consequence of
>> that, code that uses `EventTarget` ends up requiring lots of brittle
>> instanceof tests to call these methods on all the different
>> implementations of `EventTarget`.
>>
>> There are three buckets of `EventTarget` implementations:
>>
>> 1) Implementations that declare the following methods:
>> ???? <T extends Event> void addEventHandler(EventType<T>,
>> EventHandler<? super T>);
>> ???? <T extends Event> void removeEventHandler(EventType<T>,
>> EventHandler<? super T>);
>> ???? <T extends Event> void addEventFilter(EventType<T>, EventHandler<?
>> super T>);
>> ???? <T extends Event> void removeEventFilter(EventType<T>,
>> EventHandler<? super T>);
>> --> Node, Scene, Window, Transform, Task, Service
>>
>> 2) Implementations that declare the following methods:
>> ???? <T extends Event> void addEventHandler(EventType<T>, 
>> EventHandler<T>);
>> ???? <T extends Event> void removeEventHandler(EventType<T>, 
>> EventHandler<T>);
>> --> MenuItem, TreeItem, TableColumnBase
>>
>> (Note that the EventHandler argument ist parameterized as
>> EventHandler<T>, not EventHandler<? super T> as in the first set of
>> methods.)
>>
>> 3) Implementations that don't declare any methods to add or remove
>> event handlers:
>> --> Dialog, Tab
>>
>>
>> I think the situation can be improved by promoting the bucket 1
>> methods to the `EventTarget` interface, so they can be used
>> consistently across all implementations of `EventTarget`.
>>
>> This works seamlessly for bucket 1 and bucket 3 implementations.
>>
>> With bucket 2, there's the problem that, inconsistently, the
>> EventHandler<T> argument is not a lower-bounded wildcard.
>> Unfortunately, a method with an EventHandler<T> parameter cannot
>> implement an interface method that expects EventHandler<? super T>.
>>
>> However, since the erasure of the method remains the same, changing
>> the method signature would technically be a binary-compatible change.
>>
>> Do you think this is a useful improvement?


From lkostyra at openjdk.org  Tue Mar  7 14:42:46 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 7 Mar 2023 14:42:46 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue with
 uiScale > 1.0
Message-ID: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>

Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.

Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.

In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.

Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.

-------------

Commit messages:
 - SetSceneScalingTest: Properly time test elements
 - Add test for various setScene-show interactions
 - Fetch View's size after it has a valid Window ptr

Changes: https://git.openjdk.org/jfx/pull/1054/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299968
  Stats: 250 lines in 8 files changed: 247 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1054.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1054/head:pull/1054

PR: https://git.openjdk.org/jfx/pull/1054

From kcr at openjdk.org  Tue Mar  7 14:42:46 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 14:42:46 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0
In-Reply-To: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
Message-ID: <YurKo4rUHyPyKeq16t4JgsMsSnl0J56M4GwV8I247WI=.1c44810e-dfc6-41e6-939c-b3a2f8040c5e@github.com>

On Tue, 7 Mar 2023 14:33:33 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
> 
> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
> 
> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
> 
> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.

I'll test and review it. One quick comment: since the newly-added system test uses Robot, the test class will need to move under the `test.robot` hierarchy so it will be correctly excluded unless `-PUSE_ROBOT=true`.

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From pedro.duquevieira at gmail.com  Tue Mar  7 15:04:42 2023
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 7 Mar 2023 15:04:42 +0000
Subject: Integrated: JDK-8090647: Mnemonics : on windows we should cancel the
 underscore latch when an app loses focus.
Message-ID: <CAAEud6ZxBPPqnTSrD+_Qut+FFASeynuQ8SwvbvbjwSAimCAP1w@mail.gmail.com>

Hi,

It's been a while (I've been on vacation, etc) but thank you very much for
fixing this issue on such short notice!

Thanks again, kind regards,

-- 
Pedro Duque Vieira - https://www.pixelduke.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230307/64f1b15e/attachment.htm>

From lkostyra at openjdk.org  Tue Mar  7 15:20:50 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 7 Mar 2023 15:20:50 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v2]
In-Reply-To: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
Message-ID: <O210SwrmFs5MKn93HBKf7k0EOZ_PModbOe2-BwzkEf4=.239647cc-e5f3-4c3e-8163-3871a10bf204@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
> 
> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
> 
> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
> 
> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.

Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:

  Move SetSceneScalingTest to robot test directory

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1054/files
  - new: https://git.openjdk.org/jfx/pull/1054/files/396d38e5..ad2ccb02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1054.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1054/head:pull/1054

PR: https://git.openjdk.org/jfx/pull/1054

From lkostyra at openjdk.org  Tue Mar  7 15:20:53 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 7 Mar 2023 15:20:53 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0
In-Reply-To: <YurKo4rUHyPyKeq16t4JgsMsSnl0J56M4GwV8I247WI=.1c44810e-dfc6-41e6-939c-b3a2f8040c5e@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <YurKo4rUHyPyKeq16t4JgsMsSnl0J56M4GwV8I247WI=.1c44810e-dfc6-41e6-939c-b3a2f8040c5e@github.com>
Message-ID: <p6-yNitmUmEus1YCMm1HknqRhpUkB2mfsNGWPE2WaZQ=.7f120ccf-978b-48c6-8009-116b4093ccd9@github.com>

On Tue, 7 Mar 2023 14:39:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> I'll test and review it. One quick comment: since the newly-added system test uses Robot, the test class will need to move under the `test.robot` hierarchy so it will be correctly excluded unless `-PUSE_ROBOT=true`.

@kevinrushforth my mistake, should be good now!

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From kcr at openjdk.org  Tue Mar  7 15:58:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 7 Mar 2023 15:58:33 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <P4plSEg9O8NFfWpTyFDfgp3JrlfgAPx1wDIfZvkkJBk=.100a2299-fb51-4357-a817-dbf79dc50625@github.com>

On Tue, 7 Mar 2023 11:59:20 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

While the fix is probably OK, and would fix the leak, another possibility might be to store the name of the exception class (not the class itself) and check that.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From angorya at openjdk.org  Tue Mar  7 17:01:38 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Mar 2023 17:01:38 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v9]
In-Reply-To: <sNya5Sb-ec5lpqramWfXgteUfUK53j8ALJK_sBhSNN8=.bc1c41b2-bf2d-44fe-b71c-b5904b7b5438@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <sNya5Sb-ec5lpqramWfXgteUfUK53j8ALJK_sBhSNN8=.bc1c41b2-bf2d-44fe-b71c-b5904b7b5438@github.com>
Message-ID: <WpYLI0pEKhNMczMyDf1gH7tjlSqAWMLKV7_Yo_qDqV4=.97f61735-1d90-4fab-ad06-018e440ccd66@github.com>

On Tue, 7 Mar 2023 14:09:38 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
>> 
>> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
>> 
>> Added system test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by angorya (Committer).

This PR looks good.  We can address [JDK-8303060](https://bugs.openjdk.org/browse/JDK-8303060) and [JDK-8303064](https://bugs.openjdk.org/browse/JDK-8303064) separately.

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Tue Mar  7 17:10:48 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 7 Mar 2023 17:10:48 GMT
Subject: RFR: 8090123: Items are no longer visible when collection is
 changed [v6]
In-Reply-To: <xP2DF8Fn012AkvY1ZWXfDJmBRvtt6DQKLFBQRVD44LM=.75970767-3bda-473f-8121-6f5a0317f801@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
 <O_LrSOLpXLOwQb-x-rzU0jKRgI7BA8WDMVzUIPYVA24=.9c831743-b10d-45d7-8c9e-a336db25b19b@github.com>
 <MIqgBmu4OOd6WTaHwPmUpM31kGrLBR0JL6c8R1W0U2o=.f07dd359-574f-4f64-9b24-0ba5be7ad020@github.com>
 <xP2DF8Fn012AkvY1ZWXfDJmBRvtt6DQKLFBQRVD44LM=.75970767-3bda-473f-8121-6f5a0317f801@github.com>
Message-ID: <yMe0R6KMV1Uf59ZtOIz1DQX6wzd0btQvuzmS8aXUZeg=.0201a734-09d0-41b5-8617-a7114195a595@github.com>

On Tue, 7 Mar 2023 14:24:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Noticed a minor behavior issue, on Mac with multiple monitors.  The secondary monitor (scale=1) is positioned above the primary retina screen (scale=2).  When showing a popup in the case of 100 elements, the down arrow at the bottom cannot be seen.
>> 
>> In the attached screenshot, one can see the popup clipped at the secondary monitor bottom edge, the gray bar is the top of the primary screen:
>> 
>> ![Screenshot 2023-02-23 at 09 44 11](https://user-images.githubusercontent.com/107069028/220988460-2939820c-108a-4000-9bf9-fc9145dfd68a.png)
>> 
>> Perhaps the wrong Screen is used in computation, or not accounting for getVisualBounds()?
>> 
>> Since this control is designed to work with a few items, I'd suggest addressing this issue in a separate PR.  Karthik, would you please create a new bug?
>
> @andy-goryachev-oracle can you re-review?

@kevinrushforth / @andy-goryachev-oracle  could you please sponsor the PR?

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From kpk at openjdk.org  Tue Mar  7 17:19:51 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 7 Mar 2023 17:19:51 GMT
Subject: Integrated: 8090123: Items are no longer visible when collection is
 changed
In-Reply-To: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
References: <xxwcseBLKk9agND5ZyuN5cbLf_nGJnIX9T0ONYkikWY=.bede4f32-4642-4e2b-90f2-f9ef29f334f0@github.com>
Message-ID: <Cs6lhqvYwL0sqSKLXY2S34bTi99UTgUC2n6Z9_PFCI0=.b1cc8655-9a56-4a64-b2bd-f924aa2dc5a5@github.com>

On Fri, 17 Feb 2023 12:33:31 GMT, Karthik P K <kpk at openjdk.org> wrote:

> When a large number of items were scrolled in the `ChoiceBox`, the scrolled offset was carried forward when the list is replaced with small number of items. Hence the scroll up arrow was displayed with empty popup.
> 
> Changed code to scroll to top before popup display when content height of `ChoiceBox` is smaller than the scrolled offset.
> 
> Added system test to validate the fix.

This pull request has now been integrated.

Changeset: 4178ad72
Author:    Karthik P K <kpk at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4178ad72c356ce8bd8fca95ee4dd22987a3b175a
Stats:     226 lines in 3 files changed: 226 ins; 0 del; 0 mod

8090123: Items are no longer visible when collection is changed

Reviewed-by: angorya, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1039

From prr at openjdk.org  Tue Mar  7 20:00:22 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Mar 2023 20:00:22 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in TextRun.getWrapIndex()
Message-ID: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>

This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.

The fix uses a different method to choose a break point.

A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.

-------------

Commit messages:
 - 8302797

Changes: https://git.openjdk.org/jfx/pull/1055/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1055&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302797
  Stats: 221 lines in 2 files changed: 214 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1055.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1055/head:pull/1055

PR: https://git.openjdk.org/jfx/pull/1055

From angorya at openjdk.org  Tue Mar  7 20:32:09 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 7 Mar 2023 20:32:09 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex()
In-Reply-To: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
Message-ID: <om1SsyAtOOoMcYNtVjsx4Xt9GkJlDXI8CX-3zC0Ky-Y=.04e821a3-0d3f-4892-847a-4aac946b3e91@github.com>

On Tue, 7 Mar 2023 19:54:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
> 
> The fix uses a different method to choose a break point.
> 
> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.

Changes requested by angorya (Committer).

The fix introduces another problem, affecting the wrapping of RTL text.  To see the issue, use a TextFlow page in the monkey tester with a RTL text (or simply place a TextFlow in a SplitPane and reduce the width of the TextFlow.

LTR script seems unaffected.

master branch - wrapping is correct:
![Screenshot 2023-03-07 at 12 25 01](https://user-images.githubusercontent.com/107069028/223544592-30a70460-aece-4d82-8df8-0dfc4e3824ba.png)

the fix branch - wrapping leaves one character per line:
![Screenshot 2023-03-07 at 12 25 22](https://user-images.githubusercontent.com/107069028/223544760-ce4ee1b7-557d-4e2e-8a0d-bc77fca850b4.png)

modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 288:

> 286:              */
> 287:             /* Not need to check for compact as bidi disables the simple case */
> 288:             for (int gi = glyphCount; gi <= 0; gi--) {

should we also correct the comment on line 288?

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From prr at openjdk.org  Tue Mar  7 21:31:52 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Mar 2023 21:31:52 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex()
In-Reply-To: <om1SsyAtOOoMcYNtVjsx4Xt9GkJlDXI8CX-3zC0Ky-Y=.04e821a3-0d3f-4892-847a-4aac946b3e91@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <om1SsyAtOOoMcYNtVjsx4Xt9GkJlDXI8CX-3zC0Ky-Y=.04e821a3-0d3f-4892-847a-4aac946b3e91@github.com>
Message-ID: <kYj18A3TK9lBd5q8q4R7qujC62qwYItK2gdg6AJAnoo=.c526dd79-6a8c-4428-ba2a-c0eb1afb85ee@github.com>

On Tue, 7 Mar 2023 20:18:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 288:
> 
>> 286:              */
>> 287:             /* Not need to check for compact as bidi disables the simple case */
>> 288:             for (int gi = glyphCount; gi <= 0; gi--) {
> 
> should we also correct the comment on line 288?

oops. I think I see the problem.
And I had noticed the typo in the existing comment and can correct that ..

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From prr at openjdk.org  Tue Mar  7 22:03:12 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Mar 2023 22:03:12 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
Message-ID: <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>

> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
> 
> The fix uses a different method to choose a break point.
> 
> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8302797

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1055/files
  - new: https://git.openjdk.org/jfx/pull/1055/files/e9925237..ba0f28dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1055&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1055&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1055.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1055/head:pull/1055

PR: https://git.openjdk.org/jfx/pull/1055

From prr at openjdk.org  Tue Mar  7 22:03:16 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Mar 2023 22:03:16 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <kYj18A3TK9lBd5q8q4R7qujC62qwYItK2gdg6AJAnoo=.c526dd79-6a8c-4428-ba2a-c0eb1afb85ee@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <om1SsyAtOOoMcYNtVjsx4Xt9GkJlDXI8CX-3zC0Ky-Y=.04e821a3-0d3f-4892-847a-4aac946b3e91@github.com>
 <kYj18A3TK9lBd5q8q4R7qujC62qwYItK2gdg6AJAnoo=.c526dd79-6a8c-4428-ba2a-c0eb1afb85ee@github.com>
Message-ID: <FrASiIjwpEBV-uEI7uvf8ddQYjAvyK5hqU28T5z28kY=.5cf78c15-63a6-468d-bb0b-5773dbab1918@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 21:29:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 288:
>> 
>>> 286:              */
>>> 287:             /* Not need to check for compact as bidi disables the simple case */
>>> 288:             for (int gi = glyphCount; gi <= 0; gi--) {
>> 
>> should we also correct the comment on line 288?
>
> oops. I think I see the problem.
> And I had noticed the typo in the existing comment and can correct that ..

Updated to look at the right segment !

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From angorya at openjdk.org  Wed Mar  8 00:31:17 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Mar 2023 00:31:17 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
Message-ID: <E5rhcoRkCqTU9xgA-ERayxghljDHn0waQt3rivDYQzo=.c6dcf6d8-c4d1-412b-8017-7a5684d14e0e@github.com>

On Tue, 7 Mar 2023 22:03:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302797

works in monkey tester - wraps correctly, throws no  exceptions.

-------------

Marked as reviewed by angorya (Committer).

PR: https://git.openjdk.org/jfx/pull/1055

From fkirmaier at openjdk.org  Wed Mar  8 07:56:17 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 8 Mar 2023 07:56:17 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <_L0X5if-PuUhNqNlHCZBKS5RIxFDyGZ28eqDVlG6D0c=.4c52ea38-cf44-4ed3-b712-c0305bf10a80@github.com>

On Tue, 7 Mar 2023 11:59:20 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

I think it's cleaner, to just have nothing in production.
The flag is a bit ugly - just aesthetically, but I don't think it's a problem.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From jhendrikx at openjdk.org  Wed Mar  8 08:22:44 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 8 Mar 2023 08:22:44 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <_L0X5if-PuUhNqNlHCZBKS5RIxFDyGZ28eqDVlG6D0c=.4c52ea38-cf44-4ed3-b712-c0305bf10a80@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
 <_L0X5if-PuUhNqNlHCZBKS5RIxFDyGZ28eqDVlG6D0c=.4c52ea38-cf44-4ed3-b712-c0305bf10a80@github.com>
Message-ID: <JhoQsTI5mw9b9NVa9PH3-Nrf8RAQ2M6p5IRBX5ddaZw=.2ada8b48-86d8-4a09-93bf-7926d73b2f5d@github.com>

On Wed, 8 Mar 2023 07:53:22 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> I think it's cleaner, to just have nothing in production. The flag is a bit ugly - just aesthetically, but I don't think it's a problem.

IMHO, the `Logging` class should also not be there, as it is just a facade for `PlatformLogger` specifically there for these tests.

The tests took the easy way out here to test for log messages by modifying production code to use a different logger (and introducing a leak by doing so). An alternative would be to install a `LoggerFinder` only when tests run, and allow this to be inspected.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From fkirmaier at openjdk.org  Wed Mar  8 09:56:15 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 8 Mar 2023 09:56:15 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <JhoQsTI5mw9b9NVa9PH3-Nrf8RAQ2M6p5IRBX5ddaZw=.2ada8b48-86d8-4a09-93bf-7926d73b2f5d@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
 <_L0X5if-PuUhNqNlHCZBKS5RIxFDyGZ28eqDVlG6D0c=.4c52ea38-cf44-4ed3-b712-c0305bf10a80@github.com>
 <JhoQsTI5mw9b9NVa9PH3-Nrf8RAQ2M6p5IRBX5ddaZw=.2ada8b48-86d8-4a09-93bf-7926d73b2f5d@github.com>
Message-ID: <T716i-EUOiU9tXOr1H2fkuQ__x1Zden_xMsTXhMxuLY=.8529b07e-9813-43db-b0d5-5892d706cef6@github.com>

On Wed, 8 Mar 2023 08:19:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I think it's cleaner, to just have nothing in production.
>> The flag is a bit ugly - just aesthetically, but I don't think it's a problem.
>
>> I think it's cleaner, to just have nothing in production. The flag is a bit ugly - just aesthetically, but I don't think it's a problem.
> 
> IMHO, the `Logging` class should also not be there, as it is just a facade for `PlatformLogger` specifically there for these tests.
> 
> The tests took the easy way out here to test for log messages by modifying production code to use a different logger (and introducing a leak by doing so). An alternative would be to install a `LoggerFinder` only when tests run, and allow this to be inspected.

@hjohn 
You are right, this would be the correct solution.
I guess that would require more changes than my PR.
I don't plan to do it, I also don't know how to do it.
So, this PR would still provide a quick fix for the bug.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From Marc.Toni at vector.com  Wed Mar  8 11:30:48 2023
From: Marc.Toni at vector.com (Toni, Marc)
Date: Wed, 8 Mar 2023 11:30:48 +0000
Subject: Allow to extend NumberAxis
Message-ID: <AM0PR01MB470668918959C7A14942AAB683B49@AM0PR01MB4706.eurprd01.prod.exchangelabs.com>

Hi All,

There is an open Enhancement issue (https://bugs.openjdk.org/browse/JDK-8090467), back from 2011, to allow extending from the NumberAxis class.

We (at Vector Germany) want to extend from NumberAxis to overwrite the implementations of "calculateTickValues" and "calculateMinorTickMarks" for better tick marks depending on the tick unit.
For testing purposes, we copied the implementation of NumberAxis and refactored the two methods. But due to licensing issues, we must not use this approach.

Is there any good reason not to remove the "final" modifier from the class definition? We would like to have this change ASAP.

Best regards,

Marc Toni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230308/17884b8c/attachment.htm>

From aghaisas at openjdk.org  Wed Mar  8 12:12:21 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 8 Mar 2023 12:12:21 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
Message-ID: <ee-uQTvPlMqix0J3RHHAuRVi1g7EgzQpYRi2imz5MQM=.75ff0707-e620-4f62-ac1a-66cff733182c@github.com>

On Tue, 7 Mar 2023 22:03:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302797

The fix looks good.
I verified on macOS Ventura 13.1 that the test fails without this fix and passes with it.

Have you run this test on other platforms?

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From kcr at openjdk.org  Wed Mar  8 12:48:22 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Mar 2023 12:48:22 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
Message-ID: <YPG4YnZF3fgI_xvLbRuTnPNOOTfy_irEROFm8FuBgRQ=.bfc85a76-2010-44db-ac2e-615203458312@github.com>

On Tue, 7 Mar 2023 22:03:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302797

The fix looks fine. I left a few comments on the test.

tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 46:

> 44: import java.util.TimerTask;
> 45: 
> 46: public class ArabicWrappingTest extends Application {

The main test class should not extend Application. See [JDK-8234876](https://bugs.openjdk.org/browse/JDK-8234876). Instead, create an static nested class that extends Application.

tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 83:

> 81:         System.setErr(systemErrFilter);
> 82:         new Thread(() -> {
> 83:             Application.launch(ArabicWrappingTest.class);

I recommend using the recently-added [Util.launch](https://github.com/openjdk/jfx/blob/ba0f28dc072605c1ccd30e2736d39b1fcb11c4cd/tests/system/src/test/java/test/util/Util.java#L319) utility method.

tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 89:

> 87:     @AfterClass
> 88:     public static void exitTest() {
> 89:         Platform.exit();

I recommend using the recently-added [Util.shutdown](https://github.com/openjdk/jfx/blob/ba0f28dc072605c1ccd30e2736d39b1fcb11c4cd/tests/system/src/test/java/test/util/Util.java#L380) utility method.

tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 95:

> 93:     static volatile boolean testPassed;
> 94: 
> 95:     @Test

Can you add a timeout value? That way if something goes wrong the test won't hang indefinitely. Something like:


    @Test (timeout=60000)

tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 150:

> 148:         stage.setTitle("Test bidi text wrapping");
> 149:         stage.setWidth(MAX_WW+50);
> 150:         stage.setHeight(600);

In connection with `Util.launch(startupLatch, ...)`, here is where you can add:


    stage.setOnShown(e -> Platform.runLater(startupLatch::countDown));

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From kcr at openjdk.org  Wed Mar  8 12:53:22 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Mar 2023 12:53:22 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <oWN_Iwg9zXQJmz3t-cKKL2KS5eclDW5gk6nYyCAwQrU=.7e2b5acb-80ee-4d41-9609-a5a6c0eb6457@github.com>

On Tue, 7 Mar 2023 11:59:20 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

Cleaning up the logging mechanism, while a good idea, is best done as a follow-up issue. Let's proceed with the currently proposed approach, or a similar minimally-intrusive solution for this leak.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From kevin.rushforth at oracle.com  Wed Mar  8 13:24:12 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 8 Mar 2023 05:24:12 -0800
Subject: Allow to extend NumberAxis
In-Reply-To: <AM0PR01MB470668918959C7A14942AAB683B49@AM0PR01MB4706.eurprd01.prod.exchangelabs.com>
References: <AM0PR01MB470668918959C7A14942AAB683B49@AM0PR01MB4706.eurprd01.prod.exchangelabs.com>
Message-ID: <e9ec5e92-bd2a-1d79-96b1-a9b7561c28c7@oracle.com>

Hi Marc,

 > Is there any good reason not to remove the ?final? modifier from the 
class definition?

Providing extensibility is not as simple as "removing the final 
modifier". This would be an API change that needs to be motivated and 
discussed just like any other API change. That discussion needs to 
include how this would benefit applications (not just yours), and also 
discuss how the extensibility should be added. All currently public 
methods need to be examined to see which ones would be made extensible, 
and which should be left as final (since all methods in a final class 
are implicitly final). The class docs and the docs for each non-final 
method will need to explain how it should be overridden and whether 
there any considerations for doing so.

If a good case can be made for making this class extensible, then we can 
discuss the proposed changes on this list. Please see the New features / 
API additions sections of the CONTRIBUTING guidelines [1] for what needs 
to happen.

 > We would like to have this change ASAP.

The earliest this change could show up would be in JavaFX 21, and that 
would only happen if someone was sufficiently motivated enough to do the 
work needed for the change, and if there is general agreement.

-- Kevin

[1] 
https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#new-features--api-additions


On 3/8/2023 3:30 AM, Toni, Marc wrote:
>
> Hi All,
>
> There is an open Enhancement issue 
> (https://bugs.openjdk.org/browse/JDK-8090467), back from 2011, to 
> allow extending from the NumberAxis class.
>
> We (at Vector Germany) want to extend from NumberAxis to overwrite the 
> implementations of ?calculateTickValues? and ?calculateMinorTickMarks? 
> for better tick marks depending on the tick unit.
>
> For testing purposes, we copied the implementation of NumberAxis and 
> refactored the two methods. But due to licensing issues, we must not 
> use this approach.
>
> Is there any good reason not to remove the ?final? modifier from the 
> class definition? We would like to have this change ASAP.
>
> Best regards,
>
> Marc Toni
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230308/ace13f92/attachment-0001.htm>

From kcr at openjdk.org  Wed Mar  8 14:50:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 8 Mar 2023 14:50:14 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v2]
In-Reply-To: <O210SwrmFs5MKn93HBKf7k0EOZ_PModbOe2-BwzkEf4=.239647cc-e5f3-4c3e-8163-3871a10bf204@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <O210SwrmFs5MKn93HBKf7k0EOZ_PModbOe2-BwzkEf4=.239647cc-e5f3-4c3e-8163-3871a10bf204@github.com>
Message-ID: <ykbX1I0sh6WZiAOF9tq_l0hF75D0zPHHoWL3zwQhNXQ=.a53c86fc-b9a8-4cb7-99dd-f2149a93532a@github.com>

On Tue, 7 Mar 2023 15:20:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SetSceneScalingTest to robot test directory

The fix looks good to me, although I want to test on a dual screen setup. I doubt there will be any difference in behavior, since the fix looks independent of the screen. I did leave one minor suggestion on a comment you added.

The test fails for me intermittently, which suggests that there is a timing issue. You will likely need to use a latch to wait for the button to be clicked (or a sleep of around 1/2 sec) rather than immediately testing `wasClicked`.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/Window.java line 374:

> 372:             this.view = view;
> 373:             this.view.setWindow(this);
> 374:             // JDK-8299968: View size update (especially notifyResize event) have to happen

Minor: we generally don't put a bug ID in comments in the implementation when fixing a bug.

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From prr at openjdk.org  Wed Mar  8 19:25:22 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Mar 2023 19:25:22 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <YPG4YnZF3fgI_xvLbRuTnPNOOTfy_irEROFm8FuBgRQ=.bfc85a76-2010-44db-ac2e-615203458312@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
 <YPG4YnZF3fgI_xvLbRuTnPNOOTfy_irEROFm8FuBgRQ=.bfc85a76-2010-44db-ac2e-615203458312@github.com>
Message-ID: <rzRV0WeFYv5-EMREOIoaxFUrj3hTMOrjMq5WnGRUprE=.9390c999-344e-45b1-acc8-4a6607280d8f@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 12:29:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8302797
>
> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 46:
> 
>> 44: import java.util.TimerTask;
>> 45: 
>> 46: public class ArabicWrappingTest extends Application {
> 
> The main test class should not extend Application. See [JDK-8234876](https://bugs.openjdk.org/browse/JDK-8234876). Instead, create an static nested class that extends Application.

My @Test does not depend on the instance that junit creates so I don't need to worry about this.
So it was deliberate. I will add a comment explaining this.

> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 83:
> 
>> 81:         System.setErr(systemErrFilter);
>> 82:         new Thread(() -> {
>> 83:             Application.launch(ArabicWrappingTest.class);
> 
> I recommend using the recently-added [Util.launch](https://github.com/openjdk/jfx/blob/ba0f28dc072605c1ccd30e2736d39b1fcb11c4cd/tests/system/src/test/java/test/util/Util.java#L319) utility method.

I looked at it but found it un-necessary and it means you need to understand that to use it
and your test is vulnerable to changes there.

> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 89:
> 
>> 87:     @AfterClass
>> 88:     public static void exitTest() {
>> 89:         Platform.exit();
> 
> I recommend using the recently-added [Util.shutdown](https://github.com/openjdk/jfx/blob/ba0f28dc072605c1ccd30e2736d39b1fcb11c4cd/tests/system/src/test/java/test/util/Util.java#L380) utility method.

Same as above.

> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 95:
> 
>> 93:     static volatile boolean testPassed;
>> 94: 
>> 95:     @Test
> 
> Can you add a timeout value? That way if something goes wrong the test won't hang indefinitely. Something like:
> 
> 
>     @Test (timeout=60000)

Will do. I actually had one in there .. but I was having some problems with @Test not being recognised and I removed it in case it was part of the problem. I will put it back.

> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 150:
> 
>> 148:         stage.setTitle("Test bidi text wrapping");
>> 149:         stage.setWidth(MAX_WW+50);
>> 150:         stage.setHeight(600);
> 
> In connection with `Util.launch(startupLatch, ...)`, here is where you can add:
> 
> 
>     stage.setOnShown(e -> Platform.runLater(startupLatch::countDown));

Because of the sleep loop in my test I don't need this.

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From prr at openjdk.org  Wed Mar  8 19:36:54 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Mar 2023 19:36:54 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v3]
In-Reply-To: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
Message-ID: <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>

> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
> 
> The fix uses a different method to choose a break point.
> 
> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8302797

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1055/files
  - new: https://git.openjdk.org/jfx/pull/1055/files/ba0f28dc..a1cf482f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1055&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1055&range=01-02

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1055.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1055/head:pull/1055

PR: https://git.openjdk.org/jfx/pull/1055

From angorya at openjdk.org  Wed Mar  8 20:55:17 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 8 Mar 2023 20:55:17 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v3]
In-Reply-To: <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>
Message-ID: <brMzO--9YB6phYxEf51y4VQX-liNqwshaokfnWI7y7E=.bcfb11ad-e739-4641-a9d0-43d234b6419b@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 19:36:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302797

fix looks good on windows 11.

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From jvos at openjdk.org  Thu Mar  9 11:15:29 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 9 Mar 2023 11:15:29 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <EftA-Edw_QOKaXJ9pRxx8oQ2dY1hgrGHZk45W4t_-7E=.e8dd5545-f980-4907-9973-9bc7ad1ff820@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
 <BeSr3Jw3bxdEATUJ7JySWmbiqEUZa1E8c0W-YGzI2r0=.d800ca24-8a70-4d38-a917-056b9bac2e4d@github.com>
 <EftA-Edw_QOKaXJ9pRxx8oQ2dY1hgrGHZk45W4t_-7E=.e8dd5545-f980-4907-9973-9bc7ad1ff820@github.com>
Message-ID: <AxJt2z8ql7zQvcFfko1OQ7LmCa8ReOSYanNJtH4E9no=.aafe50f7-288f-455f-aa0c-5f9e895e1e9e@github.com>

On Tue, 7 Mar 2023 09:47:39 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 1718:
>> 
>>> 1716:         // Finally, update the scroll bars
>>> 1717:         updateScrollBarsAndCells(false);
>>> 1718:         lastPosition = getPosition();
>> 
>> This is not a formal review -- I'll let Andy and Johan do that -- but can you explain why this is the right fix? Presumably there was at least some reasoning behind updating `lastPosition`. Are there any side effects of not doing that?
>
> I've written more about the explanation below. Actually, it's a good question whether there is reasoning behind updating lastPosition. Wouldn't be surprised, if it is just an artifact of some bug-fixing attempt.

I'll review this. 
One of the challenges with the VirtualFlow class is that there are a number of parameters that contain some state, and the behavior depends very often on what parameters are modified in which method, and when (in which order).

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From thiago.sayao at gmail.com  Thu Mar  9 13:13:44 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 9 Mar 2023 10:13:44 -0300
Subject: Gradle help
Message-ID: <CAAP_wumwhMYJy1Mk6CLTK7HN7=8tRMj=dSJ7XOjPNcuwox+iPQ@mail.gmail.com>

Hi,

https://github.com/openjdk/jfx/pull/1009

For this PR, Intellij Idea is not importing the systemTests dependencies
correctly.

I noticed that it's this part:

dependencies {
        testImplementation project(":graphics").sourceSets.test.output
        testImplementation project(":base").sourceSets.test.output
        testImplementation project(":controls").sourceSets.test.output
        testImplementation project(":swing").sourceSets.test.output
}

It works if I remove "sourceSets.test.output".

I don't have much experience with gradle.

How could I rewrite this that it builds correctly and works with the
Intellij Idea gradle import?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230309/1c6ddeff/attachment.htm>

From lkostyra at openjdk.org  Thu Mar  9 14:56:36 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 9 Mar 2023 14:56:36 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v3]
In-Reply-To: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
Message-ID: <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>

> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
> 
> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
> 
> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
> 
> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.

Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:

 - SetSceneScalingTest: Use latch to check if button was pressed
 - Window: Remove bug ID from comment

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1054/files
  - new: https://git.openjdk.org/jfx/pull/1054/files/ad2ccb02..3e152cb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=01-02

  Stats: 24 lines in 2 files changed: 4 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/1054.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1054/head:pull/1054

PR: https://git.openjdk.org/jfx/pull/1054

From lkostyra at openjdk.org  Thu Mar  9 14:56:39 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 9 Mar 2023 14:56:39 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v2]
In-Reply-To: <O210SwrmFs5MKn93HBKf7k0EOZ_PModbOe2-BwzkEf4=.239647cc-e5f3-4c3e-8163-3871a10bf204@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <O210SwrmFs5MKn93HBKf7k0EOZ_PModbOe2-BwzkEf4=.239647cc-e5f3-4c3e-8163-3871a10bf204@github.com>
Message-ID: <4iYyw3EczjgI6-ZkQq-jPH7YrYT6OWwBvPhVD0Kja50=.6243ba30-0dc5-463b-9700-7cc284be274a@github.com>

On Tue, 7 Mar 2023 15:20:50 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SetSceneScalingTest to robot test directory

I was wondering if that could be an issue, but on my system it was (of course) fine.

I changed the test to wait for a Latch instead of checking `wasClicked`. If it timeouts after a few seconds it means the test fails. Checked it again and it seems to be stable now.

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From kcr at openjdk.org  Thu Mar  9 19:02:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Mar 2023 19:02:58 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v2]
In-Reply-To: <rzRV0WeFYv5-EMREOIoaxFUrj3hTMOrjMq5WnGRUprE=.9390c999-344e-45b1-acc8-4a6607280d8f@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UDmgQYeWbA6P7bfnSaba5tXP-Qq1DUKKaFfNk5hQ3Y4=.2e2bcb85-2917-40d5-a104-0493413fcbaa@github.com>
 <YPG4YnZF3fgI_xvLbRuTnPNOOTfy_irEROFm8FuBgRQ=.bfc85a76-2010-44db-ac2e-615203458312@github.com>
 <rzRV0WeFYv5-EMREOIoaxFUrj3hTMOrjMq5WnGRUprE=.9390c999-344e-45b1-acc8-4a6607280d8f@github.com>
Message-ID: <zRXU-kQI7-b4_upT3Ce0kRL24a8KpPVVVqIKTKNovpE=.98bb255a-eb01-431f-9821-ecb12df376d4@github.com>

On Wed, 8 Mar 2023 19:20:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 46:
>> 
>>> 44: import java.util.TimerTask;
>>> 45: 
>>> 46: public class ArabicWrappingTest extends Application {
>> 
>> The main test class should not extend Application. See [JDK-8234876](https://bugs.openjdk.org/browse/JDK-8234876). Instead, create an static nested class that extends Application.
>
> My @Test does not depend on the instance that junit creates so I don't need to worry about this.
> So it was deliberate. I will add a comment explaining this.

OK, given the comment you added.

>> tests/system/src/test/java/test/javafx/scene/text/ArabicWrappingTest.java line 83:
>> 
>>> 81:         System.setErr(systemErrFilter);
>>> 82:         new Thread(() -> {
>>> 83:             Application.launch(ArabicWrappingTest.class);
>> 
>> I recommend using the recently-added [Util.launch](https://github.com/openjdk/jfx/blob/ba0f28dc072605c1ccd30e2736d39b1fcb11c4cd/tests/system/src/test/java/test/util/Util.java#L319) utility method.
>
> I looked at it but found it un-necessary and it means you need to understand that to use it
> and your test is vulnerable to changes there.

Should be OK given that your test method will now timeout if the launch fails for some reason. If we see failures in our CI system we might need to revisit this.

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From kcr at openjdk.org  Thu Mar  9 19:02:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Mar 2023 19:02:55 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v3]
In-Reply-To: <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>
Message-ID: <6EAZQnRakuV8EhGhSv_NfHXJzXj09EpF0_vaUOBYjlU=.81ebc177-7712-4abd-9f2b-b350c57fcdd2@github.com>

On Wed, 8 Mar 2023 19:36:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302797

Looks good with the added timeout and comment. I confirm that the test passes with the fix and fails without.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1055

From angorya at openjdk.org  Thu Mar  9 19:23:44 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 9 Mar 2023 19:23:44 GMT
Subject: RFR: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex() [v3]
In-Reply-To: <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
 <UUIt96ZaS2mN0HyMFAzpbyDvZvJHrpxZZt-R3PhrEJk=.2e8140c1-e14c-42df-8429-feeba5d93a23@github.com>
Message-ID: <pvc5bpxva30VNnDflK2b3rnBQfr-UwlhbR9ZyIDX7sk=.41d1604c-7f52-4faa-9934-a8bffaa46492@github.com>

On Wed, 8 Mar 2023 19:36:54 GMT, Phil Race <prr at openjdk.org> wrote:

>> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
>> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
>> 
>> The fix uses a different method to choose a break point.
>> 
>> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8302797

Marked as reviewed by angorya (Committer).

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From prr at openjdk.org  Thu Mar  9 21:01:06 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 9 Mar 2023 21:01:06 GMT
Subject: Integrated: 8302797: ArrayIndexOutOfBoundsException in
 TextRun.getWrapIndex()
In-Reply-To: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
References: <3Nj347aYCEDwoNcBeV-Z3JtaLTRXfXWYapSpihYb3ME=.54991f62-ed34-40dd-93ac-608cbf4ef6ca@github.com>
Message-ID: <7CgMekCeoVAxZz6ZggMwsuZLe2iHOqtkuBRMnhTz710=.1133377d-3ec2-433a-84a0-8e4aa3e36e08@github.com>

On Tue, 7 Mar 2023 19:54:15 GMT, Phil Race <prr at openjdk.org> wrote:

> This fixes an the AIOOBE when finding a line break point in RTL laid out glyphs.
> The comment in the bug report explains how we can end up trying to find an unachievable break point and yet there's no "stop" on the search when we've run out of glyphs so hence the exception.
> 
> The fix uses a different method to choose a break point.
> 
> A system test has been supplied which will fail on macOS (even with standard macOS fonts, not just the Noto Sans Arabic) unless the fix is applied.

This pull request has now been integrated.

Changeset: 8cda7bc6
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/8cda7bc6a65893edb7ce6c2b9624d075412ed4ab
Stats:     229 lines in 2 files changed: 222 ins; 4 del; 3 mod

8302797: ArrayIndexOutOfBoundsException in TextRun.getWrapIndex()

Reviewed-by: angorya, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1055

From jhendrikx at openjdk.org  Fri Mar 10 05:24:11 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 10 Mar 2023 05:24:11 GMT
Subject: RFR: JDK-8303897 ObservableValue's when binding should only invalidate
 when strictly needed
Message-ID: <IWvDqVcFUjourI3pMBn_wFlFhnkl4S59ZNlDLOY0Ays=.95b14ff7-497b-4245-9779-874876fdb434@github.com>

Description copied from issue:

There are up to two additional invalidations performed that really should be avoided, causing downstream fluent bindings to be recomputed with the same values.  This is very confusing as these should only be called when there is an actual change, and not called for the same value multiple times in a row.

These two extra invalidations have two different causes, each causing an additional invalidation to be triggered:

1) ObjectBinding's `isObserved` is delayed slightly.  When you add a listener, the listener is added internally and the binding is made valid; this triggers some downstream activity which checks the `isObserved` status to decide whether to start observation of properties -- unfortunately this still returns `false` at that time.  A work-around for this existed by calling `getValue` again in `LazyObjectBinding` with a huge comment explaining why this is needed. Although this works, it still means that a downstream function like `map` is called an additional time while it should really only be called once.

The solution is to ensure `isObserved` returns `true` before the `ExpressionHelper` is called.  Already verified this solves the problem.  This also means the work-around in `LazyObjectBinding` is no longer needed, which seems like a big win.

2) The second additional call originates from a different issue. When `ConditionalBinding` (which implements the `when` construct) sees its condition property changing, it always invalidates itself. This is however only necessary if the current cached value (if it was valid) differs from the current source value. To prevent an unnecessary invalidation, and the resulting revalidation calls that this will trigger, a simple check to see if the value actually changed before invalidating solves this problem.

-------------

Commit messages:
 - Ensure ConditionalBinding only invalidates when absolutely needed

Changes: https://git.openjdk.org/jfx/pull/1056/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303897
  Stats: 270 lines in 5 files changed: 242 ins; 25 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1056.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1056/head:pull/1056

PR: https://git.openjdk.org/jfx/pull/1056

From kpk at openjdk.org  Fri Mar 10 11:45:07 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 10 Mar 2023 11:45:07 GMT
Subject: RFR: 8154038: Spinner's converter should update its editor
Message-ID: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>

When converter was changed, `setText` method of spinner was not invoked to update the spinner text using new converter.

Added a listener to converter property of `SpinnerValueFactory` to call `setText` so that spinner text is updated using new converter.

Added unit test to validate the fix. Along with spinner of Double type, added a spinner of Integer type as well so that the fix is validated using 2 types of spinner.

-------------

Commit messages:
 - Fix spinner converter issue

Changes: https://git.openjdk.org/jfx/pull/1057/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1057&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8154038
  Stats: 58 lines in 2 files changed: 58 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1057.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1057/head:pull/1057

PR: https://git.openjdk.org/jfx/pull/1057

From kevin.rushforth at oracle.com  Fri Mar 10 22:35:46 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 10 Mar 2023 14:35:46 -0800
Subject: jfx21u repo created, but not yet generally open for backports
Message-ID: <bd0154f7-1e7d-48b6-3be5-e3ca137aeb2e@oracle.com>

Skip this unless you care about update release repositories (I expect 
most developer will not care).

You may have noticed that a jfx20u [1] repo was created, matching what 
the JDK had already done. Prior to this release, e.g., for the 19.0.X 
update releases, we were using a rather ad hoc model for non-LTS update 
releases that differed from that of LTS releases. For LTS releases, we 
have a separate updates repository for each code line, for example, 
jdk17u [2] and jdk11u [3]. For non-LTS releases, we had previously 
continued to use the feature release stabilization branch for subsequent 
update releases following the GA of the feature release. That has a 
couple of drawbacks. First and foremost, it means we have to remember to 
ask the question "is this an LTS release or not" to know whether to use 
the `jfxNN` branch in the mainline repo or the `master` branch in the 
`jfxNNu` repo. The second drawback is that with the previous model, 
there is no place to put fixes for the .0.1 update release until the 
feature release ships.

In order to unify the procedures for LTS and non-LTS releases, I plan to 
always create a `jfxNNu` repo for each release. The natural time to 
create this would be some time during RDP1 of the feature release (a 
week or two after the `jfxNN` branch is forked in the main repo). By 
this measure, the jfx20u repo is already several weeks late in being 
created, but it's still a little earlier than the jfx20 branch would 
have been available for 20.0.1 fixes.

This will not impact anything related to stabilization of feature 
releases, which will continue to use stabilization branches, such as 
jfx20, in the main jfx repo.

NOTE: Since this is the first such release after transitioning to the 
new repo model, and because we are already very late in the cycle for 
the April CPU, we do not plan to accept unsolicited backport PRs to 
jfx20u for 20.0.1.

-- Kevin

[1] https://github.com/openjdk/jfx20u
[2] https://github.com/openjdk/jfx17u
[3] https://github.com/openjdk/jfx11u


From kcr at openjdk.org  Sat Mar 11 13:30:22 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 13:30:22 GMT
Subject: [jfx20u] RFR: 8303987: Change JavaFX release version to 20.0.1 in
 jfx20u
Message-ID: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>

Updates for the beginning of the 20.0.1 release.

-------------

Commit messages:
 - 8303987: Change JavaFX release version to 20.0.1 in jfx20u

Changes: https://git.openjdk.org/jfx20u/pull/1/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=1&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303987
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx20u/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/1/head:pull/1

PR: https://git.openjdk.org/jfx20u/pull/1

From kcr at openjdk.org  Sat Mar 11 13:30:23 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 13:30:23 GMT
Subject: [jfx20u] RFR: 8303987: Change JavaFX release version to 20.0.1 in
 jfx20u
In-Reply-To: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
References: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
Message-ID: <cY_gkUwAYtID3ObiuDyjxRF0Aweq4Q22XncCNGOWXwg=.3b65c32b-d43e-44ac-b84a-0d02ccfaade5@github.com>

On Fri, 10 Mar 2023 23:00:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.1 release.

@arapte or @johanvos can one of you review this?

-------------

PR: https://git.openjdk.org/jfx20u/pull/1

From kcr at openjdk.org  Sat Mar 11 13:30:31 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 13:30:31 GMT
Subject: [jfx20u] RFR: 8304008: Update README.md and CONTRIBUTING.md for jfx
 update repos
Message-ID: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>

Update README and CONTRIBUTING guidelines for this repo as appropriate for update releases (basically a copy from jfx17u with 17 changed to 20).

-------------

Commit messages:
 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos

Changes: https://git.openjdk.org/jfx20u/pull/2/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=2&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304008
  Stats: 267 lines in 2 files changed: 1 ins; 254 del; 12 mod
  Patch: https://git.openjdk.org/jfx20u/pull/2.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/2/head:pull/2

PR: https://git.openjdk.org/jfx20u/pull/2

From kcr at openjdk.org  Sat Mar 11 13:30:32 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 13:30:32 GMT
Subject: [jfx20u] RFR: 8304008: Update README.md and CONTRIBUTING.md for
 jfx update repos
In-Reply-To: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>
References: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>
Message-ID: <XhTc2v7vG-eHeaXw6R8l7dMwERi5zSXni-xd_2_abdE=.e38609d8-e90e-4d45-8c54-db3bd35d0595@github.com>

On Fri, 10 Mar 2023 23:02:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update README and CONTRIBUTING guidelines for this repo as appropriate for update releases (basically a copy from jfx17u with 17 changed to 20).

@johanvos can you review this when you get a moment? (not urgent)

-------------

PR: https://git.openjdk.org/jfx20u/pull/2

From kcr at openjdk.org  Sat Mar 11 14:44:28 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 14:44:28 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <iwyFbS44PYPpn8x-BZpXlWLia3O3H9FiNHeQIxEsn0o=.19a13bd3-0712-48e0-8980-f697af4a65d2@github.com>

On Tue, 7 Mar 2023 11:59:20 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

The fix looks OK, with a couple requested changes.

As discussed earlier, let's also file a follow-up bug to rework this so that the exception is never kept in the first place, but rather just the (fully qualified) name of the exception class.

modules/javafx.base/src/main/java/com/sun/javafx/binding/Logging.java line 32:

> 30: public class Logging {
> 31: 
> 32:     public static boolean keepException = false;

I'd rather see a private field and a public setter/getter here. Please also add a comment on the setter/getter indicating that they are only used for testing.

modules/javafx.base/src/test/java/test/com/sun/javafx/binding/TestLogging.java line 1:

> 1: package test.com.sun.javafx.binding;

You need to add a standard copyright header.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From kcr at openjdk.org  Sat Mar 11 14:44:29 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 14:44:29 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception
In-Reply-To: <JhoQsTI5mw9b9NVa9PH3-Nrf8RAQ2M6p5IRBX5ddaZw=.2ada8b48-86d8-4a09-93bf-7926d73b2f5d@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
 <_L0X5if-PuUhNqNlHCZBKS5RIxFDyGZ28eqDVlG6D0c=.4c52ea38-cf44-4ed3-b712-c0305bf10a80@github.com>
 <JhoQsTI5mw9b9NVa9PH3-Nrf8RAQ2M6p5IRBX5ddaZw=.2ada8b48-86d8-4a09-93bf-7926d73b2f5d@github.com>
Message-ID: <fPeHKTwDno95MogB90OxpddwWAD36xYTaKR_GCtsXIU=.e2c2f93d-1983-4f50-935a-6d6c408bd8ba@github.com>

On Wed, 8 Mar 2023 08:19:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> IMHO, the `Logging` class should also not be there, as it is just a facade for `PlatformLogger` specifically there for these tests.
> 
> The tests took the easy way out here to test for log messages by modifying production code to use a different logger (and introducing a leak by doing so). An alternative would be to install a `LoggerFinder` only when tests run, and allow this to be inspected.

This seems like an even better solution for the follow-up fix. The current approach of using a custom Logger in production, just for tests is undesirable.

-------------

PR: https://git.openjdk.org/jfx/pull/1053

From kcr at openjdk.org  Sat Mar 11 14:45:43 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 11 Mar 2023 14:45:43 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v46]
In-Reply-To: <vmHSZN0VCJSANQ9pLDs9aak2aBmlKPEEk-eDO3MXQ7w=.dd6b7205-fbc6-4839-ac16-87ea3a022f05@github.com>
References: <5-LHfl6_vdrmRjLivevBopnWBbzgO0ygK1dRPAFdzoM=.22e09b72-4142-4c1c-b320-94a1c48aaa69@github.com>
 <iHkEYaWbWbLGCu1CbCKcmbxVbDothovBu10AI3WPn-o=.d9f9538d-130f-4839-ad79-b4205e8a1c48@github.com>
 <vmHSZN0VCJSANQ9pLDs9aak2aBmlKPEEk-eDO3MXQ7w=.dd6b7205-fbc6-4839-ac16-87ea3a022f05@github.com>
Message-ID: <ohX7iqR9i9uauRF1lfy1QlA-2HetZA-iHM7Yoz51QCM=.a95ba5a8-f6e8-4099-8bdf-10b7e4da324c@github.com>

On Thu, 2 Feb 2023 12:58:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Fix JDK-8089923
>>  - Fix JDK-8089923
>>  - Fix JDK-8089923
>>  - Fix deiconify regression
>
> I'll re-review this week.

@johanvos Can you re-review this when you have time?

-------------

PR: https://git.openjdk.org/jfx/pull/915

From duke at openjdk.org  Sat Mar 11 14:45:39 2023
From: duke at openjdk.org (Eric Bresie)
Date: Sat, 11 Mar 2023 14:45:39 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <OLo8rLJsdlgwqHiusgAWrIr0lww1USeb5LAks8KAvkI=.5ee0579b-99bf-4678-af7c-1c5115e38701@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

> Some explanation:
> 
> The layout method contains logic, to skip the layouting.

> 
> So, when the position is changed, then the content should be layout again. But when we reset the oldPosition, to the current position, somewhere else in the code - then we interfere with this logic. This has the effect, that the layout is skipped. For that reason, it seems wrong to me, to change the "last-something" values outside of this method.
> 
> So I removed the resetting of the lastPosition in the scrollPixels method. `lastPosition = getPosition();` I also don't see a reason, why the lastPosition should be set anyways.
> 
> But I have to admit, that I don't understand the class well enough to ensure this is correct based on logic. This fixes the unit test and doesn't seem to break tests or something obvious in applications according to my tests.

Just curious?based on the explanation above about change/not changes, does the call to getPosition help in the case state may (or may not) have changed to ensure there is no stale state at that time?

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From kodosaru at gmail.com  Sun Mar 12 05:06:46 2023
From: kodosaru at gmail.com (Don Johnson)
Date: Sun, 12 Mar 2023 00:06:46 -0500
Subject: Swing works, but OpenJFX applications not working with screen
 readers
In-Reply-To: <3d41c260-6483-849c-cf43-73280e3aeef2@oracle.com>
References: <1be324c6-f275-3fa6-0296-4872d8096ad9@gmail.com>
 <3d41c260-6483-849c-cf43-73280e3aeef2@oracle.com>
Message-ID: <25634587-f28b-156f-801b-f3a0c18e01cc@gmail.com>

Hi Phil,

I understand now that JavaFX does not work with the 25 year-old Java 
Access Bridge API. As far as JAWS using Windows Narrator to communicate 
with our Java/JavaFX geospatial application, I am going to have to do 
further investigation. We are in communication with Vispero/Freedom 
Scientific. Thank you for replying and for all the hard work you JavaFX 
developers put into improving the JavaFX API.

Don

On 3/5/2023 12:16 PM, Philip Race wrote:
> Those tools as I think you've worked out are Windows-only tools which 
> use the Windows-only
> Java Access Bridge API that ships with JDK.
> AccessBridge was designed and built 25 years ago (!) to enable 
> Assistive Technologies to
> work for Swing applications at a time when no platform could do this.
> ATs like JAWS (and others) implemented support for AccessBridge and 
> still provide it today
> (we still get bug reports from customers using it)
> So Java + Swing was a long way ahead of the platforms.
>
> But JavaFX does not use AccessBridge.
> By the time it was developed platforms were starting to add AT APIs.
> So instead JavaFX implements support for the platform accessibility 
> APIs meaning
> Narrator on Windows and VoiceOver on macOS.
>
> Therefore JavaFX will not work with those JDK tools which are tied to 
> AccessBridge.
>
> > with the screen reader JAWS running, the 
> Platform.accessibilityActiveProperty() is "true
>
> I guess this is because JAWS registers itself with windows as the 
> active AT.
> Whether JAWS interjects itself into Narrator APIs would depend on 
> whether Windows
> supports that. If it doesn't then JAWS probably has to do 
> old-fashioned screen scraping
> and I don't know how well that would work.
>
> A11Y is usually tested at the application level - whereas JavaFX and 
> Swing are both
> toolkits with which to build applications - but we do try to make 
> things work well
> with the ATs that each of them use, so Narrator is supposed to work 
> for JavaFX
> applications on Windows.
>
>
> -phil.
>
> On 3/5/23 12:36 AM, Don Johnson wrote:
>> Hi All,
>>
>> This is accessibility API question. Swing applications like IntelliJ 
>> IDEA appear in the utilities jaccesswalker, jaccessinspector 
>> (JDK/bin) and access-bridge-explorer (.NET app at 
>> https://github.com/google/access-bridge-explorer.git). However, no 
>> scene graph or accessibility messages in these utilities appear for 
>> any OpenJFX application I have written. A screen reader needs both to 
>> know the scene graph and be able to send and receive accessibility 
>> messages to perform automation and read control descriptions.
>>
>> I have put these values in the "accessibility.properties" file in the 
>> JDK lib folder:
>>
>> assistive_technologies=com.sun.java.accessibility.AccessBridge
>> ??? screen_magnifier_present=true
>> ??? screen_reader_present=true
>>
>> In different test OpenJFX applications running on Windows machines, 
>> with the screen reader JAWS running, the 
>> Platform.accessibilityActiveProperty() is "true." When JAWS is not 
>> running, the value is "false." However, the screen reader cannot 
>> communicate with the OpenJFX applications.
>>
>> Why are the OpenJFX applications not communicating across the 
>> communication channel facilitated by the WindowsAccessBridge-64.dll 
>> and JavaAccessBridge.dll? Incidentally, the Java Access Bridge is 
>> enabled with jabswitch.exe. There is some type of Windows IPC used by 
>> the bridge (COM?) once it is enabled. This bridge facilitates 
>> communication between the screen reader and a Java application 
>> running inside of a JVM.
>>
>> I've also tried explicitly setting roles etc. even though OpenJFX 
>> graphical object already have default values. For example in the 
>> "bouncing ball" sample program I set,
>>
>> ??????? setAccessibleRole(AccessibleRole.BUTTON);
>> ??????? setAccessibleRoleDescription("Bouncing Ball");
>> ??????? setAccessibleText("I'm a bouncing ball");
>> ??????? setAccessibleHelp("This is bouncing ball, use the primary 
>> action to start animation");
>>
>> Does anyone have an OpenJFX sample program the shows up in the 
>> jaccesswalker and jaccessinspector utilities and works with a screen 
>> reader like JAWS or NVDA? This YouTube presentation implies 
>> accessibility is already built into OpenJFX, but I can't get it to 
>> work, see https://youtu.be/iUPPEkD9H1I "The New JavaFX Accessibility 
>> API." My applications must comply with Section 508 of the 
>> Rehabilitation Act of 1973 but cannot so far because of this OpenJFX 
>> accessibility problem.
>>
>> Thanks,
>> Don
>


From jvos at openjdk.org  Sun Mar 12 16:05:30 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 16:05:30 GMT
Subject: [jfx17u] RFR: 8254676: Alert disables Tab selection when TabDragPolicy
 REORDER is used
Message-ID: <ELmiQO52i3FXV7Ifd-Ver50HCbiqqb-AiS782pDM4Z4=.8a4945b1-11a7-41a7-9abf-83565840169f@github.com>

Clean backport of 8254676: Alert disables Tab selection when TabDragPolicy REORDER is used
Reviewed-by: arapte, kcr

-------------

Commit messages:
 - 8254676: Alert disables Tab selection when TabDragPolicy REORDER is used

Changes: https://git.openjdk.org/jfx17u/pull/115/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=115&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254676
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/115.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/115/head:pull/115

PR: https://git.openjdk.org/jfx17u/pull/115

From jvos at openjdk.org  Sun Mar 12 16:10:19 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 16:10:19 GMT
Subject: [jfx17u] RFR: 8291908: VirtualFlow creates unneeded empty cells
Message-ID: <kqrEKUldFDLAyTBTtQXFz79IjsofiTme9T7KmIGZeL8=.105a0fad-1171-4c9f-8166-6f34716d59ba@github.com>

clean backport of 8291908: VirtualFlow creates unneeded empty cells
Reviewed-by: kcr, aghaisas

-------------

Commit messages:
 - 8291908: VirtualFlow creates unneeded empty cells

Changes: https://git.openjdk.org/jfx17u/pull/116/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291908
  Stats: 40 lines in 3 files changed: 38 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx17u/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/116/head:pull/116

PR: https://git.openjdk.org/jfx17u/pull/116

From jvos at openjdk.org  Sun Mar 12 18:18:32 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 18:18:32 GMT
Subject: [jfx17u] Integrated: 8254676: Alert disables Tab selection when
 TabDragPolicy REORDER is used
In-Reply-To: <ELmiQO52i3FXV7Ifd-Ver50HCbiqqb-AiS782pDM4Z4=.8a4945b1-11a7-41a7-9abf-83565840169f@github.com>
References: <ELmiQO52i3FXV7Ifd-Ver50HCbiqqb-AiS782pDM4Z4=.8a4945b1-11a7-41a7-9abf-83565840169f@github.com>
Message-ID: <m4dSqavwzgVdq1MlBOnzpefBIXfzN9GQTChixeWArow=.7fc207ac-41a8-4675-b123-903ca4c73ce9@github.com>

On Sun, 12 Mar 2023 15:59:46 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Clean backport of 8254676: Alert disables Tab selection when TabDragPolicy REORDER is used
> Reviewed-by: arapte, kcr

This pull request has now been integrated.

Changeset: 3ec9ddae
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/3ec9ddaecbea7717f6efa1e3ab30b6b0cf919dc7
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8254676: Alert disables Tab selection when TabDragPolicy REORDER is used

Backport-of: cce85806c61f8b2a9bc18996a9922daf6daa9cd8

-------------

PR: https://git.openjdk.org/jfx17u/pull/115

From jvos at openjdk.org  Sun Mar 12 18:19:16 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 18:19:16 GMT
Subject: [jfx17u] RFR: 8303026: [TextField] IOOBE on setting text with control
 characters that replaces existing text
Message-ID: <MjZ4lq6bBpqsicAUvAChw_u1bdcQUctFb2_X8ZDP-tU=.a879c13f-f556-4e54-9a86-d1d883825053@github.com>

Almost clean backport of JDK-8303026
The test that is part of this backport is added manually, because of the large offset.

-------------

Commit messages:
 - Add test that is part of the original patch (but with a large offset)
 - 8303026: [TextField] IOOBE on setting text with control characters that replaces existing text

Changes: https://git.openjdk.org/jfx17u/pull/117/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=117&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303026
  Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx17u/pull/117.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/117/head:pull/117

PR: https://git.openjdk.org/jfx17u/pull/117

From jvos at openjdk.org  Sun Mar 12 18:20:26 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 18:20:26 GMT
Subject: [jfx17u] Integrated: 8291908: VirtualFlow creates unneeded empty cells
In-Reply-To: <kqrEKUldFDLAyTBTtQXFz79IjsofiTme9T7KmIGZeL8=.105a0fad-1171-4c9f-8166-6f34716d59ba@github.com>
References: <kqrEKUldFDLAyTBTtQXFz79IjsofiTme9T7KmIGZeL8=.105a0fad-1171-4c9f-8166-6f34716d59ba@github.com>
Message-ID: <42i0lCEoSK_l2EnqJm6b3GkpbqPXvoBpbkVHkMfJ4M8=.15fd2ee1-260f-4d15-9b07-822b71355035@github.com>

On Sun, 12 Mar 2023 16:04:06 GMT, Johan Vos <jvos at openjdk.org> wrote:

> clean backport of 8291908: VirtualFlow creates unneeded empty cells
> Reviewed-by: kcr, aghaisas

This pull request has now been integrated.

Changeset: f2f296b2
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/f2f296b2aa04b85738a98a3d8a0d899a6d61d690
Stats:     40 lines in 3 files changed: 38 ins; 0 del; 2 mod

8291908: VirtualFlow creates unneeded empty cells

Backport-of: eaddb0fbeeb99900636f9704758f6c004860ff9a

-------------

PR: https://git.openjdk.org/jfx17u/pull/116

From jvos at openjdk.org  Sun Mar 12 18:22:12 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 18:22:12 GMT
Subject: [jfx17u] RFR: 8281327: JavaFX does not support fonts installed
 per-user on Windows 10/11
Message-ID: <KFtFsHlLuxqC_iEJmR8pNnTF4Q23UC9wJhVHCc4loz4=.aeadcc77-c50c-4134-a992-27596c8fede3@github.com>

Clean backport of
8281327: JavaFX does not support fonts installed per-user on Windows 10/11

Reviewed-by: prr, arapte

-------------

Commit messages:
 - 8281327: JavaFX does not support fonts installed per-user on Windows 10/11

Changes: https://git.openjdk.org/jfx17u/pull/118/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8281327
  Stats: 113 lines in 1 file changed: 63 ins; 43 del; 7 mod
  Patch: https://git.openjdk.org/jfx17u/pull/118.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/118/head:pull/118

PR: https://git.openjdk.org/jfx17u/pull/118

From jvos at openjdk.org  Sun Mar 12 18:28:25 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 18:28:25 GMT
Subject: [jfx17u] Integrated: 8281327: JavaFX does not support fonts installed
 per-user on Windows 10/11
In-Reply-To: <KFtFsHlLuxqC_iEJmR8pNnTF4Q23UC9wJhVHCc4loz4=.aeadcc77-c50c-4134-a992-27596c8fede3@github.com>
References: <KFtFsHlLuxqC_iEJmR8pNnTF4Q23UC9wJhVHCc4loz4=.aeadcc77-c50c-4134-a992-27596c8fede3@github.com>
Message-ID: <s2i5WL1TW4Rn0yJidHgxvaPLz_O47adVC79G_Kq_d44=.f13cff3a-48dc-4b6e-92b9-353d9ec224e4@github.com>

On Sun, 12 Mar 2023 18:16:57 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Clean backport of
> 8281327: JavaFX does not support fonts installed per-user on Windows 10/11
> 
> Reviewed-by: prr, arapte

This pull request has now been integrated.

Changeset: d165e5c6
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/d165e5c65ec4eb07f2ba4ebcf2dffb85947b496d
Stats:     113 lines in 1 file changed: 63 ins; 43 del; 7 mod

8281327: JavaFX does not support fonts installed per-user on Windows 10/11

Backport-of: f4ca00dd6f81a97401f78f422a6899cb44ab462f

-------------

PR: https://git.openjdk.org/jfx17u/pull/118

From jvos at openjdk.org  Sun Mar 12 19:04:25 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 19:04:25 GMT
Subject: [jfx17u] RFR: 8300872: WebView's ColorChooser fails to initialize when
 running in security context
Message-ID: <D3MHj5K3QQEsNOn0aUeKUNfIpymD197qIjGFqHEFw18=.7a290c9d-f848-454e-8f82-faf72895df55@github.com>

Almost clean backport 
8300872: WebView's ColorChooser fails to initialize when running in security context

The non-clean parts are 2 manual changes in copyright years.

Reviewed-by: kcr, mstrauss

-------------

Commit messages:
 - 8300872: WebView's ColorChooser fails to initialize when running in security context

Changes: https://git.openjdk.org/jfx17u/pull/119/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300872
  Stats: 207 lines in 5 files changed: 196 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jfx17u/pull/119.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/119/head:pull/119

PR: https://git.openjdk.org/jfx17u/pull/119

From jvos at openjdk.org  Sun Mar 12 19:38:16 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 12 Mar 2023 19:38:16 GMT
Subject: [jfx17u] RFR: 8300893: Wrong state after deselecting two or more cells
 of a TableView selection
Message-ID: <gKQj6k6FFrcshBDYzJWn5dE4rgM2aKeZ4N5wP9vqx_M=.ae79d637-301c-43e6-b43a-95d670c09a00@github.com>

Almost clean patch for 
[PATCH] 8300893: Wrong state after deselecting two or more cells of a TableView selection

(required changes in (c) date)

Reviewed-by: aghaisas, angorya

-------------

Commit messages:
 - 8300893: Wrong state after deselecting two or more cells of a TableView selection

Changes: https://git.openjdk.org/jfx17u/pull/120/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=120&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300893
  Stats: 274 lines in 4 files changed: 247 ins; 5 del; 22 mod
  Patch: https://git.openjdk.org/jfx17u/pull/120.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/120/head:pull/120

PR: https://git.openjdk.org/jfx17u/pull/120

From tsayao at openjdk.org  Sun Mar 12 23:04:19 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 12 Mar 2023 23:04:19 GMT
Subject: RFR: 8273379: GTK3 stops sending key events during drag and drop
 [v29]
In-Reply-To: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
References: <8LJW64tevDxuYXe4HIfvvcCDZGcsv5imKtGkS9QdLmM=.44259629-6ed0-49c9-9e53-8faa7f9858e6@github.com>
Message-ID: <1ySLcmYQrCbbeTXzcs85mOxbbUy3PuBC1yxynkHvwrA=.cc4042ab-0be8-44a6-97d0-cf0f14804674@github.com>

> This PR fixes 8273379.
> 
> I reverted back to use GDK (from [8225571](https://bugs.openjdk.org/browse/JDK-8225571)) to handle the events. 
> 
> It may also fix [8280383](https://bugs.openjdk.org/browse/JDK-8280383).
> 
> There's also some cleaup.
> 
> To do general testing (two tests were added):
> `java @build/run.args -jar apps/toys/DragDrop/dist/DragDrop.jar`
> 
> Information for reviewing:
> * Previously an offscreen window where used to pass events. Now it gets the window were Drag initially started  (`WindowContextBase::sm_mouse_drag_window`);
> * There's a new `DragSourceContext` instead of global variables;
> * DragView were simplified;
> * It handles `GDK_GRAB_BROKEN` events (I still need to figure it out a test case for this - It should happen when another window grabs the device during the drag);
> * There's a special case for `GDK_BUTTON_RELEASE` because `WindowContext` will notify java about the button release and set `DnDGesture` to null before the end of the DND.
> * `gdk_drag_find_window_for_screen` -> pass the DragView window to be ignored (as it would "steal" destination motion events);
> * The Scenario were the drag source window closes during the drag is now covered;
> * It does not rely on `gdk_threads_add_idle` because it may be inconsistent.
> 
> 
> ![image](https://user-images.githubusercontent.com/30704286/213877115-18f274ff-18c9-4d38-acc4-449f24174ecc.png)
> ![image](https://user-images.githubusercontent.com/30704286/213877140-1d24c293-d70f-46e6-b040-c49170d2aa9a.png)

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Don't call gdk_device_manager_get_client_pointer() on event processing

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/986/files
  - new: https://git.openjdk.org/jfx/pull/986/files/c0eb6531..96f2debf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=28
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=986&range=27-28

  Stats: 31 lines in 4 files changed: 14 ins; 15 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/986.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/986/head:pull/986

PR: https://git.openjdk.org/jfx/pull/986

From arapte at openjdk.org  Mon Mar 13 05:01:35 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 13 Mar 2023 05:01:35 GMT
Subject: [jfx20u] RFR: 8303987: Change JavaFX release version to 20.0.1 in
 jfx20u
In-Reply-To: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
References: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
Message-ID: <cs0AFmiYovede3K2_gx7d0ADQNwdaCSQ8JjMdAOjrs0=.95400ed5-c003-4b2c-8c78-65f2b6cfe112@github.com>

On Fri, 10 Mar 2023 23:00:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.1 release.

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.org/jfx20u/pull/1

From jvos at openjdk.org  Mon Mar 13 08:20:41 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 08:20:41 GMT
Subject: [jfx20u] RFR: 8303987: Change JavaFX release version to 20.0.1 in
 jfx20u
In-Reply-To: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
References: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
Message-ID: <5GSYqNwjFX7rkDknxVybUxKP2EcE7mQyR2Td7dw5XGE=.f1a64326-166b-453f-a30d-64be20201e6d@github.com>

On Fri, 10 Mar 2023 23:00:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.1 release.

Marked as reviewed by jvos (Reviewer).

-------------

PR: https://git.openjdk.org/jfx20u/pull/1

From arapte at openjdk.org  Mon Mar 13 11:25:08 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 13 Mar 2023 11:25:08 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v3]
In-Reply-To: <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>
Message-ID: <l3Va9b8a-9vD39HuVtY-gZYvcciBZk3dOr8v9mJTIto=.8dba1221-bc86-4482-a0db-d2b88fb91eb1@github.com>

On Thu, 9 Mar 2023 14:56:36 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - SetSceneScalingTest: Use latch to check if button was pressed
>  - Window: Remove bug ID from comment

We have a bug for setting scene after showing stage: [JDK-8199204](https://bugs.openjdk.org/browse/JDK-8199204).
It seems to be fixed by this PR.

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From arapte at openjdk.org  Mon Mar 13 11:39:36 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 13 Mar 2023 11:39:36 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v3]
In-Reply-To: <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>
Message-ID: <egKIERZXquHxXfGoTUyDR7sGjrueKbkBEnUo-xlnwuw=.0fba71eb-3242-4377-8819-3292489c7d0e@github.com>

On Thu, 9 Mar 2023 14:56:36 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - SetSceneScalingTest: Use latch to check if button was pressed
>  - Window: Remove bug ID from comment

The fix seems good to me. Suggesting few changes in test and a minor correction in source.

modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1327:

> 1325:         }
> 1326:     }
> 1327:     GlassView * view;

The variable `view` is not needed, must be a copy-paste leftover.

tests/system/src/test/java/test/robot/javafx/stage/SetSceneScalingTest.java line 64:

> 62: 
> 63:         protected void testButtonClick() {
> 64:             robot.mouseMove(400, 400);

In general, this is not hard coded in our tests.
I would recommend to change as:
1. Add two variables width and height in TestApp

private final int WIDTH  = 400;
private final int HEIGHT = 400;

2. Change this line to:

robot.mouseMove((int)(stage.getX() + stage.getScene().getX() + WIDTH/2),
                (int)(stage.getY() + stage.getScene().getY() + HEIGHT/2));


3. Remove line 97, 98
4. Change line 99 and 100 as:

stage.setWidth(WIDTH);
stage.setHeight(HEIGHT);

tests/system/src/test/java/test/robot/javafx/stage/SetSceneScalingTest.java line 96:

> 94:                 stage = new Stage(StageStyle.UNDECORATED);
> 95:                 stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e ->
> 96:                                         Platform.runLater(shownLatch::countDown));

Can be changed to : 

stage.setOnShown(l -> {
    Platform.runLater(() -> startupLatch.countDown());
});

-------------

Changes requested by arapte (Reviewer).

PR: https://git.openjdk.org/jfx/pull/1054

From kcr at openjdk.org  Mon Mar 13 12:35:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 12:35:33 GMT
Subject: [jfx20u] Integrated: 8303987: Change JavaFX release version to 20.0.1
 in jfx20u
In-Reply-To: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
References: <l-dlPaRllaBuYKMUjdXgutEwr0EDdzUafv5XYBuGuDU=.afaee36a-dc90-4525-9f7c-a0753abf574a@github.com>
Message-ID: <hVkiDxrYw84kaGP6FD11EStU0In1m3runILsl4Xm6Nw=.8540400b-95f4-4496-8a19-e31cf9fe0da0@github.com>

On Fri, 10 Mar 2023 23:00:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.1 release.

This pull request has now been integrated.

Changeset: 5bf59842
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/5bf59842a2af9cfc8bdc8fd3a27646f13bd647c8
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8303987: Change JavaFX release version to 20.0.1 in jfx20u

Reviewed-by: arapte, jvos

-------------

PR: https://git.openjdk.org/jfx20u/pull/1

From kcr at openjdk.org  Mon Mar 13 12:41:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 12:41:38 GMT
Subject: [jfx17u] RFR: 8303026: [TextField] IOOBE on setting text with
 control characters that replaces existing text
In-Reply-To: <MjZ4lq6bBpqsicAUvAChw_u1bdcQUctFb2_X8ZDP-tU=.a879c13f-f556-4e54-9a86-d1d883825053@github.com>
References: <MjZ4lq6bBpqsicAUvAChw_u1bdcQUctFb2_X8ZDP-tU=.a879c13f-f556-4e54-9a86-d1d883825053@github.com>
Message-ID: <EtYG3TnvSvtf4LYFxTakl534Tw-JfYHtjC3akPobcEQ=.40b1b144-82cf-4c78-ae7e-12a9a3093e74@github.com>

On Sun, 12 Mar 2023 18:13:20 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8303026
> The test that is part of this backport is added manually, because of the large offset.

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx17u/pull/117

From lkostyra at openjdk.org  Mon Mar 13 12:55:45 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 13 Mar 2023 12:55:45 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v3]
In-Reply-To: <egKIERZXquHxXfGoTUyDR7sGjrueKbkBEnUo-xlnwuw=.0fba71eb-3242-4377-8819-3292489c7d0e@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>
 <egKIERZXquHxXfGoTUyDR7sGjrueKbkBEnUo-xlnwuw=.0fba71eb-3242-4377-8819-3292489c7d0e@github.com>
Message-ID: <oUX9jE_bOOnNYfFrukiKxM05vdWg8WYomyWHGpMMyzQ=.a35d26f2-e2bb-414c-9c34-f7f0a0fbee06@github.com>

On Mon, 13 Mar 2023 10:30:39 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - SetSceneScalingTest: Use latch to check if button was pressed
>>  - Window: Remove bug ID from comment
>
> modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 1327:
> 
>> 1325:         }
>> 1326:     }
>> 1327:     GlassView * view;
> 
> The variable `view` is not needed, must be a copy-paste leftover.

Indeed a leftover - removed

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From lkostyra at openjdk.org  Mon Mar 13 13:08:58 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 13 Mar 2023 13:08:58 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v3]
In-Reply-To: <egKIERZXquHxXfGoTUyDR7sGjrueKbkBEnUo-xlnwuw=.0fba71eb-3242-4377-8819-3292489c7d0e@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <Y27ZZF63aGNhNMl5s9ju41VE6-FfgB5v7YP-XkjLpmI=.c7c95816-37dd-48bd-afbc-fb2926b321ee@github.com>
 <egKIERZXquHxXfGoTUyDR7sGjrueKbkBEnUo-xlnwuw=.0fba71eb-3242-4377-8819-3292489c7d0e@github.com>
Message-ID: <bIp1nMdt7plyz8Jb6VcWBfaUQhIcCdxt2-fZJp54cTM=.38d470da-c599-41e2-8dff-cef57a008787@github.com>

On Mon, 13 Mar 2023 10:51:33 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - SetSceneScalingTest: Use latch to check if button was pressed
>>  - Window: Remove bug ID from comment
>
> tests/system/src/test/java/test/robot/javafx/stage/SetSceneScalingTest.java line 64:
> 
>> 62: 
>> 63:         protected void testButtonClick() {
>> 64:             robot.mouseMove(400, 400);
> 
> In general, this is not hard coded in our tests.
> I would recommend to change as:
> 1. Add two variables width and height in TestApp
> 
> private final int WIDTH  = 400;
> private final int HEIGHT = 400;
> 
> 2. Change this line to:
> 
> robot.mouseMove((int)(stage.getX() + stage.getScene().getX() + WIDTH/2),
>                 (int)(stage.getY() + stage.getScene().getY() + HEIGHT/2));
> 
> 
> 3. Remove line 97, 98
> 4. Change line 99 and 100 as:
> 
> stage.setWidth(WIDTH);
> stage.setHeight(HEIGHT);

Done

> tests/system/src/test/java/test/robot/javafx/stage/SetSceneScalingTest.java line 96:
> 
>> 94:                 stage = new Stage(StageStyle.UNDECORATED);
>> 95:                 stage.addEventHandler(WindowEvent.WINDOW_SHOWN, e ->
>> 96:                                         Platform.runLater(shownLatch::countDown));
> 
> Can be changed to : 
> 
> stage.setOnShown(l -> {
>     Platform.runLater(() -> startupLatch.countDown());
> });

Done

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From lkostyra at openjdk.org  Mon Mar 13 14:58:53 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 13 Mar 2023 14:58:53 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v4]
In-Reply-To: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
Message-ID: <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>

> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
> 
> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
> 
> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
> 
> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.

Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:

 - SetSceneScalingTest: Address review issues
   
   - Calculate robot.mouseMove coords based on Stage/Scene position
   - Use stage.setOnShown() instead of addEventListener()
 - GlassWindow: Fix Copy-Paste's Error with unnecessary View variable

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1054/files
  - new: https://git.openjdk.org/jfx/pull/1054/files/3e152cb8..4701dee6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1054&range=02-03

  Stats: 12 lines in 2 files changed: 4 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1054.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1054/head:pull/1054

PR: https://git.openjdk.org/jfx/pull/1054

From kcr at openjdk.org  Mon Mar 13 15:46:23 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 15:46:23 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v4]
In-Reply-To: <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>
Message-ID: <i08pQQu-r7tzWa9wZqVVlbtj4BBF-22Nd5QWJki24mU=.29a11533-0c96-44a7-bb37-7c6d252e8eb4@github.com>

On Mon, 13 Mar 2023 14:58:53 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - SetSceneScalingTest: Address review issues
>    
>    - Calculate robot.mouseMove coords based on Stage/Scene position
>    - Use stage.setOnShown() instead of addEventListener()
>  - GlassWindow: Fix Copy-Paste's Error with unnecessary View variable

Now that https://bugs.openjdk.org/browse/JDK-8199204 is closed as a duplicate, please `/issue remove JDK-8199204`.

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From jvos at openjdk.org  Mon Mar 13 15:57:44 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 15:57:44 GMT
Subject: [jfx17u] Integrated: 8303026: [TextField] IOOBE on setting text with
 control characters that replaces existing text
In-Reply-To: <MjZ4lq6bBpqsicAUvAChw_u1bdcQUctFb2_X8ZDP-tU=.a879c13f-f556-4e54-9a86-d1d883825053@github.com>
References: <MjZ4lq6bBpqsicAUvAChw_u1bdcQUctFb2_X8ZDP-tU=.a879c13f-f556-4e54-9a86-d1d883825053@github.com>
Message-ID: <JM3xpYxYzp8BrIGR7s-Xcypu5UkC8VAsuS_LnpRFSkU=.2196a0a2-492a-49b0-b809-18dfbcf58e64@github.com>

On Sun, 12 Mar 2023 18:13:20 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8303026
> The test that is part of this backport is added manually, because of the large offset.

This pull request has now been integrated.

Changeset: d045d2b2
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/d045d2b24b0bc66ad1203a51f614ee9a2e1151fb
Stats:     15 lines in 2 files changed: 14 ins; 0 del; 1 mod

8303026: [TextField] IOOBE on setting text with control characters that replaces existing text

Reviewed-by: kcr
Backport-of: 9df6039a27a78f40a929b5ba4de0e38ce233a6fc

-------------

PR: https://git.openjdk.org/jfx17u/pull/117

From jvos at openjdk.org  Mon Mar 13 16:51:11 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 16:51:11 GMT
Subject: [jfx17u] RFR: 8235491: Tree/TableView: implementation of
 isSelected(int) violates contract
Message-ID: <kBCzkssJi0p1mzAKWCLgfO5mhvNi8jsH3U_VxvWhuO8=.06be6c4b-7f3d-46a5-945a-0922dc81680a@github.com>

clean backport of
8235491: Tree/TableView: implementation of isSelected(int) violates contract

Reviewed-by: aghaisas, fastegal, kcr

-------------

Commit messages:
 - 8235491: Tree/TableView: implementation of isSelected(int) violates contract

Changes: https://git.openjdk.org/jfx17u/pull/121/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=121&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8235491
  Stats: 325 lines in 8 files changed: 285 ins; 9 del; 31 mod
  Patch: https://git.openjdk.org/jfx17u/pull/121.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/121/head:pull/121

PR: https://git.openjdk.org/jfx17u/pull/121

From kcr at openjdk.org  Mon Mar 13 16:56:46 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 16:56:46 GMT
Subject: [jfx17u] RFR: 8300893: Wrong state after deselecting two or more
 cells of a TableView selection
In-Reply-To: <gKQj6k6FFrcshBDYzJWn5dE4rgM2aKeZ4N5wP9vqx_M=.ae79d637-301c-43e6-b43a-95d670c09a00@github.com>
References: <gKQj6k6FFrcshBDYzJWn5dE4rgM2aKeZ4N5wP9vqx_M=.ae79d637-301c-43e6-b43a-95d670c09a00@github.com>
Message-ID: <Ohok_FQOctQDeIz9N0xFuOj3uRrVvsZeVN1tZ963SUs=.b9dba7b9-585b-4b15-8e54-9e8dd894bd06@github.com>

On Sun, 12 Mar 2023 19:32:02 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean patch for 
> [PATCH] 8300893: Wrong state after deselecting two or more cells of a TableView selection
> 
> (required changes in (c) date)
> 
> Reviewed-by: aghaisas, angorya

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx17u/pull/120

From kcr at openjdk.org  Mon Mar 13 16:57:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 16:57:55 GMT
Subject: [jfx17u] RFR: 8300872: WebView's ColorChooser fails to initialize
 when running in security context
In-Reply-To: <D3MHj5K3QQEsNOn0aUeKUNfIpymD197qIjGFqHEFw18=.7a290c9d-f848-454e-8f82-faf72895df55@github.com>
References: <D3MHj5K3QQEsNOn0aUeKUNfIpymD197qIjGFqHEFw18=.7a290c9d-f848-454e-8f82-faf72895df55@github.com>
Message-ID: <oRCir9KlQxkM-cYEoLuVwKp8DCn3U8WFXnmGZfL8j-Y=.9df2acb0-73d2-4323-bff9-c085fb66e5f6@github.com>

On Sun, 12 Mar 2023 18:57:21 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport 
> 8300872: WebView's ColorChooser fails to initialize when running in security context
> 
> The non-clean parts are 2 manual changes in copyright years.
> 
> Reviewed-by: kcr, mstrauss

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx17u/pull/119

From jvos at openjdk.org  Mon Mar 13 18:24:13 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 18:24:13 GMT
Subject: [jfx17u] Integrated: 8235491: Tree/TableView: implementation of
 isSelected(int) violates contract
In-Reply-To: <kBCzkssJi0p1mzAKWCLgfO5mhvNi8jsH3U_VxvWhuO8=.06be6c4b-7f3d-46a5-945a-0922dc81680a@github.com>
References: <kBCzkssJi0p1mzAKWCLgfO5mhvNi8jsH3U_VxvWhuO8=.06be6c4b-7f3d-46a5-945a-0922dc81680a@github.com>
Message-ID: <R33sPqqr9k-bKZbsIVBkoAIhMNgFb7YOf5VKQ__U_ME=.e164804c-2d35-482d-a95e-d7301dd8a9ee@github.com>

On Mon, 13 Mar 2023 16:45:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> clean backport of
> 8235491: Tree/TableView: implementation of isSelected(int) violates contract
> 
> Reviewed-by: aghaisas, fastegal, kcr

This pull request has now been integrated.

Changeset: 14c998c4
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/14c998c43292871db8a591ef447c0f4c59d91be6
Stats:     325 lines in 8 files changed: 285 ins; 9 del; 31 mod

8235491: Tree/TableView: implementation of isSelected(int) violates contract

Backport-of: 7cb8d679dc2aa96b7c9a2bd60983ab74aa275967

-------------

PR: https://git.openjdk.org/jfx17u/pull/121

From jvos at openjdk.org  Mon Mar 13 18:38:00 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 18:38:00 GMT
Subject: [jfx17u] Integrated: 8300893: Wrong state after deselecting two or
 more cells of a TableView selection
In-Reply-To: <gKQj6k6FFrcshBDYzJWn5dE4rgM2aKeZ4N5wP9vqx_M=.ae79d637-301c-43e6-b43a-95d670c09a00@github.com>
References: <gKQj6k6FFrcshBDYzJWn5dE4rgM2aKeZ4N5wP9vqx_M=.ae79d637-301c-43e6-b43a-95d670c09a00@github.com>
Message-ID: <hMLe4RzpnoDd0TygoERyzpatYvPSJFev93oWI26eKyo=.a9d6fddf-29cb-4d01-9513-dae86e68f065@github.com>

On Sun, 12 Mar 2023 19:32:02 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean patch for 
> [PATCH] 8300893: Wrong state after deselecting two or more cells of a TableView selection
> 
> (required changes in (c) date)
> 
> Reviewed-by: aghaisas, angorya

This pull request has now been integrated.

Changeset: cdbe1550
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/cdbe1550e84c8e5a1da18bf5c79e31f4d21b58f7
Stats:     274 lines in 4 files changed: 247 ins; 5 del; 22 mod

8300893: Wrong state after deselecting two or more cells of a TableView selection

Reviewed-by: kcr
Backport-of: dbab36b2a264cd596d0390e42e15d4b2bc0c33b8

-------------

PR: https://git.openjdk.org/jfx17u/pull/120

From jvos at openjdk.org  Mon Mar 13 18:40:06 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 18:40:06 GMT
Subject: [jfx17u] Integrated: 8300872: WebView's ColorChooser fails to
 initialize when running in security context
In-Reply-To: <D3MHj5K3QQEsNOn0aUeKUNfIpymD197qIjGFqHEFw18=.7a290c9d-f848-454e-8f82-faf72895df55@github.com>
References: <D3MHj5K3QQEsNOn0aUeKUNfIpymD197qIjGFqHEFw18=.7a290c9d-f848-454e-8f82-faf72895df55@github.com>
Message-ID: <0YukpBwOGssaiQ4gHwAy8vAz3copy2gUEPP6bzWg-t4=.e636725c-7470-4f17-9fd7-4824a67dd5ad@github.com>

On Sun, 12 Mar 2023 18:57:21 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport 
> 8300872: WebView's ColorChooser fails to initialize when running in security context
> 
> The non-clean parts are 2 manual changes in copyright years.
> 
> Reviewed-by: kcr, mstrauss

This pull request has now been integrated.

Changeset: 633b130d
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/633b130d91abdf84a51f6b922c6974d60ed28a44
Stats:     207 lines in 5 files changed: 196 ins; 5 del; 6 mod

8300872: WebView's ColorChooser fails to initialize when running in security context

Reviewed-by: kcr
Backport-of: b2134505cc0c89637019ce746d5fac6ab708d4e2

-------------

PR: https://git.openjdk.org/jfx17u/pull/119

From jvos at openjdk.org  Mon Mar 13 18:41:03 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 18:41:03 GMT
Subject: [jfx17u] RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals
 in cell selection mode
Message-ID: <-oyWb-IXNgFJhe5W3jxkYbrefp3jSH6Fnt-Eg9Wro9c=.c81dfc45-1cc6-4050-8d00-61e1f03acabb@github.com>

Clean backport of 
8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode

Reviewed-by: aghaisas, kcr

-------------

Commit messages:
 - 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode

Changes: https://git.openjdk.org/jfx17u/pull/122/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292353
  Stats: 507 lines in 4 files changed: 498 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jfx17u/pull/122.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/122/head:pull/122

PR: https://git.openjdk.org/jfx17u/pull/122

From kcr at openjdk.org  Mon Mar 13 18:42:12 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 18:42:12 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v4]
In-Reply-To: <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>
Message-ID: <JWouOTuBTKdxPx28RvGgPLKKh174U69NJSJFIgJjbRk=.3ccd7a96-3645-408b-a0f2-6dc102b2b902@github.com>

On Mon, 13 Mar 2023 14:58:53 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - SetSceneScalingTest: Address review issues
>    
>    - Calculate robot.mouseMove coords based on Stage/Scene position
>    - Use stage.setOnShown() instead of addEventListener()
>  - GlassWindow: Fix Copy-Paste's Error with unnecessary View variable

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1054

From jvos at openjdk.org  Mon Mar 13 18:45:15 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 18:45:15 GMT
Subject: [jfx17u] Integrated: 8292353: TableRow vs. TreeTableRow: inconsistent
 visuals in cell selection mode
In-Reply-To: <-oyWb-IXNgFJhe5W3jxkYbrefp3jSH6Fnt-Eg9Wro9c=.c81dfc45-1cc6-4050-8d00-61e1f03acabb@github.com>
References: <-oyWb-IXNgFJhe5W3jxkYbrefp3jSH6Fnt-Eg9Wro9c=.c81dfc45-1cc6-4050-8d00-61e1f03acabb@github.com>
Message-ID: <bsKP5S-lW6amp7IWReTslLX85z8De9qazZdEjzjxcGA=.efc1785d-a9f2-4890-b287-6e798ef655f4@github.com>

On Mon, 13 Mar 2023 18:32:32 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Clean backport of 
> 8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode
> 
> Reviewed-by: aghaisas, kcr

This pull request has now been integrated.

Changeset: 4127870e
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/4127870ea25b5cc0f9a229da13ab0463cc79ec10
Stats:     507 lines in 4 files changed: 498 ins; 4 del; 5 mod

8292353: TableRow vs. TreeTableRow: inconsistent visuals in cell selection mode

Backport-of: 9768b5e42391e2d48aefffa3a3f6b1de6c30ef9d

-------------

PR: https://git.openjdk.org/jfx17u/pull/122

From jvos at openjdk.org  Mon Mar 13 19:17:41 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 19:17:41 GMT
Subject: [jfx17u] RFR: 8187145: (Tree)TableView with null selectionModel:
 throws NPE on sorting
Message-ID: <meWxxnRMa99gwyPHLwgpW_qGZPgUQZtRPLKK-FowsRY=.74cd66a0-4c3c-49d7-a244-d49a5a8309a5@github.com>

Almost clean (apart from some offsets) backport of

8187145: (Tree)TableView with null selectionModel: throws NPE on sorting

Reviewed-by: aghaisas, kcr

-------------

Commit messages:
 - 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting

Changes: https://git.openjdk.org/jfx17u/pull/123/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=123&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8187145
  Stats: 469 lines in 15 files changed: 378 ins; 12 del; 79 mod
  Patch: https://git.openjdk.org/jfx17u/pull/123.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/123/head:pull/123

PR: https://git.openjdk.org/jfx17u/pull/123

From jvos at openjdk.org  Mon Mar 13 19:27:26 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 19:27:26 GMT
Subject: [jfx17u] Integrated: 8187145: (Tree)TableView with null
 selectionModel: throws NPE on sorting
In-Reply-To: <meWxxnRMa99gwyPHLwgpW_qGZPgUQZtRPLKK-FowsRY=.74cd66a0-4c3c-49d7-a244-d49a5a8309a5@github.com>
References: <meWxxnRMa99gwyPHLwgpW_qGZPgUQZtRPLKK-FowsRY=.74cd66a0-4c3c-49d7-a244-d49a5a8309a5@github.com>
Message-ID: <8UHah6evDXr7PQ2Qks-6emGjJsFWtpV5mTchhwgY_fw=.7bdbc18b-4bda-4e1c-8308-07710c9e9e75@github.com>

On Mon, 13 Mar 2023 19:10:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean (apart from some offsets) backport of
> 
> 8187145: (Tree)TableView with null selectionModel: throws NPE on sorting
> 
> Reviewed-by: aghaisas, kcr

This pull request has now been integrated.

Changeset: 95bc1eeb
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/95bc1eeb160fb487256a9cf37ac2c7da34122e0a
Stats:     469 lines in 15 files changed: 378 ins; 12 del; 79 mod

8187145: (Tree)TableView with null selectionModel: throws NPE on sorting

Backport-of: 58376eb844866f7e2fea726865eb2f821b09752f

-------------

PR: https://git.openjdk.org/jfx17u/pull/123

From jvos at openjdk.org  Mon Mar 13 19:42:46 2023
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 13 Mar 2023 19:42:46 GMT
Subject: [jfx17u] RFR: 8296413: Tree/TableView with null focus model throws NPE
 in queryAccessibleAttribute()
Message-ID: <nJexpj2lVU1U273EcEU3h0H9oM4TamG_-bpseL9oxzo=.fb5860c2-8f49-4688-9f6a-6fe5e8c31257@github.com>

Almost clean patch (apart from 3 (c) dates) for 
8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute()

Reviewed-by: arapte

-------------

Commit messages:
 - 8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute()

Changes: https://git.openjdk.org/jfx17u/pull/124/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=124&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296413
  Stats: 235 lines in 8 files changed: 181 ins; 26 del; 28 mod
  Patch: https://git.openjdk.org/jfx17u/pull/124.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/124/head:pull/124

PR: https://git.openjdk.org/jfx17u/pull/124

From kcr at openjdk.org  Mon Mar 13 21:47:45 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 21:47:45 GMT
Subject: [jfx17u] RFR: 8296413: Tree/TableView with null focus model throws
 NPE in queryAccessibleAttribute()
In-Reply-To: <nJexpj2lVU1U273EcEU3h0H9oM4TamG_-bpseL9oxzo=.fb5860c2-8f49-4688-9f6a-6fe5e8c31257@github.com>
References: <nJexpj2lVU1U273EcEU3h0H9oM4TamG_-bpseL9oxzo=.fb5860c2-8f49-4688-9f6a-6fe5e8c31257@github.com>
Message-ID: <b2tGoyLYJrNeWqC2dSnuRwB-l5Xuf3eVqEQTsW0QEUE=.9512a845-c98a-4a8c-9e66-dd448c0f2141@github.com>

On Mon, 13 Mar 2023 19:36:34 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean patch (apart from 3 (c) dates) for 
> 8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute()
> 
> Reviewed-by: arapte

Marked as reviewed by kcr (Lead).

-------------

PR: https://git.openjdk.org/jfx17u/pull/124

From kcr at openjdk.org  Mon Mar 13 22:06:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:06:58 GMT
Subject: [jfx17u] RFR: 8302294: Cherry-pick WebKit 615.1 stabilization fixes
Message-ID: <-1x8JikmtinArDizYHO3RKdBiTDtfvF7fHKPHoewSS8=.372a07d8-2097-4d50-baff-bd73150a76da@github.com>

Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

-------------

Commit messages:
 - 8302294: Cherry-pick WebKit 615.1 stabilization fixes

Changes: https://git.openjdk.org/jfx17u/pull/125/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302294
  Stats: 1797 lines in 198 files changed: 834 ins; 508 del; 455 mod
  Patch: https://git.openjdk.org/jfx17u/pull/125.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/125/head:pull/125

PR: https://git.openjdk.org/jfx17u/pull/125

From kcr at openjdk.org  Mon Mar 13 22:08:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:08:06 GMT
Subject: [jfx11u] RFR: 8302294: Cherry-pick WebKit 615.1 stabilization fixes
Message-ID: <zAjfUmmh4An1jqznAIjN2TQYyjcIVFORI_BJJuXQhOs=.b21dd194-0aae-48bf-afc0-47135234d676@github.com>

Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

-------------

Commit messages:
 - 8302294: Cherry-pick WebKit 615.1 stabilization fixes

Changes: https://git.openjdk.org/jfx11u/pull/135/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302294
  Stats: 1797 lines in 198 files changed: 834 ins; 508 del; 455 mod
  Patch: https://git.openjdk.org/jfx11u/pull/135.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/135/head:pull/135

PR: https://git.openjdk.org/jfx11u/pull/135

From kcr at openjdk.org  Mon Mar 13 22:14:18 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:14:18 GMT
Subject: [jfx17u] Integrated: 8302294: Cherry-pick WebKit 615.1 stabilization
 fixes
In-Reply-To: <-1x8JikmtinArDizYHO3RKdBiTDtfvF7fHKPHoewSS8=.372a07d8-2097-4d50-baff-bd73150a76da@github.com>
References: <-1x8JikmtinArDizYHO3RKdBiTDtfvF7fHKPHoewSS8=.372a07d8-2097-4d50-baff-bd73150a76da@github.com>
Message-ID: <uZyFo3zc6OgxwoJ5Bbs72uYjyECgcJBjtvofqPo1xNA=.ddf33c5d-f0bc-4ae3-b051-1be17bb461ee@github.com>

On Mon, 13 Mar 2023 22:00:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

This pull request has now been integrated.

Changeset: 8aa7d21a
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/8aa7d21a34cff3355a1d014f6f1524829bacd2f0
Stats:     1797 lines in 198 files changed: 834 ins; 508 del; 455 mod

8302294: Cherry-pick WebKit 615.1 stabilization fixes

Backport-of: 97ae4b87c7e2ce0605ff051c82d48328f83a94ca

-------------

PR: https://git.openjdk.org/jfx17u/pull/125

From kcr at openjdk.org  Mon Mar 13 22:16:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:16:54 GMT
Subject: [jfx11u] Integrated: 8302294: Cherry-pick WebKit 615.1 stabilization
 fixes
In-Reply-To: <zAjfUmmh4An1jqznAIjN2TQYyjcIVFORI_BJJuXQhOs=.b21dd194-0aae-48bf-afc0-47135234d676@github.com>
References: <zAjfUmmh4An1jqznAIjN2TQYyjcIVFORI_BJJuXQhOs=.b21dd194-0aae-48bf-afc0-47135234d676@github.com>
Message-ID: <jGfwSpaqTRF2RMyaFU0taUrBQSKcC7maiZtNPPIXcXU=.f8a71b52-10ec-4775-824e-81e68ddd9b0a@github.com>

On Mon, 13 Mar 2023 21:59:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

This pull request has now been integrated.

Changeset: c38fcb2e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/c38fcb2ebae04dee1341f3ed609f539904e913c3
Stats:     1797 lines in 198 files changed: 834 ins; 508 del; 455 mod

8302294: Cherry-pick WebKit 615.1 stabilization fixes

Backport-of: 97ae4b87c7e2ce0605ff051c82d48328f83a94ca

-------------

PR: https://git.openjdk.org/jfx11u/pull/135

From kcr at openjdk.org  Mon Mar 13 22:24:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:24:58 GMT
Subject: [jfx11u] RFR: 8302684: Cherry-pick WebKit 615.1 stabilization fixes
 (2)
Message-ID: <4n4lQrebLdw3hDvc-GDpm0dnWuYF86JAMOI2o9V3-G0=.f8858705-3808-4dcd-977e-76fa6a3f9fa0@github.com>

Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

-------------

Commit messages:
 - 8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)

Changes: https://git.openjdk.org/jfx11u/pull/136/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302684
  Stats: 34 lines in 14 files changed: 18 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jfx11u/pull/136.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/136/head:pull/136

PR: https://git.openjdk.org/jfx11u/pull/136

From kcr at openjdk.org  Mon Mar 13 22:26:01 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:26:01 GMT
Subject: [jfx17u] RFR: 8302684: Cherry-pick WebKit 615.1 stabilization fixes
 (2)
Message-ID: <Zx1oUj90Y2QbQhl-5NOI_l6_ZGNCSgtfaifHsZcnem4=.8e8f99f4-d8f9-4360-adec-53c1af690543@github.com>

Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

-------------

Commit messages:
 - 8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)

Changes: https://git.openjdk.org/jfx17u/pull/126/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302684
  Stats: 34 lines in 14 files changed: 18 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jfx17u/pull/126.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/126/head:pull/126

PR: https://git.openjdk.org/jfx17u/pull/126

From kcr at openjdk.org  Mon Mar 13 22:31:02 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:31:02 GMT
Subject: [jfx17u] Integrated: 8302684: Cherry-pick WebKit 615.1 stabilization
 fixes (2)
In-Reply-To: <Zx1oUj90Y2QbQhl-5NOI_l6_ZGNCSgtfaifHsZcnem4=.8e8f99f4-d8f9-4360-adec-53c1af690543@github.com>
References: <Zx1oUj90Y2QbQhl-5NOI_l6_ZGNCSgtfaifHsZcnem4=.8e8f99f4-d8f9-4360-adec-53c1af690543@github.com>
Message-ID: <mlnTEkMl3_iMO0w_xWnpWb6BnjhHD-xi3CknKqP45B4=.75361bc0-b3db-4be7-bade-067954c022ff@github.com>

On Mon, 13 Mar 2023 22:18:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

This pull request has now been integrated.

Changeset: 0869711c
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/0869711ce3509ad4ddfd4808a0b8bce8ce0138d8
Stats:     34 lines in 14 files changed: 18 ins; 1 del; 15 mod

8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)

Backport-of: 67c2b7a13b5d3378c1006b8fd3af28aa8eb49c25

-------------

PR: https://git.openjdk.org/jfx17u/pull/126

From kcr at openjdk.org  Mon Mar 13 22:31:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:31:58 GMT
Subject: [jfx11u] Integrated: 8302684: Cherry-pick WebKit 615.1 stabilization
 fixes (2)
In-Reply-To: <4n4lQrebLdw3hDvc-GDpm0dnWuYF86JAMOI2o9V3-G0=.f8858705-3808-4dcd-977e-76fa6a3f9fa0@github.com>
References: <4n4lQrebLdw3hDvc-GDpm0dnWuYF86JAMOI2o9V3-G0=.f8858705-3808-4dcd-977e-76fa6a3f9fa0@github.com>
Message-ID: <F12Yp5iSVvMBPy_qhj1H41KKVx8oOxWVOVO99jETM7g=.d19a39df-7446-4121-ab95-5fc16f7b0c6a@github.com>

On Mon, 13 Mar 2023 22:17:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

This pull request has now been integrated.

Changeset: a1057f8b
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/a1057f8bc665cfe4ee8d6f397471e6caa22a922f
Stats:     34 lines in 14 files changed: 18 ins; 1 del; 15 mod

8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)

Backport-of: 67c2b7a13b5d3378c1006b8fd3af28aa8eb49c25

-------------

PR: https://git.openjdk.org/jfx11u/pull/136

From kcr at openjdk.org  Mon Mar 13 22:41:07 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:41:07 GMT
Subject: [jfx17u] RFR: 8301022: Video distortion is observed while playing
 youtube video
Message-ID: <QYR5wKGM6Fmyauj6eqFBY3GWqboqI_78Z1eN8NIbn2k=.2f8553c5-f318-46c5-a5e6-91e59e0ddeed@github.com>

Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

-------------

Commit messages:
 - 8301022: Video distortion is observed while playing youtube video

Changes: https://git.openjdk.org/jfx17u/pull/127/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301022
  Stats: 1527 lines in 4 files changed: 1527 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/127.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/127/head:pull/127

PR: https://git.openjdk.org/jfx17u/pull/127

From kcr at openjdk.org  Mon Mar 13 22:41:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:41:17 GMT
Subject: [jfx11u] RFR: 8301022: Video distortion is observed while playing
 youtube video
Message-ID: <sDXkN0A63GVwyikPT9GMVc8kOkF4Lh9h94uqhCwMSeM=.03ebc0d9-fff1-4b69-8172-7c969d78970b@github.com>

Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

-------------

Commit messages:
 - 8301022: Video distortion is observed while playing youtube video

Changes: https://git.openjdk.org/jfx11u/pull/137/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301022
  Stats: 1527 lines in 4 files changed: 1527 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx11u/pull/137.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/137/head:pull/137

PR: https://git.openjdk.org/jfx11u/pull/137

From kcr at openjdk.org  Mon Mar 13 22:42:52 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:42:52 GMT
Subject: [jfx20u] RFR: 8299977: Update WebKit to 615.1
Message-ID: <gsBm31a17LdXMKBl_kBFeHbR2KXDmNZLRdXUIqW0YPY=.3e7cc7db-4161-4fa8-b60b-ec763b377700@github.com>

Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

-------------

Commit messages:
 - 8299977: Update WebKit to 615.1

Changes: https://git.openjdk.org/jfx20u/pull/3/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=3&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299977
  Stats: 197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod
  Patch: https://git.openjdk.org/jfx20u/pull/3.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/3/head:pull/3

PR: https://git.openjdk.org/jfx20u/pull/3

From kcr at openjdk.org  Mon Mar 13 22:43:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:43:17 GMT
Subject: [jfx20u] Integrated: 8299977: Update WebKit to 615.1
In-Reply-To: <gsBm31a17LdXMKBl_kBFeHbR2KXDmNZLRdXUIqW0YPY=.3e7cc7db-4161-4fa8-b60b-ec763b377700@github.com>
References: <gsBm31a17LdXMKBl_kBFeHbR2KXDmNZLRdXUIqW0YPY=.3e7cc7db-4161-4fa8-b60b-ec763b377700@github.com>
Message-ID: <9O9lhKMmq1blzWkCOtojDjznnZuTI2kzRjsIGckfavY=.610e1862-8180-49ed-acba-fc4a8fc59e31@github.com>

On Mon, 13 Mar 2023 22:23:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

This pull request has now been integrated.

Changeset: 27af3949
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/27af3949322927fbb4c371714e4b98bcf836d0c6
Stats:     197124 lines in 5579 files changed: 116283 ins; 42814 del; 38027 mod

8299977: Update WebKit to 615.1

Backport-of: 301bbd6409d463c4f789e2b3dcb6b2ea200d7373

-------------

PR: https://git.openjdk.org/jfx20u/pull/3

From kcr at openjdk.org  Mon Mar 13 22:52:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:52:35 GMT
Subject: [jfx11u] Integrated: 8301022: Video distortion is observed while
 playing youtube video
In-Reply-To: <sDXkN0A63GVwyikPT9GMVc8kOkF4Lh9h94uqhCwMSeM=.03ebc0d9-fff1-4b69-8172-7c969d78970b@github.com>
References: <sDXkN0A63GVwyikPT9GMVc8kOkF4Lh9h94uqhCwMSeM=.03ebc0d9-fff1-4b69-8172-7c969d78970b@github.com>
Message-ID: <LedOLuVQUzxFDdJSGTtj67SoJq8QGQ7CSL-GK1wOr4U=.78dbd63e-494c-410a-b20b-27d5b6fef45c@github.com>

On Mon, 13 Mar 2023 22:32:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

This pull request has now been integrated.

Changeset: d033b06f
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/d033b06fe672e4716c9ea500a688147114c1a662
Stats:     1527 lines in 4 files changed: 1527 ins; 0 del; 0 mod

8301022: Video distortion is observed while playing youtube video

Backport-of: 14883a296ac08a91fc24570a7479a6c8c2117643

-------------

PR: https://git.openjdk.org/jfx11u/pull/137

From kcr at openjdk.org  Mon Mar 13 22:53:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 22:53:30 GMT
Subject: [jfx17u] Integrated: 8301022: Video distortion is observed while
 playing youtube video
In-Reply-To: <QYR5wKGM6Fmyauj6eqFBY3GWqboqI_78Z1eN8NIbn2k=.2f8553c5-f318-46c5-a5e6-91e59e0ddeed@github.com>
References: <QYR5wKGM6Fmyauj6eqFBY3GWqboqI_78Z1eN8NIbn2k=.2f8553c5-f318-46c5-a5e6-91e59e0ddeed@github.com>
Message-ID: <tTaiOK3zXE9hUFpKlTmXK_xgtgJdh51iSi7usW5j5bE=.9ce8245e-2deb-421b-b54a-b6fc970723cf@github.com>

On Mon, 13 Mar 2023 22:32:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

This pull request has now been integrated.

Changeset: 2419ff30
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/2419ff30906b788a433bdc6d4c145612b3268edc
Stats:     1527 lines in 4 files changed: 1527 ins; 0 del; 0 mod

8301022: Video distortion is observed while playing youtube video

Backport-of: 14883a296ac08a91fc24570a7479a6c8c2117643

-------------

PR: https://git.openjdk.org/jfx17u/pull/127

From kcr at openjdk.org  Mon Mar 13 23:33:23 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:33:23 GMT
Subject: [jfx17u] Integrated: 8303217: Webview loaded webpage is not showing
 play, volume related buttons for embeded Audio/Video elements
Message-ID: <tsJX_9PXh7IbusO-wKx9GbQKqyapGPsIFwVe6J4KXk8=.73e5f73e-a1c4-4349-8790-a378509e8dfc@github.com>

Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

-------------

Commit messages:
 - 8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements

Changes: https://git.openjdk.org/jfx17u/pull/128/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=128&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303217
  Stats: 400 lines in 18 files changed: 396 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jfx17u/pull/128.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/128/head:pull/128

PR: https://git.openjdk.org/jfx17u/pull/128

From kcr at openjdk.org  Mon Mar 13 23:33:24 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:33:24 GMT
Subject: [jfx17u] Integrated: 8303217: Webview loaded webpage is not showing
 play, volume related buttons for embeded Audio/Video elements
In-Reply-To: <tsJX_9PXh7IbusO-wKx9GbQKqyapGPsIFwVe6J4KXk8=.73e5f73e-a1c4-4349-8790-a378509e8dfc@github.com>
References: <tsJX_9PXh7IbusO-wKx9GbQKqyapGPsIFwVe6J4KXk8=.73e5f73e-a1c4-4349-8790-a378509e8dfc@github.com>
Message-ID: <it3BuxOGGLodSA99GROQhREIYJy7dYbuwMJiQNFCNMM=.8d544ab6-804d-4d48-b8c1-5d6152133ca1@github.com>

On Mon, 13 Mar 2023 23:22:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx17u`. Tested in connection with all other WebKit backports in `jfx-kcr-17.0.7` branch.

This pull request has now been integrated.

Changeset: 55f5576a
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/55f5576a85a3d1ab7f1b149318b01851d6c3ac86
Stats:     400 lines in 18 files changed: 396 ins; 3 del; 1 mod

8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements
8300954: HTML default Range input control not rendered

Backport-of: bbdc59984a7f6427a5ad8b8ad39aa93ee3b4abbe

-------------

PR: https://git.openjdk.org/jfx17u/pull/128

From kcr at openjdk.org  Mon Mar 13 23:33:31 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:33:31 GMT
Subject: [jfx11u] Integrated: 8303217: Webview loaded webpage is not showing
 play, volume related buttons for embeded Audio/Video elements
Message-ID: <MxJWSz1X3DrtN67HdZQM7oCQOQd4vxtWsFXH1fMh7J8=.64afeeed-2478-4758-9f8b-7e58cb0e108b@github.com>

Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

-------------

Commit messages:
 - 8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements

Changes: https://git.openjdk.org/jfx11u/pull/138/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=138&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303217
  Stats: 400 lines in 18 files changed: 396 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jfx11u/pull/138.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/138/head:pull/138

PR: https://git.openjdk.org/jfx11u/pull/138

From kcr at openjdk.org  Mon Mar 13 23:33:32 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:33:32 GMT
Subject: [jfx11u] Integrated: 8303217: Webview loaded webpage is not showing
 play, volume related buttons for embeded Audio/Video elements
In-Reply-To: <MxJWSz1X3DrtN67HdZQM7oCQOQd4vxtWsFXH1fMh7J8=.64afeeed-2478-4758-9f8b-7e58cb0e108b@github.com>
References: <MxJWSz1X3DrtN67HdZQM7oCQOQd4vxtWsFXH1fMh7J8=.64afeeed-2478-4758-9f8b-7e58cb0e108b@github.com>
Message-ID: <KnlcrOW1kbMqb1SZfnxrOUgHqjiaMwGPXv9eJ2gmX88=.dd5addfc-0909-4df4-abc1-66f275d4253f@github.com>

On Mon, 13 Mar 2023 23:22:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx11u`. Tested in connection with all other WebKit backports in `jfx-kcr-11.0.19` branch.

This pull request has now been integrated.

Changeset: e036712d
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/e036712d1178e2ff53d271b39fe17a48822d38af
Stats:     400 lines in 18 files changed: 396 ins; 3 del; 1 mod

8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements
8300954: HTML default Range input control not rendered

Backport-of: bbdc59984a7f6427a5ad8b8ad39aa93ee3b4abbe

-------------

PR: https://git.openjdk.org/jfx11u/pull/138

From kcr at openjdk.org  Mon Mar 13 23:34:31 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:34:31 GMT
Subject: [jfx20u] RFR: 8301712: [linux] Crash on exit from WebKit 615.1
Message-ID: <gZi9mUly8sg-NGBa2M4I5QIWlyd1y_HtemmuUuRwmoY=.cdb95057-f810-42ac-9416-02ec26480c41@github.com>

Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

-------------

Commit messages:
 - 8301712: [linux] Crash on exit from WebKit 615.1

Changes: https://git.openjdk.org/jfx20u/pull/4/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=4&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301712
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx20u/pull/4.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/4/head:pull/4

PR: https://git.openjdk.org/jfx20u/pull/4

From kcr at openjdk.org  Mon Mar 13 23:41:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:41:09 GMT
Subject: [jfx20u] Integrated: 8301712: [linux] Crash on exit from WebKit 615.1
In-Reply-To: <gZi9mUly8sg-NGBa2M4I5QIWlyd1y_HtemmuUuRwmoY=.cdb95057-f810-42ac-9416-02ec26480c41@github.com>
References: <gZi9mUly8sg-NGBa2M4I5QIWlyd1y_HtemmuUuRwmoY=.cdb95057-f810-42ac-9416-02ec26480c41@github.com>
Message-ID: <snjwzYVVBFx7H9zUGzKhFUBCY4ZTWpxAFtAGvbQqS6g=.ea6b10a1-3ca0-451f-b46a-25854f51edc3@github.com>

On Mon, 13 Mar 2023 23:26:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

This pull request has now been integrated.

Changeset: e43e56bc
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/e43e56bc0e3dd3d7aedd87b45131157faa043939
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8301712: [linux] Crash on exit from WebKit 615.1

Backport-of: 13d8df31e7bc4336d01ec859e127756928db30d4

-------------

PR: https://git.openjdk.org/jfx20u/pull/4

From kcr at openjdk.org  Mon Mar 13 23:50:33 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:50:33 GMT
Subject: [jfx20u] RFR: 8302294: Cherry-pick WebKit 615.1 stabilization fixes
Message-ID: <hO3pNOGmtyMGhO1leytTTuweLDe5qRNhKS3q8Xq1GlU=.6d0da5b1-5f1f-4489-9794-336d5fbdd2c7@github.com>

Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

-------------

Commit messages:
 - 8302294: Cherry-pick WebKit 615.1 stabilization fixes

Changes: https://git.openjdk.org/jfx20u/pull/5/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=5&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302294
  Stats: 1797 lines in 198 files changed: 834 ins; 508 del; 455 mod
  Patch: https://git.openjdk.org/jfx20u/pull/5.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/5/head:pull/5

PR: https://git.openjdk.org/jfx20u/pull/5

From kcr at openjdk.org  Mon Mar 13 23:54:20 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 13 Mar 2023 23:54:20 GMT
Subject: [jfx20u] Integrated: 8302294: Cherry-pick WebKit 615.1 stabilization
 fixes
In-Reply-To: <hO3pNOGmtyMGhO1leytTTuweLDe5qRNhKS3q8Xq1GlU=.6d0da5b1-5f1f-4489-9794-336d5fbdd2c7@github.com>
References: <hO3pNOGmtyMGhO1leytTTuweLDe5qRNhKS3q8Xq1GlU=.6d0da5b1-5f1f-4489-9794-336d5fbdd2c7@github.com>
Message-ID: <dmBIDaiWxWnWqhLL_NJt4wnUABt5jYcwxew8C6uggIs=.66acbadf-a492-449d-9fec-b5ea8ecb74e8@github.com>

On Mon, 13 Mar 2023 23:43:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

This pull request has now been integrated.

Changeset: 2bb9b731
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/2bb9b73155410a17a3c65fdafaae3ee49cc1bc0b
Stats:     1797 lines in 198 files changed: 834 ins; 508 del; 455 mod

8302294: Cherry-pick WebKit 615.1 stabilization fixes

Backport-of: 97ae4b87c7e2ce0605ff051c82d48328f83a94ca

-------------

PR: https://git.openjdk.org/jfx20u/pull/5

From kcr at openjdk.org  Tue Mar 14 00:04:37 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 00:04:37 GMT
Subject: [jfx20u] RFR: 8302684: Cherry-pick WebKit 615.1 stabilization fixes
 (2)
Message-ID: <SbA-93x2iBJq0kTSTC5oIT-_lZaD71n63zYiff3c60A=.be401cf1-135b-4e2b-b2a8-bac71d7b5587@github.com>

Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

-------------

Commit messages:
 - 8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)

Changes: https://git.openjdk.org/jfx20u/pull/6/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=6&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302684
  Stats: 34 lines in 14 files changed: 18 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jfx20u/pull/6.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/6/head:pull/6

PR: https://git.openjdk.org/jfx20u/pull/6

From kcr at openjdk.org  Tue Mar 14 00:08:48 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 00:08:48 GMT
Subject: [jfx20u] Integrated: 8302684: Cherry-pick WebKit 615.1 stabilization
 fixes (2)
In-Reply-To: <SbA-93x2iBJq0kTSTC5oIT-_lZaD71n63zYiff3c60A=.be401cf1-135b-4e2b-b2a8-bac71d7b5587@github.com>
References: <SbA-93x2iBJq0kTSTC5oIT-_lZaD71n63zYiff3c60A=.be401cf1-135b-4e2b-b2a8-bac71d7b5587@github.com>
Message-ID: <Ypsagl5Zh3014CV5lFs5K8xq_GzNtvBRDhS99oRZJEg=.e5f40063-c673-46e7-8211-b2868cbf006d@github.com>

On Mon, 13 Mar 2023 23:57:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

This pull request has now been integrated.

Changeset: 32a50558
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/32a5055805a53ba33b23d26e732500aa80c8b1f3
Stats:     34 lines in 14 files changed: 18 ins; 1 del; 15 mod

8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)

Backport-of: 67c2b7a13b5d3378c1006b8fd3af28aa8eb49c25

-------------

PR: https://git.openjdk.org/jfx20u/pull/6

From kcr at openjdk.org  Tue Mar 14 00:18:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 00:18:17 GMT
Subject: [jfx20u] Integrated: 8301022: Video distortion is observed while
 playing youtube video
Message-ID: <EHguHyf_hbMTjRU_cmY7JVzmOipSgbKAEmg7UtlTUUY=.2d920c62-540c-4836-9e80-569a728ed0a6@github.com>

Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

-------------

Commit messages:
 - 8301022: Video distortion is observed while playing youtube video

Changes: https://git.openjdk.org/jfx20u/pull/7/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=7&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301022
  Stats: 1527 lines in 4 files changed: 1527 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx20u/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/7/head:pull/7

PR: https://git.openjdk.org/jfx20u/pull/7

From kcr at openjdk.org  Tue Mar 14 00:18:17 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 00:18:17 GMT
Subject: [jfx20u] Integrated: 8301022: Video distortion is observed while
 playing youtube video
In-Reply-To: <EHguHyf_hbMTjRU_cmY7JVzmOipSgbKAEmg7UtlTUUY=.2d920c62-540c-4836-9e80-569a728ed0a6@github.com>
References: <EHguHyf_hbMTjRU_cmY7JVzmOipSgbKAEmg7UtlTUUY=.2d920c62-540c-4836-9e80-569a728ed0a6@github.com>
Message-ID: <g67iMO1u6u5hsIwaVYJRqG-bDm0D-cJ_uL67rBDqsfs=.b77dcf9d-d38c-4760-bdba-d17786b9cfc9@github.com>

On Tue, 14 Mar 2023 00:08:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

This pull request has now been integrated.

Changeset: 64d8821f
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/64d8821ff7e1f5d555e33a4b5d7d6b690d46721b
Stats:     1527 lines in 4 files changed: 1527 ins; 0 del; 0 mod

8301022: Video distortion is observed while playing youtube video

Backport-of: 14883a296ac08a91fc24570a7479a6c8c2117643

-------------

PR: https://git.openjdk.org/jfx20u/pull/7

From kcr at openjdk.org  Tue Mar 14 00:26:44 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 00:26:44 GMT
Subject: [jfx20u] Integrated: 8303217: Webview loaded webpage is not showing
 play, volume related buttons for embeded Audio/Video elements
Message-ID: <oBm6rKCGlVhpyqbrlesSUW7BnGuoVRmIU4vstcHaBlA=.cee112c1-ee04-4fc4-a8a9-d87e1cc70e08@github.com>

Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

-------------

Commit messages:
 - 8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements

Changes: https://git.openjdk.org/jfx20u/pull/8/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=8&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303217
  Stats: 400 lines in 18 files changed: 396 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jfx20u/pull/8.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u pull/8/head:pull/8

PR: https://git.openjdk.org/jfx20u/pull/8

From kcr at openjdk.org  Tue Mar 14 00:26:46 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 00:26:46 GMT
Subject: [jfx20u] Integrated: 8303217: Webview loaded webpage is not showing
 play, volume related buttons for embeded Audio/Video elements
In-Reply-To: <oBm6rKCGlVhpyqbrlesSUW7BnGuoVRmIU4vstcHaBlA=.cee112c1-ee04-4fc4-a8a9-d87e1cc70e08@github.com>
References: <oBm6rKCGlVhpyqbrlesSUW7BnGuoVRmIU4vstcHaBlA=.cee112c1-ee04-4fc4-a8a9-d87e1cc70e08@github.com>
Message-ID: <HNM-f6NeiW0lomgxX86VTsGs8zSaMmc-rfgCmKlBfbA=.b0ba599d-79ee-4247-b19e-861735c530c1@github.com>

On Tue, 14 Mar 2023 00:16:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport to `jfx20u`. Tested in connection with all other WebKit backports in `jfx-20.0.1` branch.

This pull request has now been integrated.

Changeset: 0bf898ef
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/0bf898efa346b05a416621fab625aa1cd72f300a
Stats:     400 lines in 18 files changed: 396 ins; 3 del; 1 mod

8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements
8300954: HTML default Range input control not rendered

Backport-of: bbdc59984a7f6427a5ad8b8ad39aa93ee3b4abbe

-------------

PR: https://git.openjdk.org/jfx20u/pull/8

From jvos at openjdk.org  Tue Mar 14 08:17:12 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 14 Mar 2023 08:17:12 GMT
Subject: [jfx17u] RFR: 8304098: [testbug] Test compilation failure in
 ControlUtils.java after JDK-8292353
Message-ID: <-n4ya3PZLiq0qNmizbr454V4ouGt5JS4sHnJONuv5AM=.ce56bd2e-6c29-45ca-9e57-d1d8054160b8@github.com>

Remove new instanceof pattern (which is not supported in 11)
Fix JDK-8304098

-------------

Commit messages:
 - Remove new instanceof pattern (which is not supported in 11)

Changes: https://git.openjdk.org/jfx17u/pull/129/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304098
  Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jfx17u/pull/129.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/129/head:pull/129

PR: https://git.openjdk.org/jfx17u/pull/129

From hmeda at openjdk.org  Tue Mar 14 08:42:55 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Tue, 14 Mar 2023 08:42:55 GMT
Subject: RFR: 8301009: Update libxml2 to 2.10.3
Message-ID: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>

Updated Libxml2 to v2.10.3. verfied build and sanity testing on windows, mac and Linux platforms.
No issue observed.

-------------

Commit messages:
 - White space corrections
 - white space correction
 - update libxml2.md
 - Remove unwanted files
 - configure libxml to v2.10.3 on linux
 - configure libxml v2.10.3 on windows
 - Update libxml to v2.10.3

Changes: https://git.openjdk.org/jfx/pull/1058/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1058&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301009
  Stats: 6301 lines in 80 files changed: 1128 ins; 4562 del; 611 mod
  Patch: https://git.openjdk.org/jfx/pull/1058.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1058/head:pull/1058

PR: https://git.openjdk.org/jfx/pull/1058

From arapte at openjdk.org  Tue Mar 14 09:38:59 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 14 Mar 2023 09:38:59 GMT
Subject: RFR: JDK-8302355: Public API for Toolkit.canStartNestedEventLoop()
 [v3]
In-Reply-To: <zFzSimwF_d_6jySmfVZ1T4vGVzL_CAKkMyexQGQaTdc=.f339efd4-9094-4550-b8ed-2b82d367fff3@github.com>
References: <ML2teXgqOmqbv79T8EO7Rizr9thy5PiVOwul6GOcc5g=.c4ac3d82-f7eb-4662-9bc6-564ba7eb5ea4@github.com>
 <zFzSimwF_d_6jySmfVZ1T4vGVzL_CAKkMyexQGQaTdc=.f339efd4-9094-4550-b8ed-2b82d367fff3@github.com>
Message-ID: <v--GjDWhNUiCt_GXCG8eaN9aWJY3rthwvF3oOkdbxFE=.5159612d-2faa-4874-b4f5-44731bfb68d3@github.com>

On Sat, 18 Feb 2023 13:30:42 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR adds the last missing method for dealing with nested event loops.
>> As also written in the ticket, there is currently no (public) way to find out whether it is safe to start an event loop now or not.
>> Classes like `Dialog` check via `Toolkit.getToolkit().canStartNestedEventLoop()` (sun api), if it safe to start a nested event loop before doing so.
>
> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8302355: Missing brace
>  - JDK-8302355: Improved javadoc

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.org/jfx/pull/1031

From mhanl at openjdk.org  Tue Mar 14 09:53:38 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 14 Mar 2023 09:53:38 GMT
Subject: Integrated: JDK-8302355: Public API for
 Toolkit.canStartNestedEventLoop()
In-Reply-To: <ML2teXgqOmqbv79T8EO7Rizr9thy5PiVOwul6GOcc5g=.c4ac3d82-f7eb-4662-9bc6-564ba7eb5ea4@github.com>
References: <ML2teXgqOmqbv79T8EO7Rizr9thy5PiVOwul6GOcc5g=.c4ac3d82-f7eb-4662-9bc6-564ba7eb5ea4@github.com>
Message-ID: <B1d9KmeoJNQNw5mD7gCDV0NTImHZRPVBA3wpjefSw4Y=.a0b67673-815a-4727-8279-2f9e21572210@github.com>

On Mon, 13 Feb 2023 19:31:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR adds the last missing method for dealing with nested event loops.
> As also written in the ticket, there is currently no (public) way to find out whether it is safe to start an event loop now or not.
> Classes like `Dialog` check via `Toolkit.getToolkit().canStartNestedEventLoop()` (sun api), if it safe to start a nested event loop before doing so.

This pull request has now been integrated.

Changeset: df22c410
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/df22c4108e3903b4d7bc1f67067ddbba1819d212
Stats:     159 lines in 4 files changed: 152 ins; 0 del; 7 mod

8302355: Public API for Toolkit.canStartNestedEventLoop()

Reviewed-by: kcr, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/1031

From kcr at openjdk.org  Tue Mar 14 11:39:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 14 Mar 2023 11:39:30 GMT
Subject: [jfx17u] RFR: 8304098: [testbug] Test compilation failure in
 ControlUtils.java after JDK-8292353
In-Reply-To: <-n4ya3PZLiq0qNmizbr454V4ouGt5JS4sHnJONuv5AM=.ce56bd2e-6c29-45ca-9e57-d1d8054160b8@github.com>
References: <-n4ya3PZLiq0qNmizbr454V4ouGt5JS4sHnJONuv5AM=.ce56bd2e-6c29-45ca-9e57-d1d8054160b8@github.com>
Message-ID: <m7AU1Vv6AayAWLi4nFp3Bg4PcjnXvaI2h2a8UrqQf0U=.0645c0e3-c491-454c-a95f-71f33be6cf30@github.com>

On Tue, 14 Mar 2023 08:11:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Remove new instanceof pattern (which is not supported in 11)
> Fix JDK-8304098

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx17u/pull/129

From jvos at openjdk.org  Tue Mar 14 11:50:38 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 14 Mar 2023 11:50:38 GMT
Subject: [jfx17u] Integrated: 8304098: [testbug] Test compilation failure in
 ControlUtils.java after JDK-8292353
In-Reply-To: <-n4ya3PZLiq0qNmizbr454V4ouGt5JS4sHnJONuv5AM=.ce56bd2e-6c29-45ca-9e57-d1d8054160b8@github.com>
References: <-n4ya3PZLiq0qNmizbr454V4ouGt5JS4sHnJONuv5AM=.ce56bd2e-6c29-45ca-9e57-d1d8054160b8@github.com>
Message-ID: <seOVBu8CS3FcC3VbsKmG2o5bLOsy20VTvt8YozFKWsk=.717aa118-cf03-438e-b322-2d118cd4f236@github.com>

On Tue, 14 Mar 2023 08:11:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Remove new instanceof pattern (which is not supported in 11)
> Fix JDK-8304098

This pull request has now been integrated.

Changeset: 5ff65569
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/5ff655690f3236c53c6ff0e7c65c1230396630b0
Stats:     12 lines in 2 files changed: 6 ins; 0 del; 6 mod

8304098: [testbug] Test compilation failure in ControlUtils.java after JDK-8292353

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx17u/pull/129

From arapte at openjdk.org  Tue Mar 14 13:13:35 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 14 Mar 2023 13:13:35 GMT
Subject: RFR: 8299968: Second call to Stage.setScene() create sizing issue
 with uiScale > 1.0 [v4]
In-Reply-To: <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
 <SJdZFOBHSmSyUqy0XZR1316i3iMp8AWdUeJRte2FgNg=.5dd74f02-f472-4abb-9748-f674fbdfc8f1@github.com>
Message-ID: <b9UrtioQMeZs2AkbASNLifK90RyFMyXa1TbcuY9AS1s=.4076557a-974b-4aac-a355-d2bff14b6cd7@github.com>

On Mon, 13 Mar 2023 14:58:53 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
>> 
>> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
>> 
>> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
>> 
>> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.
>
> Lukasz Kostyra has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - SetSceneScalingTest: Address review issues
>    
>    - Calculate robot.mouseMove coords based on Stage/Scene position
>    - Use stage.setOnShown() instead of addEventListener()
>  - GlassWindow: Fix Copy-Paste's Error with unnecessary View variable

Marked as reviewed by arapte (Reviewer).

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From lkostyra at openjdk.org  Tue Mar 14 13:33:05 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 14 Mar 2023 13:33:05 GMT
Subject: Integrated: 8299968: Second call to Stage.setScene() create sizing
 issue with uiScale > 1.0
In-Reply-To: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
References: <eGVivs3Mt2XcLGMt4DCrYNHYrV_4jXnV4wldSjI9TLI=.70f63842-0f7b-4f39-9c57-8fa2772c56d2@github.com>
Message-ID: <b6MuXXA2_StktPiDm5oSsJ_F4uLFHNW6LepdkZYvbnc=.954c5b08-5438-49ab-8b1a-6616c5512865@github.com>

On Tue, 7 Mar 2023 14:33:33 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Issue happened during setting a new Scene - updating a new View was done while the Window reference it kept was null. This caused it to default scaling values to 1.0f (or 100%) while processing a resize notification, which for high DPI screens with scaling different than 100% caused UI issues.
> 
> Resolved by splitting `_setView()` native call into two parts - first one sets the view, then back in JVM side we set a correct Window reference, then we trigger the notification. It has to be triggered from native side, because Windows backend of Glass sends back new width/height pulled from WinAPI `::GetClientRect()` call.
> 
> In process of working on this issue I also found another scenario causing the same problem - calling `Stage.setScene()` after `Stage.show()`. The patch fixed that case as well.
> 
> Added a system test which is supposed to check for above issues. I didn't limit it to run only on platforms with UI scaling enabled because it also serves as a good sanity check in case there are some other changes to code that might move/scale the UI unwantingly. I tested this patch both on macOS Ventura and Windows 11, with `d9c091f` all tests pass while without `d9c091f` on Windows tests `testShowAndSetScene` and `testSecondSetScene` fail as expected.

This pull request has now been integrated.

Changeset: 4051f161
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4051f1611646400b59ee871fb40399b933361ba2
Stats:     251 lines in 8 files changed: 247 ins; 4 del; 0 mod

8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0

Reviewed-by: kcr, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/1054

From jvos at openjdk.org  Tue Mar 14 14:46:43 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 14 Mar 2023 14:46:43 GMT
Subject: [jfx17u] Integrated: 8296413: Tree/TableView with null focus model
 throws NPE in queryAccessibleAttribute()
In-Reply-To: <nJexpj2lVU1U273EcEU3h0H9oM4TamG_-bpseL9oxzo=.fb5860c2-8f49-4688-9f6a-6fe5e8c31257@github.com>
References: <nJexpj2lVU1U273EcEU3h0H9oM4TamG_-bpseL9oxzo=.fb5860c2-8f49-4688-9f6a-6fe5e8c31257@github.com>
Message-ID: <OO65hfdYaOychbGsnHpArBlIFEv6hTwLB-EdNxYChvI=.0a4bd1b4-f85a-4574-a86c-c3bc5495c1df@github.com>

On Mon, 13 Mar 2023 19:36:34 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean patch (apart from 3 (c) dates) for 
> 8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute()
> 
> Reviewed-by: arapte

This pull request has now been integrated.

Changeset: a094252f
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/a094252fe7d4e66fdc8e87e6184397e78954748b
Stats:     235 lines in 8 files changed: 181 ins; 26 del; 28 mod

8296413: Tree/TableView with null focus model throws NPE in queryAccessibleAttribute()

Reviewed-by: kcr
Backport-of: e866a6c35c9040115dd62c6c04fd4b3d4d0e1324

-------------

PR: https://git.openjdk.org/jfx17u/pull/124

From kpk at openjdk.org  Wed Mar 15 11:04:33 2023
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 15 Mar 2023 11:04:33 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled controls
 with graphics
Message-ID: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>

Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.

Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.

Added unit test to validate the fix.

-------------

Commit messages:
 - Fix baseline alignment issue

Changes: https://git.openjdk.org/jfx/pull/1059/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1059&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8172849
  Stats: 49 lines in 2 files changed: 46 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1059.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1059/head:pull/1059

PR: https://git.openjdk.org/jfx/pull/1059

From aghaisas at openjdk.org  Wed Mar 15 12:19:37 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 15 Mar 2023 12:19:37 GMT
Subject: RFR: 8154038: Spinner's converter should update its editor
In-Reply-To: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
References: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
Message-ID: <ksqUFLJq7pEXu2Uq29yCrD40Re9m_-78EQST4SfM2UI=.53c5f92b-57d9-48e1-a8ae-4d8c7285abb7@github.com>

On Fri, 10 Mar 2023 11:38:56 GMT, Karthik P K <kpk at openjdk.org> wrote:

> When converter was changed, `setText` method of spinner was not invoked to update the spinner text using new converter.
> 
> Added a listener to converter property of `SpinnerValueFactory` to call `setText` so that spinner text is updated using new converter.
> 
> Added unit test to validate the fix. Along with spinner of Double type, added a spinner of Integer type as well so that the fix is validated using 2 types of spinner.

Changes requested by aghaisas (Reviewer).

modules/javafx.controls/src/main/java/javafx/scene/control/Spinner.java line 545:

> 543:                         value.bind(newFactory.valueProperty());
> 544:                         // Update the spinner editor when converter is changed.
> 545:                         newFactory.converterProperty().addListener((o, oldValue, newValue) -> {

The addition of ChangeListener is fine, but, this newly added ChangeListener should be removed from old valueFactory when `valueFactory` changes.
Please see the pattern used in `TimelineController` for rateListener.

modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1529:

> 1527:     }
> 1528: 
> 1529:     @Test public void testSpinnerEditorUpdateOnConverterChange() {

It is better to split this test case into two - one for each type of Spinner.

-------------

PR: https://git.openjdk.org/jfx/pull/1057

From angorya at openjdk.org  Wed Mar 15 18:13:33 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Mar 2023 18:13:33 GMT
Subject: RFR: 8154038: Spinner's converter should update its editor
In-Reply-To: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
References: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
Message-ID: <e9vHv9GhtRVLgj4Y2vUf4U7aoSPKx6e0zgscMM26PE0=.5459e32b-20e5-4b0e-80f9-7644ea81d802@github.com>

On Fri, 10 Mar 2023 11:38:56 GMT, Karthik P K <kpk at openjdk.org> wrote:

> When converter was changed, `setText` method of spinner was not invoked to update the spinner text using new converter.
> 
> Added a listener to converter property of `SpinnerValueFactory` to call `setText` so that spinner text is updated using new converter.
> 
> Added unit test to validate the fix. Along with spinner of Double type, added a spinner of Integer type as well so that the fix is validated using 2 types of spinner.

Added SpinnerPage to the MonkeyTester

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/pages/SpinnerPage.java

-------------

PR: https://git.openjdk.org/jfx/pull/1057

From angorya at openjdk.org  Wed Mar 15 19:01:34 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Mar 2023 19:01:34 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics
In-Reply-To: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
Message-ID: <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>

On Wed, 15 Mar 2023 10:58:14 GMT, Karthik P K <kpk at openjdk.org> wrote:

> Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.
> 
> Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.
> 
> Added unit test to validate the fix.

Verified the fix with the MonkeyTester.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2102:

> 2100:      ********************************************************************/
> 2101: 
> 2102:     //Test for JDK-8172849

minor: I would have used a javadoc comment instead of the big comment block
/** Test for JDK-8172849 */

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2136:

> 2134:      *                                                                              *
> 2135:      *******************************************************************************/
> 2136: 

Minor: I would have used a javadoc explaining the purpose of this class instead of generic "Helper classes".

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From kcr at openjdk.org  Wed Mar 15 21:14:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Mar 2023 21:14:30 GMT
Subject: RFR: 8301009: Update libxml2 to 2.10.3
In-Reply-To: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>
References: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>
Message-ID: <3iMgqCUxhwGmXVAs5MtHS0lPynYwySVZjPirCrmJ69Q=.f4d9abc8-b4d4-48cd-89be-d996f98d9100@github.com>

On Tue, 14 Mar 2023 08:04:04 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated Libxml2 to v2.10.3. verfied build and sanity testing on windows, mac and Linux platforms.
> No issue observed.

Looks good. The diffs are as expected for this version. I tested it on Windows and found no problems.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/1058

From angorya at openjdk.org  Wed Mar 15 22:37:33 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 15 Mar 2023 22:37:33 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <j5r9xXW0dcmCcuFyFKYQfCICyrRYgZ3a7ZeTyoJ4g3Q=.6ead1ab3-1bf6-4471-a7aa-2c7cd844eaa6@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

Tested this fix with the MonkeyTester app on Macos Ventura 13.1
https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java

Could not see any ill effects - navigation works, selection works, variable height cells work.

-------------

Marked as reviewed by angorya (Committer).

PR: https://git.openjdk.org/jfx/pull/1052

From kcr at openjdk.org  Wed Mar 15 22:53:29 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 15 Mar 2023 22:53:29 GMT
Subject: RFR: 8178368: Right alignment of text fields and alignment of
 prompt text works incorrectly [v9]
In-Reply-To: <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
 <_MOrpIlBi9vciLj6s2qT9pjcocQVz8_dH2KNxnDJyQQ=.5e5c84ab-10c8-4214-916e-1aa0f13bc153@github.com>
Message-ID: <eUw3z2eaTrEiQxfj5xCN06Z5RneGDkzPxjcbT7yD0BU=.694cb3e2-3177-43a0-b094-3b2d2a6de05c@github.com>

On Mon, 6 Mar 2023 13:12:05 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
>> 
>> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
>> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
>> 
>> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing white space

Looks good now.

-------------

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.org/jfx/pull/980

From kpk at openjdk.org  Thu Mar 16 04:32:36 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 16 Mar 2023 04:32:36 GMT
Subject: Integrated: 8178368: Right alignment of text fields and alignment of
 prompt text works incorrectly
In-Reply-To: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
References: <gUznwz1tSL3S5IeKvmn7k0JhObNBUkZdl1i9-zi4jJ4=.0bf63773-8ed7-48a3-b49f-fa506b78d4ee@github.com>
Message-ID: <XXpeuhBeKkh56Mu4i8qzKzXFeyDXdLkHUmCwWBhFXyA=.3eb8ab5f-1bc5-4096-8246-a5d7f12077eb@github.com>

On Wed, 21 Dec 2022 10:58:50 GMT, Karthik P K <kpk at openjdk.org> wrote:

> When Text width was more than TextField width, the logic to update `textTranslateX` in `updateCaretOff` method was causing the issue of unexpected behavior for Right and Center alignment.
> 
> Made changes to update `textTranslateX` in `updateCaretOff` method only when text width is less than text field width i.e `delta` is positive. 
> For both right and center alignments, the `textTranslateX` value calculated in `updateTextPos` method will be updated without any condition so that expected behavior is achieved for all scenarios of text width relative to text field width. 
> 
> Added unit tests to validate LEFT, CENTER and RIGHT alignments. RIGHT and CENTER alignment tests are expected to fail without the fix provided in this PR.

This pull request has now been integrated.

Changeset: 147d71fa
Author:    Karthik P K <kpk at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/147d71fa3cb2e0049ed2ae2bbeeb565fc5f95a91
Stats:     129 lines in 2 files changed: 87 ins; 27 del; 15 mod

8178368: Right alignment of text fields and alignment of prompt text works incorrectly

Reviewed-by: angorya, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/980

From kpk at openjdk.org  Thu Mar 16 06:12:27 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 16 Mar 2023 06:12:27 GMT
Subject: RFR: 8154038: Spinner's converter should update its editor [v2]
In-Reply-To: <ksqUFLJq7pEXu2Uq29yCrD40Re9m_-78EQST4SfM2UI=.53c5f92b-57d9-48e1-a8ae-4d8c7285abb7@github.com>
References: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
 <ksqUFLJq7pEXu2Uq29yCrD40Re9m_-78EQST4SfM2UI=.53c5f92b-57d9-48e1-a8ae-4d8c7285abb7@github.com>
Message-ID: <RVpWPwnpy1iNHxC9bo2dewC_2GlgNxzJaq0OfDmp8RM=.9d589b49-9511-4a8b-b847-967da3bf488a@github.com>

On Wed, 15 Mar 2023 12:15:14 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Spinner.java line 545:
> 
>> 543:                         value.bind(newFactory.valueProperty());
>> 544:                         // Update the spinner editor when converter is changed.
>> 545:                         newFactory.converterProperty().addListener((o, oldValue, newValue) -> {
> 
> The addition of ChangeListener is fine, but, this newly added ChangeListener should be removed from old valueFactory when `valueFactory` changes.
> Please see the pattern used in `TimelineController` for rateListener.

Updated the code. Please check

> modules/javafx.controls/src/test/java/test/javafx/scene/control/SpinnerTest.java line 1529:
> 
>> 1527:     }
>> 1528: 
>> 1529:     @Test public void testSpinnerEditorUpdateOnConverterChange() {
> 
> It is better to split this test case into two - one for each type of Spinner.

Created separate tests for each type of Spinner. Please check

-------------

PR: https://git.openjdk.org/jfx/pull/1057

From kpk at openjdk.org  Thu Mar 16 06:09:03 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 16 Mar 2023 06:09:03 GMT
Subject: RFR: 8154038: Spinner's converter should update its editor [v2]
In-Reply-To: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
References: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
Message-ID: <OjclAS6VUNjFcsfi8nju9LMV3dRQT0mafkUdvsyU-qI=.3163098b-6462-466a-9670-47670d7c1126@github.com>

> When converter was changed, `setText` method of spinner was not invoked to update the spinner text using new converter.
> 
> Added a listener to converter property of `SpinnerValueFactory` to call `setText` so that spinner text is updated using new converter.
> 
> Added unit test to validate the fix. Along with spinner of Double type, added a spinner of Integer type as well so that the fix is validated using 2 types of spinner.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1057/files
  - new: https://git.openjdk.org/jfx/pull/1057/files/a45ba023..f4376178

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1057&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1057&range=00-01

  Stats: 31 lines in 2 files changed: 20 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1057.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1057/head:pull/1057

PR: https://git.openjdk.org/jfx/pull/1057

From kpk at openjdk.org  Thu Mar 16 06:34:37 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 16 Mar 2023 06:34:37 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics
In-Reply-To: <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>
Message-ID: <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>

On Wed, 15 Mar 2023 18:18:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.
>> 
>> Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.
>> 
>> Added unit test to validate the fix.
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2102:
> 
>> 2100:      ********************************************************************/
>> 2101: 
>> 2102:     //Test for JDK-8172849
> 
> minor: I would have used a javadoc comment instead of the big comment block
> /** Test for JDK-8172849 */

Yes javadoc comment would look better. I used the comment block to keep it consistent with the other comments present in the same file. I think if changing, then better to change all the comment blocks in the file.
Please let me know your thoughts.

> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2136:
> 
>> 2134:      *                                                                              *
>> 2135:      *******************************************************************************/
>> 2136: 
> 
> Minor: I would have used a javadoc explaining the purpose of this class instead of generic "Helper classes".

Same comment as above. In addition to that, yes, updating the comment with actual purpose of the class would be better. I will update that once we decide if all the other comment blocks also should be changed or not.
Since there was no comment for this class, I added the comment so that it gets separated from "Tests for bug reports" tests.

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From jhendrikx at openjdk.org  Thu Mar 16 08:54:07 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 16 Mar 2023 08:54:07 GMT
Subject: RFR: JDK-8304323 Provide infrastructure to make it possible for
 properties to delay listener registration
Message-ID: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>

This PR contains changes to make it easier to implement properties which want to conserve resources until they're observed themselves.  

`isObserved` is promoted from `ObjectBinding` to the `ObservableValue` interface, allowing you to ask any `ObservableValue` if it is currently observed (ie. if it has any listeners registered on it).  All JavaFX `ObservableValue`s implementations are modified to implement this method.

The protected methods `observed` and `unobserved` are added to all extendable (non final) `ObservableValue`s provided by JavaFX.  The `observed` call back is only called when the observable currently has 0 listeners and will soon have 1 listener.  During the call back, `isObserved` still returns `false` (see below for why this was chosen).  The `unobserved` call back in only called when the last listener was removed and the observable has 0 listeners.  During the call back, `isObserved` will already return `false`.

The reason why `observed` is called before `isObserved` starts returning `true` (and also why `unobserved` works the opposite) is to make it easy to implement a parent-child relationship where a nested property becoming observed may need to trigger behavior in its parent. Given a parent class and two nested properties `foo` and `bar`:

     class FooProperty extends ObjectPropertyBase<Foo> {
          void observed() {
               nestedPropertyObserved();  // call to parent
          }

          void unobserved() {
               nestedPropertyUnobserved();  // call to parent
          }
     }

The parent may determine whether any of the properties is observed with a helper:

      private boolean isANestedPropertyObserved() {
           return foo.isObserved() || bar.isObserved();
      }

The `nestedPropertyObserved` and `nestedPropertyUnobserved` methods can now be implemented simply as:

      private void nestedPropertyObserved() {
            if (!isANestedPropertyObserved()) {
                // take action as no properties were observed before, but now one will become observed
            }
      }

      private void nestedPropertyUnobserved() {
            if (!isANestedPropertyObserved()) {
                // take action as a property was observed before, but the last listener is about to be removed
            }
      }

If `isObserved` would change immediately, this becomes more difficult as the observed status of the property that has just become observed would need to be excluded to determine if this is the first observation of a nested property or a later one.

- Add `isObserved` to `ObservableValue` to check if it is observed and implement it in all overriding classes
- Add `observed`/`unobserved` protected methods to all extendable observables
- Use *Base classes in a few places (avoids duplication code)
- Simplify `LazyObjectBinding`
- In `ObjectBinding`, `isObserved` has become public as it is specified by the `ObservableValue` interface now

-------------

Commit messages:
 - Add delayed listener registration support

Changes: https://git.openjdk.org/jfx/pull/1023/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1023&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304323
  Stats: 1225 lines in 43 files changed: 802 ins; 211 del; 212 mod
  Patch: https://git.openjdk.org/jfx/pull/1023.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1023/head:pull/1023

PR: https://git.openjdk.org/jfx/pull/1023

From sykora at openjdk.org  Thu Mar 16 11:35:26 2023
From: sykora at openjdk.org (Joeri Sykora)
Date: Thu, 16 Mar 2023 11:35:26 GMT
Subject: RFR: 8301009: Update libxml2 to 2.10.3
In-Reply-To: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>
References: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>
Message-ID: <YfOyjeEIeZ4jGDaH-5W0G33EFjtODIiE7ygUqnzXUdM=.45a4af61-099f-4532-b47a-60b68a02d7a9@github.com>

On Tue, 14 Mar 2023 08:04:04 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated Libxml2 to v2.10.3. verfied build and sanity testing on windows, mac and Linux platforms.
> No issue observed.

Building and running tests worked on windows, linux and macos.

-------------

Marked as reviewed by sykora (Author).

PR: https://git.openjdk.org/jfx/pull/1058

From hmeda at openjdk.org  Thu Mar 16 12:13:28 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 16 Mar 2023 12:13:28 GMT
Subject: Integrated: 8301009: Update libxml2 to 2.10.3
In-Reply-To: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>
References: <Hd5ozq-IwoYAw1quUP_A1i-XbmVyfa3zBRHJuBpbe6g=.99b87ee4-6b3d-4f93-8659-3f7244c87df9@github.com>
Message-ID: <NgSW-zoGvy9gpNaNfxbiX-uYCMKp_7cFHJx8zMGKDao=.197e40a3-a420-48df-af04-43556dd1ab7f@github.com>

On Tue, 14 Mar 2023 08:04:04 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated Libxml2 to v2.10.3. verfied build and sanity testing on windows, mac and Linux platforms.
> No issue observed.

This pull request has now been integrated.

Changeset: 935c7b79
Author:    Hima Bindu Meda <hmeda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/935c7b797d79407d741735324313684617d1292d
Stats:     6301 lines in 80 files changed: 1128 ins; 4562 del; 611 mod

8301009: Update libxml2 to 2.10.3

Reviewed-by: kcr, sykora

-------------

PR: https://git.openjdk.org/jfx/pull/1058

From kcr at openjdk.org  Thu Mar 16 12:17:29 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 12:17:29 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics
In-Reply-To: <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>
 <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>
Message-ID: <gn_uMl-9JoisJ_p-JXbp6PFKcXOflyS49uxLR1JJ1Mw=.1af5f5be-b732-4c33-a4cf-6b69b41c9cad@github.com>

On Thu, 16 Mar 2023 06:31:04 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2102:
>> 
>>> 2100:      ********************************************************************/
>>> 2101: 
>>> 2102:     //Test for JDK-8172849
>> 
>> minor: I would have used a javadoc comment instead of the big comment block
>> /** Test for JDK-8172849 */
>
> Yes javadoc comment would look better. I used the comment block to keep it consistent with the other comments present in the same file. I think if changing, then better to change all the comment blocks in the file.
> Please let me know your thoughts.

Please don't change all of the other comment blocks as part of this PR. You can file a follow-up bug if you like, but in that case, we should first define a "best practice", probably something that would align with what the JDK's jtreg test harness expects. So I think this can be left as-is for now.

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From kpk at openjdk.org  Thu Mar 16 12:35:30 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 16 Mar 2023 12:35:30 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics
In-Reply-To: <gn_uMl-9JoisJ_p-JXbp6PFKcXOflyS49uxLR1JJ1Mw=.1af5f5be-b732-4c33-a4cf-6b69b41c9cad@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>
 <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>
 <gn_uMl-9JoisJ_p-JXbp6PFKcXOflyS49uxLR1JJ1Mw=.1af5f5be-b732-4c33-a4cf-6b69b41c9cad@github.com>
Message-ID: <PyZAMYn2GafwSoc8QFme9OHkqHjcCL-EzlQpbu0skro=.7f83ef4a-5824-410c-a44c-5a99dec0cd1c@github.com>

On Thu, 16 Mar 2023 12:14:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Yes javadoc comment would look better. I used the comment block to keep it consistent with the other comments present in the same file. I think if changing, then better to change all the comment blocks in the file.
>> Please let me know your thoughts.
>
> Please don't change all of the other comment blocks as part of this PR. You can file a follow-up bug if you like, but in that case, we should first define a "best practice", probably something that would align with what the JDK's jtreg test harness expects. So I think this can be left as-is for now.

Sure Kevin. I'll keep the comments as-is and file a follow-up bug for this.

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From kpk at openjdk.org  Thu Mar 16 12:46:27 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 16 Mar 2023 12:46:27 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics
In-Reply-To: <PyZAMYn2GafwSoc8QFme9OHkqHjcCL-EzlQpbu0skro=.7f83ef4a-5824-410c-a44c-5a99dec0cd1c@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>
 <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>
 <gn_uMl-9JoisJ_p-JXbp6PFKcXOflyS49uxLR1JJ1Mw=.1af5f5be-b732-4c33-a4cf-6b69b41c9cad@github.com>
 <PyZAMYn2GafwSoc8QFme9OHkqHjcCL-EzlQpbu0skro=.7f83ef4a-5824-410c-a44c-5a99dec0cd1c@github.com>
Message-ID: <gXZMv87MUsVa9Gnf4oXwEFvjb0xeQarWC7dhWtsjXjQ=.bb18dc71-fe89-45e7-a42a-ed30aebaa7bb@github.com>

On Thu, 16 Mar 2023 12:32:36 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> Please don't change all of the other comment blocks as part of this PR. You can file a follow-up bug if you like, but in that case, we should first define a "best practice", probably something that would align with what the JDK's jtreg test harness expects. So I think this can be left as-is for now.
>
> Sure Kevin. I'll keep the comments as-is and file a follow-up bug for this.

Filed the bug [JDK-8304344](https://bugs.openjdk.org/browse/JDK-8304344)

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From jvos at openjdk.org  Thu Mar 16 13:28:31 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 16 Mar 2023 13:28:31 GMT
Subject: RFR: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <bz1kGxJtvP9AmzeBrW8Pm4u6pVdb388huoJiwp9xpEo=.0f73097a-e368-4215-aa87-341d228ce029@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

Marked as reviewed by jvos (Reviewer).

The patch looks ok, and the test fails before and passes after. No regression is observed. Also, the explanation about the changed position outside the layout process makes sense.
The only hesitation I still have is why the `lastPosition = getPosition();` is there in the first place. 
As I wrote before, there are many implicit rules in this class, e.g. only change layout-related properties inside the layout _cycle_ ; but there are methods that are called from within the layoutChildren method as well as from methods that are triggered by different inputs. 

I'm approving this, as the removal of this line is in line with the general approach here where we don't change the lastXXX properties outside the layout process -- as Florian mentioned as well.

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From jvos at openjdk.org  Thu Mar 16 14:21:33 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 16 Mar 2023 14:21:33 GMT
Subject: [jfx20u] RFR: 8304008: Update README.md and CONTRIBUTING.md for
 jfx update repos
In-Reply-To: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>
References: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>
Message-ID: <93S1m6fzhhMEctCQX2K6jWXWm2kPr1hLeGza2wG4V-s=.c5633b4b-f462-4ef0-a402-e1f9d1d23fae@github.com>

On Fri, 10 Mar 2023 23:02:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update README and CONTRIBUTING guidelines for this repo as appropriate for update releases (basically a copy from jfx17u with 17 changed to 20).

Marked as reviewed by jvos (Reviewer).

-------------

PR: https://git.openjdk.org/jfx20u/pull/2

From kcr at openjdk.org  Thu Mar 16 15:28:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 15:28:30 GMT
Subject: [jfx20u] Integrated: 8304008: Update README.md and CONTRIBUTING.md for
 jfx update repos
In-Reply-To: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>
References: <ZkbVveEwxQGprXQ1HEkmxVJvRIbG2NExPsnS2HL2H34=.14408dce-3f86-4888-9063-cf6d3ccc2e9f@github.com>
Message-ID: <8ym9lyXkjnckbKgiB8SpFBofrCtmjZwpa5a-YTBlpNo=.b049f010-7f1c-4794-aa94-9667319e009a@github.com>

On Fri, 10 Mar 2023 23:02:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Update README and CONTRIBUTING guidelines for this repo as appropriate for update releases (basically a copy from jfx17u with 17 changed to 20).

This pull request has now been integrated.

Changeset: 9733e7a9
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/9733e7a925df2cf47d5994b55dbb563d7fa90e94
Stats:     267 lines in 2 files changed: 1 ins; 254 del; 12 mod

8304008: Update README.md and CONTRIBUTING.md for jfx update repos

Reviewed-by: jvos

-------------

PR: https://git.openjdk.org/jfx20u/pull/2

From kcr at openjdk.org  Thu Mar 16 16:58:21 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 16:58:21 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20
Message-ID: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>

Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.

Note: This PR is targeted to `jfx20`.

-------------

Commit messages:
 - 8304359: Create release notes for JavaFX 20

Changes: https://git.openjdk.org/jfx/pull/1060/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304359
  Stats: 127 lines in 1 file changed: 127 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1060.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1060/head:pull/1060

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Thu Mar 16 16:58:21 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 16:58:21 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <VBENqEpllQFWFk_M_KUJVaxHbpTW8rTX439jZZjJcOs=.5f1eed94-c913-4444-8915-8d70debb865c@github.com>

On Thu, 16 Mar 2023 16:53:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

@abhinayagarwal Can you also review this?

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Thu Mar 16 17:05:48 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 17:05:48 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <JYiWHdm37uB0KnX3FN5RsW6dh18RCKZxRw8C30S3mUE=.3c42a3af-3356-4621-97d9-b7adbd6a006e@github.com>

On Thu, 16 Mar 2023 16:53:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

While reviewing the changes, I realized I forgot to include the release note for [FXML JavaScript Engine Disabled by Default](https://github.com/openjdk/jfx/blob/jfx19/doc-files/release-notes-19.0.2.md#fxml-javascript-engine-disabled-by-default) from the January CPU release notes. I'll update shortly.

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Thu Mar 16 17:14:28 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 17:14:28 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v2]
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <VlHTFOb1vPCjq01rvovPvD5oM034z48knKpsmuCqZ64=.26aff7d1-e636-454e-895b-7dedf6442ef0@github.com>

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Add missing FXMLLoader note

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1060/files
  - new: https://git.openjdk.org/jfx/pull/1060/files/81a43a29..f972b19d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=00-01

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1060.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1060/head:pull/1060

PR: https://git.openjdk.org/jfx/pull/1060

From nlisker at openjdk.org  Thu Mar 16 18:22:51 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 16 Mar 2023 18:22:51 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v2]
In-Reply-To: <VlHTFOb1vPCjq01rvovPvD5oM034z48knKpsmuCqZ64=.26aff7d1-e636-454e-895b-7dedf6442ef0@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <VlHTFOb1vPCjq01rvovPvD5oM034z48knKpsmuCqZ64=.26aff7d1-e636-454e-895b-7dedf6442ef0@github.com>
Message-ID: <nOQfuCOV4bv7z7pG_yDPAq11H6PhfoVldmlpfXcpfww=.fa008db6-ca71-4596-b774-a11ef30cc475@github.com>

On Thu, 16 Mar 2023 17:14:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing FXMLLoader note

Isn't https://bugs.openjdk.org/browse/JDK-8298728 a bug and not an enhancement?

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From fkirmaier at openjdk.org  Thu Mar 16 18:37:39 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 16 Mar 2023 18:37:39 GMT
Subject: Integrated: 8303680 Virtual Flow freezes after calling scrollTo and
 scrollPixels in succession
In-Reply-To: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
References: <vPFD3AZ0S4aML5coshchkXOY8xAqHInUtyCqW89FRrM=.5c7b248f-570b-42ff-a7eb-743e79156281@github.com>
Message-ID: <tap7H62rM00gV00cJRp0jrN5V-J9U_grw9bdtlCq7dQ=.61e4587f-a1ce-4fe0-8fa5-c932f31dd902@github.com>

On Mon, 6 Mar 2023 16:04:02 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> Possible fix for VirtualFlow freeze.
> 
> I encountered the problem when experimenting with VirtualFlow.
> 
> Guess @johanvos should take a look.
> All tests are still green, so with some luck, this doesn't break anything but fixes some known and unknown bugs.

This pull request has now been integrated.

Changeset: 6be8703c
Author:    Florian Kirmaier <fkirmaier at openjdk.org>
Committer: Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/6be8703ca9e6dccdda8b75b63efbcea5c6728d6f
Stats:     43 lines in 2 files changed: 42 ins; 1 del; 0 mod

8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession

Reviewed-by: angorya, jvos

-------------

PR: https://git.openjdk.org/jfx/pull/1052

From mstrauss at openjdk.org  Thu Mar 16 19:06:33 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 16 Mar 2023 19:06:33 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
In-Reply-To: <hgLcQs317u7D04GKy6wfoywHTBgHGlr9Pp1t-EAttKw=.006761e1-4d71-49ac-8da0-950eb86e5622@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <hgLcQs317u7D04GKy6wfoywHTBgHGlr9Pp1t-EAttKw=.006761e1-4d71-49ac-8da0-950eb86e5622@github.com>
Message-ID: <v4fIUyYTDT42Y5ulQxCkPUg0ZTqUvtBR9IamIs06dbk=.f2b03de5-ed21-4b27-bdec-a2983f9d82ca@github.com>

On Wed, 22 Sep 2021 18:48:13 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> I had a look at the PR. But it took quite a while to fully understand the changes (also the current implementation ?). 
> I think it make sense to improve it a bit e.g. by adding javadoc to the new methods, maybe also the existing? Other ideas are also welcome. 
> With that said maybe more people will review it then. I will have a full look soon as well. :)

@Maran23 You previously reviewed and tested the proposed changes. If everything looks good to you, can you approve this PR?

-------------

PR: https://git.openjdk.org/jfx/pull/445

From kcr at openjdk.org  Thu Mar 16 19:11:13 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 19:11:13 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v2]
In-Reply-To: <nOQfuCOV4bv7z7pG_yDPAq11H6PhfoVldmlpfXcpfww=.fa008db6-ca71-4596-b774-a11ef30cc475@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <VlHTFOb1vPCjq01rvovPvD5oM034z48knKpsmuCqZ64=.26aff7d1-e636-454e-895b-7dedf6442ef0@github.com>
 <nOQfuCOV4bv7z7pG_yDPAq11H6PhfoVldmlpfXcpfww=.fa008db6-ca71-4596-b774-a11ef30cc475@github.com>
Message-ID: <n6RHJxsqtxPm-s4x726ozjMv884tg7GMJkas8GZa2hc=.2e73e09d-3079-4875-888a-d0d1908f400c@github.com>

On Thu, 16 Mar 2023 18:20:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Isn't https://bugs.openjdk.org/browse/JDK-8298728 a bug and not an enhancement?

Yes, you're right. I'll fix that (both in JBS and in the release notes).

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From angorya at openjdk.org  Thu Mar 16 19:18:07 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 16 Mar 2023 19:18:07 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
Message-ID: <d52IUyHkbQkWfzSiM4t16ttwMn2rxwFK6ZMBsswBgtk=.f18742d7-8cdf-4bcd-862f-62ca05106281@github.com>

On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - changes per review
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>  - revert snappedSum
>  - don't call snappedSum in hot loop
>  - Improved code documentation
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - changed some method names, make test config a local class
>  - added documentation, improved method names
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 583:

> 581:         // distribute (currentDelta), as well as children that are eligible to grow or
> 582:         // shrink (adjustingNumber).
> 583:         while ((currentDelta > Double.MIN_VALUE || currentDelta < -Double.MIN_VALUE) && adjustingNumber > 0) {

is there a guarantee that this while loop ends?

-------------

PR: https://git.openjdk.org/jfx/pull/445

From angorya at openjdk.org  Thu Mar 16 19:22:18 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 16 Mar 2023 19:22:18 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
Message-ID: <bZnmCU7_wp25l-RayVwUHfB4rWt917iyOMACQgBG5eM=.14816c4c-3631-4885-94b2-55012f551948@github.com>

On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - changes per review
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>  - revert snappedSum
>  - don't call snappedSum in hot loop
>  - Improved code documentation
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - changed some method names, make test config a local class
>  - added documentation, improved method names
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 567:

> 565:         // distribute (currentDelta), as well as children that are eligible to grow or
> 566:         // shrink (adjustingNumber).
> 567:         while ((currentDelta > Double.MIN_VALUE || currentDelta < -Double.MIN_VALUE) && adjustingNumber > 0) {

same question: is it possible to enter an infinite loop?

I suspect the problem being solved here is the same as with the constrained column resize policy with non-integer scale JDK-8299753.  I was going to use some kind of simulated annealing algorithm there, perhaps it could be extracted into a generic utility and used in all three cases.

-------------

PR: https://git.openjdk.org/jfx/pull/445

From mstrauss at openjdk.org  Thu Mar 16 19:27:57 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 16 Mar 2023 19:27:57 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <d52IUyHkbQkWfzSiM4t16ttwMn2rxwFK6ZMBsswBgtk=.f18742d7-8cdf-4bcd-862f-62ca05106281@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <d52IUyHkbQkWfzSiM4t16ttwMn2rxwFK6ZMBsswBgtk=.f18742d7-8cdf-4bcd-862f-62ca05106281@github.com>
Message-ID: <Z5VyDGj5eIgG9VR7yMW_U61b0_ePukBSZdCNkfRdQFo=.0d8a9a9c-03ed-4bed-a6f5-26bbceda9528@github.com>

On Thu, 16 Mar 2023 19:15:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - changes per review
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>>  - revert snappedSum
>>  - don't call snappedSum in hot loop
>>  - Improved code documentation
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>  - changed some method names, make test config a local class
>>  - added documentation, improved method names
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 583:
> 
>> 581:         // distribute (currentDelta), as well as children that are eligible to grow or
>> 582:         // shrink (adjustingNumber).
>> 583:         while ((currentDelta > Double.MIN_VALUE || currentDelta < -Double.MIN_VALUE) && adjustingNumber > 0) {
> 
> is there a guarantee that this while loop ends?

Yes, in line 612 we return from this method once we can't resize any further.

-------------

PR: https://git.openjdk.org/jfx/pull/445

From kcr at openjdk.org  Thu Mar 16 19:44:04 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 19:44:04 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
Message-ID: <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>

On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - changes per review
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>  - revert snappedSum
>  - don't call snappedSum in hot loop
>  - Improved code documentation
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - changed some method names, make test config a local class
>  - added documentation, improved method names
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

This one hasn't been on my queue to review. I remember when I first took a look at it that it seems like a pretty large change that will need very careful review and a lot of testing. I seem to recall there are a couple places where the changes didn't seem quite right, but I'd need to go back and take a look.

@andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910  (for which the review still needs to be completed).

-------------

PR: https://git.openjdk.org/jfx/pull/445

From mstrauss at openjdk.org  Thu Mar 16 19:44:08 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 16 Mar 2023 19:44:08 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <bZnmCU7_wp25l-RayVwUHfB4rWt917iyOMACQgBG5eM=.14816c4c-3631-4885-94b2-55012f551948@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <bZnmCU7_wp25l-RayVwUHfB4rWt917iyOMACQgBG5eM=.14816c4c-3631-4885-94b2-55012f551948@github.com>
Message-ID: <m07SPbjtZN9LHcEh4hYWs4LAhdkW93KR-RTwzD30KMw=.e0668b9c-5b75-4de5-81e0-9e2609b5d837@github.com>

On Thu, 16 Mar 2023 19:19:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - changes per review
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>>  - revert snappedSum
>>  - don't call snappedSum in hot loop
>>  - Improved code documentation
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>  - changed some method names, make test config a local class
>>  - added documentation, improved method names
>>  - Merge branch 'master' into fixes/box-snap-to-pixel
>>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/VBox.java line 567:
> 
>> 565:         // distribute (currentDelta), as well as children that are eligible to grow or
>> 566:         // shrink (adjustingNumber).
>> 567:         while ((currentDelta > Double.MIN_VALUE || currentDelta < -Double.MIN_VALUE) && adjustingNumber > 0) {
> 
> same question: is it possible to enter an infinite loop?
> 
> I suspect the problem being solved here is the same as with the constrained column resize policy with non-integer scale JDK-8299753.  I was going to use some kind of simulated annealing algorithm there, perhaps it could be extracted into a generic utility and used in all three cases.

I don't know that a randomized algorithm would be preferable for this problem, since the algorithm implemented here seems to work pretty well as it is. But if the two problems are very similar, factoring out the implementation might be a good idea.

In any case, this shouldn't prevent this PR from being integrated, as it also includes tests for the desired outcome. These will come in handy if the implementation is refactored at some point in the future.

-------------

PR: https://git.openjdk.org/jfx/pull/445

From kevin.rushforth at oracle.com  Thu Mar 16 22:06:42 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 16 Mar 2023 15:06:42 -0700
Subject: Java 20 / JavaFX 20 launch event on March 21st
Message-ID: <654665b2-8a88-b494-ec0b-8d983170ad61@oracle.com>

For next week's GA release of Java 20 and JavaFX 20, on March 21st, we 
are hosting a Java Developer Day as part of Oracle's new FREE "DevLive: 
Level Up" event series. I'll be presenting "JavaFX 20 and Beyond" at 
this event. You can attend either in-person or online.

Learn more: https://inside.java/2023/02/27/devlive-java-developer-day/
Register here: 
https://developer.oracle.com/community/events/devlive-level-up-march-2023.html

The JavaFX 20 session is at 13:15 Pacific Daylight Time (UTC-7)

-- Kevin


From kcr at openjdk.org  Thu Mar 16 23:20:05 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 23:20:05 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v3]
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <VH8-ff0a6EYxWI5I43QokE34LQyjCqUmcOhhcEQAmUc=.3f034609-8f59-401a-8fdc-b8891942995e@github.com>

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Move JDK-8298728 to the Bugs list

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1060/files
  - new: https://git.openjdk.org/jfx/pull/1060/files/f972b19d..ff93eca6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1060.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1060/head:pull/1060

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Thu Mar 16 23:20:09 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Mar 2023 23:20:09 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v2]
In-Reply-To: <VlHTFOb1vPCjq01rvovPvD5oM034z48knKpsmuCqZ64=.26aff7d1-e636-454e-895b-7dedf6442ef0@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <VlHTFOb1vPCjq01rvovPvD5oM034z48knKpsmuCqZ64=.26aff7d1-e636-454e-895b-7dedf6442ef0@github.com>
Message-ID: <yQdvh9pn2-Bvh0BawtMEos3gV2OXyCY_75vYWpZzL1k=.59ee7946-53be-4699-9b77-c067dc72986a@github.com>

On Thu, 16 Mar 2023 17:14:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing FXMLLoader note

I pushed the fix to move [JDK-8298728](https://bugs.openjdk.org/browse/JDK-8298728) to the list of Bugs, and while doing so, noticed that the bugs aren't sorted within each subcomponent. I'll fix this tomorrow.

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From kpk at openjdk.org  Fri Mar 17 06:12:07 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 17 Mar 2023 06:12:07 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics [v2]
In-Reply-To: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
Message-ID: <tLubbMQfYIbkIYm4EEfMnn0qeqDGuVW-2H6wxD9VuPQ=.4a0ea747-1af2-49a3-829b-682d80d9123a@github.com>

> Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.
> 
> Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.
> 
> Added unit test to validate the fix.

Karthik P K has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1059/files
  - new: https://git.openjdk.org/jfx/pull/1059/files/85f84c22..8e733c58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1059&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1059&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1059.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1059/head:pull/1059

PR: https://git.openjdk.org/jfx/pull/1059

From kpk at openjdk.org  Fri Mar 17 06:12:11 2023
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 17 Mar 2023 06:12:11 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics [v2]
In-Reply-To: <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <G-dTJREYJ0O6ke2YoB8CT5oqoRh2OYmLUh5xmZIRNP4=.c243fe2c-5330-4a00-9267-82c0f6333959@github.com>
 <UCtmRHUzsrIKir6oT47KhpX5alSp4Id3nYvegkohemc=.b6b5454f-4f36-45c9-9957-86565eba6095@github.com>
Message-ID: <Ed3R2LbMgHRQE07cw4xQS8nlf81g8J2yAYFSwFkTg9w=.fde69431-41b3-4ace-89a0-c65fed14715a@github.com>

On Thu, 16 Mar 2023 06:32:30 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2136:
>> 
>>> 2134:      *                                                                              *
>>> 2135:      *******************************************************************************/
>>> 2136: 
>> 
>> Minor: I would have used a javadoc explaining the purpose of this class instead of generic "Helper classes".
>
> Same comment as above. In addition to that, yes, updating the comment with actual purpose of the class would be better. I will update that once we decide if all the other comment blocks also should be changed or not.
> Since there was no comment for this class, I added the comment so that it gets separated from "Tests for bug reports" tests.

Updated the comment with purpose of the class instead of generic comment.

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From duke at openjdk.org  Fri Mar 17 11:11:31 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Fri, 17 Mar 2023 11:11:31 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v3]
In-Reply-To: <VH8-ff0a6EYxWI5I43QokE34LQyjCqUmcOhhcEQAmUc=.3f034609-8f59-401a-8fdc-b8891942995e@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <VH8-ff0a6EYxWI5I43QokE34LQyjCqUmcOhhcEQAmUc=.3f034609-8f59-401a-8fdc-b8891942995e@github.com>
Message-ID: <PQYtHfASkWziuNHn-ha4tF_hF77XnH266IKJAd9CAPU=.41649892-f802-4116-9e95-c4693b91774b@github.com>

On Thu, 16 Mar 2023 23:20:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JDK-8298728 to the Bugs list

There are [a few issues](https://bugs.openjdk.org/browse/JDK-8288449?jql=resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20jfx20%20AND%20(labels%20%3D%20%22noreg-doc%22)%20AND%20type%20%3D%20Bug%20ORDER%20BY%20cf%5B10008%5D%20ASC) labelled as `noreg-doc`, but are still a part of the release notes. Can you confirm if these are required to be in this list?

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Fri Mar 17 14:09:12 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Mar 2023 14:09:12 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v4]
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <KU6I6ZxPwhxkk_VJJ1KYLq9rGaoJzVsy7CoXALZQi38=.170c433b-bc8a-4c15-83cd-8fbee35b2c73@github.com>

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:

 - Remove two bugs that were introduced and fixed in jfx20
 - Sort by bug ID within each subcomponent

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1060/files
  - new: https://git.openjdk.org/jfx/pull/1060/files/ff93eca6..68ab9a9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=02-03

  Stats: 76 lines in 1 file changed: 25 ins; 27 del; 24 mod
  Patch: https://git.openjdk.org/jfx/pull/1060.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1060/head:pull/1060

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Fri Mar 17 14:09:16 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Mar 2023 14:09:16 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v3]
In-Reply-To: <VH8-ff0a6EYxWI5I43QokE34LQyjCqUmcOhhcEQAmUc=.3f034609-8f59-401a-8fdc-b8891942995e@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <VH8-ff0a6EYxWI5I43QokE34LQyjCqUmcOhhcEQAmUc=.3f034609-8f59-401a-8fdc-b8891942995e@github.com>
Message-ID: <oPwGWVRkU1bn8xmixQTpwDJmtgUDuEYqNZt8jtLu4cw=.6360dab0-5f57-4d1c-8a0c-6a649fcbc638@github.com>

On Thu, 16 Mar 2023 23:20:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move JDK-8298728 to the Bugs list

> There are a few issues labelled as `noreg-doc`, but are still a part of the release notes. Can you confirm if these are required to be in this list?

Thanks for checking. Of the 10 `noreg-doc` bugs, 7 of them are correctly included in the release notes, since they affect the published API docs (the other three are explicitly excluded, since they don't affect any production docs). This matches what we did for previous releases.

Your question did cause me to look more closely at the JBS query, and I found a bug in the query that was causing intra-release bugs (bugs introduced in one build of jfx20 and fixed in a subsequent build) to be included, which wasn't the intention. So there are two bugs that should be excluded: [JDK-8301797](https://bugs.openjdk.org/browse/JDK-8301797) and [JDK-8301832](https://bugs.openjdk.org/browse/JDK-8301832). I have updated the [FX 20 RN Issues](https://bugs.openjdk.org/issues/?filter=42636) filter, so it should now match the latest state of this PR.

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From duke at openjdk.org  Fri Mar 17 16:22:06 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Fri, 17 Mar 2023 16:22:06 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v4]
In-Reply-To: <KU6I6ZxPwhxkk_VJJ1KYLq9rGaoJzVsy7CoXALZQi38=.170c433b-bc8a-4c15-83cd-8fbee35b2c73@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <KU6I6ZxPwhxkk_VJJ1KYLq9rGaoJzVsy7CoXALZQi38=.170c433b-bc8a-4c15-83cd-8fbee35b2c73@github.com>
Message-ID: <uDt5HlPqLvRUOESTtIeIdATF1PYK2SR0Oe880noA1hY=.e67ad307-e021-4921-a284-1c83f66385c9@github.com>

On Fri, 17 Mar 2023 14:09:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove two bugs that were introduced and fixed in jfx20
>  - Sort by bug ID within each subcomponent

doc-files/release-notes-20.md line 123:

> 121: [JDK-8292922](https://bugs.openjdk.org/browse/JDK-8292922) | [Linux] No more drag events when new Stage is created in drag handler | window-toolkit
> 122: [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621) | Stage steals focus on scene change | window-toolkit
> 123: [JDK-8296654](https://bugs.openjdk.org/browse/JDK-8296654) | [macos] Crash when launching JavaFX app with JDK that targets SDK 13 | window-toolkit

In the previous release notes, `|` was not wrapped with white-spaces.

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From angorya at openjdk.org  Fri Mar 17 16:26:59 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Mar 2023 16:26:59 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics [v2]
In-Reply-To: <tLubbMQfYIbkIYm4EEfMnn0qeqDGuVW-2H6wxD9VuPQ=.4a0ea747-1af2-49a3-829b-682d80d9123a@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <tLubbMQfYIbkIYm4EEfMnn0qeqDGuVW-2H6wxD9VuPQ=.4a0ea747-1af2-49a3-829b-682d80d9123a@github.com>
Message-ID: <yAgl5i0IPsEauFIcFfbNM1pvjn83Nsbci3swqxXxfAM=.8b5152c7-f478-4f0e-b5d5-fa41965dc61a@github.com>

On Fri, 17 Mar 2023 06:12:07 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.
>> 
>> Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.
>> 
>> Added unit test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

lgtm

-------------

Marked as reviewed by angorya (Committer).

PR: https://git.openjdk.org/jfx/pull/1059

From kcr at openjdk.org  Fri Mar 17 16:37:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Mar 2023 16:37:54 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v4]
In-Reply-To: <uDt5HlPqLvRUOESTtIeIdATF1PYK2SR0Oe880noA1hY=.e67ad307-e021-4921-a284-1c83f66385c9@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <KU6I6ZxPwhxkk_VJJ1KYLq9rGaoJzVsy7CoXALZQi38=.170c433b-bc8a-4c15-83cd-8fbee35b2c73@github.com>
 <uDt5HlPqLvRUOESTtIeIdATF1PYK2SR0Oe880noA1hY=.e67ad307-e021-4921-a284-1c83f66385c9@github.com>
Message-ID: <F58i5pwnzYLe94Gre1Iz9Hkk6pGxWll4rW0NstzagHU=.8acfbc82-f674-4a8c-8fc5-1eccb4cb3a39@github.com>

On Fri, 17 Mar 2023 16:18:44 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove two bugs that were introduced and fixed in jfx20
>>  - Sort by bug ID within each subcomponent
>
> doc-files/release-notes-20.md line 123:
> 
>> 121: [JDK-8292922](https://bugs.openjdk.org/browse/JDK-8292922) | [Linux] No more drag events when new Stage is created in drag handler | window-toolkit
>> 122: [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621) | Stage steals focus on scene change | window-toolkit
>> 123: [JDK-8296654](https://bugs.openjdk.org/browse/JDK-8296654) | [macos] Crash when launching JavaFX app with JDK that targets SDK 13 | window-toolkit
> 
> In the previous release notes, `|` was not wrapped in white-spaces. This has no side-effect to the final markdown, but I would like to know the preferred styling.

Ah, I see that now. Actually, we were inconsistent: the security bugs table is surrounded by white space, but the rest were not. I can fix that to match what we did previously.

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Fri Mar 17 16:47:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Mar 2023 16:47:11 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v5]
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <4jJZaxLqgbUBtOQhuDohl0-zFuSI7iUD6dGpHc9upi4=.8a81c92d-0653-41c5-ab5a-cb1c726db90a@github.com>

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Change whitespace to match prior releases: ' | ' -> '|'

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1060/files
  - new: https://git.openjdk.org/jfx/pull/1060/files/68ab9a9d..d2a72f61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1060&range=03-04

  Stats: 98 lines in 1 file changed: 0 ins; 0 del; 98 mod
  Patch: https://git.openjdk.org/jfx/pull/1060.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/1060/head:pull/1060

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Fri Mar 17 16:47:14 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 17 Mar 2023 16:47:14 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v4]
In-Reply-To: <F58i5pwnzYLe94Gre1Iz9Hkk6pGxWll4rW0NstzagHU=.8acfbc82-f674-4a8c-8fc5-1eccb4cb3a39@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <KU6I6ZxPwhxkk_VJJ1KYLq9rGaoJzVsy7CoXALZQi38=.170c433b-bc8a-4c15-83cd-8fbee35b2c73@github.com>
 <uDt5HlPqLvRUOESTtIeIdATF1PYK2SR0Oe880noA1hY=.e67ad307-e021-4921-a284-1c83f66385c9@github.com>
 <F58i5pwnzYLe94Gre1Iz9Hkk6pGxWll4rW0NstzagHU=.8acfbc82-f674-4a8c-8fc5-1eccb4cb3a39@github.com>
Message-ID: <3FORZtB3bVaVfs0Ws7LiSiW7DQHDLGeqjzppl0vpQ_M=.095a66cd-e948-4460-989b-c07a45acaa3e@github.com>

On Fri, 17 Mar 2023 16:35:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> doc-files/release-notes-20.md line 123:
>> 
>>> 121: [JDK-8292922](https://bugs.openjdk.org/browse/JDK-8292922) | [Linux] No more drag events when new Stage is created in drag handler | window-toolkit
>>> 122: [JDK-8296621](https://bugs.openjdk.org/browse/JDK-8296621) | Stage steals focus on scene change | window-toolkit
>>> 123: [JDK-8296654](https://bugs.openjdk.org/browse/JDK-8296654) | [macos] Crash when launching JavaFX app with JDK that targets SDK 13 | window-toolkit
>> 
>> In the previous release notes, `|` was not wrapped in white-spaces. This has no side-effect to the final markdown, but I would like to know the preferred styling.
>
> Ah, I see that now. Actually, we were inconsistent: the security bugs table is surrounded by white space, but the rest were not. I can fix that to match what we did previously.

I removed the extra space in all places (even the security bugs section)

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From perini.davide at dpsoftware.org  Sat Mar 18 00:33:26 2023
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sat, 18 Mar 2023 01:33:26 +0100
Subject: JavaFX combo, issue with focus since JavaFX 19
Message-ID: <52f9f28f-16af-7a8a-78d2-a9fa5179bc31@dpsoftware.org>

This issue isn't solved yet.
https://stackoverflow.com/questions/74147187/issue-with-combobox-focus-in-fx-19

Is this a known issue from JavaFX devs?

Adding

|Platform.runLater works as a workaround. Thanks Davide |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230318/dabb06e0/attachment.htm>

From michaelstrau2 at gmail.com  Sat Mar 18 02:02:11 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sat, 18 Mar 2023 06:02:11 +0400
Subject: JavaFX combo, issue with focus since JavaFX 19
In-Reply-To: <52f9f28f-16af-7a8a-78d2-a9fa5179bc31@dpsoftware.org>
References: <52f9f28f-16af-7a8a-78d2-a9fa5179bc31@dpsoftware.org>
Message-ID: <CAJEpuXS7571mmB5w_84YfmiK5HSbi-MYT4s3UVug59xBWgaX4w@mail.gmail.com>

This issue is fixed in JavaFX 20, see JDK-8297130.



Davide Perini <perini.davide at dpsoftware.org> schrieb am Sa. 18. M?rz 2023
um 01:33:

> This issue isn't solved yet.
>
> https://stackoverflow.com/questions/74147187/issue-with-combobox-focus-in-fx-19
>
> Is this a known issue from JavaFX devs?
>
> Adding
>
> Platform.runLater
> works as a workaround.
>
> Thanks
> Davide
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230318/504a2d63/attachment.htm>

From duke at openjdk.org  Sat Mar 18 06:14:29 2023
From: duke at openjdk.org (Abhinay Agarwal)
Date: Sat, 18 Mar 2023 06:14:29 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v5]
In-Reply-To: <4jJZaxLqgbUBtOQhuDohl0-zFuSI7iUD6dGpHc9upi4=.8a81c92d-0653-41c5-ab5a-cb1c726db90a@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <4jJZaxLqgbUBtOQhuDohl0-zFuSI7iUD6dGpHc9upi4=.8a81c92d-0653-41c5-ab5a-cb1c726db90a@github.com>
Message-ID: <oJkQMS0ZY8nKi_cdPUpmJ4CQk3kjujZ4Mr5TMpIy7tA=.d2365883-8c6f-4f2d-9b3e-c0a52a289544@github.com>

On Fri, 17 Mar 2023 16:47:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change whitespace to match prior releases: ' | ' -> '|'

Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From jvos at openjdk.org  Sat Mar 18 07:41:31 2023
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 18 Mar 2023 07:41:31 GMT
Subject: [jfx20] RFR: 8304359: Create release notes for JavaFX 20 [v5]
In-Reply-To: <4jJZaxLqgbUBtOQhuDohl0-zFuSI7iUD6dGpHc9upi4=.8a81c92d-0653-41c5-ab5a-cb1c726db90a@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
 <4jJZaxLqgbUBtOQhuDohl0-zFuSI7iUD6dGpHc9upi4=.8a81c92d-0653-41c5-ab5a-cb1c726db90a@github.com>
Message-ID: <Km-Myte8cNaYQSwy858jICIZIst3mDj5uWKvV2t5Aks=.cf46cb16-e709-428c-bf72-079430695e4b@github.com>

On Fri, 17 Mar 2023 16:47:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
>> 
>> Note: This PR is targeted to `jfx20`.
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change whitespace to match prior releases: ' | ' -> '|'

Marked as reviewed by jvos (Reviewer).

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From aghaisas at openjdk.org  Mon Mar 20 08:59:38 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 20 Mar 2023 08:59:38 GMT
Subject: RFR: 8154038: Spinner's converter should update its editor [v2]
In-Reply-To: <OjclAS6VUNjFcsfi8nju9LMV3dRQT0mafkUdvsyU-qI=.3163098b-6462-466a-9670-47670d7c1126@github.com>
References: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
 <OjclAS6VUNjFcsfi8nju9LMV3dRQT0mafkUdvsyU-qI=.3163098b-6462-466a-9670-47670d7c1126@github.com>
Message-ID: <Z8fNLNH76qk6RMJc2zrMhM9gA9Xyzpjlqor2JtrR7Cw=.4faffa8d-f158-44e4-a5c0-1472674c6df0@github.com>

On Thu, 16 Mar 2023 06:09:03 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> When converter was changed, `setText` method of spinner was not invoked to update the spinner text using new converter.
>> 
>> Added a listener to converter property of `SpinnerValueFactory` to call `setText` so that spinner text is updated using new converter.
>> 
>> Added unit test to validate the fix. Along with spinner of Double type, added a spinner of Integer type as well so that the fix is validated using 2 types of spinner.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good!

-------------

Marked as reviewed by aghaisas (Reviewer).

PR: https://git.openjdk.org/jfx/pull/1057

From thiago.sayao at gmail.com  Mon Mar 20 12:50:30 2023
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 20 Mar 2023 09:50:30 -0300
Subject: Linux IME work
Message-ID: <CAAP_wu=Y_tEX4H39KK7T6NHxgpzAi9iZNQTStwg5ka=Zj7P_mg@mail.gmail.com>

Hi,

I'm working on IME (Input Method Editor) on Linux as the current solution
using XIM is probably not working and XIM is known to be outdated.

I'm basing it on
https://docs.gtk.org/gtk3/class.IMContext.html

Which is built on top of Ibus (Intelligent Input Bus). To my understanding
there's an option for XIM too.

I'm testing it using Japanese and Anthy. For now it's compiling and sending
IME commits to a TextArea but not deleting preedits (have to figure it out
how to do it).

It's a land I started to explore (and I know nothing outside the
latin-based languages). I'm looking for use cases or samples I can use to
test.

It's also a work to eliminate X11 calls so we can support wayland.

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230320/f7b3473d/attachment.htm>

From kcr at openjdk.org  Mon Mar 20 21:56:54 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 21:56:54 GMT
Subject: [jfx20] Integrated: 8304359: Create release notes for JavaFX 20
In-Reply-To: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
References: <VFidkuLsf1FU_I9u2l6II2bkm9JlYjCCNjcdhNdQUtI=.7ca49b13-b46e-4b06-86a3-2b2bac551355@github.com>
Message-ID: <T6-bNxwBYhuRJIbYVjbYzGv9V94nL3b6dKGInaYIT1o=.39fec478-7fa2-4b21-825a-5a62d726e991@github.com>

On Thu, 16 Mar 2023 16:53:25 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 20, including one important change to note (the requirement of JDK 17 as the minimum needed to run JavaFX 20) and the list of enhancements and bugs fixed in this release.
> 
> Note: This PR is targeted to `jfx20`.

This pull request has now been integrated.

Changeset: f2118a13
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f2118a131c39c490ee372e3a5ed0ab40b1b47de1
Stats:     135 lines in 1 file changed: 135 ins; 0 del; 0 mod

8304359: Create release notes for JavaFX 20

Reviewed-by: jvos

-------------

PR: https://git.openjdk.org/jfx/pull/1060

From kcr at openjdk.org  Mon Mar 20 22:27:57 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 22:27:57 GMT
Subject: [jfx20u] RFR: Merge jfx:jfx20
Message-ID: <xTrU7kmlFoRR5E_mQdLm7bwvA_dDO_917fRF6g4wvgg=.582a3100-745a-49da-ba73-cf3d43d7d2db@github.com>

Merge `jfx:jfx20` into `jfx20u:master`

-------------

Commit messages:
 - Merge jfx/jfx20
 - 8304359: Create release notes for JavaFX 20

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx20u/pull/9/files
  Stats: 135 lines in 1 file changed: 135 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx20u/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u.git pull/9/head:pull/9

PR: https://git.openjdk.org/jfx20u/pull/9

From kcr at openjdk.org  Mon Mar 20 22:33:49 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 22:33:49 GMT
Subject: RFR: Merge jfx20
Message-ID: <oV-I1x7ZtTg1zSgx1QlQw2jEaV4Ct12iA0ntVyZui_s=.d4f40058-f277-44ef-aac5-33a1f314fa27@github.com>

Final merge of `jfx20` into `master`.

-------------

Commit messages:
 - Merge jfx20
 - 8304359: Create release notes for JavaFX 20

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx/pull/1062/files
  Stats: 135 lines in 1 file changed: 135 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1062.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1062/head:pull/1062

PR: https://git.openjdk.org/jfx/pull/1062

From kcr at openjdk.org  Mon Mar 20 23:28:45 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 23:28:45 GMT
Subject: RFR: Merge jfx20 [v2]
In-Reply-To: <oV-I1x7ZtTg1zSgx1QlQw2jEaV4Ct12iA0ntVyZui_s=.d4f40058-f277-44ef-aac5-33a1f314fa27@github.com>
References: <oV-I1x7ZtTg1zSgx1QlQw2jEaV4Ct12iA0ntVyZui_s=.d4f40058-f277-44ef-aac5-33a1f314fa27@github.com>
Message-ID: <b6oAoUoaoS7Z5A07JDr5hElXJFkNZ_nu2ScegxmLeA8=.f6f5025c-cdbf-42f3-a81b-366a271283ee@github.com>

> Final merge of `jfx20` into `master`.

Kevin Rushforth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Merge jfx20
 - 8303680: Virtual Flow freezes after calling scrollTo and scrollPixels in succession
   
   Reviewed-by: angorya, jvos
 - 8301009: Update libxml2 to 2.10.3
   
   Reviewed-by: kcr, sykora
 - 8178368: Right alignment of text fields and alignment of prompt text works incorrectly
   
   Reviewed-by: angorya, kcr
 - 8299968: Second call to Stage.setScene() create sizing issue with uiScale > 1.0
   
   Reviewed-by: kcr, arapte
 - 8302355: Public API for Toolkit.canStartNestedEventLoop()
   
   Reviewed-by: kcr, arapte
 - 8302797: ArrayIndexOutOfBoundsException in TextRun.getWrapIndex()
   
   Reviewed-by: angorya, kcr
 - 8090123: Items are no longer visible when collection is changed
   
   Reviewed-by: angorya, kcr
 - 8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements
   8300954: HTML default Range input control not rendered
   
   Co-authored-by: Hima Bindu Meda <hmeda at openjdk.org>
   Reviewed-by: kcr, hmeda
 - 8300872: WebView's ColorChooser fails to initialize when running in security context
   
   Reviewed-by: kcr, mstrauss
 - ... and 34 more: https://git.openjdk.org/jfx/compare/f2118a13...a98714a2

-------------

Changes: https://git.openjdk.org/jfx/pull/1062/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1062&range=01
  Stats: 207648 lines in 5810 files changed: 121713 ins; 46442 del; 39493 mod
  Patch: https://git.openjdk.org/jfx/pull/1062.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1062/head:pull/1062

PR: https://git.openjdk.org/jfx/pull/1062

From kcr at openjdk.org  Mon Mar 20 23:28:46 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 23:28:46 GMT
Subject: Integrated: Merge jfx20
In-Reply-To: <oV-I1x7ZtTg1zSgx1QlQw2jEaV4Ct12iA0ntVyZui_s=.d4f40058-f277-44ef-aac5-33a1f314fa27@github.com>
References: <oV-I1x7ZtTg1zSgx1QlQw2jEaV4Ct12iA0ntVyZui_s=.d4f40058-f277-44ef-aac5-33a1f314fa27@github.com>
Message-ID: <Yz6-MHpXvEKWVZrM9HtgjmXHhXZDXXYT84cQgIr3NYU=.7c9e7823-9813-4644-8d29-cba5e9e13f0e@github.com>

On Mon, 20 Mar 2023 22:28:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Final merge of `jfx20` into `master`.

This pull request has now been integrated.

Changeset: b1964d98
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b1964d98c4ae6db2bb74b09734506fbb3f8742bc
Stats:     135 lines in 1 file changed: 135 ins; 0 del; 0 mod

Merge

-------------

PR: https://git.openjdk.org/jfx/pull/1062

From kcr at openjdk.org  Mon Mar 20 23:30:10 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 23:30:10 GMT
Subject: [jfx20u] RFR: Merge jfx:jfx20 [v2]
In-Reply-To: <xTrU7kmlFoRR5E_mQdLm7bwvA_dDO_917fRF6g4wvgg=.582a3100-745a-49da-ba73-cf3d43d7d2db@github.com>
References: <xTrU7kmlFoRR5E_mQdLm7bwvA_dDO_917fRF6g4wvgg=.582a3100-745a-49da-ba73-cf3d43d7d2db@github.com>
Message-ID: <Ifo59QrerNE-ieb8SlITY77UfKrsRcYxlVvYC43wH1Y=.6a0e7360-896c-4b6b-8ce0-b5927c393ca1@github.com>

> Merge `jfx:jfx20` into `jfx20u: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 ten additional commits since the last revision:

 - Merge jfx/jfx20
 - 8304008: Update README.md and CONTRIBUTING.md for jfx update repos
   
   Reviewed-by: jvos
 - 8303217: Webview loaded webpage is not showing play, volume related buttons for embeded Audio/Video elements
   8300954: HTML default Range input control not rendered
   
   Backport-of: bbdc59984a7f6427a5ad8b8ad39aa93ee3b4abbe
 - 8301022: Video distortion is observed while playing youtube video
   
   Backport-of: 14883a296ac08a91fc24570a7479a6c8c2117643
 - 8302684: Cherry-pick WebKit 615.1 stabilization fixes (2)
   
   Backport-of: 67c2b7a13b5d3378c1006b8fd3af28aa8eb49c25
 - 8302294: Cherry-pick WebKit 615.1 stabilization fixes
   
   Backport-of: 97ae4b87c7e2ce0605ff051c82d48328f83a94ca
 - 8301712: [linux] Crash on exit from WebKit 615.1
   
   Backport-of: 13d8df31e7bc4336d01ec859e127756928db30d4
 - 8299977: Update WebKit to 615.1
   
   Backport-of: 301bbd6409d463c4f789e2b3dcb6b2ea200d7373
 - 8303987: Change JavaFX release version to 20.0.1 in jfx20u
   
   Reviewed-by: arapte, jvos

-------------

Changes:
  - all: https://git.openjdk.org/jfx20u/pull/9/files
  - new: https://git.openjdk.org/jfx20u/pull/9/files/1d94761d..1d94761d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx20u&pr=9&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx20u&pr=9&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx20u/pull/9.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u.git pull/9/head:pull/9

PR: https://git.openjdk.org/jfx20u/pull/9

From kcr at openjdk.org  Mon Mar 20 23:30:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 20 Mar 2023 23:30:11 GMT
Subject: [jfx20u] Integrated: Merge jfx:jfx20
In-Reply-To: <xTrU7kmlFoRR5E_mQdLm7bwvA_dDO_917fRF6g4wvgg=.582a3100-745a-49da-ba73-cf3d43d7d2db@github.com>
References: <xTrU7kmlFoRR5E_mQdLm7bwvA_dDO_917fRF6g4wvgg=.582a3100-745a-49da-ba73-cf3d43d7d2db@github.com>
Message-ID: <tCOGaHmuDucLyw7pR-G15_itluhmCusxmvVVTewyqPI=.5751f5b8-be8e-432e-96a1-560308e60cc2@github.com>

On Mon, 20 Mar 2023 22:23:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Merge `jfx:jfx20` into `jfx20u:master`

This pull request has now been integrated.

Changeset: de60a131
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/de60a1311aad4fae00b2b6d8b5e8380f4b9e9c2e
Stats:     135 lines in 1 file changed: 135 ins; 0 del; 0 mod

Merge

-------------

PR: https://git.openjdk.org/jfx20u/pull/9

From kpk at openjdk.org  Tue Mar 21 05:59:56 2023
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 21 Mar 2023 05:59:56 GMT
Subject: Integrated: 8154038: Spinner's converter should update its editor
In-Reply-To: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
References: <GBp42xiK3AJykNqMFfVW0B9xbQ840lkotet6tSDefhw=.aef7d162-1522-4236-8d46-6c9deadd76f6@github.com>
Message-ID: <WTpnQEbe01gNOEp-XLz0gcapxcWyB2-fCQWaHGAyM8g=.56333c40-4d7a-4a16-a462-6afc689b1906@github.com>

On Fri, 10 Mar 2023 11:38:56 GMT, Karthik P K <kpk at openjdk.org> wrote:

> When converter was changed, `setText` method of spinner was not invoked to update the spinner text using new converter.
> 
> Added a listener to converter property of `SpinnerValueFactory` to call `setText` so that spinner text is updated using new converter.
> 
> Added unit test to validate the fix. Along with spinner of Double type, added a spinner of Integer type as well so that the fix is validated using 2 types of spinner.

This pull request has now been integrated.

Changeset: 0ab54e27
Author:    Karthik P K <kpk at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0ab54e27d931d024c0d42235e6f70b859efec3bc
Stats:     72 lines in 2 files changed: 71 ins; 0 del; 1 mod

8154038: Spinner's converter should update its editor

Reviewed-by: aghaisas

-------------

PR: https://git.openjdk.org/jfx/pull/1057

From john.hendrikx at gmail.com  Tue Mar 21 11:26:22 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 21 Mar 2023 12:26:22 +0100
Subject: Changes detected by reference equality for all ObservableValues...
 except String
Message-ID: <5b844bff-3b94-9228-06be-e1746b0e1514@gmail.com>

I had a run in today with a (known) issue where StringProperty seems to 
violate the implementation spec as described by ObservableValue for 
which I'd really like to investigate a solution:

 ?* All implementing classes in the JavaFX library check for a change 
using reference
 ?* equality (and not object equality, {@code Object#equals(Object)}) of 
the value.

Yet, in StringPropertyBase#set, we see this:

 ??????? if ((value == null)? newValue != null : !value.equals(newValue)) {
 ??????????? value = newValue;
 ??????????? markInvalid();
 ??????? }

Note the use of `equals` here.? In ObjectPropertyBase (and all the other 
PropertyBase classes, even something like ListPropertyBase) it's this:

 ??????? if (value != newValue) {
 ??????????? value = newValue;
 ??????????? markInvalid();
 ??????? }

Now, I can understand why this is done, as String is almost regarded as 
a primitive class in Java, however, it does make downstream properties 
which may not know they're dealing with Strings and that need to check 
for changes a bit harder to implement. A downstream property may want to 
check for changes to prevent an unnecessary invalidation for example.

This could look like this:

 ??????? if (isValid() && source.getValue() != getValue()) {
 ??????????? invalidate();
 ??????? }

Or this:

 ??????????? T value = source.getValue();

 ??????????? if (cachedValue != value) {
 ??????????????? cachedValue = value;
 ??????????????? invalidate();
 ??????????? }

Now, since StringProperty strictly speaking violates the implementation 
specification for JavaFX provided properties, but not the general 
contract of an ObservableValue, there are I think two possible actions:

1) Make StringProperty no longer violate this implementation 
specification and make it use reference equality; this can mean 
invalidations and changes are triggered where, according to equals, the 
old and new value are the same.

2) Make an exception for String values, as they're almost like 
primitives in Java, and update the implementation specification

In the first case, downstream properties can continue to use reference 
equality to do their checks.? In the second case, we may need to change 
these to specifically use `equals` when a String value is encountered.? 
Strictly speaking that would mean changing ObjectPropertyBase as well to 
change its equality:

Old:

 ??????? if (value != newValue) {
 ??????????? value = newValue;
 ??????????? markInvalid();
 ??????? }

New:

 ??????? boolean changed = value instanceof String s ? 
!s.equals(newValue) : value != newValue;

 ??????? if (changed) {
 ??????????? value = newValue;
 ??????????? markInvalid();
 ??????? }

This way of checking equality would best be encoded somewhere that is 
easy to reach for other code that needs to do the same, so I'd propose a 
static method on ObservableValue (or somewhere else):

 ??? static <T> boolean isEquals(T a, T b) {
 ????? return a instanceof String s ? s.equals(b) : a == b;
 ??? }

I'd like to hear your thoughts on this as it is can have consequences 
for how the `when` fluent binding prevents invalidations, but also other 
(future) implementations that sometimes deal with Strings, and sometimes 
with any other kind of object.

--John


From john.hendrikx at gmail.com  Tue Mar 21 11:59:33 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 21 Mar 2023 12:59:33 +0100
Subject: Changes detected by reference equality for all
 ObservableValues... except String
In-Reply-To: <5b844bff-3b94-9228-06be-e1746b0e1514@gmail.com>
References: <5b844bff-3b94-9228-06be-e1746b0e1514@gmail.com>
Message-ID: <cb90b027-8da2-9bdf-b536-19b8d77534c8@gmail.com>

Looks like it is even more fuzzy than I thought...

ExpressionHelper (used by almost all property implementations) checks 
before sending out changed events using `equals`:

 ???? final boolean changed = (currentValue == null)? (oldValue != null) 
: !currentValue.equals(oldValue);

What this means is that when you do:

 ????? T a = new T();
 ????? T b = a.clone();

 ????? ObjectProperty<T> x = new SimpleObjectProperty<>(a);

 ????? x.set(b);

The above triggers an invalidation because a != b, but no changes 
because a.equals(b) even though b here is a totally different instance. 
As change listeners weren't called, code may still be referring to a; if 
a is mutated, these changes would be seen by such downstream code, while 
a `getValue` (which would return b) would not see them.

The behavior is "okay" for immutable T's (of which String is one), but 
could still be surprising.

For StringProperty such code would trigger no invalidation and no changes

--John

On 21/03/2023 12:26, John Hendrikx wrote:
> I had a run in today with a (known) issue where StringProperty seems 
> to violate the implementation spec as described by ObservableValue for 
> which I'd really like to investigate a solution:
>
> ?* All implementing classes in the JavaFX library check for a change 
> using reference
> ?* equality (and not object equality, {@code Object#equals(Object)}) 
> of the value.
>
> Yet, in StringPropertyBase#set, we see this:
>
> ??????? if ((value == null)? newValue != null : 
> !value.equals(newValue)) {
> ??????????? value = newValue;
> ??????????? markInvalid();
> ??????? }
>
> Note the use of `equals` here.? In ObjectPropertyBase (and all the 
> other PropertyBase classes, even something like ListPropertyBase) it's 
> this:
>
> ??????? if (value != newValue) {
> ??????????? value = newValue;
> ??????????? markInvalid();
> ??????? }
>
> Now, I can understand why this is done, as String is almost regarded 
> as a primitive class in Java, however, it does make downstream 
> properties which may not know they're dealing with Strings and that 
> need to check for changes a bit harder to implement. A downstream 
> property may want to check for changes to prevent an unnecessary 
> invalidation for example.
>
> This could look like this:
>
> ??????? if (isValid() && source.getValue() != getValue()) {
> ??????????? invalidate();
> ??????? }
>
> Or this:
>
> ??????????? T value = source.getValue();
>
> ??????????? if (cachedValue != value) {
> ??????????????? cachedValue = value;
> ??????????????? invalidate();
> ??????????? }
>
> Now, since StringProperty strictly speaking violates the 
> implementation specification for JavaFX provided properties, but not 
> the general contract of an ObservableValue, there are I think two 
> possible actions:
>
> 1) Make StringProperty no longer violate this implementation 
> specification and make it use reference equality; this can mean 
> invalidations and changes are triggered where, according to equals, 
> the old and new value are the same.
>
> 2) Make an exception for String values, as they're almost like 
> primitives in Java, and update the implementation specification
>
> In the first case, downstream properties can continue to use reference 
> equality to do their checks.? In the second case, we may need to 
> change these to specifically use `equals` when a String value is 
> encountered.? Strictly speaking that would mean changing 
> ObjectPropertyBase as well to change its equality:
>
> Old:
>
> ??????? if (value != newValue) {
> ??????????? value = newValue;
> ??????????? markInvalid();
> ??????? }
>
> New:
>
> ??????? boolean changed = value instanceof String s ? 
> !s.equals(newValue) : value != newValue;
>
> ??????? if (changed) {
> ??????????? value = newValue;
> ??????????? markInvalid();
> ??????? }
>
> This way of checking equality would best be encoded somewhere that is 
> easy to reach for other code that needs to do the same, so I'd propose 
> a static method on ObservableValue (or somewhere else):
>
> ??? static <T> boolean isEquals(T a, T b) {
> ????? return a instanceof String s ? s.equals(b) : a == b;
> ??? }
>
> I'd like to hear your thoughts on this as it is can have consequences 
> for how the `when` fluent binding prevents invalidations, but also 
> other (future) implementations that sometimes deal with Strings, and 
> sometimes with any other kind of object.
>
> --John
>

From kcr at openjdk.org  Tue Mar 21 14:14:01 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Mar 2023 14:14:01 GMT
Subject: RFR: 8304665: Change to Xcode12.4+1.1 devkit
Message-ID: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>

This bumps the build number for the devkit we use for our CI builds to match what the JDK did in openjdk/jdk#11869 to fix [JDK-8299693](https://bugs.openjdk.org/browse/JDK-8299693) to resolve a build issue on macOS 13.x Ventura. There are no changes in Xcode itself.

-------------

Commit messages:
 - 8304665: Change to Xcode12.4+1.1 devkit

Changes: https://git.openjdk.org/jfx/pull/1063/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304665
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1063.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1063/head:pull/1063

PR: https://git.openjdk.org/jfx/pull/1063

From kcr at openjdk.org  Tue Mar 21 14:17:50 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Mar 2023 14:17:50 GMT
Subject: RFR: 8304665: Change to Xcode12.4+1.1 devkit
In-Reply-To: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
References: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
Message-ID: <Js4gp5FWeGk38dgNtn8ZAv6CASuY_8wzMW8-gc2FvA8=.016f159f-cb0a-4ca5-820c-c0ba5eac2095@github.com>

On Tue, 21 Mar 2023 14:07:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This bumps the build number for the devkit we use for our CI builds to match what the JDK did in openjdk/jdk#11869 to fix [JDK-8299693](https://bugs.openjdk.org/browse/JDK-8299693) to resolve a build issue on macOS 13.x Ventura. There are no changes in Xcode itself.

Reviewer: @arapte 

I'll wait for a day to integrate this in case @johanvos or @tiainen have any comments (although I expect that this won't affect their builds).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1063#issuecomment-1477916800

From jvos at openjdk.org  Tue Mar 21 14:23:06 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 21 Mar 2023 14:23:06 GMT
Subject: RFR: 8304665: Change to Xcode12.4+1.1 devkit
In-Reply-To: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
References: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
Message-ID: <QJdituykx9NC88Y0aW3nVGHxcuWIGy1MgzVeCCcjPA4=.9a4cbfe0-f1d4-4e54-924f-0386585c498f@github.com>

On Tue, 21 Mar 2023 14:07:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This bumps the build number for the devkit we use for our CI builds to match what the JDK did in openjdk/jdk#11869 to fix [JDK-8299693](https://bugs.openjdk.org/browse/JDK-8299693) to resolve a build issue on macOS 13.x Ventura. There are no changes in Xcode itself.

Marked as reviewed by jvos (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1063#pullrequestreview-1350599561

From jvos at openjdk.org  Tue Mar 21 14:23:08 2023
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 21 Mar 2023 14:23:08 GMT
Subject: RFR: 8304665: Change to Xcode12.4+1.1 devkit
In-Reply-To: <Js4gp5FWeGk38dgNtn8ZAv6CASuY_8wzMW8-gc2FvA8=.016f159f-cb0a-4ca5-820c-c0ba5eac2095@github.com>
References: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
 <Js4gp5FWeGk38dgNtn8ZAv6CASuY_8wzMW8-gc2FvA8=.016f159f-cb0a-4ca5-820c-c0ba5eac2095@github.com>
Message-ID: <Z7iJ-zrP1uI0Dr1Q3ybMiv4LEqa96MDoKmAs-4tU1YE=.eca94063-55eb-42a5-865b-3b1867c68c3c@github.com>

On Tue, 21 Mar 2023 14:15:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Reviewer: @arapte
> 
> I'll wait for a day to integrate this in case @johanvos or @tiainen have any comments (although I expect that this won't affect their builds).

This indeed doesn't affect our builds (for now) -- go ahead.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1063#issuecomment-1477927501

From arapte at openjdk.org  Tue Mar 21 15:12:54 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 21 Mar 2023 15:12:54 GMT
Subject: RFR: 8304665: Change to Xcode12.4+1.1 devkit
In-Reply-To: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
References: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
Message-ID: <ecZQaNyPrm6UXXr1pY-dK5xfNPtQf46Hd8C49DJFXf0=.cd73948f-a861-46b3-b9b9-fb8aa8a7f754@github.com>

On Tue, 21 Mar 2023 14:07:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This bumps the build number for the devkit we use for our CI builds to match what the JDK did in openjdk/jdk#11869 to fix [JDK-8299693](https://bugs.openjdk.org/browse/JDK-8299693) to resolve a build issue on macOS 13.x Ventura. There are no changes in Xcode itself.

Marked as reviewed by arapte (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1063#pullrequestreview-1350719462

From duke at openjdk.org  Tue Mar 21 22:49:34 2023
From: duke at openjdk.org (Martin Fox)
Date: Tue, 21 Mar 2023 22:49:34 GMT
Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v7]
In-Reply-To: <wqczQSMrWbX5jGjbbINLlChHN4qGcbowKhS851EGIyw=.bfb72ac4-78ea-4f08-80fd-67521e15b139@github.com>
References: <wqczQSMrWbX5jGjbbINLlChHN4qGcbowKhS851EGIyw=.bfb72ac4-78ea-4f08-80fd-67521e15b139@github.com>
Message-ID: <qIEqLtvZs_KXzgraClHESsTRVW-SLmu4OTyESX3e6y8=.84fa4050-afe3-4ab7-8aeb-f74e57c6b0ea@github.com>

> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as expected by more accurately mapping from a Mac key code to a Java key code based on the user?s active keyboard layout (the existing code assumes a US QWERTY layout). The new code first identifies a set of Mac keys which can produce different characters based on the user?s keyboard layout. A Mac key code outside that area is processed exactly as before. For a key inside the layout-sensitive area the code calls UCKeyTranslate to translate the key to an unshifted ASCII character based on the active keyboard and uses that to determine the Java key code.
> 
> When performing the reverse mapping for the Robot the code first uses the old QWERTY mapping to find a candidate key. If it lies in the layout-sensitive area the code then scans the entire area calling UCKeyTranslate until it finds a match. If the key lies outside the layout-sensitive area it?s processed exactly as before.
> 
> There are multiple duplicates of these bugs logged against Mac applications built with JavaFX.
> 
> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents with alternative keyboard layouts
> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z accelerator is not working with French keyboard
> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't take into account azerty keyboard layout
> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard Layout (Y/Z)

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Added manual cross-platform keyboard handling test

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/425/files
  - new: https://git.openjdk.org/jfx/pull/425/files/99d24ae0..47b4eb86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=425&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=425&range=05-06

  Stats: 812 lines in 1 file changed: 812 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/425.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/425/head:pull/425

PR: https://git.openjdk.org/jfx/pull/425

From kcr at openjdk.org  Tue Mar 21 23:39:52 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Mar 2023 23:39:52 GMT
Subject: Integrated: 8304665: Change to Xcode12.4+1.1 devkit
In-Reply-To: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
References: <Uaut4Jw_D3KSJyLOma4igjyJzcMCN2O5Uib6BhAMVBs=.2207ecd5-1e78-4d24-91cb-4aec663f091b@github.com>
Message-ID: <k6vUQv6maAujxqMtb-IV6C4xibTxQRUpVROqjqDYSYQ=.5c454d8f-7717-44d3-a28f-26d93fe4168c@github.com>

On Tue, 21 Mar 2023 14:07:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This bumps the build number for the devkit we use for our CI builds to match what the JDK did in openjdk/jdk#11869 to fix [JDK-8299693](https://bugs.openjdk.org/browse/JDK-8299693) to resolve a build issue on macOS 13.x Ventura. There are no changes in Xcode itself.

This pull request has now been integrated.

Changeset: d875c876
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d875c876512260b47e93c49270e7dcc589a7c8b2
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8304665: Change to Xcode12.4+1.1 devkit

Reviewed-by: jvos, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/1063

From jhendrikx at openjdk.org  Wed Mar 22 10:05:46 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 22 Mar 2023 10:05:46 GMT
Subject: RFR: JDK-8304705 Parent class contains 6 constants that should be
 static
Message-ID: <X7zSFhEYTSxE6_M5YLUXyN_6TtQWx9Mt0gnFsXTbTbA=.fc8ac190-21d9-44cb-b714-f4712fa7bac3@github.com>

Made 6 constants static in `Parent`.  Discovered these with the Java Object Layout tool.

-------------

Commit messages:
 - Make constants static

Changes: https://git.openjdk.org/jfx/pull/1064/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304705
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1064.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1064/head:pull/1064

PR: https://git.openjdk.org/jfx/pull/1064

From armin.schrenk at skymatic.de  Wed Mar 22 10:55:45 2023
From: armin.schrenk at skymatic.de (Armin Schrenk)
Date: Wed, 22 Mar 2023 11:55:45 +0100
Subject: Loading of shared libraries required by JFX
Message-ID: <5f275e93-8b40-4210-eebd-1a9289f22158@skymatic.de>

Hey everybody,

what is the recommended way for loading shared libraries required by 
JFX? I have to decide between "java.library.path" and some internal path 
determination of jfx.

My background: I'm a software developer of Cryptomator, a Java GUI app 
to encrypt files using JFX. We are shipping the app with a custom JRE 
created with jlink. A while ago, I learned on this mailing list that the 
recommended way of shipping the required shared libs is by backing them 
into the custom JRE using jmods. We changed our CI builds and thought 
everything is working now, but another problem arose. Depending on the 
used JDK, on Windows the shipped native libs were not used, but the ones 
found in the system PATH variable. During investigation, we also looked 
in the jfx project at the class "NativeLibLoader.class", which handles 
the loading of the shared libraries. (Source: 
https://github.com/openjdk/jfx/blob/19.0.2.1%2B1/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java)

The loading precedence is according to inline documentation (line 117 
ff) the following:

// The search order for native library loading is:
// - try to load the native library from either ${java.home}
//?? (for jlinked javafx modules) or from the same folder as
//?? this jar (if using modular jars)
// - if the native library comes bundled as a resource it is extracted
//?? and loaded
// - the java.library.path is searched for the library in definition
//?? order
// - the library is loaded via System#loadLibrary
// - on iOS native library is staticly linked and detected from the
//?? existence of a JNI_OnLoad_libraryname funtion

BUT,? 2 lines below there is a FIXME comment stating to eventually 
discard the first step (load from java.home or jar). Hence my question: 
Should we directly switch to the second or third step or does the 
comment target something different?

Kind regards,

Armin


PS: Regarding the the problem using different JDKs: Azul offers its Zulu 
JDK in a "JFX flavor", but this flavor is not directly compatible with 
the NativeLibLoader of JFX. For more details, see 
https://forums.foojay.io/forums/topic/jdkfx-fx-app-with-custom-jre-created-with-jlink/


From kcr at openjdk.org  Wed Mar 22 12:21:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 12:21:55 GMT
Subject: RFR: JDK-8304705 Parent class contains 6 constants that should be
 static
In-Reply-To: <X7zSFhEYTSxE6_M5YLUXyN_6TtQWx9Mt0gnFsXTbTbA=.fc8ac190-21d9-44cb-b714-f4712fa7bac3@github.com>
References: <X7zSFhEYTSxE6_M5YLUXyN_6TtQWx9Mt0gnFsXTbTbA=.fc8ac190-21d9-44cb-b714-f4712fa7bac3@github.com>
Message-ID: <gvm7cC0K3gvq1cLpwsHh18J83UibVipa6Ub2al7DOh0=.5403a657-7360-4d40-a5f1-af4ff4619b30@github.com>

On Wed, 22 Mar 2023 10:00:04 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Made 6 constants static in `Parent`.  Discovered these with the Java Object Layout tool.

Looks good. This seems like an obvious oversight.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1064#pullrequestreview-1352455644

From kcr at openjdk.org  Wed Mar 22 14:12:59 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 14:12:59 GMT
Subject: RFR: 8304323 Provide infrastructure to make it possible for
 properties to delay listener registration
In-Reply-To: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>
References: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>
Message-ID: <eHQmvCSj0wFQ9YCdBsMVwc3yetJZqa24YsX7fOzZ5ck=.cacc8fae-2bba-4da4-819e-57ae598afd51@github.com>

On Sun, 5 Feb 2023 13:07:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR contains changes to make it easier to implement properties which want to conserve resources until they're observed themselves.  
> 
> `isObserved` is promoted from `ObjectBinding` to the `ObservableValue` interface, allowing you to ask any `ObservableValue` if it is currently observed (ie. if it has any listeners registered on it).  All JavaFX `ObservableValue`s implementations are modified to implement this method.
> 
> The protected methods `observed` and `unobserved` are added to all extendable (non final) `ObservableValue`s provided by JavaFX.  The `observed` call back is only called when the observable currently has 0 listeners and will soon have 1 listener.  During the call back, `isObserved` still returns `false` (see below for why this was chosen).  The `unobserved` call back is only called when the last listener was removed and the observable has 0 listeners.  During the call back, `isObserved` will already return `false`.
> 
> The reason why `observed` is called before `isObserved` starts returning `true` (and also why `unobserved` works the opposite) is to make it easy to implement a parent-child relationship where a nested property becoming observed may need to trigger behavior in its parent. Given a parent class and two nested properties `foo` and `bar`:
> 
>      class FooProperty extends ObjectPropertyBase<Foo> {
>           void observed() {
>                nestedPropertyObserved();  // call to parent
>           }
> 
>           void unobserved() {
>                nestedPropertyUnobserved();  // call to parent
>           }
>      }
> 
> The parent may determine whether any of the properties is observed with a helper:
> 
>       private boolean isANestedPropertyObserved() {
>            return foo.isObserved() || bar.isObserved();
>       }
> 
> The `nestedPropertyObserved` and `nestedPropertyUnobserved` methods can now be implemented simply as:
> 
>       private void nestedPropertyObserved() {
>             if (!isANestedPropertyObserved()) {
>                 // take action as no properties were observed before, but now one will become observed
>             }
>       }
> 
>       private void nestedPropertyUnobserved() {
>             if (!isANestedPropertyObserved()) {
>                 // take action as a property was observed before, but the last listener is about to be removed
>             }
>       }
> 
> If `isObserved` would change immediately, this becomes more difficult as the observed status of the property that has just become observed would need to be excluded to determine if this is the first observation of a nested property or a later one.
> 
> - Add `isObserved` to `ObservableValue` to check if it is observed and implement it in all overriding classes
> - Add `observed`/`unobserved` protected methods to all extendable observables
> - Use *Base classes in a few places (avoids duplication code)
> - Simplify `LazyObjectBinding`
> - In `ObjectBinding`, `isObserved` has become public as it is specified by the `ObservableValue` interface now

@nlisker do you also want to review this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1023#issuecomment-1479635579

From nlisker at openjdk.org  Wed Mar 22 15:17:08 2023
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 22 Mar 2023 15:17:08 GMT
Subject: RFR: 8304323 Provide infrastructure to make it possible for
 properties to delay listener registration
In-Reply-To: <eHQmvCSj0wFQ9YCdBsMVwc3yetJZqa24YsX7fOzZ5ck=.cacc8fae-2bba-4da4-819e-57ae598afd51@github.com>
References: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>
 <eHQmvCSj0wFQ9YCdBsMVwc3yetJZqa24YsX7fOzZ5ck=.cacc8fae-2bba-4da4-819e-57ae598afd51@github.com>
Message-ID: <ltjhTamSDTTQYX2NviZ6CfTCMQho_QHsVEV-ntCBpSs=.4f36c2b3-6080-4d40-82bf-946f13e1ee25@github.com>

On Wed, 22 Mar 2023 14:10:20 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> @nlisker do you also want to review this?

Yes, but it will take me a bit of time to get to it.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1023#issuecomment-1479756994

From kcr at openjdk.org  Wed Mar 22 15:19:50 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 15:19:50 GMT
Subject: RFR: 8304323 Provide infrastructure to make it possible for
 properties to delay listener registration
In-Reply-To: <ltjhTamSDTTQYX2NviZ6CfTCMQho_QHsVEV-ntCBpSs=.4f36c2b3-6080-4d40-82bf-946f13e1ee25@github.com>
References: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>
 <eHQmvCSj0wFQ9YCdBsMVwc3yetJZqa24YsX7fOzZ5ck=.cacc8fae-2bba-4da4-819e-57ae598afd51@github.com>
 <ltjhTamSDTTQYX2NviZ6CfTCMQho_QHsVEV-ntCBpSs=.4f36c2b3-6080-4d40-82bf-946f13e1ee25@github.com>
Message-ID: <T5TI3Ds6pAibdzM02hBBJHuR22RZWtFV1TDbXN11edA=.f4c2bb74-4084-477c-b320-754360ffaa35@github.com>

On Wed, 22 Mar 2023 15:14:22 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > @nlisker do you also want to review this?
> 
> Yes, but it will take me a bit of time to get to it.

Likewise. This is a pretty big change that will need careful review.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1023#issuecomment-1479761993

From jhendrikx at openjdk.org  Wed Mar 22 15:44:53 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 22 Mar 2023 15:44:53 GMT
Subject: RFR: 8304323 Provide infrastructure to make it possible for
 properties to delay listener registration
In-Reply-To: <T5TI3Ds6pAibdzM02hBBJHuR22RZWtFV1TDbXN11edA=.f4c2bb74-4084-477c-b320-754360ffaa35@github.com>
References: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>
 <eHQmvCSj0wFQ9YCdBsMVwc3yetJZqa24YsX7fOzZ5ck=.cacc8fae-2bba-4da4-819e-57ae598afd51@github.com>
 <ltjhTamSDTTQYX2NviZ6CfTCMQho_QHsVEV-ntCBpSs=.4f36c2b3-6080-4d40-82bf-946f13e1ee25@github.com>
 <T5TI3Ds6pAibdzM02hBBJHuR22RZWtFV1TDbXN11edA=.f4c2bb74-4084-477c-b320-754360ffaa35@github.com>
Message-ID: <NnFOD6lQA0OV_VDYO6wriQs89k63PU8iqCwPEspL6LI=.a7dfc022-0beb-4e6c-a142-4f2c998b9ae5@github.com>

On Wed, 22 Mar 2023 15:17:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> @nlisker do you also want to review this?
>> 
>> Yes, but it will take me a bit of time to get to it.
>
>> > @nlisker do you also want to review this?
>> 
>> Yes, but it will take me a bit of time to get to it.
> 
> Likewise. This is a pretty big change that will need careful review.

@kevinrushforth @nlisker There is some small overlap with https://github.com/openjdk/jfx/pull/1056 where I fixed some unnecessary invalidations in existing code. Either this PR or the other one will need to be adjusted slightly when the other is accepted.

BTW, not sure why `jcheck` keeps failing on this PR, as far as I can see it is not a lack of reviewers or an incorrect title.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1023#issuecomment-1479806392

From jhendrikx at openjdk.org  Wed Mar 22 15:46:52 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 22 Mar 2023 15:46:52 GMT
Subject: Integrated: JDK-8304705 Parent class contains 6 constants that should
 be static
In-Reply-To: <X7zSFhEYTSxE6_M5YLUXyN_6TtQWx9Mt0gnFsXTbTbA=.fc8ac190-21d9-44cb-b714-f4712fa7bac3@github.com>
References: <X7zSFhEYTSxE6_M5YLUXyN_6TtQWx9Mt0gnFsXTbTbA=.fc8ac190-21d9-44cb-b714-f4712fa7bac3@github.com>
Message-ID: <SOIW3Jzg5x0hL8sZjGkR9w9nAPSXGGT4EUlm3-OKVs0=.55b1d61d-e265-444e-b844-bca468759007@github.com>

On Wed, 22 Mar 2023 10:00:04 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Made 6 constants static in `Parent`.  Discovered these with the Java Object Layout tool.

This pull request has now been integrated.

Changeset: 85e529de
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/85e529de7307b85c2ead204284cefa3994553310
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8304705: Parent class contains 6 constants that should be static

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1064

From kcr at openjdk.org  Wed Mar 22 16:19:00 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 16:19:00 GMT
Subject: RFR: 8304323 Provide infrastructure to make it possible for
 properties to delay listener registration
In-Reply-To: <NnFOD6lQA0OV_VDYO6wriQs89k63PU8iqCwPEspL6LI=.a7dfc022-0beb-4e6c-a142-4f2c998b9ae5@github.com>
References: <wWKY87ViwdC4QkNZ6V37OHLEvf38N7VTxV8IIQCN1ss=.4a6ce224-d239-487d-8cbe-14bf858d1a7c@github.com>
 <eHQmvCSj0wFQ9YCdBsMVwc3yetJZqa24YsX7fOzZ5ck=.cacc8fae-2bba-4da4-819e-57ae598afd51@github.com>
 <ltjhTamSDTTQYX2NviZ6CfTCMQho_QHsVEV-ntCBpSs=.4f36c2b3-6080-4d40-82bf-946f13e1ee25@github.com>
 <T5TI3Ds6pAibdzM02hBBJHuR22RZWtFV1TDbXN11edA=.f4c2bb74-4084-477c-b320-754360ffaa35@github.com>
 <NnFOD6lQA0OV_VDYO6wriQs89k63PU8iqCwPEspL6LI=.a7dfc022-0beb-4e6c-a142-4f2c998b9ae5@github.com>
Message-ID: <BBJwl_1h8cbHSmqNGdvwqjMlAxC_hMW6nKgRiES5b_A=.0053d9ff-eb97-4150-9aad-44a568480c8c@github.com>

On Wed, 22 Mar 2023 15:42:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> BTW, not sure why `jcheck` keeps failing on this PR, as far as I can see it is not a lack of reviewers or an incorrect title.

It doesn't keep failing. The `jcheck` check is a stale check that has been superseded by `jcheck-openjdk/jfx-1023` (a recent change in Skara changed the name of this check). Note that the `jcheck` check was last run on Feb 7. Skara will ignore the stale check (and so can we).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1023#issuecomment-1479845184

From kevin.rushforth at oracle.com  Wed Mar 22 17:42:09 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 22 Mar 2023 10:42:09 -0700
Subject: Loading of shared libraries required by JFX
In-Reply-To: <5f275e93-8b40-4210-eebd-1a9289f22158@skymatic.de>
References: <5f275e93-8b40-4210-eebd-1a9289f22158@skymatic.de>
Message-ID: <652d96f4-ce1b-27ba-71a4-687d56318c28@oracle.com>

This seems like a bug to me. Can you provide the output of running with 
"java -Djavafx.verbose=true". That will show how the libraries are being 
loaded. Depending on what the verbose output shows, we can file a bug to 
investigate fixing it. As for your question about the first item in the 
search order, I think that comment is wrong (I'll take a closer look), 
since it should be using that first step for a custom jlinked JDK with 
the JavaFX modules.

Can you confirm that the JavaFX libraries are in $JAVA_HOME/bin/javafx 
and not in $JAVA_HOME/bin?

-- Kevin


On 3/22/2023 3:55 AM, Armin Schrenk wrote:
> Hey everybody,
>
> what is the recommended way for loading shared libraries required by 
> JFX? I have to decide between "java.library.path" and some internal 
> path determination of jfx.
>
> My background: I'm a software developer of Cryptomator, a Java GUI app 
> to encrypt files using JFX. We are shipping the app with a custom JRE 
> created with jlink. A while ago, I learned on this mailing list that 
> the recommended way of shipping the required shared libs is by backing 
> them into the custom JRE using jmods. We changed our CI builds and 
> thought everything is working now, but another problem arose. 
> Depending on the used JDK, on Windows the shipped native libs were not 
> used, but the ones found in the system PATH variable. During 
> investigation, we also looked in the jfx project at the class 
> "NativeLibLoader.class", which handles the loading of the shared 
> libraries. (Source: 
> https://github.com/openjdk/jfx/blob/19.0.2.1%2B1/modules/javafx.graphics/src/main/java/com/sun/glass/utils/NativeLibLoader.java)
>
> The loading precedence is according to inline documentation (line 117 
> ff) the following:
>
> // The search order for native library loading is:
> // - try to load the native library from either ${java.home}
> //?? (for jlinked javafx modules) or from the same folder as
> //?? this jar (if using modular jars)
> // - if the native library comes bundled as a resource it is extracted
> //?? and loaded
> // - the java.library.path is searched for the library in definition
> //?? order
> // - the library is loaded via System#loadLibrary
> // - on iOS native library is staticly linked and detected from the
> //?? existence of a JNI_OnLoad_libraryname funtion
>
> BUT,? 2 lines below there is a FIXME comment stating to eventually 
> discard the first step (load from java.home or jar). Hence my 
> question: Should we directly switch to the second or third step or 
> does the comment target something different?
>
> Kind regards,
>
> Armin
>
>
> PS: Regarding the the problem using different JDKs: Azul offers its 
> Zulu JDK in a "JFX flavor", but this flavor is not directly compatible 
> with the NativeLibLoader of JFX. For more details, see 
> https://forums.foojay.io/forums/topic/jdkfx-fx-app-with-custom-jre-created-with-jlink/ 
>
>


From kcr at openjdk.org  Wed Mar 22 22:08:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 22:08:58 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <BqHthkyEu-fXihddKXYvJ_CcxW3jKjIfFZ2TWcYHOPI=.8b669a58-08b4-409d-93c7-cc603c016828@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
 <BqHthkyEu-fXihddKXYvJ_CcxW3jKjIfFZ2TWcYHOPI=.8b669a58-08b4-409d-93c7-cc603c016828@github.com>
Message-ID: <_HoBHTwpOXB1obrctX5kMAugYyLsIDEQ8Pj1bFd2d90=.bea29c66-c380-492d-8407-1fd6b1cc8eff@github.com>

On Mon, 6 Mar 2023 23:47:27 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Rollback + Change Warnings
>>  - Revert "Throw exception if unsupported or invalid version specified."
>>    
>>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.
>
> Will do it in a few days.

@tsayao The CSR is now approved, but the bot doesn't seem to think so. This is an oddity in the current behavior that I'm discussing with the Skara bot maintainers. Depending on the outcome, it might be necessary for you to merge your PR branch with the latest master to remedy it, but before you do that -- which would then require myself and Johan to re-review the PR -- let's wait another day.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/999#issuecomment-1480319386

From kcr at openjdk.org  Wed Mar 22 22:46:57 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 22:46:57 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <BqHthkyEu-fXihddKXYvJ_CcxW3jKjIfFZ2TWcYHOPI=.8b669a58-08b4-409d-93c7-cc603c016828@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
 <BqHthkyEu-fXihddKXYvJ_CcxW3jKjIfFZ2TWcYHOPI=.8b669a58-08b4-409d-93c7-cc603c016828@github.com>
Message-ID: <dVOf2kYBhvMZczwRA7a2JJl_eiR365uwf-E1mvPJvt0=.91bf3d94-449a-446e-a156-fb4fabec9a6f@github.com>

On Mon, 6 Mar 2023 23:47:27 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Rollback + Change Warnings
>>  - Revert "Throw exception if unsupported or invalid version specified."
>>    
>>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.
>
> Will do it in a few days.

@tsayao After discussion with the Skara bot maintainers, the conclusion is that you will need to merge the latest upstream master into your branch in order for the bot to unblock this. The current situation isn't ideal, but there isn't a quick solution in the bot (and I don't want to work around it by removing the requirement for a CSR, since it isn't that urgent to get this integrated).

@johanvos and I will need to do a quick re-review once you merge from master.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/999#issuecomment-1480351621

From tsayao at openjdk.org  Wed Mar 22 23:08:49 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 22 Mar 2023 23:08:49 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v11]
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <vWE2a63U2CvKyHrJJ5Ch5N-hufiD4af-Tw32nsw2bRc=.0064e4de-4679-4eeb-8695-d84c6a06fe01@github.com>

> Simple PR to remove gtk2 library compilation and loading.

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 49 additional commits since the last revision:

 - Merge branch 'master' into remove_gtk2
 - Merge branch 'openjdk:master' into master
 - Merge branch 'master' into remove_gtk2
 - Merge branch 'openjdk:master' into master
 - Rollback + Change Warnings
 - Revert "Throw exception if unsupported or invalid version specified."
   
   This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.
 - Throw exception if unsupported or invalid version specified.
 - Review changes
 - Improve exception
 - Check minimum gtk version
 - ... and 39 more: https://git.openjdk.org/jfx/compare/fb0da259...c75c6449

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/999/files
  - new: https://git.openjdk.org/jfx/pull/999/files/c5ab9ba3..c75c6449

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=999&range=09-10

  Stats: 13748 lines in 405 files changed: 6828 ins; 5444 del; 1476 mod
  Patch: https://git.openjdk.org/jfx/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/999/head:pull/999

PR: https://git.openjdk.org/jfx/pull/999

From tsayao at openjdk.org  Wed Mar 22 23:08:51 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Wed, 22 Mar 2023 23:08:51 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v10]
In-Reply-To: <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <KRRR6MvegF3-5gVpTX9gIHyecsrowU3jH_9rrVLVUYs=.a99c1637-dd11-4f5d-b2a7-4f21a29e812d@github.com>
Message-ID: <bpAKOmiWJyQ02QW38gUI5jhrudS-ivjTvWZRLvYcgQs=.5f8f303e-4f69-4b13-bc62-fb14a2537743@github.com>

On Thu, 2 Mar 2023 17:01:02 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.

No problem. Merged from master.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/999#issuecomment-1480364290

From kcr at openjdk.org  Wed Mar 22 23:15:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 22 Mar 2023 23:15:35 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v11]
In-Reply-To: <vWE2a63U2CvKyHrJJ5Ch5N-hufiD4af-Tw32nsw2bRc=.0064e4de-4679-4eeb-8695-d84c6a06fe01@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <vWE2a63U2CvKyHrJJ5Ch5N-hufiD4af-Tw32nsw2bRc=.0064e4de-4679-4eeb-8695-d84c6a06fe01@github.com>
Message-ID: <6pir76AiIM0Rj42Tu9ioG6beTu2d7q1TsoaUHfHaERc=.179b545e-7b08-4ab3-bbcd-92aa604d2630@github.com>

On Wed, 22 Mar 2023 23:08:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> 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 49 additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_gtk2
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' into remove_gtk2
>  - Merge branch 'openjdk:master' into master
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.
>  - Throw exception if unsupported or invalid version specified.
>  - Review changes
>  - Improve exception
>  - Check minimum gtk version
>  - ... and 39 more: https://git.openjdk.org/jfx/compare/3e332994...c75c6449

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/999#pullrequestreview-1353616371

From fkirmaier at openjdk.org  Thu Mar 23 08:31:41 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 23 Mar 2023 08:31:41 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception [v2]
In-Reply-To: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
Message-ID: <lbwMH1boXWqarpnrjWaQFU4zIRqmmwlyLnjW96bQ560=.09be8031-d4a3-478b-868e-a8b86c33ae8f@github.com>

> When an exception is logged in JavaFX, then the exception is kept in a reference.
> This way, always the last logged exception is retained.
> 
> This is a memory-leak.
> This was done to write unit-tests to ensure certain error-cases are logged.
> 
> A simple fix is, to add a flag, to enable/disable retaining the exception.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8303740
  Added changes based on code review

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1053/files
  - new: https://git.openjdk.org/jfx/pull/1053/files/1fe0d464..ad34efb7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1053&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1053&range=00-01

  Stats: 45 lines in 3 files changed: 41 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1053.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1053/head:pull/1053

PR: https://git.openjdk.org/jfx/pull/1053

From fkirmaier at openjdk.org  Thu Mar 23 08:44:01 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 23 Mar 2023 08:44:01 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception [v2]
In-Reply-To: <lbwMH1boXWqarpnrjWaQFU4zIRqmmwlyLnjW96bQ560=.09be8031-d4a3-478b-868e-a8b86c33ae8f@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
 <lbwMH1boXWqarpnrjWaQFU4zIRqmmwlyLnjW96bQ560=.09be8031-d4a3-478b-868e-a8b86c33ae8f@github.com>
Message-ID: <sVtIEFYAezIaBtqfc-Ba3gU6TX7DJiULpsjgthXLkcA=.f8d3c2e2-7a08-4b9b-820b-871f90433a93@github.com>

On Thu, 23 Mar 2023 08:31:41 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When an exception is logged in JavaFX, then the exception is kept in a reference.
>> This way, always the last logged exception is retained.
>> 
>> This is a memory-leak.
>> This was done to write unit-tests to ensure certain error-cases are logged.
>> 
>> A simple fix is, to add a flag, to enable/disable retaining the exception.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8303740
>   Added changes based on code review

I've now updated the PR according to the feedback!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1053#issuecomment-1480789382

From fkirmaier at openjdk.org  Thu Mar 23 08:44:02 2023
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 23 Mar 2023 08:44:02 GMT
Subject: RFR: 8303740 JavaFX - Leak in Logging,
 Logging remembers last exception [v2]
In-Reply-To: <iwyFbS44PYPpn8x-BZpXlWLia3O3H9FiNHeQIxEsn0o=.19a13bd3-0712-48e0-8980-f697af4a65d2@github.com>
References: <lwtmAuFYNSdJOJnSLw9KMWUeOBg-nt5tCqTgg2wU-yc=.6210b7ec-7978-4cf0-b7a9-9db13e6419f0@github.com>
 <iwyFbS44PYPpn8x-BZpXlWLia3O3H9FiNHeQIxEsn0o=.19a13bd3-0712-48e0-8980-f697af4a65d2@github.com>
Message-ID: <XUzek1DmfSvh_pMmI9ZPZE2dFpty2RwyYx_GAgKKuwc=.48592279-5ffa-4dbb-bd02-b29d922b16c2@github.com>

On Sat, 11 Mar 2023 14:28:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8303740
>>   Added changes based on code review
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/Logging.java line 32:
> 
>> 30: public class Logging {
>> 31: 
>> 32:     public static boolean keepException = false;
> 
> I'd rather see a private field and a public setter/getter here. Please also add a comment on the setter/getter indicating that they are only used for testing.

done

> modules/javafx.base/src/test/java/test/com/sun/javafx/binding/TestLogging.java line 1:
> 
>> 1: package test.com.sun.javafx.binding;
> 
> You need to add a standard copyright header.

done

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1053#discussion_r1145847263
PR Review Comment: https://git.openjdk.org/jfx/pull/1053#discussion_r1145847602

From aghaisas at openjdk.org  Thu Mar 23 10:35:56 2023
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 23 Mar 2023 10:35:56 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics [v2]
In-Reply-To: <tLubbMQfYIbkIYm4EEfMnn0qeqDGuVW-2H6wxD9VuPQ=.4a0ea747-1af2-49a3-829b-682d80d9123a@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <tLubbMQfYIbkIYm4EEfMnn0qeqDGuVW-2H6wxD9VuPQ=.4a0ea747-1af2-49a3-829b-682d80d9123a@github.com>
Message-ID: <-h-CY_Q2An3OxkfeYwgpkSp0LuUo_SuKcBg7iLVBapk=.86da0042-0231-4c09-ac27-2d4c2887c8f9@github.com>

On Fri, 17 Mar 2023 06:12:07 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.
>> 
>> Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.
>> 
>> Added unit test to validate the fix.
>
> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Looks good to me!

-------------

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1059#pullrequestreview-1354291884

From kpk at openjdk.org  Thu Mar 23 11:07:57 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 23 Mar 2023 11:07:57 GMT
Subject: RFR: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics [v2]
In-Reply-To: <-h-CY_Q2An3OxkfeYwgpkSp0LuUo_SuKcBg7iLVBapk=.86da0042-0231-4c09-ac27-2d4c2887c8f9@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
 <tLubbMQfYIbkIYm4EEfMnn0qeqDGuVW-2H6wxD9VuPQ=.4a0ea747-1af2-49a3-829b-682d80d9123a@github.com>
 <-h-CY_Q2An3OxkfeYwgpkSp0LuUo_SuKcBg7iLVBapk=.86da0042-0231-4c09-ac27-2d4c2887c8f9@github.com>
Message-ID: <1tkl0AGTHxIk-vqON5JHABOkW0eEVlu05Y850Jdqq7I=.12ca709d-7f5e-4cee-8819-457f4c166db2@github.com>

On Thu, 23 Mar 2023 10:32:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Karthik P K has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> Looks good to me!

@aghaisas could you please sponsor this PR?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1059#issuecomment-1480991867

From jvos at openjdk.org  Thu Mar 23 11:17:09 2023
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 23 Mar 2023 11:17:09 GMT
Subject: RFR: 8299595: Remove terminally deprecated JavaFX GTK 2 library
 [v11]
In-Reply-To: <vWE2a63U2CvKyHrJJ5Ch5N-hufiD4af-Tw32nsw2bRc=.0064e4de-4679-4eeb-8695-d84c6a06fe01@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
 <vWE2a63U2CvKyHrJJ5Ch5N-hufiD4af-Tw32nsw2bRc=.0064e4de-4679-4eeb-8695-d84c6a06fe01@github.com>
Message-ID: <jGOIy7K2bdBK8Q57lz6VgnXFtAPbhTKMuPfehRR3c9g=.b78e72bb-7bc3-46e0-8fcc-803451142f14@github.com>

On Wed, 22 Mar 2023 23:08:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Simple PR to remove gtk2 library compilation and loading.
>
> 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 49 additional commits since the last revision:
> 
>  - Merge branch 'master' into remove_gtk2
>  - Merge branch 'openjdk:master' into master
>  - Merge branch 'master' into remove_gtk2
>  - Merge branch 'openjdk:master' into master
>  - Rollback + Change Warnings
>  - Revert "Throw exception if unsupported or invalid version specified."
>    
>    This reverts commit 9f8b60ff7d6045d8c35738b81a4f6a9a563129b4.
>  - Throw exception if unsupported or invalid version specified.
>  - Review changes
>  - Improve exception
>  - Check minimum gtk version
>  - ... and 39 more: https://git.openjdk.org/jfx/compare/46e71d3e...c75c6449

Marked as reviewed by jvos (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/999#pullrequestreview-1354358226

From tsayao at openjdk.org  Thu Mar 23 11:29:02 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 23 Mar 2023 11:29:02 GMT
Subject: Integrated: 8299595: Remove terminally deprecated JavaFX GTK 2 library
In-Reply-To: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
References: <jSZkw0iHTB-mDN_GcSbT2qcEqKynFrXPSyWMQO_odMk=.c9c4230e-1d6a-4292-a68b-b02ae2792a65@github.com>
Message-ID: <70exvqZHxrWwA0aDLkg8RYyxb7uJHFToKtJuYlCoggQ=.1b034914-fffd-4e78-9a4f-50069fb5f1e4@github.com>

On Tue, 17 Jan 2023 22:57:49 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Simple PR to remove gtk2 library compilation and loading.

This pull request has now been integrated.

Changeset: 63635ee8
Author:    Thiago Milczarek Sayao <tsayao at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/63635ee8160ba6507d625c44320b58e2f9bfb87a
Stats:     437 lines in 10 files changed: 158 ins; 242 del; 37 mod

8299595: Remove terminally deprecated JavaFX GTK 2 library

Reviewed-by: kcr, jvos

-------------

PR: https://git.openjdk.org/jfx/pull/999

From kpk at openjdk.org  Thu Mar 23 11:36:53 2023
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 23 Mar 2023 11:36:53 GMT
Subject: Integrated: 8172849: Non-intuitive baseline alignment for labeled
 controls with graphics
In-Reply-To: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
References: <3tXMoflFb3LdAiKGLgxuC7MAvtsRBJnbHkV8cjzdznk=.06f9772f-8255-42cb-a396-1fa67565f0bc@github.com>
Message-ID: <1asgHSiqMd9oEVVynwStQICQrMIL_QajW7uRaMgiCNc=.80d958ef-f30e-4b85-89fa-820e1f826828@github.com>

On Wed, 15 Mar 2023 10:58:14 GMT, Karthik P K <kpk at openjdk.org> wrote:

> Issue was observed because even when graphic height was less than text height of the Label, graphic height was considered while calculating the baseline offset. This was shifting the baseline offset and resulted in misalignment.
> 
> Updated `computeBaselineOffset` to exclude graphic height from baseline offset calculation when graphic height is more than text height.
> 
> Added unit test to validate the fix.

This pull request has now been integrated.

Changeset: ae2e71fc
Author:    Karthik P K <kpk at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ae2e71fc5ac2e6c7cf6d671c15b53249783c71b3
Stats:     50 lines in 2 files changed: 47 ins; 0 del; 3 mod

8172849: Non-intuitive baseline alignment for labeled controls with graphics

Reviewed-by: angorya, aghaisas

-------------

PR: https://git.openjdk.org/jfx/pull/1059

From john.hendrikx at gmail.com  Thu Mar 23 16:09:12 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 23 Mar 2023 17:09:12 +0100
Subject: Gauging interest in bindings that can delay changing their value
 (debounce/throttle)
Message-ID: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>

Hi list,

I've been working on a potential new API (and proof of concept 
implementation) for adding a new type of fluent binding which can delay 
changing their values, and I'm wondering how much interest there is in 
such a thing.

The main purpose of such an API is to prevent being flooded with changes 
when properties change often, or to simply delay certain actions until 
the user has settled on a selection or has stopped typing.

For this purpose I would like to introduce a default method on 
`ObservableValue` with the signature:

 ??? ObservableValue<T> throttle(Throttler throttler);

The parameter `Throttler` can be obtained via static methods of a helper 
class named `FXThrottlers`. These provide various pre-configured 
throttlers that work correctly with JavaFX's event thread model.? My 
current proof of concept provides:

 ??? public static Throttler debounce(Duration quietPeriod);
 ??? public static Throttler debounceTrailing(Duration quietPeriod);
 ??? public static Throttler throttle(Duration period);
 ??? public static Throttler throttleTrailing(Duration period);

These are variations of similar concepts, and vary mostly in when 
exactly they will allow value changes; debouncers will wait for a period 
without any changes, while throttlers will periodically allow changes. 
The trailing variants will not immediately emit the first change but 
will wait for the period to elapse first; all variants will eventually 
take on the value of the source observable.? Debouncing is typically 
used when you wish for an input to settle before taking action (like 
typing in a search bar), while throttling is used to give regular 
feedback but avoid doing so too often (like feedback during window 
resizing).

Usage example which updates a preview panel when the user has finished 
(cursor) scrolling through a list view:

 ??? ObjectProperty<T> selectedItem = 
listView.getSelectionModel().selectedItemProperty();

 ??? selectedItem
.throttle(FXThrottlers.debounceTrailing(Duration.ofMillis(500)))
 ??????? .addListener((obs, old, current) -> {
 ???????????? if (current != null) {
 ? ?? ??????????? updatePreviewPanel(current);
 ???????????? }
 ??????? });

Implementation details:

ObservableValue is part of javafx.base, and as such can't use animations 
or call Platform::runLater.? The ThrottledBinding implementation has 
abstracted all of these out into the Throttler class, and FXThrottlers 
(which would live in javafx.graphics) therefore provides the necessary 
call backs to integrate property changes correctly back onto the JavaFX 
event thread.? The Throttler class also simplifies testing; the test can 
provide its own timing source and background scheduler.? The Throttler 
interface has the following methods:

 ??? /**
 ???? * Schedules a command to run on an unspecified thread after the time
 ???? * given by {@code nanos} elapses.
 ???? *
 ???? * @param command a command to run, cannot be {@code null}
 ???? * @param nanos a time in nanoseconds
 ???? */
 ??? void schedule(Runnable command, long nanos);

 ??? /**
 ???? * Provides the current time in nanoseconds.
 ???? *
 ???? * @return the current time in nanoseconds
 ???? */
 ??? long nanoTime();

 ??? /**
 ???? * Runs the given command as soon as possible on a thread specified 
by this
 ???? * throttler for updating property values.
 ???? *
 ???? * @param command a command to run, cannot be {@code null}
 ???? */
 ??? void update(Runnable command);

 ??? /**
 ???? * Given the current elapsed time in the current change window, and the
 ???? * amount of time elapsed since the last change was detected, 
determines
 ???? * if and by how much the current change window should be extended.
 ???? *
 ???? * @param elapsed nanoseconds elapsed since the start of the 
current change window
 ???? * @param elapsedSinceLastChange nanoseconds elapsed since the last 
change
 ???? * @return nanoseconds to extend the window with
 ???? */
 ??? long determineInterval(long elapsed, long elapsedSinceLastChange);

For testing purposes, the schedule and nanoTime can be provided such 
that the throttle function can be tested deterministically. For 
integrating with JavaFX, update is implemented as 
`Platform.runLater(command)`.? The schedule and nanoTime methods 
delegate to an Executor and System.nanoTime respectively.? When using 
properties without JavaFX, Throttler implementations can be provided 
which run property updates on a scheduler thread (just calling 
Runnable::run on the current thread) or via some user provided executor.

A sample test case looks like this (read with a mono space font :-)):

 ??? @Test
 ??? void testThrottleLeadingAndTrailing() {
 ????? // create Throttler with deterministic behavior:
 ????? Throttler throttler = 
create(Throttler.IntervalHandler.throttle(Duration.ofNanos(4));

 ????? // create throttled observable:
 ????? ObservableValue<String> binding = source.throttle(throttler);

 ????? assertChanges(
 ??????? binding,
 ??????? "--a-b--c---d-----e-------f-g-----------f-g-----",
 ??????? "--a---b---c---d---e------f---g---------f---g---"
 ????? );

 ????? assertInvalidations(
 ??????? binding,
 ??????? "--a-b--c---d-----e-------f-g-----------f-g-----",
 ??????? "--i---i---i---i---i------i---i---------i---i---"
 ????? );
 ??? }

Thanks for reading, I look forward to your feedback!

--John





From tsayao at openjdk.org  Thu Mar 23 23:40:31 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 23 Mar 2023 23:40:31 GMT
Subject: RFR: 8304832: [linux] Exception initializing the JavaFX runtime when a
 security manager is enabled
Message-ID: <7gMZ4Ac3UKSECwJO0xY8ZqDRX2IBH7nbfI52FPiK1Xc=.8add00f4-1166-4d22-8f6d-b69bbfbe1d74@github.com>

#999 changed the way to detect SWT gtk version to read a system property. It was done without the security manger call, causing the issue.

-------------

Commit messages:
 - Fix startup with security manager
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 26 more: https://git.openjdk.org/jfx/compare/ae2e71fc...da8621ec

Changes: https://git.openjdk.org/jfx/pull/1065/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1065&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304832
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1065.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1065/head:pull/1065

PR: https://git.openjdk.org/jfx/pull/1065

From tsayao at openjdk.org  Thu Mar 23 23:45:18 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Thu, 23 Mar 2023 23:45:18 GMT
Subject: RFR: 8304832: [linux] Exception initializing the JavaFX runtime
 when a security manager is enabled [v2]
In-Reply-To: <7gMZ4Ac3UKSECwJO0xY8ZqDRX2IBH7nbfI52FPiK1Xc=.8add00f4-1166-4d22-8f6d-b69bbfbe1d74@github.com>
References: <7gMZ4Ac3UKSECwJO0xY8ZqDRX2IBH7nbfI52FPiK1Xc=.8add00f4-1166-4d22-8f6d-b69bbfbe1d74@github.com>
Message-ID: <q-rIMeo-h93p2qE8-sWJErVJgeYwbG_CxFBmY-Dvq3c=.780ae908-8590-4e5f-8871-70a007628fba@github.com>

> #999 changed the way to detect SWT gtk version to read a system property. It was done without the security manger call, causing the issue.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Supress warning

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1065/files
  - new: https://git.openjdk.org/jfx/pull/1065/files/da8621ec..43168d82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1065&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1065&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1065.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1065/head:pull/1065

PR: https://git.openjdk.org/jfx/pull/1065

From kcr at openjdk.org  Fri Mar 24 12:10:56 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 24 Mar 2023 12:10:56 GMT
Subject: RFR: 8304832: [linux] Exception initializing the JavaFX runtime
 when a security manager is enabled [v2]
In-Reply-To: <q-rIMeo-h93p2qE8-sWJErVJgeYwbG_CxFBmY-Dvq3c=.780ae908-8590-4e5f-8871-70a007628fba@github.com>
References: <7gMZ4Ac3UKSECwJO0xY8ZqDRX2IBH7nbfI52FPiK1Xc=.8add00f4-1166-4d22-8f6d-b69bbfbe1d74@github.com>
 <q-rIMeo-h93p2qE8-sWJErVJgeYwbG_CxFBmY-Dvq3c=.780ae908-8590-4e5f-8871-70a007628fba@github.com>
Message-ID: <7t1FpGsuo-KH8OvhJ3eA3lrm77hp2FFQm6629zvo6a0=.b1664dfc-f1bd-4461-9411-84e1d57e9e18@github.com>

On Thu, 23 Mar 2023 23:45:18 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> #999 changed the way to detect SWT gtk version to read a system property. It was done without the security manger call, causing the issue.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Supress warning

Looks good. Thanks for the quick fix.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1065#pullrequestreview-1356570852

From tsayao at openjdk.org  Fri Mar 24 12:22:44 2023
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 24 Mar 2023 12:22:44 GMT
Subject: Integrated: 8304832: [linux] Exception initializing the JavaFX runtime
 when a security manager is enabled
In-Reply-To: <7gMZ4Ac3UKSECwJO0xY8ZqDRX2IBH7nbfI52FPiK1Xc=.8add00f4-1166-4d22-8f6d-b69bbfbe1d74@github.com>
References: <7gMZ4Ac3UKSECwJO0xY8ZqDRX2IBH7nbfI52FPiK1Xc=.8add00f4-1166-4d22-8f6d-b69bbfbe1d74@github.com>
Message-ID: <Fa2CMh41nWLLjXrVSKAjsCv87JgECpQQTn2GEfciwVs=.5fc3ef45-0b93-4d02-8713-e9a7ab7ff93c@github.com>

On Thu, 23 Mar 2023 23:33:09 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> #999 changed the way to detect SWT gtk version to read a system property. It was done without the security manger call, causing the issue.

This pull request has now been integrated.

Changeset: 102a90ce
Author:    Thiago Milczarek Sayao <tsayao at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/102a90ceee88e6ccf6703519b5f722f23dc58a3a
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8304832: [linux] Exception initializing the JavaFX runtime when a security manager is enabled

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1065

From armin.schrenk at skymatic.de  Fri Mar 24 14:43:20 2023
From: armin.schrenk at skymatic.de (Armin Schrenk)
Date: Fri, 24 Mar 2023 15:43:20 +0100
Subject: Loading of shared libraries required by JFX
In-Reply-To: <mailman.44866.1679526537.325.openjfx-dev@openjdk.org>
References: <mailman.44866.1679526537.325.openjfx-dev@openjdk.org>
Message-ID: <271ef5c6-2db7-b80e-4d49-55563643eccc@skymatic.de>

Just to avoid confusion: Building a custom JRE with jlink with the Azul 
Zulu JDK+FX on Windows, the resulting JRE does not have a not have 
"/bin/javafx". That bug is either in the Zulu JDK or in jlink itself.

An excerpt from stdout/stderr with Zulu being the build JDK:
//-- general dlls required by jdk --
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program 
Files\Cryptomator\runtime\bin\javafx\msvcp140_1.dll
Loaded C:\WINDOWS\system32\msvcp140_1.dll from java.library.path
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program 
Files\Cryptomator\runtime\bin\javafx\msvcp140_2.dll
Loaded C:\WINDOWS\system32\msvcp140_2.dll from java.library.path
//-- jfx specifc dlls --
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program 
Files\Cryptomator\runtime\bin\javafx\prism_d3d.dll
System.loadLibrary(prism_d3d) succeeded
JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program 
Files\Cryptomator\runtime\bin\javafx\glass.dll
System.loadLibrary(glass) succeeded
14:44:49.558 [JavaFX Application Thread] INFO 
o.cryptomator.launcher.Cryptomator - JavaFX runtime started after 962ms
WARNING: java.lang.UnsatisfiedLinkError: Can't load library: C:\Program 
Files\Cryptomator\runtime\bin\javafx\javafx_font.dll
System.loadLibrary(javafx_font) succeeded

I marked with two comments, which DLLs are in general needed by the JDK 
and which are JFX specifc. The build JDK was zulu19.32.15 +FX . As it 
can be seen in the excerpt, the JDK DLLs and JFX DLLs are also loaded 
differently (Stdout message: "Loaded XXX.dll from java.library.path" vs 
"System.loadLibrary(XXX) succeeded"). Looking into NativeLibLoader.java, 
those are the third and fourth try of loading a shared lib. While 
System.loadLibrary(...) does not have documented load order 
(https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/System.html#loadLibrary(java.lang.String)), 
it seems like it also checks "java.home".

This approach (third traverse java.library.path and only on fourth try 
use System.loadLib) breaks the application under the following conditions:
* app uses the default "java.library.path" (defaults to %PATH% in Windows)
* %PATH% has a directory, which contains required (aka with the same 
name), but outdated DLLs
A user of Cryptomator had a JRE 8 in its path "C:\Program Files 
(x86)\Zulu\zulu-8-jre\bin\", which resulted in loading the wrong libs. 
If the load order would be to call System.loadLibrary(...) before 
traversing "java.library.path", in this application _might_ run. (since 
System.loadLibrary(...) lacks documentation about where it looks first 
for shared libs this might also depend on the JDK)

 > Can you confirm that the JavaFX libraries are in 
$JAVA_HOME/bin/javafx and not in $JAVA_HOME/bin?

As mentioned before, this depends on the build JDK. With Zulu JDK+FX, 
"bin/javafx/" won't be created and all JFX related shared libs are 
inside the "/bin" directory. With Adoptium JDK and additional Gluon 
Jmods, "bin/javafx" exists. In my previous mail I linked post in the 
zulu dev forum, asking for this behaviour.

In the end, for us the failure cause is clear. What we are asking now 
ourself is, what the best fix is:
* use a different JDK (because Zulu might be broken)
* define "java.library.path" (because this might be the convention/spec)
Since JFX has this custom lib loader, we hope to get some suggestion on 
this list.

Kind regards,

Armin

Am 23/03/2023 um 00:08 schrieb openjfx-dev-request at openjdk.org:
> Message: 1
> Date: Wed, 22 Mar 2023 10:42:09 -0700
> From: Kevin Rushforth <kevin.rushforth at oracle.com>
> To: openjfx-dev at openjdk.org
> Subject: Re: Loading of shared libraries required by JFX
> Message-ID: <652d96f4-ce1b-27ba-71a4-687d56318c28 at oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> This seems like a bug to me. Can you provide the output of running with
> "java -Djavafx.verbose=true". That will show how the libraries are being
> loaded. Depending on what the verbose output shows, we can file a bug to
> investigate fixing it. As for your question about the first item in the
> search order, I think that comment is wrong (I'll take a closer look),
> since it should be using that first step for a custom jlinked JDK with
> the JavaFX modules.
>
> Can you confirm that the JavaFX libraries are in $JAVA_HOME/bin/javafx
> and not in $JAVA_HOME/bin?
>
> -- Kevin

From kcr at openjdk.org  Sat Mar 25 15:56:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 25 Mar 2023 15:56:38 GMT
Subject: RFR: 8304924: [testbug] Skip failing tests on Linux
Message-ID: <iW-rYGJmPgkBaqCXojciwwq5QbuZBE8pT7evieUeu-Q=.299f12f3-97ec-4c6c-8d51-963c0697caee@github.com>

This PR skips three headful tests on Linux until the issues with the tests can be fixed. These tests consistently fail on our physical Ubuntu 22.04 test machine. This is a step towards getting clean headful test runs. Each of the skipped tests has an associated bug that needs to be fixed.

-------------

Commit messages:
 - 8304924: [testbug] Skip failing tests on Linux

Changes: https://git.openjdk.org/jfx/pull/1068/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1068&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304924
  Stats: 22 lines in 3 files changed: 14 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1068.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1068/head:pull/1068

PR: https://git.openjdk.org/jfx/pull/1068

From jhendrikx at openjdk.org  Sat Mar 25 16:26:30 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 25 Mar 2023 16:26:30 GMT
Subject: RFR: JDK-8304439: Subscription based listeners
Message-ID: <RVyMTPlZqQevyemG8d7GhaOG7DeYXygXhOqifPI8V6M=.9b6545f9-199a-4d36-bbe3-bf497a0fdebf@github.com>

Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`.

-------------

Commit messages:
 - Make Subscription public and add methods to provide them

Changes: https://git.openjdk.org/jfx/pull/1069/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304439
  Stats: 461 lines in 11 files changed: 328 ins; 122 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1069.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069

PR: https://git.openjdk.org/jfx/pull/1069

From michaelstrau2 at gmail.com  Mon Mar 27 00:48:43 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 27 Mar 2023 02:48:43 +0200
Subject: Allow input controls to indicate significant user interaction
Message-ID: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>

Many form-based applications require some sort of data validation for
input controls. It is also often desirable to visualize the validation
state of a control directly in the user interface, for example by
showing a red border to indicate a validation failure.

However, simply validating the current value of a control and
rendering a validation decorator often leads to an undesirable user
experience: for example, in many cases an empty form field shouldn't
indicate a validation failure unless the user has significantly
interacted with the field, or validation was explicitly requested by
pressing a "submit" button.

The first of these validation conditions, "significantly interacted
with the input control" is quite popular on contemporary web forms,
and offers a balanced user experience compared to immediately and
eagerly validating every control, or delaying validation until the
very end of the form submission process (see also the proposed
:user-valid/:user-invalid CSS pseudo-classes).

Unfortunately, this is very hard to implement in JavaFX since controls
have no way of signalling when they were significantly interacted
with. In particular, we don't want to count programmatic
initialization of field values as a significant interaction. What
constitutes a significant interaction is dependent on the type of
input control. For example, a text field might define a significant
interaction as the sequence of gaining focus, receiving a new text
value, and losing focus. A slider might define a significant
interaction as the sequence of pressing the mouse button, dragging the
slider thumb to a new value, and releasing the mouse button.

The information of how an input control changed its value is only
really knowable by its skin and associated behavior classes, both of
which are basically black boxes for a JavaFX application. In order to
expose this information, I propose to add the following new interface
in the "javafx.scene.input" package:

public interface InputNode {
    ReadOnlyBooleanProperty userModifiedProperty();
    boolean isUserModified();
    void setUserModified(boolean value);
}

This interface identifies a node that can receive user input. It is
implemented by the following controls: ButtonBase, ChoiceBox,
ComboBoxBase, Slider, Spinner, and TextInputControl.

The associated skins and behaviors are modified to invoke
setUserModified(true) on the control when a significant user
interaction is detected. Once this flag is set on a control, it can
only be unset programmatically from application code by invoking
setUserModified(false).

You might note that userModifiedProperty() returns
ReadOnlyBooleanProperty, while a public setter is availabe. The reason
for this is that while applications should be able to set or clear the
userModified flag programmatically, they shouldn't be able to bind the
property to prevent it from being set by skins.

Note also that it is not a goal of this proposal to add a data
validation framework to JavaFX (this is best left to third-party
libraries instead). The goal is to expose a crucial piece of
information that is not easily accessible otherwise.

I'm interested on your thoughts on this idea.

From jhendrikx at openjdk.org  Mon Mar 27 14:29:48 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Mar 2023 14:29:48 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
Message-ID: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>

The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.

-------------

Commit messages:
 - Remove references to PseudoClassState (private) in Match (public API)

Changes: https://git.openjdk.org/jfx/pull/1070/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304959
  Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1070.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1070/head:pull/1070

PR: https://git.openjdk.org/jfx/pull/1070

From jhendrikx at openjdk.org  Mon Mar 27 14:34:23 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Mar 2023 14:34:23 GMT
Subject: RFR: JDK-8304933: BitSet (used for CSS pseudo class states) listener
 management is incorrect
Message-ID: <Z6wIY2VZ1s7w9cf5t6WaZyhM8FY6k-IUiU8MLYqwU2Y=.ed7a206f-c7e9-44b7-821c-1367fbdd8fd5@github.com>

JDK-8304933: BitSet (used for CSS pseudo class states) listener management is incorrect

-------------

Commit messages:
 - Fix spelling error
 - Fix bug in BitSet listener management

Changes: https://git.openjdk.org/jfx/pull/1071/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304933
  Stats: 227 lines in 3 files changed: 224 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1071.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1071/head:pull/1071

PR: https://git.openjdk.org/jfx/pull/1071

From jhendrikx at openjdk.org  Mon Mar 27 14:36:45 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Mar 2023 14:36:45 GMT
Subject: RFR: JDK-8304439: Subscription based listeners [v2]
In-Reply-To: <RVyMTPlZqQevyemG8d7GhaOG7DeYXygXhOqifPI8V6M=.9b6545f9-199a-4d36-bbe3-bf497a0fdebf@github.com>
References: <RVyMTPlZqQevyemG8d7GhaOG7DeYXygXhOqifPI8V6M=.9b6545f9-199a-4d36-bbe3-bf497a0fdebf@github.com>
Message-ID: <1ybACQTFTQ4PqtoPyikEJ0WM0i6p-Sou3BOBKOpCrrA=.fdfe08aa-9458-4e6b-a099-2331a89bf951@github.com>

> Makes `Subscription` public (removing some of its methods that are unnecessary), and adds methods that can provide `Subscription`s in `ObservableValue`.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Move Subscription method for invalidations to Observable
  
  - moved Subscription class to the Observable package

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1069/files
  - new: https://git.openjdk.org/jfx/pull/1069/files/315e158e..df31b3fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=00-01

  Stats: 53 lines in 10 files changed: 25 ins; 24 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1069.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069

PR: https://git.openjdk.org/jfx/pull/1069

From kcr at openjdk.org  Mon Mar 27 15:11:25 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Mar 2023 15:11:25 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
Message-ID: <KqjZbobm6UZBUeAWFmz4n-4KVqNQAgbb51LRV4u_zIY=.8669bf96-7aaa-4ed5-b5f0-254eadf46f59@github.com>

On Mon, 27 Mar 2023 13:50:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.

This was clearly a mistake back when the public API was first created in JDK 9.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1070#issuecomment-1485291399

From angorya at openjdk.org  Mon Mar 27 15:43:01 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Mar 2023 15:43:01 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
Message-ID: <8hpvtPU3rG2eIrWbymHism9zw0abRIjLVgi7sfacxW8=.d4beebad-c997-41cc-a7ba-1ad886a81091@github.com>

On Mon, 27 Mar 2023 13:50:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.

modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:

> 77:      * @return the pseudo class state
> 78:      */
> 79:     public Set<PseudoClass> getPseudoClasses() {

does this change need a CSR?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1149443167

From kcr at openjdk.org  Mon Mar 27 15:59:18 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Mar 2023 15:59:18 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <8hpvtPU3rG2eIrWbymHism9zw0abRIjLVgi7sfacxW8=.d4beebad-c997-41cc-a7ba-1ad886a81091@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <8hpvtPU3rG2eIrWbymHism9zw0abRIjLVgi7sfacxW8=.d4beebad-c997-41cc-a7ba-1ad886a81091@github.com>
Message-ID: <f90zm5pNpVFR3HXgEa0YwcjhKsMV4gsDVdatEnSwlAM=.10ebdb7a-b2a2-4188-9824-f74df547232f@github.com>

On Mon, 27 Mar 2023 15:40:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
> 
>> 77:      * @return the pseudo class state
>> 78:      */
>> 79:     public Set<PseudoClass> getPseudoClasses() {
> 
> does this change need a CSR?

Yes, thanks for checking. I already flagged it as needing a CSR.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1149465925

From angorya at openjdk.org  Mon Mar 27 16:03:50 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 27 Mar 2023 16:03:50 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <f90zm5pNpVFR3HXgEa0YwcjhKsMV4gsDVdatEnSwlAM=.10ebdb7a-b2a2-4188-9824-f74df547232f@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <8hpvtPU3rG2eIrWbymHism9zw0abRIjLVgi7sfacxW8=.d4beebad-c997-41cc-a7ba-1ad886a81091@github.com>
 <f90zm5pNpVFR3HXgEa0YwcjhKsMV4gsDVdatEnSwlAM=.10ebdb7a-b2a2-4188-9824-f74df547232f@github.com>
Message-ID: <8a74HX6vJ_QQsa_vAwEdrClGe_OA2qPMoEsxcBGIhoA=.8b411ac3-e0ce-4022-b43d-2e0355b08c8d@github.com>

On Mon, 27 Mar 2023 15:56:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
>> 
>>> 77:      * @return the pseudo class state
>>> 78:      */
>>> 79:     public Set<PseudoClass> getPseudoClasses() {
>> 
>> does this change need a CSR?
>
> Yes, thanks for checking. I already flagged it as needing a CSR.

oh, sorry, missed the label...

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1149470689

From quizynox at gmail.com  Mon Mar 27 16:31:29 2023
From: quizynox at gmail.com (mkpaz)
Date: Mon, 27 Mar 2023 20:31:29 +0400
Subject: Allow input controls to indicate significant user interaction
In-Reply-To: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
Message-ID: <a59854a4-79ec-5153-abbe-15b6e29908bc@gmail.com>

I can compare this with Vuetify framework, generally because it uses 
good abstractions. It provides the three types of validation.

1. Eager - an input is validated immediately after loading (adding to 
the scene). Usually it's initialized with some default valid value to 
not disturb user.
2. Input - an input is validated after a user interaction (lazy 
validation). It puts the input to the *dirty state* and that state is 
used to trigger the validation.
3. Submit - an input is validated after the form submission.

While it's already possible to implement the second option, one "simply" 
need to subscribe to all focus, keyboard and mouse events and manage the 
dirty state manually, it seems reasonable to delegate this work to the 
skins. The question is what should be considered as a "significant 
interaction". Some implementations set dirty state immediately after the 
input loses focus state, others require some actual keyboard input.

On 3/27/23 04:48, Michael Strau? wrote:
> Many form-based applications require some sort of data validation for
> input controls. It is also often desirable to visualize the validation
> state of a control directly in the user interface, for example by
> showing a red border to indicate a validation failure.
>
> However, simply validating the current value of a control and
> rendering a validation decorator often leads to an undesirable user
> experience: for example, in many cases an empty form field shouldn't
> indicate a validation failure unless the user has significantly
> interacted with the field, or validation was explicitly requested by
> pressing a "submit" button.
>
> The first of these validation conditions, "significantly interacted
> with the input control" is quite popular on contemporary web forms,
> and offers a balanced user experience compared to immediately and
> eagerly validating every control, or delaying validation until the
> very end of the form submission process (see also the proposed
> :user-valid/:user-invalid CSS pseudo-classes).
>
> Unfortunately, this is very hard to implement in JavaFX since controls
> have no way of signalling when they were significantly interacted
> with. In particular, we don't want to count programmatic
> initialization of field values as a significant interaction. What
> constitutes a significant interaction is dependent on the type of
> input control. For example, a text field might define a significant
> interaction as the sequence of gaining focus, receiving a new text
> value, and losing focus. A slider might define a significant
> interaction as the sequence of pressing the mouse button, dragging the
> slider thumb to a new value, and releasing the mouse button.
>
> The information of how an input control changed its value is only
> really knowable by its skin and associated behavior classes, both of
> which are basically black boxes for a JavaFX application. In order to
> expose this information, I propose to add the following new interface
> in the "javafx.scene.input" package:
>
> public interface InputNode {
>      ReadOnlyBooleanProperty userModifiedProperty();
>      boolean isUserModified();
>      void setUserModified(boolean value);
> }
>
> This interface identifies a node that can receive user input. It is
> implemented by the following controls: ButtonBase, ChoiceBox,
> ComboBoxBase, Slider, Spinner, and TextInputControl.
>
> The associated skins and behaviors are modified to invoke
> setUserModified(true) on the control when a significant user
> interaction is detected. Once this flag is set on a control, it can
> only be unset programmatically from application code by invoking
> setUserModified(false).
>
> You might note that userModifiedProperty() returns
> ReadOnlyBooleanProperty, while a public setter is availabe. The reason
> for this is that while applications should be able to set or clear the
> userModified flag programmatically, they shouldn't be able to bind the
> property to prevent it from being set by skins.
>
> Note also that it is not a goal of this proposal to add a data
> validation framework to JavaFX (this is best left to third-party
> libraries instead). The goal is to expose a crucial piece of
> information that is not easily accessible otherwise.
>
> I'm interested on your thoughts on this idea.

From andy.goryachev at oracle.com  Mon Mar 27 16:46:14 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 27 Mar 2023 16:46:14 +0000
Subject: Allow input controls to indicate significant user interaction
In-Reply-To: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
Message-ID: <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>

I think this functionality belongs to the application-level code, not in the platform.  It's the application that knows which parts of a form need the visual feedback and which do not.  In my opinion, there is no APIs that are missing in order to implement a validation framework of any level of complexity.

Not responding to programmatic changes is easy: disable validation logic when setting values.

The validation and subsequent user feedback may happen at the time of form submission, or as a result of a short timer expiring.  The timer should be restarted upon each update of the value properties being validated.

In any case, this problem has a well-defined solution and, in my opinion, does not require a change in the core platform.

Cheers,
-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
Date: Sunday, March 26, 2023 at 17:49
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Allow input controls to indicate significant user interaction
Many form-based applications require some sort of data validation for
input controls. It is also often desirable to visualize the validation
state of a control directly in the user interface, for example by
showing a red border to indicate a validation failure.

However, simply validating the current value of a control and
rendering a validation decorator often leads to an undesirable user
experience: for example, in many cases an empty form field shouldn't
indicate a validation failure unless the user has significantly
interacted with the field, or validation was explicitly requested by
pressing a "submit" button.

The first of these validation conditions, "significantly interacted
with the input control" is quite popular on contemporary web forms,
and offers a balanced user experience compared to immediately and
eagerly validating every control, or delaying validation until the
very end of the form submission process (see also the proposed
:user-valid/:user-invalid CSS pseudo-classes).

Unfortunately, this is very hard to implement in JavaFX since controls
have no way of signalling when they were significantly interacted
with. In particular, we don't want to count programmatic
initialization of field values as a significant interaction. What
constitutes a significant interaction is dependent on the type of
input control. For example, a text field might define a significant
interaction as the sequence of gaining focus, receiving a new text
value, and losing focus. A slider might define a significant
interaction as the sequence of pressing the mouse button, dragging the
slider thumb to a new value, and releasing the mouse button.

The information of how an input control changed its value is only
really knowable by its skin and associated behavior classes, both of
which are basically black boxes for a JavaFX application. In order to
expose this information, I propose to add the following new interface
in the "javafx.scene.input" package:

public interface InputNode {
    ReadOnlyBooleanProperty userModifiedProperty();
    boolean isUserModified();
    void setUserModified(boolean value);
}

This interface identifies a node that can receive user input. It is
implemented by the following controls: ButtonBase, ChoiceBox,
ComboBoxBase, Slider, Spinner, and TextInputControl.

The associated skins and behaviors are modified to invoke
setUserModified(true) on the control when a significant user
interaction is detected. Once this flag is set on a control, it can
only be unset programmatically from application code by invoking
setUserModified(false).

You might note that userModifiedProperty() returns
ReadOnlyBooleanProperty, while a public setter is availabe. The reason
for this is that while applications should be able to set or clear the
userModified flag programmatically, they shouldn't be able to bind the
property to prevent it from being set by skins.

Note also that it is not a goal of this proposal to add a data
validation framework to JavaFX (this is best left to third-party
libraries instead). The goal is to expose a crucial piece of
information that is not easily accessible otherwise.

I'm interested on your thoughts on this idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230327/f6ac3394/attachment-0001.htm>

From kevin.rushforth at oracle.com  Mon Mar 27 16:51:23 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 27 Mar 2023 09:51:23 -0700
Subject: Allow input controls to indicate significant user interaction
In-Reply-To: <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
 <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <d19f85a7-c72f-a42b-15a9-b46cc40d9781@oracle.com>

I also am skeptical regarding the need for API in the core platform to 
support this.

-- Kevin


On 3/27/2023 9:46 AM, Andy Goryachev wrote:
>
> I think this functionality belongs to the application-level code, not 
> in the platform.? It's the application that knows which parts of a 
> form need the visual feedback and which do not.? In my opinion, there 
> is no APIs that are missing in order to implement a validation 
> framework of any level of complexity.
>
> Not responding to programmatic changes is easy: disable validation 
> logic when setting values.
>
> The validation and subsequent user feedback may happen at the time of 
> form submission, or as a result of a short timer expiring.? The timer 
> should be restarted upon each update of the value properties being 
> validated.
>
> In any case, this problem has a well-defined solution and, in my 
> opinion, does not require a change in the core platform.
>
> Cheers,
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Michael Strau? <michaelstrau2 at gmail.com>
> *Date: *Sunday, March 26, 2023 at 17:49
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Allow input controls to indicate significant user interaction
>
> Many form-based applications require some sort of data validation for
> input controls. It is also often desirable to visualize the validation
> state of a control directly in the user interface, for example by
> showing a red border to indicate a validation failure.
>
> However, simply validating the current value of a control and
> rendering a validation decorator often leads to an undesirable user
> experience: for example, in many cases an empty form field shouldn't
> indicate a validation failure unless the user has significantly
> interacted with the field, or validation was explicitly requested by
> pressing a "submit" button.
>
> The first of these validation conditions, "significantly interacted
> with the input control" is quite popular on contemporary web forms,
> and offers a balanced user experience compared to immediately and
> eagerly validating every control, or delaying validation until the
> very end of the form submission process (see also the proposed
> :user-valid/:user-invalid CSS pseudo-classes).
>
> Unfortunately, this is very hard to implement in JavaFX since controls
> have no way of signalling when they were significantly interacted
> with. In particular, we don't want to count programmatic
> initialization of field values as a significant interaction. What
> constitutes a significant interaction is dependent on the type of
> input control. For example, a text field might define a significant
> interaction as the sequence of gaining focus, receiving a new text
> value, and losing focus. A slider might define a significant
> interaction as the sequence of pressing the mouse button, dragging the
> slider thumb to a new value, and releasing the mouse button.
>
> The information of how an input control changed its value is only
> really knowable by its skin and associated behavior classes, both of
> which are basically black boxes for a JavaFX application. In order to
> expose this information, I propose to add the following new interface
> in the "javafx.scene.input" package:
>
> public interface InputNode {
> ??? ReadOnlyBooleanProperty userModifiedProperty();
> ??? boolean isUserModified();
> ??? void setUserModified(boolean value);
> }
>
> This interface identifies a node that can receive user input. It is
> implemented by the following controls: ButtonBase, ChoiceBox,
> ComboBoxBase, Slider, Spinner, and TextInputControl.
>
> The associated skins and behaviors are modified to invoke
> setUserModified(true) on the control when a significant user
> interaction is detected. Once this flag is set on a control, it can
> only be unset programmatically from application code by invoking
> setUserModified(false).
>
> You might note that userModifiedProperty() returns
> ReadOnlyBooleanProperty, while a public setter is availabe. The reason
> for this is that while applications should be able to set or clear the
> userModified flag programmatically, they shouldn't be able to bind the
> property to prevent it from being set by skins.
>
> Note also that it is not a goal of this proposal to add a data
> validation framework to JavaFX (this is best left to third-party
> libraries instead). The goal is to expose a crucial piece of
> information that is not easily accessible otherwise.
>
> I'm interested on your thoughts on this idea.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230327/8b9bfead/attachment.htm>

From michaelstrau2 at gmail.com  Mon Mar 27 17:03:54 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 27 Mar 2023 19:03:54 +0200
Subject: Allow input controls to indicate significant user interaction
In-Reply-To: <a59854a4-79ec-5153-abbe-15b6e29908bc@gmail.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
 <a59854a4-79ec-5153-abbe-15b6e29908bc@gmail.com>
Message-ID: <CAJEpuXS_j+L21Mr8S+91KRFV3OELNMyjS+Sj=+HDoTS-HYJ2eQ@mail.gmail.com>

It's true that a choice needs to be made as to what should be
considered a significant interaction.
This proposal delegates the choice to skins, as that's where these
kinds of choices are generally made.
For example, skins also decide when a button's action is invoked, or
when a context menu opens.
In fact, many of these kinds of semantic choices are internally
represented as behavior classes, which are intrinsically tied to
skins.
Since skins define the behavior of controls, it seems fitting that
they should also define what should be a significant interaction for
the control.
If control authors want to change that, they can create a new skin for
that, the same as what one would do to change any other behavioral
aspect of a control.


On Mon, Mar 27, 2023 at 6:31?PM mkpaz <quizynox at gmail.com> wrote:
>
> I can compare this with Vuetify framework, generally because it uses
> good abstractions. It provides the three types of validation.
>
> 1. Eager - an input is validated immediately after loading (adding to
> the scene). Usually it's initialized with some default valid value to
> not disturb user.
> 2. Input - an input is validated after a user interaction (lazy
> validation). It puts the input to the *dirty state* and that state is
> used to trigger the validation.
> 3. Submit - an input is validated after the form submission.
>
> While it's already possible to implement the second option, one "simply"
> need to subscribe to all focus, keyboard and mouse events and manage the
> dirty state manually, it seems reasonable to delegate this work to the
> skins. The question is what should be considered as a "significant
> interaction". Some implementations set dirty state immediately after the
> input loses focus state, others require some actual keyboard input.

From almatvee at openjdk.org  Mon Mar 27 17:14:17 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 27 Mar 2023 17:14:17 GMT
Subject: RFR: 8304924: [testbug] Skip failing tests on Linux
In-Reply-To: <iW-rYGJmPgkBaqCXojciwwq5QbuZBE8pT7evieUeu-Q=.299f12f3-97ec-4c6c-8d51-963c0697caee@github.com>
References: <iW-rYGJmPgkBaqCXojciwwq5QbuZBE8pT7evieUeu-Q=.299f12f3-97ec-4c6c-8d51-963c0697caee@github.com>
Message-ID: <uNiHCw8rSfkhZjeb81NSj5b6JteoVe7WnANdG4hlE3Y=.4ce51595-c772-46ce-9a56-45f7c57b6050@github.com>

On Sat, 25 Mar 2023 15:50:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR skips three headful tests on Linux until the issues with the tests can be fixed. These tests consistently fail on our physical Ubuntu 22.04 test machine. This is a step towards getting clean headful test runs. Each of the skipped tests has an associated bug that needs to be fixed.

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1068#pullrequestreview-1359530257

From michaelstrau2 at gmail.com  Mon Mar 27 17:18:43 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 27 Mar 2023 19:18:43 +0200
Subject: Allow input controls to indicate significant user interaction
In-Reply-To: <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
 <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXSz1g7GiMvuYWmMfif6RNCo8fr3QmsniRoJwh3X_fTJbw@mail.gmail.com>

Hi Andy, thanks for your feedback.

It's true that only an application knows which fields require feedback
and which don't. That's why I don't propose to create a validation
framework in the core platform.

However, I don't think your solution addresses the point that I've raised.
While using timers to trigger validation is certainly possible, it's
not what I was describing; in fact, I would argue that this would be a
very bad user experience in most cases.

There are basically three kinds of validation semantics that are widely used:
1. Eager validation for every value change
2. Just-in-time validation for every significant interaction
3. Delayed validation at the time of form submission

The first and third options have easy solutions in JavaFX
applications, but the second option has no good solution.
Sure, I can add event listeners to applicable controls and try to find
out whether any particular sequence of key strokes or mouse events
corresponds to a significant interaction.
But that requires me to also consider many different ways in which
controls can be significantly interacted with. For example, while I
can type text into a text field, I can also paste text using my mouse.
It would be very hard for me to detect all these interactions, and
there is certainly no well-defined solution, as most aspects of
control behavior are delegated to black-box skins in any case.

There simply is no reliable way to answer the question that I need to
have answered: when did a user significantly interact with the
control?


On Mon, Mar 27, 2023 at 6:46?PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> I think this functionality belongs to the application-level code, not in the platform.  It's the application that knows which parts of a form need the visual feedback and which do not.  In my opinion, there is no APIs that are missing in order to implement a validation framework of any level of complexity.
>
>
>
> Not responding to programmatic changes is easy: disable validation logic when setting values.
>
>
>
> The validation and subsequent user feedback may happen at the time of form submission, or as a result of a short timer expiring.  The timer should be restarted upon each update of the value properties being validated.
>
>
>
> In any case, this problem has a well-defined solution and, in my opinion, does not require a change in the core platform.
>
>
>
> Cheers,
>
> -andy

From kcr at openjdk.org  Mon Mar 27 17:39:55 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 27 Mar 2023 17:39:55 GMT
Subject: Integrated: 8304924: [testbug] Skip failing tests on Linux
In-Reply-To: <iW-rYGJmPgkBaqCXojciwwq5QbuZBE8pT7evieUeu-Q=.299f12f3-97ec-4c6c-8d51-963c0697caee@github.com>
References: <iW-rYGJmPgkBaqCXojciwwq5QbuZBE8pT7evieUeu-Q=.299f12f3-97ec-4c6c-8d51-963c0697caee@github.com>
Message-ID: <usdlLfTQXN7p_aEfq1ou6be0yVMoFZr-jzIQNx5zDpo=.bbf4513d-b3df-4184-b401-76f066fb8f16@github.com>

On Sat, 25 Mar 2023 15:50:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR skips three headful tests on Linux until the issues with the tests can be fixed. These tests consistently fail on our physical Ubuntu 22.04 test machine. This is a step towards getting clean headful test runs. Each of the skipped tests has an associated bug that needs to be fixed.

This pull request has now been integrated.

Changeset: 2a5bf464
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/2a5bf4647ca19f67eb56f2459f0a5acee6c05146
Stats:     22 lines in 3 files changed: 14 ins; 0 del; 8 mod

8304924: [testbug] Skip failing tests on Linux

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jfx/pull/1068

From andy.goryachev at oracle.com  Mon Mar 27 17:47:33 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 27 Mar 2023 17:47:33 +0000
Subject: [External] : Re: Allow input controls to indicate significant
 user interaction
In-Reply-To: <CAJEpuXSz1g7GiMvuYWmMfif6RNCo8fr3QmsniRoJwh3X_fTJbw@mail.gmail.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
 <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXSz1g7GiMvuYWmMfif6RNCo8fr3QmsniRoJwh3X_fTJbw@mail.gmail.com>
Message-ID: <DM5PR1001MB21725B2E088641230C89A12FE58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>

Michael:

> 2. Just-in-time validation for every significant interaction

I'd think a loss of focus might be considered as a trigger for "significant interaction".  Or perhaps you could give us an example of a use case in which it'll be insufficient?

> when did a user significantly interact with the
control?

It depends on the application requirements.  So, ultimately, the validation framework that the app developers are going to use must be flexible enough to handle all the cases.

-andy


From: Michael Strau? <michaelstrau2 at gmail.com>
Date: Monday, March 27, 2023 at 10:19
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: Allow input controls to indicate significant user interaction
Hi Andy, thanks for your feedback.

It's true that only an application knows which fields require feedback
and which don't. That's why I don't propose to create a validation
framework in the core platform.

However, I don't think your solution addresses the point that I've raised.
While using timers to trigger validation is certainly possible, it's
not what I was describing; in fact, I would argue that this would be a
very bad user experience in most cases.

There are basically three kinds of validation semantics that are widely used:
1. Eager validation for every value change
2. Just-in-time validation for every significant interaction
3. Delayed validation at the time of form submission

The first and third options have easy solutions in JavaFX
applications, but the second option has no good solution.
Sure, I can add event listeners to applicable controls and try to find
out whether any particular sequence of key strokes or mouse events
corresponds to a significant interaction.
But that requires me to also consider many different ways in which
controls can be significantly interacted with. For example, while I
can type text into a text field, I can also paste text using my mouse.
It would be very hard for me to detect all these interactions, and
there is certainly no well-defined solution, as most aspects of
control behavior are delegated to black-box skins in any case.

There simply is no reliable way to answer the question that I need to
have answered: when did a user significantly interact with the
control?


On Mon, Mar 27, 2023 at 6:46?PM Andy Goryachev
<andy.goryachev at oracle.com> wrote:
>
> I think this functionality belongs to the application-level code, not in the platform.  It's the application that knows which parts of a form need the visual feedback and which do not.  In my opinion, there is no APIs that are missing in order to implement a validation framework of any level of complexity.
>
>
>
> Not responding to programmatic changes is easy: disable validation logic when setting values.
>
>
>
> The validation and subsequent user feedback may happen at the time of form submission, or as a result of a short timer expiring.  The timer should be restarted upon each update of the value properties being validated.
>
>
>
> In any case, this problem has a well-defined solution and, in my opinion, does not require a change in the core platform.
>
>
>
> Cheers,
>
> -andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230327/7a983eb1/attachment-0001.htm>

From michaelstrau2 at gmail.com  Mon Mar 27 17:58:41 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 27 Mar 2023 19:58:41 +0200
Subject: Allow input controls to indicate significant user interaction
In-Reply-To: <d19f85a7-c72f-a42b-15a9-b46cc40d9781@oracle.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
 <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <d19f85a7-c72f-a42b-15a9-b46cc40d9781@oracle.com>
Message-ID: <CAJEpuXRi1-Z8Z9svGmW69+1ppJKW8AsokbB=ows1uG2war-V+w@mail.gmail.com>

I should add that aside from the javafx.scene.input.InputNode
interface, there is no addition to or modification of the core
platform.
Nothing in javaxf.graphics uses InputNode, it is provided solely as a
contract for the "significant interaction" information, which
third-party libraries can depend on without depending explicitly on
the javafx.controls module or any particular controls implementation.

On Mon, Mar 27, 2023 at 7:02?PM Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
>
> I also am skeptical regarding the need for API in the core platform to support this.
>
> -- Kevin
>
>
> On 3/27/2023 9:46 AM, Andy Goryachev wrote:
>
> I think this functionality belongs to the application-level code, not in the platform.  It's the application that knows which parts of a form need the visual feedback and which do not.  In my opinion, there is no APIs that are missing in order to implement a validation framework of any level of complexity.
>
>
>
> Not responding to programmatic changes is easy: disable validation logic when setting values.
>
>
>
> The validation and subsequent user feedback may happen at the time of form submission, or as a result of a short timer expiring.  The timer should be restarted upon each update of the value properties being validated.
>
>
>
> In any case, this problem has a well-defined solution and, in my opinion, does not require a change in the core platform.
>
>
>
> Cheers,
>
> -andy
>
>
>
>
>
> From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Michael Strau? <michaelstrau2 at gmail.com>
> Date: Sunday, March 26, 2023 at 17:49
> To: openjfx-dev <openjfx-dev at openjdk.org>
> Subject: Allow input controls to indicate significant user interaction
>
> Many form-based applications require some sort of data validation for
> input controls. It is also often desirable to visualize the validation
> state of a control directly in the user interface, for example by
> showing a red border to indicate a validation failure.
>
> However, simply validating the current value of a control and
> rendering a validation decorator often leads to an undesirable user
> experience: for example, in many cases an empty form field shouldn't
> indicate a validation failure unless the user has significantly
> interacted with the field, or validation was explicitly requested by
> pressing a "submit" button.
>
> The first of these validation conditions, "significantly interacted
> with the input control" is quite popular on contemporary web forms,
> and offers a balanced user experience compared to immediately and
> eagerly validating every control, or delaying validation until the
> very end of the form submission process (see also the proposed
> :user-valid/:user-invalid CSS pseudo-classes).
>
> Unfortunately, this is very hard to implement in JavaFX since controls
> have no way of signalling when they were significantly interacted
> with. In particular, we don't want to count programmatic
> initialization of field values as a significant interaction. What
> constitutes a significant interaction is dependent on the type of
> input control. For example, a text field might define a significant
> interaction as the sequence of gaining focus, receiving a new text
> value, and losing focus. A slider might define a significant
> interaction as the sequence of pressing the mouse button, dragging the
> slider thumb to a new value, and releasing the mouse button.
>
> The information of how an input control changed its value is only
> really knowable by its skin and associated behavior classes, both of
> which are basically black boxes for a JavaFX application. In order to
> expose this information, I propose to add the following new interface
> in the "javafx.scene.input" package:
>
> public interface InputNode {
>     ReadOnlyBooleanProperty userModifiedProperty();
>     boolean isUserModified();
>     void setUserModified(boolean value);
> }
>
> This interface identifies a node that can receive user input. It is
> implemented by the following controls: ButtonBase, ChoiceBox,
> ComboBoxBase, Slider, Spinner, and TextInputControl.
>
> The associated skins and behaviors are modified to invoke
> setUserModified(true) on the control when a significant user
> interaction is detected. Once this flag is set on a control, it can
> only be unset programmatically from application code by invoking
> setUserModified(false).
>
> You might note that userModifiedProperty() returns
> ReadOnlyBooleanProperty, while a public setter is availabe. The reason
> for this is that while applications should be able to set or clear the
> userModified flag programmatically, they shouldn't be able to bind the
> property to prevent it from being set by skins.
>
> Note also that it is not a goal of this proposal to add a data
> validation framework to JavaFX (this is best left to third-party
> libraries instead). The goal is to expose a crucial piece of
> information that is not easily accessible otherwise.
>
> I'm interested on your thoughts on this idea.
>
>

From michaelstrau2 at gmail.com  Mon Mar 27 18:32:07 2023
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 27 Mar 2023 20:32:07 +0200
Subject: [External] : Re: Allow input controls to indicate significant
 user interaction
In-Reply-To: <DM5PR1001MB21725B2E088641230C89A12FE58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
References: <CAJEpuXTjeo-WDdTS-dQq9fQ+ZeSvNN7K6icmZSYOqiSZ0pQ4cA@mail.gmail.com>
 <DM5PR1001MB2172540FD6FE207B586EE759E58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
 <CAJEpuXSz1g7GiMvuYWmMfif6RNCo8fr3QmsniRoJwh3X_fTJbw@mail.gmail.com>
 <DM5PR1001MB21725B2E088641230C89A12FE58B9@DM5PR1001MB2172.namprd10.prod.outlook.com>
Message-ID: <CAJEpuXSx8dUW+px5Y_UsNNmnB4Or7r9CvZ60tj14K61NukFNnw@mail.gmail.com>

> I'd think a loss of focus might be considered as a trigger for "significant interaction".  Or perhaps you could give us an example of a use case in which it'll be insufficient?

For example, for a text field, gaining and losing focus is probably
sufficient to count as an interaction. Everything that happens between
gaining and losing focus can be thought of a as an operation in
progress.
The same isn't true for a slider: when we click-and-drag, the slider
should probably count as being interacted with as soon as the mouse
button is released, not when the slider loses focus (the same should
be true for key-press-and-hold).
Similarly, operations that are immediately completed (like pressing
the HOME or END keys on a slider) should most likely also immediately
count as a significant interaction.

It is true that I can do this without platform support, but it
requires me to hard-wire each type of control with its particular
behavioral details.


> It depends on the application requirements.  So, ultimately, the validation framework that the app developers are going to use must be flexible enough to handle all the cases.

Yes, and ideally, the third-party validation framework would work with
all kinds of controls (and even non-controls, as "Control" is a
concept that is only introduced with the javafx.controls module), not
only the standard controls that come with JavaFX.

From jhendrikx at openjdk.org  Mon Mar 27 23:10:27 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Mar 2023 23:10:27 GMT
Subject: RFR: JDK-8245919: Region#padding property rendering error
Message-ID: <yt-TMHqjeZnoFvuHKLJB1EvDZ9Y7OnWsA-GXdLxTPFM=.ccd98b5b-fdb4-491f-8959-176f43355a3c@github.com>

Fix bug in CSS caching code that could reset values on unrelated nodes.

The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values.

-------------

Commit messages:
 - Fix bug in CSS caching code that could reset values on unrelated nodes

Changes: https://git.openjdk.org/jfx/pull/1072/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8245919
  Stats: 95 lines in 2 files changed: 69 ins; 23 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1072.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1072/head:pull/1072

PR: https://git.openjdk.org/jfx/pull/1072

From jhendrikx at openjdk.org  Mon Mar 27 23:16:43 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 27 Mar 2023 23:16:43 GMT
Subject: RFR: JDK-8245919: Region#padding property rendering error
In-Reply-To: <yt-TMHqjeZnoFvuHKLJB1EvDZ9Y7OnWsA-GXdLxTPFM=.ccd98b5b-fdb4-491f-8959-176f43355a3c@github.com>
References: <yt-TMHqjeZnoFvuHKLJB1EvDZ9Y7OnWsA-GXdLxTPFM=.ccd98b5b-fdb4-491f-8959-176f43355a3c@github.com>
Message-ID: <-ypPhDce19uqwTo5kOpthcChMemjQFBrF4vBr2wmaZ4=.07008d37-adb2-4bd7-8f61-39099d3e11ee@github.com>

On Mon, 27 Mar 2023 23:05:00 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fix bug in CSS caching code that could reset values on unrelated nodes.
> 
> The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values.

Note for reviewers:

The problem of one Node affecting another unrelated Node is because all properties of the same type, at the same level and same pseudo state set share a cache entry. When the cache entry is constructed based on a Node with an overridden property, the calculated value for the overridden property would be omitted incorrectly -- it is incorrect because other Nodes that would share the same entry may not have this property overridden!  The cache entry always should have a complete set of calculated values, regardless of which Node was used to construct the initial cache entry.

I removed the user overridden property check in `lookup`. I think this is harmless because both callers of `lookup` do the same check themselves again to avoid applying a style that would override a user set value.  However, in `transitionToState` this is just **after** the calculated value is added to the cache, which is exactly what you want.  A test verifies that the fix works.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1072#issuecomment-1485983070

From jbhaskar at openjdk.org  Tue Mar 28 02:14:22 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 28 Mar 2023 02:14:22 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
Message-ID: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>

Issue: Error copying file (if different) from Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_header.py" to "modules/javafx.web/build/mac/Release/JavaScriptCcripts/builtins_generate_separate_header.py".

Root cause: The number of build threads more than 8, causing a synchronization issue for builtins_generate_separate_header.py, the file needs to be copied before use at build dir

Solution: Use the sleep of 1 second and retry 10 times to copy in CMakeList.txt and execute using the execute_process cmake command

-------------

Commit messages:
 - 8286089: Fix Build error mac osx 11

Changes: https://git.openjdk.org/jfx/pull/1073/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1073&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286089
  Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1073.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1073/head:pull/1073

PR: https://git.openjdk.org/jfx/pull/1073

From s.howman.4580 at gmail.com  Tue Mar 28 05:17:13 2023
From: s.howman.4580 at gmail.com (Sam Howman)
Date: Tue, 28 Mar 2023 13:17:13 +0800
Subject: Gauging interest in bindings that can delay changing their value
 (debounce/throttle)
In-Reply-To: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>
References: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>
Message-ID: <CABU7dshAoKR4aEaXa2wYkzwy=csQRoXqDs_EnCbtGGcfpwXfPg@mail.gmail.com>

I love this idea and would use it immediately!

On Fri, Mar 24, 2023 at 12:10?AM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Hi list,
>
> I've been working on a potential new API (and proof of concept
> implementation) for adding a new type of fluent binding which can delay
> changing their values, and I'm wondering how much interest there is in
> such a thing.
>
> The main purpose of such an API is to prevent being flooded with changes
> when properties change often, or to simply delay certain actions until
> the user has settled on a selection or has stopped typing.
>
> For this purpose I would like to introduce a default method on
> `ObservableValue` with the signature:
>
>      ObservableValue<T> throttle(Throttler throttler);
>
> The parameter `Throttler` can be obtained via static methods of a helper
> class named `FXThrottlers`. These provide various pre-configured
> throttlers that work correctly with JavaFX's event thread model.  My
> current proof of concept provides:
>
>      public static Throttler debounce(Duration quietPeriod);
>      public static Throttler debounceTrailing(Duration quietPeriod);
>      public static Throttler throttle(Duration period);
>      public static Throttler throttleTrailing(Duration period);
>
> These are variations of similar concepts, and vary mostly in when
> exactly they will allow value changes; debouncers will wait for a period
> without any changes, while throttlers will periodically allow changes.
> The trailing variants will not immediately emit the first change but
> will wait for the period to elapse first; all variants will eventually
> take on the value of the source observable.  Debouncing is typically
> used when you wish for an input to settle before taking action (like
> typing in a search bar), while throttling is used to give regular
> feedback but avoid doing so too often (like feedback during window
> resizing).
>
> Usage example which updates a preview panel when the user has finished
> (cursor) scrolling through a list view:
>
>      ObjectProperty<T> selectedItem =
> listView.getSelectionModel().selectedItemProperty();
>
>      selectedItem
> .throttle(FXThrottlers.debounceTrailing(Duration.ofMillis(500)))
>          .addListener((obs, old, current) -> {
>               if (current != null) {
>                   updatePreviewPanel(current);
>               }
>          });
>
> Implementation details:
>
> ObservableValue is part of javafx.base, and as such can't use animations
> or call Platform::runLater.  The ThrottledBinding implementation has
> abstracted all of these out into the Throttler class, and FXThrottlers
> (which would live in javafx.graphics) therefore provides the necessary
> call backs to integrate property changes correctly back onto the JavaFX
> event thread.  The Throttler class also simplifies testing; the test can
> provide its own timing source and background scheduler.  The Throttler
> interface has the following methods:
>
>      /**
>       * Schedules a command to run on an unspecified thread after the time
>       * given by {@code nanos} elapses.
>       *
>       * @param command a command to run, cannot be {@code null}
>       * @param nanos a time in nanoseconds
>       */
>      void schedule(Runnable command, long nanos);
>
>      /**
>       * Provides the current time in nanoseconds.
>       *
>       * @return the current time in nanoseconds
>       */
>      long nanoTime();
>
>      /**
>       * Runs the given command as soon as possible on a thread specified
> by this
>       * throttler for updating property values.
>       *
>       * @param command a command to run, cannot be {@code null}
>       */
>      void update(Runnable command);
>
>      /**
>       * Given the current elapsed time in the current change window, and
> the
>       * amount of time elapsed since the last change was detected,
> determines
>       * if and by how much the current change window should be extended.
>       *
>       * @param elapsed nanoseconds elapsed since the start of the
> current change window
>       * @param elapsedSinceLastChange nanoseconds elapsed since the last
> change
>       * @return nanoseconds to extend the window with
>       */
>      long determineInterval(long elapsed, long elapsedSinceLastChange);
>
> For testing purposes, the schedule and nanoTime can be provided such
> that the throttle function can be tested deterministically. For
> integrating with JavaFX, update is implemented as
> `Platform.runLater(command)`.  The schedule and nanoTime methods
> delegate to an Executor and System.nanoTime respectively.  When using
> properties without JavaFX, Throttler implementations can be provided
> which run property updates on a scheduler thread (just calling
> Runnable::run on the current thread) or via some user provided executor.
>
> A sample test case looks like this (read with a mono space font :-)):
>
>      @Test
>      void testThrottleLeadingAndTrailing() {
>        // create Throttler with deterministic behavior:
>        Throttler throttler =
> create(Throttler.IntervalHandler.throttle(Duration.ofNanos(4));
>
>        // create throttled observable:
>        ObservableValue<String> binding = source.throttle(throttler);
>
>        assertChanges(
>          binding,
>          "--a-b--c---d-----e-------f-g-----------f-g-----",
>          "--a---b---c---d---e------f---g---------f---g---"
>        );
>
>        assertInvalidations(
>          binding,
>          "--a-b--c---d-----e-------f-g-----------f-g-----",
>          "--i---i---i---i---i------i---i---------i---i---"
>        );
>      }
>
> Thanks for reading, I look forward to your feedback!
>
> --John
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230328/c4150aec/attachment.htm>

From andrea.vacondio at gmail.com  Tue Mar 28 07:07:47 2023
From: andrea.vacondio at gmail.com (Andrea Vacondio)
Date: Tue, 28 Mar 2023 09:07:47 +0200
Subject: Gauging interest in bindings that can delay changing their value
 (debounce/throttle)
In-Reply-To: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>
References: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>
Message-ID: <CANs-Dhv03tp9Px9YM+CnrJxxg49DcFfMYtQS=qWM=mM1LGRNFg@mail.gmail.com>

I've used RxJava to debounce search text fields.
+1 for me.

Il giorno gio 23 mar 2023 alle ore 17:10 John Hendrikx <
john.hendrikx at gmail.com> ha scritto:

> Hi list,
>
> I've been working on a potential new API (and proof of concept
> implementation) for adding a new type of fluent binding which can delay
> changing their values, and I'm wondering how much interest there is in
> such a thing.
>
> The main purpose of such an API is to prevent being flooded with changes
> when properties change often, or to simply delay certain actions until
> the user has settled on a selection or has stopped typing.
>
> For this purpose I would like to introduce a default method on
> `ObservableValue` with the signature:
>
>      ObservableValue<T> throttle(Throttler throttler);
>
> The parameter `Throttler` can be obtained via static methods of a helper
> class named `FXThrottlers`. These provide various pre-configured
> throttlers that work correctly with JavaFX's event thread model.  My
> current proof of concept provides:
>
>      public static Throttler debounce(Duration quietPeriod);
>      public static Throttler debounceTrailing(Duration quietPeriod);
>      public static Throttler throttle(Duration period);
>      public static Throttler throttleTrailing(Duration period);
>
> These are variations of similar concepts, and vary mostly in when
> exactly they will allow value changes; debouncers will wait for a period
> without any changes, while throttlers will periodically allow changes.
> The trailing variants will not immediately emit the first change but
> will wait for the period to elapse first; all variants will eventually
> take on the value of the source observable.  Debouncing is typically
> used when you wish for an input to settle before taking action (like
> typing in a search bar), while throttling is used to give regular
> feedback but avoid doing so too often (like feedback during window
> resizing).
>
> Usage example which updates a preview panel when the user has finished
> (cursor) scrolling through a list view:
>
>      ObjectProperty<T> selectedItem =
> listView.getSelectionModel().selectedItemProperty();
>
>      selectedItem
> .throttle(FXThrottlers.debounceTrailing(Duration.ofMillis(500)))
>          .addListener((obs, old, current) -> {
>               if (current != null) {
>                   updatePreviewPanel(current);
>               }
>          });
>
> Implementation details:
>
> ObservableValue is part of javafx.base, and as such can't use animations
> or call Platform::runLater.  The ThrottledBinding implementation has
> abstracted all of these out into the Throttler class, and FXThrottlers
> (which would live in javafx.graphics) therefore provides the necessary
> call backs to integrate property changes correctly back onto the JavaFX
> event thread.  The Throttler class also simplifies testing; the test can
> provide its own timing source and background scheduler.  The Throttler
> interface has the following methods:
>
>      /**
>       * Schedules a command to run on an unspecified thread after the time
>       * given by {@code nanos} elapses.
>       *
>       * @param command a command to run, cannot be {@code null}
>       * @param nanos a time in nanoseconds
>       */
>      void schedule(Runnable command, long nanos);
>
>      /**
>       * Provides the current time in nanoseconds.
>       *
>       * @return the current time in nanoseconds
>       */
>      long nanoTime();
>
>      /**
>       * Runs the given command as soon as possible on a thread specified
> by this
>       * throttler for updating property values.
>       *
>       * @param command a command to run, cannot be {@code null}
>       */
>      void update(Runnable command);
>
>      /**
>       * Given the current elapsed time in the current change window, and
> the
>       * amount of time elapsed since the last change was detected,
> determines
>       * if and by how much the current change window should be extended.
>       *
>       * @param elapsed nanoseconds elapsed since the start of the
> current change window
>       * @param elapsedSinceLastChange nanoseconds elapsed since the last
> change
>       * @return nanoseconds to extend the window with
>       */
>      long determineInterval(long elapsed, long elapsedSinceLastChange);
>
> For testing purposes, the schedule and nanoTime can be provided such
> that the throttle function can be tested deterministically. For
> integrating with JavaFX, update is implemented as
> `Platform.runLater(command)`.  The schedule and nanoTime methods
> delegate to an Executor and System.nanoTime respectively.  When using
> properties without JavaFX, Throttler implementations can be provided
> which run property updates on a scheduler thread (just calling
> Runnable::run on the current thread) or via some user provided executor.
>
> A sample test case looks like this (read with a mono space font :-)):
>
>      @Test
>      void testThrottleLeadingAndTrailing() {
>        // create Throttler with deterministic behavior:
>        Throttler throttler =
> create(Throttler.IntervalHandler.throttle(Duration.ofNanos(4));
>
>        // create throttled observable:
>        ObservableValue<String> binding = source.throttle(throttler);
>
>        assertChanges(
>          binding,
>          "--a-b--c---d-----e-------f-g-----------f-g-----",
>          "--a---b---c---d---e------f---g---------f---g---"
>        );
>
>        assertInvalidations(
>          binding,
>          "--a-b--c---d-----e-------f-g-----------f-g-----",
>          "--i---i---i---i---i------i---i---------i---i---"
>        );
>      }
>
> Thanks for reading, I look forward to your feedback!
>
> --John
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230328/a6cff8f8/attachment-0001.htm>

From kcr at openjdk.org  Tue Mar 28 13:03:01 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Mar 2023 13:03:01 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
In-Reply-To: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
References: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
Message-ID: <kyP_xErsLKBaI0UI0fE4IaPIUcz_gLCXiY96NbgEO1w=.b15fea03-dd46-4167-a628-6bb42fc40d51@github.com>

On Tue, 28 Mar 2023 02:08:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Error copying file (if different) from Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_header.py" to "modules/javafx.web/build/mac/Release/JavaScriptCcripts/builtins_generate_separate_header.py".
> 
> Root cause: The number of build threads more than 8, causing a synchronization issue for builtins_generate_separate_header.py, the file needs to be copied before use at build dir
> 
> Solution: Use the sleep of 1 second and retry 10 times to copy in CMakeList.txt and execute using the execute_process cmake command

@johanvos @tiainen Can one of you also review this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1073#issuecomment-1486844505

From kcr at openjdk.org  Tue Mar 28 15:16:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Mar 2023 15:16:35 GMT
Subject: RFR: 8304441: [macos] Crash when putting invalid unicode char on
 clipboard
Message-ID: <6AADnJNah6umVMFeVYodgaBdDoVnDj5UicoE6IST0Kk=.a63ed42d-16ad-4901-aa8b-3f5fac9f64ea@github.com>

A malformed unicode string containing only half of a surrogate pair (either a high or low surrogate without the other half) will cause a native exception in the macOS `NSPasteboardItem setString:forType:` method. This uncaught exception will terminate (crash) the application.

The fix is to validate the string before calling `setString:forType:`. I also added a try / catch that logs a warning, so that if we ever run into other exceptions, they won't be fatal.

I added an automated test that fails on macOS without the fix and passes with the fix. The test is run on other platforms as well, and passes both before and after the fix.

-------------

Commit messages:
 - fix whitespace
 - 8304441: [macos] Crash when putting invalid unicode char on clipboard

Changes: https://git.openjdk.org/jfx/pull/1074/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304441
  Stats: 115 lines in 2 files changed: 113 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1074.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1074/head:pull/1074

PR: https://git.openjdk.org/jfx/pull/1074

From kcr at openjdk.org  Tue Mar 28 21:35:37 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Mar 2023 21:35:37 GMT
Subject: [jfx20u] RFR: 8305108: Change JavaFX release version to 20.0.2 in
 jfx20u
Message-ID: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>

Updates for the beginning of the 20.0.2 release.

-------------

Commit messages:
 - 8305108: Change JavaFX release version to 20.0.2 in jfx20u

Changes: https://git.openjdk.org/jfx20u/pull/10/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx20u&pr=10&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305108
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx20u/pull/10.diff
  Fetch: git fetch https://git.openjdk.org/jfx20u.git pull/10/head:pull/10

PR: https://git.openjdk.org/jfx20u/pull/10

From kcr at openjdk.org  Tue Mar 28 21:35:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 28 Mar 2023 21:35:38 GMT
Subject: [jfx20u] RFR: 8305108: Change JavaFX release version to 20.0.2 in
 jfx20u
In-Reply-To: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>
References: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>
Message-ID: <2gYsfDBNgkwvEr7XKrX7BLmv9Al2OOxisoafpFXRsqI=.e869c693-fadb-4582-a825-5d6329aab5cd@github.com>

On Tue, 28 Mar 2023 21:29:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.2 release.

@arapte or @johanvos can one of you review this?

-------------

PR Comment: https://git.openjdk.org/jfx20u/pull/10#issuecomment-1487619927

From mhanl at openjdk.org  Wed Mar 29 07:36:19 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 29 Mar 2023 07:36:19 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>
Message-ID: <mQvJOGY4J-Mx68yfaz2f6gapQmadULfdinj58z63vAQ=.e904bfcc-96f1-4dfb-9665-41ee952735d2@github.com>

On Thu, 16 Mar 2023 19:41:07 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed).

Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all.
We might even want to look into other frameworks like Swing. 
Maybe there are people internally at Oracle who can give valuable input here too?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1488086235

From lkostyra at openjdk.org  Wed Mar 29 08:58:39 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 29 Mar 2023 08:58:39 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
In-Reply-To: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
References: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
Message-ID: <_4Ie1WzQhX7jvbrAghcGyGpsAV7JdaAboAR24OZDnLg=.00ebf660-da95-4487-94d1-cd1b243a7936@github.com>

On Tue, 28 Mar 2023 02:08:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Error copying file (if different) from Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_header.py" to "modules/javafx.web/build/mac/Release/JavaScriptCcripts/builtins_generate_separate_header.py".
> 
> Root cause: The number of build threads more than 8, causing a synchronization issue for builtins_generate_separate_header.py, the file needs to be copied before use at build dir
> 
> Solution: Use the sleep of 1 second and retry 10 times to copy in CMakeList.txt and execute using the execute_process cmake command

modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt line 198:

> 196:         )
> 197:         if(copy_result)
> 198:             message(WARNING "Failed to copy ${_file} to ${JavaScriptCore_SCRIPTS_DIR}/${_script}: ${copy_output}")

Shouldn't `${copy_output}` at the end of this message be `${copy_result}`?

If not, I think it would be worth to print the `${copy_result}` variable regardless, in case there are any issues with the copy process.

modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt line 210:

> 208:     endif()
> 209:     endif() # end for port "Java"
> 210:     add_custom_command(

Suggestion: I feel this add_custom_command doesn't have to be called anymore because our loop did that job already. Maybe this old behavior should be fallen back to only when we're not fulfilling the PORT "Java" condition, or it should be removed completely.

So, in short:

if(PORT STREQUAL "Java")
  # code for 10-try loop
else() # else for port "Java"
  # old add_custom_command call
endif() # end for port "Java"


Or keep the code as is and remove this add_custom_command call. What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151597002
PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151605041

From jhendrikx at openjdk.org  Wed Mar 29 09:53:09 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Mar 2023 09:53:09 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
Message-ID: <pdOwNePOkItIS1jl_gI0LVx82d3qbaGW4us8BiLSjFU=.17528e34-6c6f-491e-a9fd-9e513f9ead2b@github.com>

On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - changes per review
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>  - revert snappedSum
>  - don't call snappedSum in hot loop
>  - Improved code documentation
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - changed some method names, make test config a local class
>  - added documentation, improved method names
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

I only looked at HBox changes:

Although this code is probably an improvement, I'm not convinced it always is doing the right thing with regards to the final child sizes -- I think the container will indeed always fill up perfectly, but I think the child sizes can be off by a few pixels from ideal values given some crafted input values, that would require multiple passes in the adjust loop and multiple "snap" calls being applied.

Extending the tests to verify the final layout widths of the children could alleviate these doubts, as well as adding more edge cases.  I don't think the current tests exercise all of the newly written code; a coverage check could verify this.

I think the tests could be written to use an unsnapped simplistic sizing algorithm, and verifies resulting child widths are never off by more than 1 pixel.  It may also be possible to set the container to unsnapped, then to snapped and verify sizes never change by more than 1 pixel for random input values.

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 483:

> 481:      *         of all children as well as the spacing between them
> 482:      */
> 483:     private double adjustChildrenWidths(List<Node> managed, double[][] childrenWidths, double width, double height) {

Could you document all the parameters, and mention what they represent (min, max, pref) and whether they're snapped or not?

Further, could you split `childrenWidths` in its constituent parts (I think it is `prefWidths` and `maxWidths` ?) -- the `double[][]` is confusing and after its initial creation, it can be passed as two separate arrays to subsequent functions for clarity.

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 504:

> 502:     /**
> 503:      * Shrinks all children widths to fit the target width.
> 504:      * In contrast to growing, shrinking does not require two phases of processing.

I find the terminology used confusing in many areas.  Children widths seems to be referring to their preferred widths here, not (for example) their current widths.  As these are preferred widths, it makes sense that shrinking would not need to look at priorities; if they had been current widths, you'd need to shrink `SOMETIMES` nodes first.

Documenting the parameter could alleviate this confusion.  It may also be good to re-iterate in every parameter documentation whether this is a snapped value or not.

In fact, reading this a bit more, I think the "input" childrenWidths are pref + unused values (splitting the array would make that clearer).  The values are snapped already.  The empty values are then filled with minimum values, effectively modifying the array (should be documented), while the pref values are modified to become the layout values.

It looks like the `double[][]` construct is an optimization to prevent allocating two separate arrays... pretty sure that it would not make any difference if it had been split.

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 527:

> 525:      */
> 526:     private void growChildrenWidths(List<Node> managed, double[][] childrenWidths, double targetWidth, double height) {
> 527:         double[] currentWidths = childrenWidths[0];

This is named `usedWidths` in the shrink version, while I think it actually are the preferred widths, which will be adjusted in this function to become the final layout widths.

As mutating values in Java is rare, a comment would help to clarify this:   

    double[] currentWidths = childrenWidths[0];  // initially pref widths, adjusted to layout widths

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 559:

> 557:     /**
> 558:      * Resizes the children widths to fit the target width, while taking into account the resize limits
> 559:      * for each child (their minimum and maximum width). This method will be called once when shrinking,

Perhaps clarify why only once is sufficient for shrinking (if I read the code correctly, I think the reason is that adjustments always use the preferred children widths as a "base" value; the naming however is often generic enough that it could be their current layout widths that are being adjusted to a new reality, in which case even shrinking would need to take `Priority` into acount).

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 586:

> 584:             // The amount of space that, in the ideal case, we need to add to or subtract from
> 585:             // each eligible child in order to fit the children into the target width.
> 586:             double idealChange = snapPortionX(currentDelta / adjustingNumber);

Can this be 0 ?

For example, I have a targetWidth of 100, and two children that have preferred widths of 49 and 50, both with `Priority.ALWAYS`.  I would need to grow to reach the target width of 100.  As far as I can see the values in the code would then be:

     targetWidth = 100.0;
     currentTotalWidth = 99.0;
     currentDelta = 1.0;
     adjustingNumber = 2;

This would enter the `while` loop, and ideal change would be:

     idealChange = snapPortionX(1.0 / 2) = 0  // snapPortionX does a "floor".

That doesn't look good.

However, I now see that it wouldn't become an infinite loop, and that's because the input parameter `adjustingNumber` is being modified, and so doesn't always represent what I think it does.

modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java line 604:

> 602:                 double oldWidth = currentWidths[i];
> 603:                 currentWidths[i] = snapSizeX(oldWidth + actualChange);
> 604:                 currentTotalWidth = snapSpaceX(currentTotalWidth + (currentWidths[i] - oldWidth));

What I don't like about these two lines is that they're already dealing with values that are all snapped (and thus a fractional portion was lost). Then another calculation is done, and they're snapped again, losing even more information. Or is it that the snapping here is unnecessary as the calculation already involves values that are all have been snapped before?

So either, the snapping isn't needed, or things are being snapped multiple times -- the first is confusing, the second is like rounding values multiple times in a calculation instead of only the end result...

-------------

PR Review: https://git.openjdk.org/jfx/pull/445#pullrequestreview-1362487101
PR Review Comment: https://git.openjdk.org/jfx/pull/445#discussion_r1151589527
PR Review Comment: https://git.openjdk.org/jfx/pull/445#discussion_r1151582955
PR Review Comment: https://git.openjdk.org/jfx/pull/445#discussion_r1151612290
PR Review Comment: https://git.openjdk.org/jfx/pull/445#discussion_r1151549496
PR Review Comment: https://git.openjdk.org/jfx/pull/445#discussion_r1151650961
PR Review Comment: https://git.openjdk.org/jfx/pull/445#discussion_r1151656708

From jhendrikx at openjdk.org  Wed Mar 29 10:22:56 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Mar 2023 10:22:56 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <mQvJOGY4J-Mx68yfaz2f6gapQmadULfdinj58z63vAQ=.e904bfcc-96f1-4dfb-9665-41ee952735d2@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>
 <mQvJOGY4J-Mx68yfaz2f6gapQmadULfdinj58z63vAQ=.e904bfcc-96f1-4dfb-9665-41ee952735d2@github.com>
Message-ID: <hRgVP787FVNV5lVYXkjfweXSwP0jCeDXU4Uung9lB5I=.58ae1e6c-eb5e-4562-873a-335dbbb88f03@github.com>

On Wed, 29 Mar 2023 07:33:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed).
> 
> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all. We might even want to look into other frameworks like Swing. Maybe there are people internally at Oracle who can give valuable input here too?

I think extracting the common code out of HBox and VBox would be good, as they're basically doing the same thing in a different axis.  The code could then be unit tested directly (ie. given a set of min/max/pref sizes, a target size and a "snapper", calculate optimal sizes).  Something like this:

     double[] distribute(double space, double[] minWidths, double[] maxWidths, Snapper snapper);

The minWidths/maxWidths would be min + pref or pref + max depending on the situation, but this function wouldn't care.  The `Snapper` here would be aware of the scale, and would be a dummy implementation that does nothing when snapping is disabled.

This purposely does not handle spacing between children, as you can calculate that before hand and adjust `space` to the actual space available for children, simplifying the code.

Disclaimer: I used to create my own layout manager (see: [smartlayout](https://github.com/hjohn/hs.ui.smartlayout/blob/master/src/main/java/hs/smartlayout/LayoutRequirements.java)) that took into account min/max and weight of each child, and even groups of children (a restriction over two or more children at once) -- weight would affect resizing, allowing you to make layouts where children took space according to some ratio (1:2:3 for example).  This functionality I called a `SpaceDistributor` which was purposely given a neutral name as it could be used for both horizontal or vertical calculations.  When including weight, the calculations could get so complex that I had multiple implementations and an exhaustive search implementation (which was used by unit tests to verify the optimized implementations). This was before scaling became an issue though, so this code did not take snapping values to pixels into account.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1488330078

From jbhaskar at openjdk.org  Wed Mar 29 10:49:28 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 29 Mar 2023 10:49:28 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
In-Reply-To: <_4Ie1WzQhX7jvbrAghcGyGpsAV7JdaAboAR24OZDnLg=.00ebf660-da95-4487-94d1-cd1b243a7936@github.com>
References: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
 <_4Ie1WzQhX7jvbrAghcGyGpsAV7JdaAboAR24OZDnLg=.00ebf660-da95-4487-94d1-cd1b243a7936@github.com>
Message-ID: <0WhO3LWqSZPwJJ_L6CqHIdHvO2YXRfAHcwUPEgf2Sqs=.70d6120e-c15d-4e17-b57e-58b063571f0e@github.com>

On Wed, 29 Mar 2023 08:46:53 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Issue: Error copying file (if different) from Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_header.py" to "modules/javafx.web/build/mac/Release/JavaScriptCcripts/builtins_generate_separate_header.py".
>> 
>> Root cause: The number of build threads more than 8, causing a synchronization issue for builtins_generate_separate_header.py, the file needs to be copied before use at build dir
>> 
>> Solution: Use the sleep of 1 second and retry 10 times to copy in CMakeList.txt and execute using the execute_process cmake command
>
> modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt line 198:
> 
>> 196:         )
>> 197:         if(copy_result)
>> 198:             message(WARNING "Failed to copy ${_file} to ${JavaScriptCore_SCRIPTS_DIR}/${_script}: ${copy_output}")
> 
> Shouldn't `${copy_output}` at the end of this message be `${copy_result}`?
> 
> If not, I think it would be worth to print the `${copy_result}` variable regardless, in case there are any issues with the copy process.

do you mean as 
if(copy_result)
            message(WARNING "Failed to copy ${_file} to ${JavaScriptCore_SCRIPTS_DIR}/${_script}: ${copy_output}")
should be as

if(copy_result)
            message(WARNING "${copy_result")

> modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt line 210:
> 
>> 208:     endif()
>> 209:     endif() # end for port "Java"
>> 210:     add_custom_command(
> 
> Suggestion: I feel this add_custom_command doesn't have to be called anymore because our loop did that job already. Maybe this old behavior should be fallen back to only when we're not fulfilling the PORT "Java" condition, or it should be removed completely.
> 
> So, in short:
> 
> if(PORT STREQUAL "Java")
>   # code for 10-try loop
> else() # else for port "Java"
>   # old add_custom_command call
> endif() # end for port "Java"
> 
> 
> Or keep the code as is and remove this add_custom_command call. What do you think?

I intentionally left the previous code unchanged. 
    add_custom_command(
        OUTPUT ${JavaScriptCore_SCRIPTS_DIR}/${_script}
        MAIN_DEPENDENCY ${_file}
        WORKING_DIRECTORY ${JavaScriptCore_DERIVED_SOURCES_DIR}
        COMMAND ${CMAKE_COMMAND} -E copy_if_different ${_file} ${JavaScriptCore_SCRIPTS_DIR}/${_script}
        VERBATIM)
copy_if_different  will do nothing , if the changed code already did copy

incase of our changed code fail , the remaining add_custom_comand would prevent build issue.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151744460
PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151744625

From jbhaskar at openjdk.org  Wed Mar 29 11:14:49 2023
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 29 Mar 2023 11:14:49 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
In-Reply-To: <vJdbOS4CchuC9iJVq3eO9xB4gu4q8RjGr0bxJVTqars=.a1c873d1-6c26-4b88-b559-dcc987b819e2@github.com>
References: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
 <_4Ie1WzQhX7jvbrAghcGyGpsAV7JdaAboAR24OZDnLg=.00ebf660-da95-4487-94d1-cd1b243a7936@github.com>
 <0WhO3LWqSZPwJJ_L6CqHIdHvO2YXRfAHcwUPEgf2Sqs=.70d6120e-c15d-4e17-b57e-58b063571f0e@github.com>
 <vJdbOS4CchuC9iJVq3eO9xB4gu4q8RjGr0bxJVTqars=.a1c873d1-6c26-4b88-b559-dcc987b819e2@github.com>
Message-ID: <cvttriJQpDfM4LhbD0Kq6VKTK_jXYvFpbYnElZvtKnQ=.d806451a-7efd-4923-872d-1257c5b69aa6@github.com>

On Wed, 29 Mar 2023 11:09:52 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> do you mean as 
>> if(copy_result)
>>             message(WARNING "Failed to copy ${_file} to ${JavaScriptCore_SCRIPTS_DIR}/${_script}: ${copy_output}")
>> should be as
>> 
>> if(copy_result)
>>             message(WARNING "${copy_result")
>
> Actually, you can disregard this comment - I thought that `cmake -E copy_if_different ...` returns some meaningful error code (ex. one of errno variables) but I double-checked and it seems it returns 0 if succeeded and 1 if failed. Won't bring us any good to print it out, so it can stay as it is.

ok, thanks

>> I intentionally left the previous code unchanged. 
>>     add_custom_command(
>>         OUTPUT ${JavaScriptCore_SCRIPTS_DIR}/${_script}
>>         MAIN_DEPENDENCY ${_file}
>>         WORKING_DIRECTORY ${JavaScriptCore_DERIVED_SOURCES_DIR}
>>         COMMAND ${CMAKE_COMMAND} -E copy_if_different ${_file} ${JavaScriptCore_SCRIPTS_DIR}/${_script}
>>         VERBATIM)
>> copy_if_different  will do nothing , if the changed code already did copy
>> 
>> incase of our changed code fail , the remaining add_custom_comand would prevent build issue.
>
> Understood, thanks for the explanation!

Thanks for review

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151771242
PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151772181

From lkostyra at openjdk.org  Wed Mar 29 11:14:49 2023
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 29 Mar 2023 11:14:49 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
In-Reply-To: <0WhO3LWqSZPwJJ_L6CqHIdHvO2YXRfAHcwUPEgf2Sqs=.70d6120e-c15d-4e17-b57e-58b063571f0e@github.com>
References: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
 <_4Ie1WzQhX7jvbrAghcGyGpsAV7JdaAboAR24OZDnLg=.00ebf660-da95-4487-94d1-cd1b243a7936@github.com>
 <0WhO3LWqSZPwJJ_L6CqHIdHvO2YXRfAHcwUPEgf2Sqs=.70d6120e-c15d-4e17-b57e-58b063571f0e@github.com>
Message-ID: <vJdbOS4CchuC9iJVq3eO9xB4gu4q8RjGr0bxJVTqars=.a1c873d1-6c26-4b88-b559-dcc987b819e2@github.com>

On Wed, 29 Mar 2023 10:46:05 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt line 198:
>> 
>>> 196:         )
>>> 197:         if(copy_result)
>>> 198:             message(WARNING "Failed to copy ${_file} to ${JavaScriptCore_SCRIPTS_DIR}/${_script}: ${copy_output}")
>> 
>> Shouldn't `${copy_output}` at the end of this message be `${copy_result}`?
>> 
>> If not, I think it would be worth to print the `${copy_result}` variable regardless, in case there are any issues with the copy process.
>
> do you mean as 
> if(copy_result)
>             message(WARNING "Failed to copy ${_file} to ${JavaScriptCore_SCRIPTS_DIR}/${_script}: ${copy_output}")
> should be as
> 
> if(copy_result)
>             message(WARNING "${copy_result")

Actually, you can disregard this comment - I thought that `cmake -E copy_if_different ...` returns some meaningful error code (ex. one of errno variables) but I double-checked and it seems it returns 0 if succeeded and 1 if failed. Won't bring us any good to print it out, so it can stay as it is.

>> modules/javafx.web/src/main/native/Source/JavaScriptCore/CMakeLists.txt line 210:
>> 
>>> 208:     endif()
>>> 209:     endif() # end for port "Java"
>>> 210:     add_custom_command(
>> 
>> Suggestion: I feel this add_custom_command doesn't have to be called anymore because our loop did that job already. Maybe this old behavior should be fallen back to only when we're not fulfilling the PORT "Java" condition, or it should be removed completely.
>> 
>> So, in short:
>> 
>> if(PORT STREQUAL "Java")
>>   # code for 10-try loop
>> else() # else for port "Java"
>>   # old add_custom_command call
>> endif() # end for port "Java"
>> 
>> 
>> Or keep the code as is and remove this add_custom_command call. What do you think?
>
> I intentionally left the previous code unchanged. 
>     add_custom_command(
>         OUTPUT ${JavaScriptCore_SCRIPTS_DIR}/${_script}
>         MAIN_DEPENDENCY ${_file}
>         WORKING_DIRECTORY ${JavaScriptCore_DERIVED_SOURCES_DIR}
>         COMMAND ${CMAKE_COMMAND} -E copy_if_different ${_file} ${JavaScriptCore_SCRIPTS_DIR}/${_script}
>         VERBATIM)
> copy_if_different  will do nothing , if the changed code already did copy
> 
> incase of our changed code fail , the remaining add_custom_comand would prevent build issue.

Understood, thanks for the explanation!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151769585
PR Review Comment: https://git.openjdk.org/jfx/pull/1073#discussion_r1151769841

From kcr at openjdk.org  Wed Mar 29 11:21:39 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Mar 2023 11:21:39 GMT
Subject: RFR: 8286089: Intermittent WebKit build failure on macOS in
 JavaScriptCore
In-Reply-To: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
References: <t0FK6tFSEDm2nq19ezyic8DIHyyAOQyDprtyCOH276c=.2d4d6807-7c47-4e64-8940-61c0da3ce81a@github.com>
Message-ID: <tnjJH88L2a3xzyoY1F2JkR6T3syRp3WUZBkIi1OShgY=.f96d5965-b586-4db9-932b-aeb668516115@github.com>

On Tue, 28 Mar 2023 02:08:27 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Error copying file (if different) from Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_header.py" to "modules/javafx.web/build/mac/Release/JavaScriptCcripts/builtins_generate_separate_header.py".
> 
> Root cause: The number of build threads more than 8, causing a synchronization issue for builtins_generate_separate_header.py, the file needs to be copied before use at build dir
> 
> Solution: Use the sleep of 1 second and retry 10 times to copy in CMakeList.txt and execute using the execute_process cmake command

Looks good. I see that your CI test build passed on all platforms, and a continuous stress build on our Mac CI build machines ran for several days with no failures.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1073#pullrequestreview-1362845584

From jhendrikx at openjdk.org  Wed Mar 29 12:20:38 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Mar 2023 12:20:38 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
Message-ID: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>

A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

-------------

Commit messages:
 - Defer initialization of ListChangeBuilder in ObservableListBase

Changes: https://git.openjdk.org/jfx/pull/1075/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1075&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304960
  Stats: 18 lines in 1 file changed: 8 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1075.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1075/head:pull/1075

PR: https://git.openjdk.org/jfx/pull/1075

From angorya at openjdk.org  Wed Mar 29 15:05:44 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Mar 2023 15:05:44 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
Message-ID: <OL43fURZ9XrV29DDaEVeCM9GJb3c0s8R-piYgknwfcI=.5b27a7d5-5505-4157-aec3-05fac5d3d148@github.com>

On Wed, 29 Mar 2023 12:15:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

a good idea!

-------------

Marked as reviewed by angorya (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1075#pullrequestreview-1363344143

From angorya at openjdk.org  Wed Mar 29 15:34:40 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Mar 2023 15:34:40 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
Message-ID: <VAQXYvGZU0SOtT-9VPkDOcgrgeQwG53NFW9n6Zt3MVI=.42ee6ee5-2c94-447d-ad5c-e66129a25665@github.com>

On Wed, 29 Mar 2023 12:15:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

the only place where this code might fail is when it gets accessed from multiple threads.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1075#issuecomment-1488851086

From arapte at openjdk.org  Wed Mar 29 16:39:50 2023
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 29 Mar 2023 16:39:50 GMT
Subject: [jfx20u] RFR: 8305108: Change JavaFX release version to 20.0.2 in
 jfx20u
In-Reply-To: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>
References: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>
Message-ID: <jNrhMhmkskwp9Fz8xVIf6zwJiV3ev7po_-NxbvGsp0E=.e38ac18e-16f8-43a6-89cd-9deacce7b1a6@github.com>

On Tue, 28 Mar 2023 21:29:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.2 release.

Marked as reviewed by arapte (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx20u/pull/10#pullrequestreview-1363539495

From jhendrikx at openjdk.org  Wed Mar 29 16:42:46 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Mar 2023 16:42:46 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <VAQXYvGZU0SOtT-9VPkDOcgrgeQwG53NFW9n6Zt3MVI=.42ee6ee5-2c94-447d-ad5c-e66129a25665@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
 <VAQXYvGZU0SOtT-9VPkDOcgrgeQwG53NFW9n6Zt3MVI=.42ee6ee5-2c94-447d-ad5c-e66129a25665@github.com>
Message-ID: <94kJaPxlKXUK00vyYWAD5djzi9zqzfhhZJJmfvIqbws=.f596b39b-e525-4398-ac1d-c1913cb296f8@github.com>

On Wed, 29 Mar 2023 15:31:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> the only place where this code might fail is when it gets accessed from multiple threads.

`ListChangeBuilder` itself is not thread safe :)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1075#issuecomment-1488939702

From angorya at openjdk.org  Wed Mar 29 16:55:12 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Mar 2023 16:55:12 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
Message-ID: <EHWnkT8uMMMxeFlYyYFY7PRruLZyB6m8fAWiZMjAa8s=.60fb39f2-548e-4ef6-b637-030a3b4fddbc@github.com>

On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - changes per review
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>  - revert snappedSum
>  - don't call snappedSum in hot loop
>  - Improved code documentation
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - changed some method names, make test config a local class
>  - added documentation, improved method names
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

I suspect John is right: the kind of scenarios that would fail with the proposed code is when we have
a) fractional scale and
b) min/max constraints
c) requirement to fill the available space

The reason it would fail is that the component width is not invariant in respect of translation due to snapping and fractional scale.  Not only it means that multiple passes are required, but also that each time something gets changed or even moved, the computation needs to be discarded and re-done.  It is essentially the same issue as https://bugs.openjdk.org/browse/JDK-8299753

I think John is also right when talking about the common code.  I too, have encountered the problem with the Tree/TableView constrained resize policies (bug mentioned above) as well as with my own table layout implementation
https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md

Perhaps we could come up with something along the lines John described

double[] distribute(double space, double[] prefWidth, double[] minWidths, double[] maxWidths, Snapper snapper);

though I would think the gaps between the components would have to be accounted for - again, due to snapping and fractional scale (or simply passed as components of the minWidths/maxWidths arrays.

I still owe you guys the formal review - mostly my intent is to hand-craft a case that would illustrate the problem.  It is still on my list of things to do.

cheers,
-andy




From: John Hendrikx ***@***.***>
Date: Wednesday, March 29, 2023 at 02:50
To: openjdk/jfx ***@***.***>
Cc: Andy Goryachev ***@***.***>, Mention ***@***.***>
Subject: [External] : Re: [openjdk/jfx] 8264591: HBox/VBox child widths pixel-snap to wrong value (#445)

@hjohn commented on this pull request.

I only looked at HBox changes:

Although this code is probably an improvement, I'm not convinced it always is doing the right thing with regards to the final child sizes -- I think the container will indeed always fill up perfectly, but I think the child sizes can be off by a few pixels from ideal values given some crafted input values, that would require multiple passes in the adjust loop and multiple "snap" calls being applied.

Extending the tests to verify the final layout widths of the children could alleviate these doubts, as well as adding more edge cases. I don't think the current tests exercise all of the newly written code; a coverage check could verify this.

I think the tests could be written to use an unsnapped simplistic sizing algorithm, and verifies resulting child widths are never off by more than 1 pixel. It may also be possible to set the container to unsnapped, then to snapped and verify sizes never change by more than 1 pixel for random input values.

________________________________

In modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*discussion_r1151549496__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio97IfcEqEA$>:

>

-        double available = extraWidth; // will be negative in shrinking case

-        outer:while (Math.abs(available) > 1 && adjustingNumber > 0) {

-            final double portion = snapPortionX(available / adjustingNumber); // negative in shrinking case

-            for (int i = 0, size = managed.size(); i < size; i++) {

-                if (temp[i] == -1) {

+    /**

+     * Resizes the children widths to fit the target width, while taking into account the resize limits

+     * for each child (their minimum and maximum width). This method will be called once when shrinking,

Perhaps clarify why only once is sufficient for shrinking (if I read the code correctly, I think the reason is that adjustments always use the preferred children widths as a "base" value; the naming however is often generic enough that it could be their current layout widths that are being adjusted to a new reality, in which case even shrinking would need to take Priority into acount).

________________________________

In modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*discussion_r1151582955__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio97De-abfA$>:

>      }



-    private double growOrShrinkAreaWidths(List<Node>managed, double areaWidths[][], Priority priority, double extraWidth, double height) {

-        final boolean shrinking = extraWidth < 0;

-        int adjustingNumber = 0;

+    /**

+     * Shrinks all children widths to fit the target width.

+     * In contrast to growing, shrinking does not require two phases of processing.

I find the terminology used confusing in many areas. Children widths seems to be referring to their preferred widths here, not (for example) their current widths. As these are preferred widths, it makes sense that shrinking would not need to look at priorities; if they had been current widths, you'd need to shrink SOMETIMES nodes first.

Documenting the parameter could alleviate this confusion. It may also be good to re-iterate in every parameter documentation whether this is a snapped value or not.

In fact, reading this a bit more, I think the "input" childrenWidths are pref + unused values (splitting the array would make that clearer). The values are snapped already. The empty values are then filled with minimum values, effectively modifying the array (should be documented), while the pref values are modified to become the layout values.

It looks like the double[][] construct is an optimization to prevent allocating two separate arrays... pretty sure that it would not make any difference if it had been split.

________________________________

In modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*discussion_r1151589527__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio97K4wqIsg$>:

> @@ -467,77 +472,170 @@ private double[][] getAreaWidths(List<Node>managed, double height, boolean minim

         return temp;

     }



-    private double adjustAreaWidths(List<Node>managed, double areaWidths[][], double width, double height) {

+    /**

+     * Adjusts the children widths (within their min-max limits) to fit the provided space.

+     * This is necessary when the HBox is constrained to be larger or smaller than the combined preferred

+     * widths of its children. In this case, we grow or shrink the children until they fit the HBox exactly.

+     *

+     * @return the pixel-snapped content width, which is the combined width

+     *         of all children as well as the spacing between them

+     */

+    private double adjustChildrenWidths(List<Node> managed, double[][] childrenWidths, double width, double height) {

Could you document all the parameters, and mention what they represent (min, max, pref) and whether they're snapped or not?

Further, could you split childrenWidths in its constituent parts (I think it is prefWidths and maxWidths ?) -- the double[][] is confusing and after its initial creation, it can be passed as two separate arrays to subsequent functions for clarity.

________________________________

In modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*discussion_r1151612290__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio94JmcG_nQ$>:

>

-        double[] usedWidths = areaWidths[0];

-        double[] temp = areaWidths[1];

-        final boolean shouldFillHeight = shouldFillHeight();

+        adjustWidthsWithinLimits(managed, usedWidths, minWidths, targetWidth, managed.size());

+    }

+

+    /**

+     * Grows all children widths to fit the target width.

+     * Growing is a two-phase process: first, only children with ***@***.*** Priority#ALWAYS} are eligible

+     * for adjustment. If the first adjustment didn't suffice to fit the target width, children with

+     * ***@***.*** Priority#SOMETIMES} are also eligible for adjustment.

+     */

+    private void growChildrenWidths(List<Node> managed, double[][] childrenWidths, double targetWidth, double height) {

+        double[] currentWidths = childrenWidths[0];

This is named usedWidths in the shrink version, while I think it actually are the preferred widths, which will be adjusted in this function to become the final layout widths.

As mutating values in Java is rare, a comment would help to clarify this:

double[] currentWidths = childrenWidths[0];  // initially pref widths, adjusted to layout widths

________________________________

In modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*discussion_r1151650961__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio94S7vhfPQ$>:

> +    private boolean adjustWidthsWithinLimits(

+            List<Node> managed, double[] currentWidths, double[] limitWidths, double targetWidth, int adjustingNumber) {

+        double totalSpacing = (managed.size() - 1) * snapSpaceX(getSpacing());

+

+        // Current total width and current delta are two important numbers that we continuously

+        // update as this method converges towards a solution.

+        double currentTotalWidth = snapSpaceX(sum(currentWidths, managed.size())) + totalSpacing;

+        double currentDelta = targetWidth - currentTotalWidth;

+

+        // We repeatedly apply the following algorithm as long as we have space left to

+        // distribute (currentDelta), as well as children that are eligible to grow or

+        // shrink (adjustingNumber).

+        while ((currentDelta > Double.MIN_VALUE || currentDelta < -Double.MIN_VALUE) && adjustingNumber > 0) {

+            // The amount of space that, in the ideal case, we need to add to or subtract from

+            // each eligible child in order to fit the children into the target width.

+            double idealChange = snapPortionX(currentDelta / adjustingNumber);

Can this be 0 ?

For example, I have a targetWidth of 100, and two children that have preferred widths of 49 and 50, both with Priority.ALWAYS. I would need to grow to reach the target width of 100. As far as I can see the values in the code would then be:

 targetWidth = 100.0;

 currentTotalWidth = 99.0;

 currentDelta = 1.0;

 adjustingNumber = 2;

This would enter the while loop, and ideal change would be:

 idealChange = snapPortionX(1.0 / 2) = 0  // snapPortionX does a "floor".

That doesn't look good.

However, I now see that it wouldn't become an infinite loop, and that's because the input parameter adjustingNumber is being modified, and so doesn't always represent what I think it does.

________________________________

In modules/javafx.graphics/src/main/java/javafx/scene/layout/HBox.java<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*discussion_r1151656708__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio97OrRRKqQ$>:

> +                currentWidths[i] = snapSizeX(oldWidth + actualChange);

+                currentTotalWidth = snapSpaceX(currentTotalWidth + (currentWidths[i] - oldWidth));

What I don't like about these two lines is that they're already dealing with values that are all snapped (and thus a fractional portion was lost). Then another calculation is done, and they're snapped again, losing even more information. Or is it that the snapping here is unnecessary as the calculation already involves values that are all have been snapped before?

So either, the snapping isn't needed, or things are being snapped multiple times -- the first is confusing, the second is like rounding values multiple times in a calculation instead of only the end result...

?
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/openjdk/jfx/pull/445*pullrequestreview-1362487101__;Iw!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio965LQaXGA$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AZQ34ZECB4CKOP5B246PPW3W6QAVJANCNFSM42AIJ57Q__;!!ACWV5N9M2RV99hQ!KzBy-Nwzdqqe5UkuUWmRz2ReYMEkKWOyZ0g9cDGrsm88iZTdWLOyJ9It_9xcXBR2MwFW5YxmrL31nR_pgSDio97M0GlT9w$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1488957378

From mstrauss at openjdk.org  Wed Mar 29 17:34:52 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 29 Mar 2023 17:34:52 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <hRgVP787FVNV5lVYXkjfweXSwP0jCeDXU4Uung9lB5I=.58ae1e6c-eb5e-4562-873a-335dbbb88f03@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>
 <mQvJOGY4J-Mx68yfaz2f6gapQmadULfdinj58z63vAQ=.e904bfcc-96f1-4dfb-9665-41ee952735d2@github.com>
 <hRgVP787FVNV5lVYXkjfweXSwP0jCeDXU4Uung9lB5I=.58ae1e6c-eb5e-4562-873a-335dbbb88f03@github.com>
Message-ID: <JF52RkXjuV8B1ICJQwcvbYPt17sU6MXa-ZdqQ91Jjv0=.45ec3317-2cd3-40a0-b88c-b79287222153@github.com>

On Wed, 29 Mar 2023 10:20:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed).
>> 
>> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all.
>> We might even want to look into other frameworks like Swing. 
>> Maybe there are people internally at Oracle who can give valuable input here too?
>
>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed).
>> 
>> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all. We might even want to look into other frameworks like Swing. Maybe there are people internally at Oracle who can give valuable input here too?
> 
> I think extracting the common code out of HBox and VBox would be good, as they're basically doing the same thing in a different axis.  The code could then be unit tested directly (ie. given a set of min/max/pref sizes, a target size and a "snapper", calculate optimal sizes).  Something like this:
> 
>      double[] distribute(double space, double[] minWidths, double[] maxWidths, Snapper snapper);
> 
> The minWidths/maxWidths would be min + pref or pref + max depending on the situation, but this function wouldn't care.  The `Snapper` here would be aware of the scale, and would be a dummy implementation that does nothing when snapping is disabled.
> 
> This purposely does not handle spacing between children, as you can calculate that before hand and adjust `space` to the actual space available for children, simplifying the code.
> 
> Disclaimer: I used to create my own layout manager (see: [smartlayout](https://github.com/hjohn/hs.ui.smartlayout/blob/master/src/main/java/hs/smartlayout/LayoutRequirements.java)) that took into account min/max and weight of each child, and even groups of children (a restriction over two or more children at once) -- weight would affect resizing, allowing you to make layouts where children took space according to some ratio (1:2:3 for example).  This functionality I called a `SpaceDistributor` which was purposely given a neutral name as it could be used for both horizontal or vertical calculations.  When including weight, the calculations could get so complex that I had multiple implementations and an exhaustive search implementation (which was used by unit tests to verify the optimized implementations). This was before scaling became an issue though, so this code did not take snapping values to pixels into account.

Thank you very much @hjohn for your extensive review. Before addressing your comments, I'd like to get some clarification (ideally also from @kevinrushforth), because I am a bit confused by the discussion so far.

This PR is a very narrow patch that fixes an obvious bug in `HBox` and `VBox`. It's narrow in that it doesn't change the present algorithm, it merely corrects some of its flaws. There is a little bit of refactoring, but that's only done where it helps readers to better understand the algorithm.

However, the discussion seems to center around the idea of large-scale refactoring, even across multiple components, including  open tickets like [8299753](https://bugs.openjdk.org/browse/JDK-8299753). That's not something I can do as part of this PR, and if large-scale refactoring is the way we choose to go forward, I'd rather not spend more of my time on this particular PR. There needs to be a realistic chance that this PR will be accepted for integration basically as it is.

If we want to expand the scope of this work, this PR should be closed and the discussion should be continued on the mailing list.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1489019711

From angorya at openjdk.org  Wed Mar 29 17:41:49 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 29 Mar 2023 17:41:49 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
Message-ID: <BB_Wn8N9BVPckaQM5CenY6tdfhOji1n8mt9ouIhWoW0=.5870e1ab-82d0-43d1-b7a2-9c0c639eb6dd@github.com>

On Tue, 3 Jan 2023 06:31:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The children of HBox/VBox don't always pixel-snap to the same value as the container itself when a render scale other than 1 is used. This can lead to a visual glitch where the content bounds don't line up with the container bounds. In this case, the container will extend beyond its content, or vice versa.
>> 
>> The following program shows the problem for HBox:
>> 
>> Region r1 = new Region();
>> Region r2 = new Region();
>> Region r3 = new Region();
>> Region r4 = new Region();
>> Region r5 = new Region();
>> Region r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox1 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox1.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox1.setPrefHeight(40);
>> 
>> r1 = new Region();
>> r2 = new Region();
>> r3 = new Region();
>> r4 = new Region();
>> r5 = new Region();
>> r6 = new Region();
>> r1.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r2.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r3.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r4.setBackground(new Background(new BackgroundFill(Color.GREY, null, null)));
>> r5.setBackground(new Background(new BackgroundFill(Color.DARKGRAY, null, null)));
>> r6.setBackground(new Background(new BackgroundFill(Color.BLACK, null, null)));
>> r1.setPrefWidth(25.3);
>> r2.setPrefWidth(25.3);
>> r3.setPrefWidth(25.4);
>> r4.setPrefWidth(25.3);
>> r5.setPrefWidth(25.3);
>> r6.setPrefWidth(25.4);
>> r1.setMaxHeight(30);
>> r2.setMaxHeight(30);
>> r3.setMaxHeight(30);
>> r4.setMaxHeight(30);
>> r5.setMaxHeight(30);
>> r6.setMaxHeight(30);
>> HBox hbox2 = new HBox(r1, r2, r3, r4, r5, r6);
>> hbox2.setBackground(new Background(new BackgroundFill(Color.RED, null, null)));
>> hbox2.setPrefHeight(40);
>> hbox2.setPrefWidth(152);
>> 
>> VBox root = new VBox(new HBox(hbox1), new HBox(hbox2));
>> root.setSpacing(20);
>> Scene scene = new Scene(root, 500, 250);
>> 
>> primaryStage.setScene(scene);
>> primaryStage.show();
>> 
>> 
>> Here's a before-and-after comparison of the program above after applying the fix. Note that 'before', the backgrounds of the container (red) and its content (black) don't align perfectly. The render scale is 175% in this example.
>> ![pixel-glitch](https://user-images.githubusercontent.com/43553916/112891996-146e2d80-90d9-11eb-9d83-97754ae38dc1.png)
>> 
>> I've filed a bug report and will change the title of the GitHub issue as soon as it's posted.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - changes per review
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>    
>    # Conflicts:
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HBoxTest.java
>    #	modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java
>  - Merge branch 'openjdk:master' into fixes/box-snap-to-pixel
>  - revert snappedSum
>  - don't call snappedSum in hot loop
>  - Improved code documentation
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - changed some method names, make test config a local class
>  - added documentation, improved method names
>  - Merge branch 'master' into fixes/box-snap-to-pixel
>  - ... and 2 more: https://git.openjdk.org/jfx/compare/a35c3bf7...fbbc273a

(copying here from the mailing list)

I suspect @hjohn  is right: the kind of scenarios that would fail with the proposed code is when we have
a) fractional scale and
b) min/max constraints
c) requirement to fill the available space
 
The reason it would fail is that the component width is not invariant in respect of translation due to snapping and fractional scale.  Not only it means that multiple passes are required, but also that each time something gets changed or even moved, the computation needs to be discarded and re-done.  It is essentially the same issue as https://bugs.openjdk.org/browse/JDK-8299753
 
I think John is also right when talking about the common code.  I too, have encountered the problem with the Tree/TableView constrained resize policies (bug mentioned above) as well as with my own table layout implementation
https://github.com/andy-goryachev/FxDock/blob/master/doc/CPane.md
 
Perhaps we could come up with something along the lines John described
 
`double[] distribute(double space, **double[] prefWidth**, double[] minWidths, double[] maxWidths, Snapper snapper);`
 
though I would think the gaps between the components would have to be accounted for - again, due to snapping and fractional scale (or simply passed as components of the minWidths/maxWidths arrays.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1489030962

From kcr at openjdk.org  Wed Mar 29 20:39:51 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Mar 2023 20:39:51 GMT
Subject: [jfx20u] Integrated: 8305108: Change JavaFX release version to 20.0.2
 in jfx20u
In-Reply-To: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>
References: <-NxHCVu6g_Osq7Ya9euzB6ehpmL9M0CJxZOr0apY0ts=.91b897ca-16fa-4bb0-88c2-0413f9af11b9@github.com>
Message-ID: <_4jr7fVPOh1qXrFvHdHI0xCjV_AL3nZwHhF_5Amr-1Y=.41bca17a-39e4-4874-adf5-0577182a5134@github.com>

On Tue, 28 Mar 2023 21:29:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Updates for the beginning of the 20.0.2 release.

This pull request has now been integrated.

Changeset: f16c1211
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx20u/commit/f16c12116439afe8ec4e992270c77207b8944691
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8305108: Change JavaFX release version to 20.0.2 in jfx20u

Reviewed-by: arapte

-------------

PR: https://git.openjdk.org/jfx20u/pull/10

From kevin.rushforth at oracle.com  Wed Mar 29 20:41:33 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 29 Mar 2023 13:41:33 -0700
Subject: jfx20u now open for JavaFX 20.0.2 backports
Message-ID: <e924d263-5c5e-d94c-06c1-2f5c25ea26b4@oracle.com>

All,

The jfx20u repo is now open for JavaFX 20.0.2 backports, with prior 
approval. The general criteria is that we want to backport fixes for 
regressions introduced in JavaFX 20, 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 jfx20u.

To make the process of tracking the request and approval easier, we 
would like to adopt 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 "jfx20u-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.

2. One of the JavaFX projects leads, either Johan Vos or myself, will 
add a "jfx20u-fix-yes" label to approve or "jfx20u-fix-no" label to 
reject the request, along with a comment. In either case, the 
jfx20u-request label is left in place.

3. Once the bug has the "jfx20u-fix-yes" label, you can create the 
backport PR for jfx20u.

Let Johan or me know if you have any questions.

Thanks.

-- Kevin


From jhendrikx at openjdk.org  Wed Mar 29 22:04:09 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 29 Mar 2023 22:04:09 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <hRgVP787FVNV5lVYXkjfweXSwP0jCeDXU4Uung9lB5I=.58ae1e6c-eb5e-4562-873a-335dbbb88f03@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>
 <mQvJOGY4J-Mx68yfaz2f6gapQmadULfdinj58z63vAQ=.e904bfcc-96f1-4dfb-9665-41ee952735d2@github.com>
 <hRgVP787FVNV5lVYXkjfweXSwP0jCeDXU4Uung9lB5I=.58ae1e6c-eb5e-4562-873a-335dbbb88f03@github.com>
Message-ID: <3kdQHK3hMHK9NMq9cBTSf-WnaJ6p0QhoPJ0DVEd3MvI=.05616219-6d4f-44ce-b181-484b28ebd3f9@github.com>

On Wed, 29 Mar 2023 10:20:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed).
>> 
>> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all.
>> We might even want to look into other frameworks like Swing. 
>> Maybe there are people internally at Oracle who can give valuable input here too?
>
>> > @andy-goryachev-oracle raises a good point about perhaps wanting to solve this in a similar way for the various places where we need to do some sort of iterative adjustment (such as here and in the eventual solution for JDK-8299753). It seems also worth looking at what @Maran23 proposes for AnchorPane to fix JDK-8295078 in PR #910 (for which the review still needs to be completed).
>> 
>> Yes, at this point we should probably discuss what would be the best solution to fix the snapping issues once and for all. We might even want to look into other frameworks like Swing. Maybe there are people internally at Oracle who can give valuable input here too?
> 
> I think extracting the common code out of HBox and VBox would be good, as they're basically doing the same thing in a different axis.  The code could then be unit tested directly (ie. given a set of min/max/pref sizes, a target size and a "snapper", calculate optimal sizes).  Something like this:
> 
>      double[] distribute(double space, double[] minWidths, double[] maxWidths, Snapper snapper);
> 
> The minWidths/maxWidths would be min + pref or pref + max depending on the situation, but this function wouldn't care.  The `Snapper` here would be aware of the scale, and would be a dummy implementation that does nothing when snapping is disabled.
> 
> This purposely does not handle spacing between children, as you can calculate that before hand and adjust `space` to the actual space available for children, simplifying the code.
> 
> Disclaimer: I used to create my own layout manager (see: [smartlayout](https://github.com/hjohn/hs.ui.smartlayout/blob/master/src/main/java/hs/smartlayout/LayoutRequirements.java)) that took into account min/max and weight of each child, and even groups of children (a restriction over two or more children at once) -- weight would affect resizing, allowing you to make layouts where children took space according to some ratio (1:2:3 for example).  This functionality I called a `SpaceDistributor` which was purposely given a neutral name as it could be used for both horizontal or vertical calculations.  When including weight, the calculations could get so complex that I had multiple implementations and an exhaustive search implementation (which was used by unit tests to verify the optimized implementations). This was before scaling became an issue though, so this code did not take snapping values to pixels into account.

> Thank you very much @hjohn for your extensive review. Before addressing your comments, I'd like to get some clarification (ideally also from @kevinrushforth), because I am a bit confused by the discussion so far.
> 
> This PR is a very narrow patch that fixes an obvious bug in `HBox` and `VBox`. It's narrow in that it doesn't change the present algorithm, it merely corrects some of its flaws. There is a little bit of refactoring, but that's only done where it helps readers to better understand the algorithm.

Yes, I think it's an improvement in filling the boxes properly (I asked for some clarification as I found the code hard to read, but that's probably how you found it).  My only worry is that it fixes this specific problem, but may be introducing a new issue (I think snapping values multiple times can introduce artifacts in the child sizes, even though they will all align correctly, I think they might be off a bit).  If you can confirm this isn't the case, or if it is, fix those last problems then I think it is a positive change.

I have noticed similar problems on my system where I don't use 100 or 200% scaling, and it would be good to see them fixed.
 
> However, the discussion seems to center around the idea of large-scale refactoring, even across multiple components, including open tickets like [8299753](https://bugs.openjdk.org/browse/JDK-8299753). That's not something I can do as part of this PR, and if large-scale refactoring is the way we choose to go forward, I'd rather not spend more of my time on this particular PR. There needs to be a realistic chance that this PR will be accepted for integration basically as it is.

Those were possible future directions I suppose, not necessarily as part of this PR.  I dislike the code duplication, but it was that way already.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1489314876

From armin.schrenk at skymatic.de  Thu Mar 30 08:20:48 2023
From: armin.schrenk at skymatic.de (Armin Schrenk)
Date: Thu, 30 Mar 2023 10:20:48 +0200
Subject: Loading of shared libraries required by JFX
Message-ID: <7d260f8c-1723-d6ef-bd8f-f9458d0a9319@skymatic.de>

Hey,

is there any update or suggestion? Did you, @Kevin, had time to look 
into it?

If not, just fyi, i replied to my own message by mistake, so for the 
anwser of your questions, read 
https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039324.html.


Kind regards,

Armin


From armin.schrenk at skymatic.de  Thu Mar 30 09:01:52 2023
From: armin.schrenk at skymatic.de (Armin Schrenk)
Date: Thu, 30 Mar 2023 11:01:52 +0200
Subject: Bug using binary stylesheets: Loading relative @font-face paths are
 converted to absolute ones
Message-ID: <3a1a49b8-e467-9c93-9cbd-108e2c24450a@skymatic.de>

Hi,

binary stylesheets is a more hidden feature of javafx, so before filing 
a bug ticket i'm writing to this mailing list.

As said javafx offers working with binary stylesheets. For example, 
normal css files can be converted into binary ones and later those can 
be used instead to reduce the loading time. The conversion can be done 
programatically, or by calling the main method of Css2Bin.java (see 
https://github.com/openjdk/jfx/blob/19.0.2.1%2B1/modules/javafx.graphics/src/main/java/com/sun/javafx/css/parser/Css2Bin.java).

Also, javafx supports loading fonts via the @font-face rule. As 
"src"-tag you specify an url(...), its format is specified in 
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/doc-files/cssref.html#typeurl 
with some examples. From the examples, one can see that relative paths 
are supported.

Combining those two features leads to a bug: Converting a css file with 
relative @font-face paths, the resulting bss file contains absolute 
@font-face paths, which makes the app non-portable when used at compile 
time. I looked into the javafx code, and internally the conversion is a 
two step process by first loading the css file into the javafx model, 
and second writing from the model in a file using the binary format. 
During loading the css file, @font-face paths are resolved to absolute 
ones, and the original path is not retained.

Is this intended behaviour?

Kind regards,

Armin Schrenk


From jhendrikx at openjdk.org  Thu Mar 30 10:04:35 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 10:04:35 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <KqjZbobm6UZBUeAWFmz4n-4KVqNQAgbb51LRV4u_zIY=.8669bf96-7aaa-4ed5-b5f0-254eadf46f59@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <KqjZbobm6UZBUeAWFmz4n-4KVqNQAgbb51LRV4u_zIY=.8669bf96-7aaa-4ed5-b5f0-254eadf46f59@github.com>
Message-ID: <68O1lxFphhi9n2IsPZE3Xl8izA1sLhIrNNA7BTmHeb8=.4ba00ab6-a496-4dc3-acfe-b98470a77a24@github.com>

On Mon, 27 Mar 2023 15:07:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.
>
> This was clearly a mistake back when the public API was first created in JDK 9.

@kevinrushforth I've created the CSR for this.  Can I move it to proposed?

Also, I've been looking into https://bugs.openjdk.org/browse/JDK-8199216 which sees excessive use of `PseudoClassState` instances (and I see this even under more "normal" circumstances as well).  I've got a fix for this issue which involves making use of an immutable variant of `PseudoClassState` (as almost 99% of all the instances are never mutated, but must be copied just in case they are). 

This change would need to go in first though to make this possible.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1070#issuecomment-1490030627

From mhanl at openjdk.org  Thu Mar 30 10:29:31 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Mar 2023 10:29:31 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
Message-ID: <C_3tQ_hrktNyHV931NUvDaEVmsY8_u9E_A3DluDbA8E=.839b0c45-78a4-4604-b173-9be9b4a2dd02@github.com>

On Wed, 29 Mar 2023 12:15:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

Looks good to me too and makes sense.
This also aligns well with the `listenerHelper`, which is also created when needed.

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1075#pullrequestreview-1364806283

From mhanl at openjdk.org  Thu Mar 30 10:48:32 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Mar 2023 10:48:32 GMT
Subject: RFR: 8283063: Optimize
 Observable{List/Set/Map}Wrapper.retainAll/removeAll
In-Reply-To: <-aiwH9PDbedjpWb7bH4HslseE9dcMsYURM9exz-aKUQ=.ad96630a-350a-4a1a-8d6e-612a501a0032@github.com>
References: <dGAUl9aLiCB6LBoTicQG7_kcFPwDOnfmPWjzDyF6VsQ=.6c5784d8-8f93-43ef-88ac-4a1f8efcaf6c@github.com>
 <-aiwH9PDbedjpWb7bH4HslseE9dcMsYURM9exz-aKUQ=.ad96630a-350a-4a1a-8d6e-612a501a0032@github.com>
Message-ID: <S8tRCCmemDLOp-dzP92oyZXl3XUBcFE2xamQ3wSZkUQ=.a7fb8f7b-bbd1-4417-9f9a-d460bb85d982@github.com>

On Sun, 3 Jul 2022 23:25:09 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> `Observable{List/Set/Map}Wrapper.retainAll/removeAll` can be optimized for some edge cases.
>> 
>> 1. `removeAll(c)`:
>> This is a no-op if 'c' is empty.
>> For `ObservableListWrapper`, returning early skips an object allocation. For `ObservableSetWrapper` and `ObservableMapWrapper`, returning early prevents an enumeration of the entire collection.
>> 
>> 2. `retainAll(c)`:
>> This is a no-op if the backing collection is empty, or equivalent to `clear()` if `c` is empty.
>> 
>> I've added some tests to verify the optimized behavior for each of the three classes.
>
> modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableSetWrapper.java line 359:
> 
>> 357: 
>> 358:             return false;
>> 359:         }
> 
> This is good, but if `!c.isEmpty()` then we can optimize too, I think: if `backingSet.isEmpty()`, then removing/retaining all will also return `false`. Then again, the iterator will return quickly, so it might not do much.
> 
> If you take this path, I think that doing these optimizations in the `removeAll` and `retainAll` before calling this method will be clearer, similarly to how it's done in the `List` case.
> 
> Same comment for the `Map` wrapper.

`+ 1` for this. Otherwise the changes look good to me.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/751#discussion_r1153074947

From jhendrikx at openjdk.org  Thu Mar 30 13:14:00 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 13:14:00 GMT
Subject: RFR: 8283063: Optimize
 Observable{List/Set/Map}Wrapper.retainAll/removeAll
In-Reply-To: <dGAUl9aLiCB6LBoTicQG7_kcFPwDOnfmPWjzDyF6VsQ=.6c5784d8-8f93-43ef-88ac-4a1f8efcaf6c@github.com>
References: <dGAUl9aLiCB6LBoTicQG7_kcFPwDOnfmPWjzDyF6VsQ=.6c5784d8-8f93-43ef-88ac-4a1f8efcaf6c@github.com>
Message-ID: <_ixCsWPttlgmKoW--42gWJo0lEKTnMAcXqUt2KL19ik=.8a2a17cc-db25-4e38-a549-283a8d8dc4f8@github.com>

On Sat, 12 Mar 2022 04:57:37 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> `Observable{List/Set/Map}Wrapper.retainAll/removeAll` can be optimized for some edge cases.
> 
> 1. `removeAll(c)`:
> This is a no-op if 'c' is empty.
> For `ObservableListWrapper`, returning early skips an object allocation. For `ObservableSetWrapper` and `ObservableMapWrapper`, returning early prevents an enumeration of the entire collection.
> 
> 2. `retainAll(c)`:
> This is a no-op if the backing collection is empty, or equivalent to `clear()` if `c` is empty.
> 
> I've added some tests to verify the optimized behavior for each of the three classes.

Changes requested by jhendrikx (Committer).

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 172:

> 170:     @Override
> 171:     public boolean removeAll(Collection<?> c) {
> 172:         if (backingList.isEmpty() || c.isEmpty()) {

I think you should do an explicit `null` check here on `c` or swap the order of these arguments so it always throws an NPE here if `c` is `null` as per collection contract.  If you don't, it will do this implicit `null` check just after `beginChange`, and as I don't see a `try/finally` there to call `endChange`, it would mean the wrapper / changeListBuilder gets in a bad state.

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableListWrapper.java line 195:

> 193:     @Override
> 194:     public boolean retainAll(Collection<?> c) {
> 195:         if (backingList.isEmpty()) {

I think we need to check `c` for `null` here first to conform to the collection contract.

modules/javafx.base/src/main/java/com/sun/javafx/collections/ObservableMapWrapper.java line 328:

> 326: 
> 327:         private boolean removeRetain(Collection<?> c, boolean remove) {
> 328:             if (c.isEmpty()) {

There is an implicit `null` check here, but it makes `removeAll` and `retainAll` conform to the collection contract at least.

If you want to make this explicit (or document it), then this comment should be applied to all the `removeRetain` methods.

-------------

PR Review: https://git.openjdk.org/jfx/pull/751#pullrequestreview-1365073384
PR Review Comment: https://git.openjdk.org/jfx/pull/751#discussion_r1153233153
PR Review Comment: https://git.openjdk.org/jfx/pull/751#discussion_r1153235221
PR Review Comment: https://git.openjdk.org/jfx/pull/751#discussion_r1153239642

From john at status6.com  Thu Mar 30 13:58:09 2023
From: john at status6.com (John Neffenger)
Date: Thu, 30 Mar 2023 06:58:09 -0700
Subject: Bug using binary stylesheets: Loading relative @font-face paths
 are converted to absolute ones
In-Reply-To: <3a1a49b8-e467-9c93-9cbd-108e2c24450a@skymatic.de>
References: <3a1a49b8-e467-9c93-9cbd-108e2c24450a@skymatic.de>
Message-ID: <a1478883-cb81-b2a2-1a87-c72fe9e70a1c@status6.com>

On 3/30/23 2:01 AM, Armin Schrenk wrote:
> Is this intended behaviour?

I'm guessing it's a bug. The class you mention, Css2Bin, also stores the 
absolute path of its .css input file in the corresponding .bss output 
file, which is then included in the JavaFX Controls module. That causes 
the build path to be included, blocking reproducible builds.

See #4 of the Fixes listed in the first comment here:

https://github.com/openjdk/jfx/pull/446

I plan to open a bug report and fix that particular issue after Pull 
Request #446 is integrated. The fix would have to remove any 
self-generated absolute paths for the included fonts as well.

John


From jhendrikx at openjdk.org  Thu Mar 30 17:19:24 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 17:19:24 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with nested
 nodes (hbox) and pseudo-class in style sheet
Message-ID: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>

This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.

In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.

Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.

The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`).

The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.

A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.

Although the test case above was extreme, this change should have positive effects for most applications.

-------------

Commit messages:
 - Remove double call to getIndex
 - Fix null test case
 - Fix null addAll call
 - Introduce immutable variant of PseudoClassState, using it where possible
 - Fix several major bugs in BitSet to make it usable as a generic set
 - Remove references to PseudoClassState (private) in Match (public API)

Changes: https://git.openjdk.org/jfx/pull/1076/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8199216
  Stats: 299 lines in 11 files changed: 187 ins; 47 del; 65 mod
  Patch: https://git.openjdk.org/jfx/pull/1076.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076

PR: https://git.openjdk.org/jfx/pull/1076

From mhanl at openjdk.org  Thu Mar 30 17:19:26 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Mar 2023 17:19:26 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet
In-Reply-To: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
Message-ID: <78YbvSedNzcdRK_s3afIGxeEApPD3d7YZUKoJ4xzmxI=.75ba1856-3501-40c7-b2c1-1cc14be588bd@github.com>

On Thu, 30 Mar 2023 12:49:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
> 
> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
> 
> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
> 
> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`).
> 
> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
> 
> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
> 
> Although the test case above was extreme, this change should have positive effects for most applications.

One more optimization we could have a look at is too create the `BitSet` or related subclasses with a predefined size, so we don't need to grow the `long[] bits` array too often. `PseudoClassState` already has a constructor that accepts another collection, but can not use this information to create a bigger `bits` array.
(Like e.g. the `ArrayList` or `HashSet` constructor)

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 227:

> 225:         final T t = cast(o);
> 226: 
> 227:         if (t == null) {  // if cast failed, it can't be part of this set

If I understand the code correctly, this can't happen right now, right?

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 231:

> 229:         }
> 230: 
> 231:         final int element = getIndex(t) / Long.SIZE;

`getIndex(t)` is called twice here and below, maybe we should consider calling it once and save the result in a local variable instead?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1490264725
PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153276734
PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153274025

From jhendrikx at openjdk.org  Thu Mar 30 17:19:28 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 17:19:28 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet
In-Reply-To: <78YbvSedNzcdRK_s3afIGxeEApPD3d7YZUKoJ4xzmxI=.75ba1856-3501-40c7-b2c1-1cc14be588bd@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <78YbvSedNzcdRK_s3afIGxeEApPD3d7YZUKoJ4xzmxI=.75ba1856-3501-40c7-b2c1-1cc14be588bd@github.com>
Message-ID: <3DtfHxygvgzZxVgcD0DGT1rtSFhtjxR5T7ndToORxFE=.0c80c4cc-0078-4f87-a8b0-72bcbfa02978@github.com>

On Thu, 30 Mar 2023 13:01:09 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> One more optimization we could have a look at is too create the `BitSet` or related subclasses with a predefined size, so we don't need to grow the `long[] bits` array too often. `PseudoClassState` already has a constructor that accepts another collection, but can not use this information to create a bigger `bits` array. (Like e.g. the `ArrayList` or `HashSet` constructor)

I only looked at `PseudoClassState`, and it will rarely exceed the 64 bits that are available, although users can of course create as many pseudo classes as they want -- I wouldn't recommend this though with how the CSS caching logic is currently implemented.  A new key is created for every combination of pseudo classes encountered per depth level in a live scenegraph (but only for classes that can affect styling).

The low amount of pseudo classes is also why I didn't bother creating an immutable variant which maps them to bits.  This is IMHO an optimization that was done because of the mutable nature of `PseudoClassState` (resulting in many many copies), but which is mostly irrelevant now that most of them are immutable.

Perhaps this is useful for the other subclass `StyleClassSet`, but I have my doubts it is currently a pressing performance issue.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 227:
> 
>> 225:         final T t = cast(o);
>> 226: 
>> 227:         if (t == null) {  // if cast failed, it can't be part of this set
> 
> If I understand the code correctly, this can't happen right now, right?

`BitSet` did not conform to the collection contract here.  It can happen in current JavaFX releases by calling a method that returns `Set<PseudoClass>` and asking it `contains("text")` -- as `String` cannot be cast to `PseudoClass`, this will result in a `ClassCastException` while it should just return `false`.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1490316678
PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153280950

From zjx001202 at gmail.com  Thu Mar 30 17:34:25 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 31 Mar 2023 01:34:25 +0800
Subject: Allow OpenJFX to be built on unknown architectures
In-Reply-To: <CAJL5A3kinX_CxY5_Ev1W80+Dx-8QVF7ApKYsMPbVp-KGTO7xsw@mail.gmail.com>
References: <CAJL5A3kinX_CxY5_Ev1W80+Dx-8QVF7ApKYsMPbVp-KGTO7xsw@mail.gmail.com>
Message-ID: <CAJL5A3ni+NxvGRqWmsEMZ5K1jkcqu3oAFAO3EqmgHc6E0z9SdQ@mail.gmail.com>

Did I successfully send this email to the mailing list?

On Wed, Mar 29, 2023 at 10:18?PM Glavo <zjx001202 at gmail.com> wrote:

> Hi everyone,
>
> Currently OpenJFX's build script asserts the CPU architecture and does not
> allow building on unknown architectures.
> But in fact OpenJFX is cross-platform, it can actually be built and run on
> almost all architectures.
> The only hurdle was the asserts in the build scripts, and John made it
> compile on the s390x and ppc64el platforms with a simple patch[1].
>
> I'm working on some niche architectures (such as MIPS64el and RISC-V) and
> I need to compile OpenJFX for them.
> I understand the need to warn users that there may be unknown issues
> building on these architectures,
> and I don't have time to do regular testing to ensure that OpenJFX works
> on these architectures.
> But I wish it was simpler to build OpenJFX on these architectures.
> So can we add a gradle property to have the build script skip the
> assertion on the architecture,
> thus allowing us to build OpenJFX on unknown architectures without
> modifying any files?
>
> Glavo
>
> [1]:
> https://github.com/jgneff/openjfx/blob/candidate/snap/local/allow-armhf-i386-ppc64el-s390x.patch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230331/4d4c3272/attachment-0001.htm>

From kevin.rushforth at oracle.com  Thu Mar 30 17:44:26 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Mar 2023 10:44:26 -0700
Subject: Allow OpenJFX to be built on unknown architectures
In-Reply-To: <CAJL5A3ni+NxvGRqWmsEMZ5K1jkcqu3oAFAO3EqmgHc6E0z9SdQ@mail.gmail.com>
References: <CAJL5A3kinX_CxY5_Ev1W80+Dx-8QVF7ApKYsMPbVp-KGTO7xsw@mail.gmail.com>
 <CAJL5A3ni+NxvGRqWmsEMZ5K1jkcqu3oAFAO3EqmgHc6E0z9SdQ@mail.gmail.com>
Message-ID: <d5b76cae-043b-f61e-8841-78adb5763e2d@oracle.com>

No, I didn't see this. Yes, this seems a reasonable request.

-- Kevin


On 3/30/2023 10:34 AM, Glavo wrote:
> Did I successfully send this email to the mailing list?
>
> On Wed, Mar 29, 2023 at 10:18?PM Glavo <zjx001202 at gmail.com> wrote:
>
>     Hi everyone,
>
>     Currently OpenJFX's build script asserts the CPU architecture and
>     does not allow building on unknown architectures.
>     But in fact OpenJFX is cross-platform, it can actually be built
>     and run on almost all architectures.
>     The only hurdle was the asserts in the build scripts, and John
>     made it compile on the s390x and ppc64el platforms with a simple
>     patch[1].
>
>     I'm working on some niche architectures (such as MIPS64el and
>     RISC-V) and I need to compile OpenJFX for them.
>     I understand the need to warn users that there may be unknown
>     issues building on these architectures,
>     and I don't have time to do regular testing to ensure that OpenJFX
>     works on these architectures.
>     But I wish it was simpler to build OpenJFX on these architectures.
>     So can we add a gradle property to have the build script skip the
>     assertion on the architecture,
>     thus allowing us to build OpenJFX on unknown architectures without
>     modifying any files?
>
>     Glavo
>
>     [1]:
>     https://github.com/jgneff/openjfx/blob/candidate/snap/local/allow-armhf-i386-ppc64el-s390x.patch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230330/955b9d82/attachment.htm>

From john at status6.com  Thu Mar 30 17:59:14 2023
From: john at status6.com (John Neffenger)
Date: Thu, 30 Mar 2023 10:59:14 -0700
Subject: Allow OpenJFX to be built on unknown architectures
In-Reply-To: <d5b76cae-043b-f61e-8841-78adb5763e2d@oracle.com>
References: <CAJL5A3kinX_CxY5_Ev1W80+Dx-8QVF7ApKYsMPbVp-KGTO7xsw@mail.gmail.com>
 <CAJL5A3ni+NxvGRqWmsEMZ5K1jkcqu3oAFAO3EqmgHc6E0z9SdQ@mail.gmail.com>
 <d5b76cae-043b-f61e-8841-78adb5763e2d@oracle.com>
Message-ID: <b631e3fc-bb66-79b6-85fb-3dc3316d52dd@status6.com>

On 3/30/23 10:44 AM, Kevin Rushforth wrote:
> No, I didn't see this. Yes, this seems a reasonable request.

Actually, I was going to submit a pull request to get my patch for this 
change integrated (after the reproducible builds PR is merged). I've 
tested JavaFX on all six architectures for Linux: amd64, arm64, armhf, 
i386, ppc64el, and even s390x! It works on all platforms except for the 
software rendering on an IBM mainframe (s390x), but even that could be 
fixed someday. The bug is due to the mainframe being big-endian instead 
of little-endian.

My tests of Java and JavaFX on all Linux architectures are posted here:

Status
https://github.com/jgneff/openjdk/discussions/11

The Java bug on an s390x virtual machine should be fixed by now, too, 
but I haven't yet had a chance to test the QEMU fix.

John

> On 3/30/2023 10:34 AM, Glavo wrote:
>> Did I successfully send this email to the mailing list?
>>
>> On Wed, Mar 29, 2023 at 10:18?PM Glavo <zjx001202 at gmail.com> wrote:
>>
>>     Hi everyone,
>>
>>     Currently OpenJFX's build script asserts the CPU architecture and
>>     does not allow building on unknown architectures.
>>     But in fact OpenJFX is cross-platform, it can actually be built
>>     and run on almost all architectures.
>>     The only hurdle was the asserts in the build scripts, and John
>>     made it compile on the s390x and ppc64el platforms with a simple
>>     patch[1].
>>
>>     I'm working on some niche architectures (such as MIPS64el and
>>     RISC-V) and I need to compile OpenJFX for them.
>>     I understand the need to warn users that there may be unknown
>>     issues building on these architectures,
>>     and I don't have time to do regular testing to ensure that OpenJFX
>>     works on these architectures.
>>     But I wish it was simpler to build OpenJFX on these architectures.
>>     So can we add a gradle property to have the build script skip the
>>     assertion on the architecture,
>>     thus allowing us to build OpenJFX on unknown architectures without
>>     modifying any files?
>>
>>     Glavo
>>
>>     [1]:
>>     https://github.com/jgneff/openjfx/blob/candidate/snap/local/allow-armhf-i386-ppc64el-s390x.patch
>>
> 


From zjx001202 at gmail.com  Thu Mar 30 18:17:26 2023
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 31 Mar 2023 02:17:26 +0800
Subject: Allow OpenJFX to be built on unknown architectures
In-Reply-To: <b631e3fc-bb66-79b6-85fb-3dc3316d52dd@status6.com>
References: <CAJL5A3kinX_CxY5_Ev1W80+Dx-8QVF7ApKYsMPbVp-KGTO7xsw@mail.gmail.com>
 <CAJL5A3ni+NxvGRqWmsEMZ5K1jkcqu3oAFAO3EqmgHc6E0z9SdQ@mail.gmail.com>
 <d5b76cae-043b-f61e-8841-78adb5763e2d@oracle.com>
 <b631e3fc-bb66-79b6-85fb-3dc3316d52dd@status6.com>
Message-ID: <CAJL5A3nR+1zv609uGM_8YW37GXtZAdHBLMiCRgcq0hYr7Geo7w@mail.gmail.com>

Thank you for your contribution!

I compiled OpenJFX for RISC-V and MIPS64el platforms with reference to your
patch, thereby porting our JavaFX applications to these platforms, and it
worked well.

Glavo

On Fri, Mar 31, 2023 at 1:59?AM John Neffenger <john at status6.com> wrote:

> On 3/30/23 10:44 AM, Kevin Rushforth wrote:
> > No, I didn't see this. Yes, this seems a reasonable request.
>
> Actually, I was going to submit a pull request to get my patch for this
> change integrated (after the reproducible builds PR is merged). I've
> tested JavaFX on all six architectures for Linux: amd64, arm64, armhf,
> i386, ppc64el, and even s390x! It works on all platforms except for the
> software rendering on an IBM mainframe (s390x), but even that could be
> fixed someday. The bug is due to the mainframe being big-endian instead
> of little-endian.
>
> My tests of Java and JavaFX on all Linux architectures are posted here:
>
> Status
> https://github.com/jgneff/openjdk/discussions/11
>
> The Java bug on an s390x virtual machine should be fixed by now, too,
> but I haven't yet had a chance to test the QEMU fix.
>
> John
>
> > On 3/30/2023 10:34 AM, Glavo wrote:
> >> Did I successfully send this email to the mailing list?
> >>
> >> On Wed, Mar 29, 2023 at 10:18?PM Glavo <zjx001202 at gmail.com> wrote:
> >>
> >>     Hi everyone,
> >>
> >>     Currently OpenJFX's build script asserts the CPU architecture and
> >>     does not allow building on unknown architectures.
> >>     But in fact OpenJFX is cross-platform, it can actually be built
> >>     and run on almost all architectures.
> >>     The only hurdle was the asserts in the build scripts, and John
> >>     made it compile on the s390x and ppc64el platforms with a simple
> >>     patch[1].
> >>
> >>     I'm working on some niche architectures (such as MIPS64el and
> >>     RISC-V) and I need to compile OpenJFX for them.
> >>     I understand the need to warn users that there may be unknown
> >>     issues building on these architectures,
> >>     and I don't have time to do regular testing to ensure that OpenJFX
> >>     works on these architectures.
> >>     But I wish it was simpler to build OpenJFX on these architectures.
> >>     So can we add a gradle property to have the build script skip the
> >>     assertion on the architecture,
> >>     thus allowing us to build OpenJFX on unknown architectures without
> >>     modifying any files?
> >>
> >>     Glavo
> >>
> >>     [1]:
> >>
> https://github.com/jgneff/openjfx/blob/candidate/snap/local/allow-armhf-i386-ppc64el-s390x.patch
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230331/e3075f27/attachment-0001.htm>

From mstrauss at openjdk.org  Thu Mar 30 19:41:31 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 30 Mar 2023 19:41:31 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet
In-Reply-To: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
Message-ID: <gZuJvXvOzVA4GUjV1vAaO_7TBjZzrJedUddtR7pWvDA=.926aee0f-cecd-41c9-a2ac-6cf6f7f7cab8@github.com>

On Thu, 30 Mar 2023 12:49:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
> 
> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
> 
> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
> 
> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`).
> 
> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
> 
> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
> 
> Although the test case above was extreme, this change should have positive effects for most applications.

modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 55:

> 53:          *
> 54:          * If the given set was already immutable; the copyOf will return the same
> 55:          * set; however, that may or may not be the set that is already in the cache.

Do we want to depend on this behavior? The specification of `Set.copyOf` says:

@implNote
If the given Collection is an unmodifiable Set, calling copyOf will generally not create a copy.


While the actual implementation _never_ creates a copy if the given collection is immutable, the specification does not guarantee that in all cases, but only in the general case. This behavior could theoretically change without changing the specification of `Set.copyOf`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153711165

From mstrauss at openjdk.org  Thu Mar 30 19:46:29 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 30 Mar 2023 19:46:29 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
Message-ID: <bfeYz_HJOrMvcvUmD8nbJNfdT3GGkSseZvmkdvWwB3w=.6a67eec2-8fde-4466-8bde-927902e3c415@github.com>

On Wed, 29 Mar 2023 12:15:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

Looks good to me.

-------------

Marked as reviewed by mstrauss (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1075#pullrequestreview-1365815852

From mhanl at openjdk.org  Thu Mar 30 20:04:17 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Mar 2023 20:04:17 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
Message-ID: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>

The determined `prefWidth` of a `TableCell` could be `0.0` when a `fixedCellSize` is set.
This happened because the `TableCell` may not have a skin since it was never added to the scene graph yet.

The fix is to make sure we get the `prefWidth` after the `TableCell` was added to the scene graph.
That is also the reason why the problem only happened the first time and never again after (skin is then already created).

-------------

Commit messages:
 - JDK-8305248: TableView not rendered correctly after column is made visible if fixed cell size is set

Changes: https://git.openjdk.org/jfx/pull/1077/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1077&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305248
  Stats: 52 lines in 2 files changed: 48 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1077.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1077/head:pull/1077

PR: https://git.openjdk.org/jfx/pull/1077

From kcr at openjdk.org  Thu Mar 30 20:13:25 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 20:13:25 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
In-Reply-To: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
References: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
Message-ID: <TwFVLvH73iqcNBFSnAygS27t9hwHdIVM7xFzjLtORa8=.3475b832-bfd9-43de-9982-6cccbf62e9ad@github.com>

On Thu, 30 Mar 2023 19:58:31 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> The determined `prefWidth` of a `TableCell` could be `0.0` when a `fixedCellSize` is set.
> This happened because the `TableCell` may not have a skin since it was never added to the scene graph yet.
> 
> The fix is to make sure we get the `prefWidth` after the `TableCell` was added to the scene graph.
> That is also the reason why the problem only happened the first time and never again after (skin is then already created).

@andy-goryachev-oracle can you also review this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1077#issuecomment-1490886686

From jhendrikx at openjdk.org  Thu Mar 30 20:26:32 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 20:26:32 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet
In-Reply-To: <gZuJvXvOzVA4GUjV1vAaO_7TBjZzrJedUddtR7pWvDA=.926aee0f-cecd-41c9-a2ac-6cf6f7f7cab8@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <gZuJvXvOzVA4GUjV1vAaO_7TBjZzrJedUddtR7pWvDA=.926aee0f-cecd-41c9-a2ac-6cf6f7f7cab8@github.com>
Message-ID: <RKtdH7x8Hz6za5AuALr0W6sipDxDJdR2J_wciUaMPrs=.63d1b491-bce8-4f68-9d03-88e0e303a527@github.com>

On Thu, 30 Mar 2023 19:38:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Do we want to depend on this behavior? The specification of `Set.copyOf` says:
> 
> ```
> @implNote
> If the given Collection is an unmodifiable Set, calling copyOf will generally not create a copy.
> ```
> 
> While the actual implementation _never_ creates a copy if the given collection is immutable, the specification does not guarantee that in all cases, but only in the general case. This behavior could theoretically change without changing the specification of `Set.copyOf`.

If it ever changes implementation, I suppose we could do this logic ourselves -- however, you did give me an idea... before making the copy, I could check if it is in the cache already.  In the case that the set you pass is mutable, but I have an immutable copy already then no copy would need to be made.  The only time a copy is made then is if it wasn't in the cache yet.

Before arriving at this solution I had a class `ImmutablePseudoClassState` which extended `AbstractSet`.  But after stripping everything out that I didn't need, the only thing that was left was a single private field... which was also a `Set`.  I then concluded that there is no need for this wrapper at all, as everything in the CSS code can deal with `Set<PseudoClass>` directly.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153751462

From jhendrikx at openjdk.org  Thu Mar 30 20:34:13 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 20:34:13 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
Message-ID: <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>

> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
> 
> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
> 
> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
> 
> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`).
> 
> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
> 
> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
> 
> Although the test case above was extreme, this change should have positive effects for most applications.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1076/files
  - new: https://git.openjdk.org/jfx/pull/1076/files/87e6f63e..e9300e9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=00-01

  Stats: 18 lines in 1 file changed: 2 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1076.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076

PR: https://git.openjdk.org/jfx/pull/1076

From jhendrikx at openjdk.org  Thu Mar 30 20:37:32 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 20:37:32 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <78YbvSedNzcdRK_s3afIGxeEApPD3d7YZUKoJ4xzmxI=.75ba1856-3501-40c7-b2c1-1cc14be588bd@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <78YbvSedNzcdRK_s3afIGxeEApPD3d7YZUKoJ4xzmxI=.75ba1856-3501-40c7-b2c1-1cc14be588bd@github.com>
Message-ID: <257qbIeTapvBokKlPvFxil7TKSpGagCMyWDPWXP0oyM=.ab70f322-8e3b-455c-9e81-897bcce47eda@github.com>

On Thu, 30 Mar 2023 13:34:41 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 231:
> 
>> 229:         }
>> 230: 
>> 231:         final int element = getIndex(t) / Long.SIZE;
> 
> `getIndex(t)` is called twice here and below, maybe we should consider calling it once and save the result in a local variable instead?

I fixed this.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153760022

From angorya at openjdk.org  Thu Mar 30 21:10:35 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Mar 2023 21:10:35 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
In-Reply-To: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
References: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
Message-ID: <GbY-QuGIypZAo9sSQebi3xiNP9oJjn0BqXlJZ4KdHMQ=.8df46eef-85fc-48ac-8151-52a09f385a80@github.com>

On Thu, 30 Mar 2023 19:58:31 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> The determined `prefWidth` of a `TableCell` could be `0.0` when a `fixedCellSize` is set.
> This happened because the `TableCell` may not have a skin since it was never added to the scene graph yet.
> 
> The fix is to make sure we get the `prefWidth` after the `TableCell` was added to the scene graph.
> That is also the reason why the problem only happened the first time and never again after (skin is then already created).

thank you for a quick turnaround!
tested with the MonkeyTester with and without fixed cell height, different models, different resize policies.

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/monkey/MonkeyTesterApp.java

if you want to make one change (assuming if it's safe to do so), i'll re-approve.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 358:

> 356:                 // Note: We have to determine the pref width here because the add operation above may trigger the skin
> 357:                 // creation first, which is what makes it possible to get a correct value here in the first place.
> 358:                 width = tableCell.prefWidth(height);

I wonder if it's safe to move this call (one one after else:430) before the if statement on line 352?

-------------

Marked as reviewed by angorya (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1077#pullrequestreview-1365923242
PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1153783393

From jhendrikx at openjdk.org  Thu Mar 30 22:00:13 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 22:00:13 GMT
Subject: RFR: JDK-8224260: ChangeListener not triggered when adding a new
 listener in invalidated method
Message-ID: <L-WJC6_FNeTEJ3lWC9IRuX3dQAzkT7xs5kTH_wDFFHI=.5f08753a-73a6-46e2-9e64-b52d2d0bf2f2@github.com>

Fixes three issues in ExpressionHelper:

- Current Value was not retained when changing from SingleChange to Generic, this can lead to missed changes
- Current Value was not retained when changing from Generic to SingleChange, this can lead to missed changes
- Current Value was not cleared when last change listener was removed in Generic variant, resulting in an older value being referenced and not becoming eligible for GC until either a ChangeListener is added again, or sufficient InvalidationListeners are removed to switch to the SingleInvalidation implementation...

-------------

Commit messages:
 - Fix current value handling in ExpressionHelper

Changes: https://git.openjdk.org/jfx/pull/1078/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1078&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8224260
  Stats: 114 lines in 2 files changed: 90 ins; 10 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/1078.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1078/head:pull/1078

PR: https://git.openjdk.org/jfx/pull/1078

From mhanl at openjdk.org  Thu Mar 30 22:09:30 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Mar 2023 22:09:30 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
In-Reply-To: <GbY-QuGIypZAo9sSQebi3xiNP9oJjn0BqXlJZ4KdHMQ=.8df46eef-85fc-48ac-8151-52a09f385a80@github.com>
References: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
 <GbY-QuGIypZAo9sSQebi3xiNP9oJjn0BqXlJZ4KdHMQ=.8df46eef-85fc-48ac-8151-52a09f385a80@github.com>
Message-ID: <jzOid4H3K51E5h1bsxcKbm9W9H2oFIo5Vc1iMiWR7BI=.913fd49d-6eb2-429d-927c-8635d41c7c3c@github.com>

On Thu, 30 Mar 2023 21:01:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The determined `prefWidth` of a `TableCell` could be `0.0` when a `fixedCellSize` is set.
>> This happened because the `TableCell` may not have a skin since it was never added to the scene graph yet.
>> 
>> The fix is to make sure we get the `prefWidth` after the `TableCell` was added to the scene graph.
>> That is also the reason why the problem only happened the first time and never again after (skin is then already created).
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 358:
> 
>> 356:                 // Note: We have to determine the pref width here because the add operation above may trigger the skin
>> 357:                 // creation first, which is what makes it possible to get a correct value here in the first place.
>> 358:                 width = tableCell.prefWidth(height);
> 
> I wonder if it's safe to move this call (one one after else:430) before the if statement on line 352?

I'm not sure if I understand correctly: You mean call `tableCell.prefWidth(height)` above?
I chose this way so we always call `tableCell.prefWidth(height)` just once, never twice.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1153835648

From angorya at openjdk.org  Thu Mar 30 22:16:23 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 30 Mar 2023 22:16:23 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
In-Reply-To: <jzOid4H3K51E5h1bsxcKbm9W9H2oFIo5Vc1iMiWR7BI=.913fd49d-6eb2-429d-927c-8635d41c7c3c@github.com>
References: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
 <GbY-QuGIypZAo9sSQebi3xiNP9oJjn0BqXlJZ4KdHMQ=.8df46eef-85fc-48ac-8151-52a09f385a80@github.com>
 <jzOid4H3K51E5h1bsxcKbm9W9H2oFIo5Vc1iMiWR7BI=.913fd49d-6eb2-429d-927c-8635d41c7c3c@github.com>
Message-ID: <hM3QbUleqEhG2MBO-opq1ojNnMLxGYkqCX1Ut8qBCNI=.be68a9a6-d71a-4116-adc5-e3be81b3fcb0@github.com>

On Thu, 30 Mar 2023 22:06:59 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 358:
>> 
>>> 356:                 // Note: We have to determine the pref width here because the add operation above may trigger the skin
>>> 357:                 // creation first, which is what makes it possible to get a correct value here in the first place.
>>> 358:                 width = tableCell.prefWidth(height);
>> 
>> I wonder if it's safe to move this call (one one after else:430) before the if statement on line 352?
>
> I'm not sure if I understand correctly: You mean call `tableCell.prefWidth(height)` above?
> I chose this way so we always call `tableCell.prefWidth(height)` just once, never twice.

actually, please disregard my suggestion:  the first `width = tableCell.prefWidth(height);` happens after adding the `tableCell` to a parent, so it is likely would not be an equivalent change.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1153839950

From kevin.rushforth at oracle.com  Thu Mar 30 22:18:48 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 30 Mar 2023 15:18:48 -0700
Subject: Loading of shared libraries required by JFX
In-Reply-To: <7d260f8c-1723-d6ef-bd8f-f9458d0a9319@skymatic.de>
References: <7d260f8c-1723-d6ef-bd8f-f9458d0a9319@skymatic.de>
Message-ID: <195498db-1f87-e60d-212f-ce4f62b95a44@oracle.com>

I haven't had time to look into it in detail. A quick look suggests that 
the problem lies in the way the Zulu JDK+FX was built. The libraries 
should be in bin/javafx after the fix for 
https://bugs.openjdk.org/browse/JDK-8281089 and, as you pointed out, 
they aren't there, but are one directory higher, under bin (which is 
where they were before that fix).

I have downloaded JDK 20 and JavaFX 20 from jdk.java.net, used jlink to 
build a custom JDK with the JavaFX modules, and the JavaFX DLLs are 
correctly placed in the bin/javafx dir.

-- Kevin


On 3/30/2023 1:20 AM, Armin Schrenk wrote:
> Hey,
>
> is there any update or suggestion? Did you, @Kevin, had time to look 
> into it?
>
> If not, just fyi, i replied to my own message by mistake, so for the 
> anwser of your questions, read 
> https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039324.html.
>
>
> Kind regards,
>
> Armin
>


From mariushanl at web.de  Thu Mar 30 22:19:30 2023
From: mariushanl at web.de (Marius Hanl)
Date: Fri, 31 Mar 2023 00:19:30 +0200
Subject: Aw: Gauging interest in bindings that can delay changing their
 value (debounce/throttle)
In-Reply-To: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>
References: <f3c0dbed-0089-d2cc-2421-ffd77c6f6064@gmail.com>
Message-ID: <trinity-3f77e3cf-afa4-4c84-bf34-5410664659f6-1680214770794@3c-app-webde-bap33>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20230331/8756cb7d/attachment.htm>

From kcr at openjdk.org  Thu Mar 30 22:23:26 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 22:23:26 GMT
Subject: RFR: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
Message-ID: <4XaagWAY-SPL1-fV5mxk6IKJe3IrCJaRi66ME0u9qnI=.a2cd69bc-352f-4963-84eb-cf94eb323d3c@github.com>

On Wed, 29 Mar 2023 12:15:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1075#pullrequestreview-1366014448

From kcr at openjdk.org  Thu Mar 30 22:28:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 22:28:30 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <KqjZbobm6UZBUeAWFmz4n-4KVqNQAgbb51LRV4u_zIY=.8669bf96-7aaa-4ed5-b5f0-254eadf46f59@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <KqjZbobm6UZBUeAWFmz4n-4KVqNQAgbb51LRV4u_zIY=.8669bf96-7aaa-4ed5-b5f0-254eadf46f59@github.com>
Message-ID: <VHwudKd4yC3WlXev1E_dGRASJiJ0uKg2rBdeL8eLdvM=.abb0cd19-4703-4b98-8fc5-c09d03130e8b@github.com>

On Mon, 27 Mar 2023 15:07:52 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.
>
> This was clearly a mistake back when the public API was first created in JDK 9.

> @kevinrushforth I've created the CSR for this. Can I move it to proposed?

I took a quick look, and it is fine to move to Proposed.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1070#issuecomment-1491046397

From kcr at openjdk.org  Thu Mar 30 22:29:25 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 22:29:25 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
Message-ID: <gStsaplye-vzIzR2rLjInF5hOLlbdqrwyhuO75YCrzk=.e48741c0-0fe7-4905-b583-0085254db61d@github.com>

On Thu, 30 Mar 2023 20:34:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
>> 
>> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
>> 
>> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
>> 
>> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well.
>> 
>> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
>> 
>> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
>> 
>> Although the test case above was extreme, this change should have positive effects for most applications.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy

I'd like to see an extra pair of eyes on this one.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1491047339

From mhanl at openjdk.org  Thu Mar 30 22:30:24 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 30 Mar 2023 22:30:24 GMT
Subject: RFR: 8223373: Remove IntelliJ IDEA specific files from the source
 code repository [v5]
In-Reply-To: <M39o2Q7HdkRklw5Biu7Nrq4kLVbyWrPrOcGz32FIC5k=.6468b4e0-9027-4841-bdca-9d74bfe4dcf3@github.com>
References: <fiZpOR7Dkjzd4pX7fwHRImCZ-mz9Bb5QeqwhbkRr87s=.03e6df19-b31e-423f-a00e-667d4e006b06@github.com>
 <3zCUdkkbxcB1NMO9-VFrOgALNGa4k2vC0yXoyqYSbyQ=.596e4f9c-9101-4548-9d7e-134f06d1770c@github.com>
 <M39o2Q7HdkRklw5Biu7Nrq4kLVbyWrPrOcGz32FIC5k=.6468b4e0-9027-4841-bdca-9d74bfe4dcf3@github.com>
Message-ID: <yjafVyWi1k5IsA_KZsHJ9qF4QO__nu5wbpsww8gukJU=.c814d846-85a0-4bb4-8ee6-7df2023e321f@github.com>

On Fri, 3 Mar 2023 01:21:12 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Intellij Ideas does not see the dependencies:
> 
> ```
> dependencies {
>         testImplementation project(":graphics").sourceSets.test.output
>         testImplementation project(":base").sourceSets.test.output
>         testImplementation project(":controls").sourceSets.test.output
>         testImplementation project(":swing").sourceSets.test.output
> }
> ```
> 
> How do I rewrite it?
> 
> It works if i remove `.sourceSets.test.output`, so I thought maybe It can be rewritten so it's good for Intellij and the build.

I do not know either. But with this PR the setup works already better than before and finally no more files inside my git staging.
So if you agree we can also just merge the IntelliJ changes now and try to fix the remaining issue(s) later, since this PR already improves the situation a lot. :)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1009#issuecomment-1491047767

From kcr at openjdk.org  Thu Mar 30 22:37:26 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 22:37:26 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
Message-ID: <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>

On Mon, 27 Mar 2023 13:50:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.

I did leave one question that you might want to address before proposing the CSR.

modules/javafx.graphics/src/main/java/javafx/css/Match.java line 43:

> 41: 
> 42:     final Selector selector;
> 43:     final Set<PseudoClass> pseudoClasses;

Should this be an `ObservableSet`? Changing the type to the `Set` superclass will mean that applications would need to do an `instanceof` check to know whether it was observable or not?

modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:

> 77:      * @return the pseudo class state
> 78:      */
> 79:     public Set<PseudoClass> getPseudoClasses() {

Should this be an `ObservableSet`? Changing the type to the `Set` superclass will mean that applications would need to do an `instanceof` check to know whether it was observable or not?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1070#pullrequestreview-1366022684
PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1153851418
PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1153852687

From kcr at openjdk.org  Thu Mar 30 22:37:27 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 22:37:27 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>
Message-ID: <9c5u6gAjNdDYV4FDnhimQOzIN4aLdF4rs8ck4paS4PQ=.4c2c000e-f964-449c-a9a2-935109d7725a@github.com>

On Thu, 30 Mar 2023 22:32:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 43:
> 
>> 41: 
>> 42:     final Selector selector;
>> 43:     final Set<PseudoClass> pseudoClasses;
> 
> Should this be an `ObservableSet`? Changing the type to the `Set` superclass will mean that applications would need to do an `instanceof` check to know whether it was observable or not?

Btw, I meant to add this comment on the public getter method.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1153852490

From kcr at openjdk.org  Thu Mar 30 22:51:25 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 30 Mar 2023 22:51:25 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v7]
In-Reply-To: <3kdQHK3hMHK9NMq9cBTSf-WnaJ6p0QhoPJ0DVEd3MvI=.05616219-6d4f-44ce-b181-484b28ebd3f9@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <BUw9cARWV7EMvBYNVkuW215VW3S_CE9Pc1JUifTQ_OA=.e306ca1f-89fb-495b-80f6-b1046a0ab000@github.com>
 <CWzYQC7rn0YJsLJUwyCebJu6Sz4Ar_CJo-fSAsgUgrA=.b20abb30-2610-4488-b221-6e19369e1048@github.com>
 <mQvJOGY4J-Mx68yfaz2f6gapQmadULfdinj58z63vAQ=.e904bfcc-96f1-4dfb-9665-41ee952735d2@github.com>
 <hRgVP787FVNV5lVYXkjfweXSwP0jCeDXU4Uung9lB5I=.58ae1e6c-eb5e-4562-873a-335dbbb88f03@github.com>
 <3kdQHK3hMHK9NMq9cBTSf-WnaJ6p0QhoPJ0DVEd3MvI=.05616219-6d4f-44ce-b181-484b28ebd3f9@github.com>
Message-ID: <O2tPCI7t8JyVle4Q5-4MZdt3AJLp3xu3hspjcAWrROU=.e364407d-1277-40fe-b27b-8555b1dd8338@github.com>

On Wed, 29 Mar 2023 21:01:30 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > Thank you very much @hjohn for your extensive review. Before addressing your comments, I'd like to get some clarification (ideally also from @kevinrushforth), because I am a bit confused by the discussion so far.

If we can resolve all of the concerns with the existing approach, without the need for a more holistic fix, then it seems OK to proceed with this. The question is: can we?

> > This PR is a very narrow patch that fixes an obvious bug in `HBox` and `VBox`. It's narrow in that it doesn't change the present algorithm, it merely corrects some of its flaws. There is a little bit of refactoring, but that's only done where it helps readers to better understand the algorithm.
> 
> Yes, I think it's an improvement in filling the boxes properly (I asked for some clarification as I found the code hard to read, but that's probably how you found it). My only worry is that it fixes this specific problem, but may be introducing a new issue (I think snapping values multiple times can introduce artifacts in the child sizes, even though they will all align correctly, I think they might be off a bit). If you can confirm this isn't the case, or if it is, fix those last problems then I think it is a positive change.

This was one my worries as well, but I haven't looked at it closely enough to point out any specific concerns.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/445#issuecomment-1491065670

From jhendrikx at openjdk.org  Thu Mar 30 23:11:25 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 23:11:25 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>
Message-ID: <dP-prymaJkkyaHfdFP86vRPTqH8zMWOT3Z3PzPtgYYc=.2d0b6596-4604-4c77-bdeb-3d2fe9de47a2@github.com>

On Thu, 30 Mar 2023 22:34:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set<PseudoClass>` should have been used. This PR corrects this.
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
> 
>> 77:      * @return the pseudo class state
>> 78:      */
>> 79:     public Set<PseudoClass> getPseudoClasses() {
> 
> Should this be an `ObservableSet`? Changing the type to the `Set` superclass will mean that applications would need to do an `instanceof` check to know whether it was observable or not?

I think that `Match` is supposed to be immutable, given the non-public constructor.  Match itself will never change the set (and nothing else will) so making it observable seems unnecessary.

However, this was not correctly spec'd, and you can change a `Match` now, and since it doesn't make a copy, you'd be changing the pseudo classes of whatever selector created it.  Note that `SimpleSelector` does make a copy, and goes to great pains to not expose anything mutable, but exposes it accidentally via `Match`.

In other words, `simpleSelector.createMatch().getPseudoClasses().clear()` would break the Selectors encapsulation.

I think it's best to close that loophole.  If you agree, I can document this method that it returns an immutable set, which is also what I assumed would be the case in my other PR where I made many of these immutable.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1153871673

From jhendrikx at openjdk.org  Thu Mar 30 23:14:28 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 30 Mar 2023 23:14:28 GMT
Subject: Integrated: JDK-8304960: ObservableListBase should defer constructing
 ListChangeBuilder
In-Reply-To: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
References: <OzHs_5ahFMsrDVFiO0QIU0Yh0BBJX3-E7OZ7YpR_lsw=.5e7bc2af-374a-4e3f-ad1e-953be958907f@github.com>
Message-ID: <qQmcMw6cYQIAg_3J0XTEpbcUytSjkaC_kitqm8uwfl4=.4c90fcb4-c21d-4bcd-956e-8e5945e1cb10@github.com>

On Wed, 29 Mar 2023 12:15:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> A 1200 Node application sees a 2/3rds reduction of ListChangeBuilder's created.  Every `Node` for example has an `ObservableList` for style classes, and every `Parent` has one for stylesheets, which rarely if ever change.

This pull request has now been integrated.

Changeset: c23d067d
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c23d067db92789daadc28025fab31f394ce022f9
Stats:     18 lines in 1 file changed: 8 ins; 0 del; 10 mod

8304960: ObservableListBase should defer constructing ListChangeBuilder

Reviewed-by: angorya, mhanl, mstrauss, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1075

From jhendrikx at openjdk.org  Fri Mar 31 00:02:23 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 31 Mar 2023 00:02:23 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <dP-prymaJkkyaHfdFP86vRPTqH8zMWOT3Z3PzPtgYYc=.2d0b6596-4604-4c77-bdeb-3d2fe9de47a2@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>
 <dP-prymaJkkyaHfdFP86vRPTqH8zMWOT3Z3PzPtgYYc=.2d0b6596-4604-4c77-bdeb-3d2fe9de47a2@github.com>
Message-ID: <VWziXlx7yG9yzsuKGRSLZeAhtW6q1qJOLp29IXTXzqQ=.e2a649bd-6ad3-414f-ae82-93faa96b84ae@github.com>

On Thu, 30 Mar 2023 23:08:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
>> 
>>> 77:      * @return the pseudo class state
>>> 78:      */
>>> 79:     public Set<PseudoClass> getPseudoClasses() {
>> 
>> Should this be an `ObservableSet`? Changing the type to the `Set` superclass will mean that applications would need to do an `instanceof` check to know whether it was observable or not?
>
> I think that `Match` is supposed to be immutable, given the non-public constructor.  Match itself will never change the set (and nothing else will) so making it observable seems unnecessary.
> 
> However, this was not correctly spec'd, and you can change a `Match` now, and since it doesn't make a copy, you'd be changing the pseudo classes of whatever selector created it.  Note that `SimpleSelector` does make a copy, and goes to great pains to not expose anything mutable, but exposes it accidentally via `Match`.
> 
> In other words, `simpleSelector.createMatch().getPseudoClasses().clear()` would break the Selectors encapsulation.
> 
> I think it's best to close that loophole.  If you agree, I can document this method that it returns an immutable set, which is also what I assumed would be the case in my other PR where I made many of these immutable.

The CSS API baffles me a bit.  It doesn't seem consistent.

Just now I took a look at the class `SimpleSelector` and `CompoundSelector`. These are public, yet cannot be constructed by users.  They're also not returned anywhere (the closest is `Selector#createSelector` which returns the interface).

Essentially this means that `SimpleSelector` and `CompoundSelector` should probably be package private.  Yet, I guess they were made public because `SelectorPartitioning` is doing instanceof checks and is casting to these classes.  But anybody can do that now, and that means that for example `SimpleSelector#getStyleClassSet` is exposed, which returns a mutable set...

Reading between the lines though it seems that `SimpleSelector` and `CompoundSelector` were intended to be fully immutable (which makes sense as they represent a style sheet).  Any changes would not be picked up as nothing is observing these properties.

I think these loopholes should be closed.

There are two options IMHO:

1. Move `SimpleSelector` and `CompoundSelector` to the com hierarchy.  They can't be publically constructed, and are never returned.  The only way to reach them is by casting.
2. If it's too late for that, then close all loopholes and ensure that these two classes are fully immutable. From what I can see now, only `getStyleClassSet` and the mentioned method in `Match` need closing.  `CompoundSelector` is already immutable.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1153894723

From hmeda at openjdk.org  Fri Mar 31 08:02:34 2023
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Fri, 31 Mar 2023 08:02:34 GMT
Subject: RFR: 8282359: Intermittent WebKit build failure on Windows: C1090: PDB
 API call failed, error code 23
Message-ID: <D1KxtNtJMHMlZQv73LkMllkdlWJ7SJYGR_lH8qGqr8Q=.38e76858-437e-413d-a2e6-61b9f0eb7ed7@github.com>

In Jenkins Build, the intermediate failure on windows is observed due to crash in mspdbserv.exe, which generates Program database (.pdb) files.
Disabled the pdb file generation in order to resolve the build failure.
Sanity testing looks fine. Verified build on windows, mac and linux.

-------------

Commit messages:
 - Disable DEBUG flag
 - comment compile flag for pdb generation

Changes: https://git.openjdk.org/jfx/pull/1079/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282359
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1079.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1079/head:pull/1079

PR: https://git.openjdk.org/jfx/pull/1079

From jpereda at openjdk.org  Fri Mar 31 09:00:30 2023
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 31 Mar 2023 09:00:30 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
In-Reply-To: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
References: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
Message-ID: <XmV8t6tmKvLN9_qEYNCmF5Y9CTS4vLZnIsKZNffIqzQ=.35566c6d-ce37-4fe1-8abc-4c7ad8a96c4b@github.com>

On Thu, 30 Mar 2023 19:58:31 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> The determined `prefWidth` of a `TableCell` could be `0.0` when a `fixedCellSize` is set.
> This happened because the `TableCell` may not have a skin since it was never added to the scene graph yet.
> 
> The fix is to make sure we get the `prefWidth` after the `TableCell` was added to the scene graph.
> That is also the reason why the problem only happened the first time and never again after (skin is then already created).

The proposed fix works and solves the test case in JDK-8305248. One of the added tests fails without the fix, passes with it (the other one passes in both cases).

I have added a few comments

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 357:

> 355:                 }
> 356:                 // Note: We have to determine the pref width here because the add operation above may trigger the skin
> 357:                 // creation first, which is what makes it possible to get a correct value here in the first place.

The comment needs some rewording. As is now, it only explains why the change proposed in this PR (moving the `prefWidth()` call, that is), but then it will be out of context.

Something like:

// prefWidth() has to be called only after the tableCell is added to the tableRow, if it wasn't already. 
// Otherwise it might not have its skin yet, and its width value would be 0.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 358:

> 356:                 // Note: We have to determine the pref width here because the add operation above may trigger the skin
> 357:                 // creation first, which is what makes it possible to get a correct value here in the first place.
> 358:                 width = tableCell.prefWidth(height);

Alternatively, you could have just kept the first call to `tableCell::prefWidth` as it was, and add a second one only inside the above if expression, right after the tableCell is added to the tableRow. 
I take that, only for such case, there would be two calls instead of one, but it seems to be somehow a cleaner patch and explanation

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 251:

> 249: 
> 250:     /**
> 251:      * When we make an invisible column visible we expect the underlying cells to be visible, e.g. as width > 0.

This only applies to the case of fixed cell size set (this test will fail if you comment out line 256), so maybe you could clarify the comment?

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java line 276:

> 274:     public void testMakeVisibleColumnInvisible() {
> 275:         tableView.setFixedCellSize(24);
> 276:         TableColumn<Person, ?> firstColumn = tableView.getColumns().get(0);

Might be unnecessary, but you could assert that the first column was visible, just to make sure that the next call to make it invisible has a real change?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1077#pullrequestreview-1366491500
PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1154176903
PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1154197254
PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1154215820
PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1154206575

From mhanl at openjdk.org  Fri Mar 31 11:16:31 2023
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 31 Mar 2023 11:16:31 GMT
Subject: RFR: JDK-8305248: TableView not rendered correctly after column is
 made visible if fixed cell size is set
In-Reply-To: <XmV8t6tmKvLN9_qEYNCmF5Y9CTS4vLZnIsKZNffIqzQ=.35566c6d-ce37-4fe1-8abc-4c7ad8a96c4b@github.com>
References: <r-2A4Tlyq57b2W-U68cNiYqw6JKTRDEheRpQ8XQH6Xo=.e13d73d0-5d48-42f6-8e8e-00f19fe634d0@github.com>
 <XmV8t6tmKvLN9_qEYNCmF5Y9CTS4vLZnIsKZNffIqzQ=.35566c6d-ce37-4fe1-8abc-4c7ad8a96c4b@github.com>
Message-ID: <prphRvhnj7ZHd0FF3JLTpixytTHdef8b147zbNwdwT0=.a76f782c-e8d0-4ba8-92d7-8f9862f5d6c3@github.com>

On Fri, 31 Mar 2023 08:40:15 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> The determined `prefWidth` of a `TableCell` could be `0.0` when a `fixedCellSize` is set.
>> This happened because the `TableCell` may not have a skin since it was never added to the scene graph yet.
>> 
>> The fix is to make sure we get the `prefWidth` after the `TableCell` was added to the scene graph.
>> That is also the reason why the problem only happened the first time and never again after (skin is then already created).
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 358:
> 
>> 356:                 // Note: We have to determine the pref width here because the add operation above may trigger the skin
>> 357:                 // creation first, which is what makes it possible to get a correct value here in the first place.
>> 358:                 width = tableCell.prefWidth(height);
> 
> Alternatively, you could have just kept the first call to `tableCell::prefWidth` as it was, and add a second one only inside the above if expression, right after the tableCell is added to the tableRow. 
> I take that, only for such case, there would be two calls instead of one, but it seems to be somehow a cleaner patch and explanation

True and I also thought about it, but I'm still in favor of calling it only as much as needed

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1077#discussion_r1154348166

From kcr at openjdk.org  Fri Mar 31 13:27:30 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 31 Mar 2023 13:27:30 GMT
Subject: RFR: JDK-8304959: Public API in javafx.css.Match should not return
 private API class PseudoClassState
In-Reply-To: <VWziXlx7yG9yzsuKGRSLZeAhtW6q1qJOLp29IXTXzqQ=.e2a649bd-6ad3-414f-ae82-93faa96b84ae@github.com>
References: <atr_wVKdw_s8NMRnHtng-7346xOGMRnIS0lkTw15ey0=.6187e529-16de-451a-994d-691af8facaf3@github.com>
 <-zNr6tpAvHM6uPLbSIoSdws0ASyWrg6U_LJf4R5FTTY=.5f540c9b-4f7c-47ed-9321-61b2c804181d@github.com>
 <dP-prymaJkkyaHfdFP86vRPTqH8zMWOT3Z3PzPtgYYc=.2d0b6596-4604-4c77-bdeb-3d2fe9de47a2@github.com>
 <VWziXlx7yG9yzsuKGRSLZeAhtW6q1qJOLp29IXTXzqQ=.e2a649bd-6ad3-414f-ae82-93faa96b84ae@github.com>
Message-ID: <lkV_1raENFNDYZf2yiGjXp-AxliUrhjuXksC1FjkSBs=.ee809126-6936-45fc-8ba5-81a1bb4c32db@github.com>

On Thu, 30 Mar 2023 23:59:50 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I think that `Match` is supposed to be immutable, given the non-public constructor.  Match itself will never change the set (and nothing else will) so making it observable seems unnecessary.
>> 
>> However, this was not correctly spec'd, and you can change a `Match` now, and since it doesn't make a copy, you'd be changing the pseudo classes of whatever selector created it.  Note that `SimpleSelector` does make a copy, and goes to great pains to not expose anything mutable, but exposes it accidentally via `Match`.
>> 
>> In other words, `simpleSelector.createMatch().getPseudoClasses().clear()` would break the Selectors encapsulation.
>> 
>> I think it's best to close that loophole.  If you agree, I can document this method that it returns an immutable set, which is also what I assumed would be the case in my other PR where I made many of these immutable.
>
> The CSS API baffles me a bit.  It doesn't seem consistent.
> 
> Just now I took a look at the class `SimpleSelector` and `CompoundSelector`. These are public, yet cannot be constructed by users.  They're also not returned anywhere (the closest is `Selector#createSelector` which returns the interface).
> 
> Essentially this means that `SimpleSelector` and `CompoundSelector` should probably be package private.  Yet, I guess they were made public because `SelectorPartitioning` is doing instanceof checks and is casting to these classes.  But anybody can do that now, and that means that for example `SimpleSelector#getStyleClassSet` is exposed, which returns a mutable set...
> 
> Reading between the lines though it seems that `SimpleSelector` and `CompoundSelector` were intended to be fully immutable (which makes sense as they represent a style sheet).  Any changes would not be picked up as nothing is observing these properties.
> 
> I think these loopholes should be closed.
> 
> There are two options IMHO:
> 
> 1. Move `SimpleSelector` and `CompoundSelector` to the com hierarchy.  They can't be publically constructed, and are never returned.  The only way to reach them is by casting.
> 2. If it's too late for that, then close all loopholes and ensure that these two classes are fully immutable. From what I can see now, only `getStyleClassSet` and the mentioned method in `Match` need closing.  `CompoundSelector` is already immutable.

I'll take a closer look early next week.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1154473373

From mstrauss at openjdk.org  Fri Mar 31 15:26:45 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 31 Mar 2023 15:26:45 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
Message-ID: <dROLx_jEbSrUbNLtjnt7dZlQwZunE7sd6xzPn7k94dA=.9f6fc4a6-6921-4e21-9f8e-f06cbbb92d6a@github.com>

On Thu, 30 Mar 2023 20:34:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
>> 
>> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
>> 
>> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
>> 
>> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well.
>> 
>> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
>> 
>> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
>> 
>> Although the test case above was extreme, this change should have positive effects for most applications.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 588:

> 586:     protected abstract T cast(Object obj);
> 587: 
> 588:     protected long[] getBits() {

Since your patch already contains some cleanup work: can you make this method `final`? The way it's specified at the moment looks like it was made to be overridable, which is clearly not useful.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1154612038

From mstrauss at openjdk.org  Fri Mar 31 15:35:02 2023
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 31 Mar 2023 15:35:02 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
Message-ID: <wdh-VgOI2ECyhVbv1CyQIc1otNfgFYGUOTlOBh27vKQ=.86e11b84-760a-4795-9988-187b1b3a7e81@github.com>

On Thu, 30 Mar 2023 20:34:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
>> 
>> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
>> 
>> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
>> 
>> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well.
>> 
>> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
>> 
>> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
>> 
>> Although the test case above was extreme, this change should have positive effects for most applications.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy

modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 584:

> 582:      * @param obj the object to cast, cannot be {@code null}
> 583:      * @return a type T, or {@code null} if the argument was not of this type
> 584:      * @throws NullPointerException when {@code obj} is {@code null}

Previously, this method always returned an instance of `T`. Now that is not the case, it might also simply return `null` if the argument passed into it is an instance of a different class. I think it makes sense to also return `null` when the argument passed into the method is `null`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1154620769

From john at status6.com  Fri Mar 31 16:03:54 2023
From: john at status6.com (John Neffenger)
Date: Fri, 31 Mar 2023 09:03:54 -0700
Subject: Allow OpenJFX to be built on unknown architectures
In-Reply-To: <CAJL5A3nR+1zv609uGM_8YW37GXtZAdHBLMiCRgcq0hYr7Geo7w@mail.gmail.com>
References: <CAJL5A3kinX_CxY5_Ev1W80+Dx-8QVF7ApKYsMPbVp-KGTO7xsw@mail.gmail.com>
 <CAJL5A3ni+NxvGRqWmsEMZ5K1jkcqu3oAFAO3EqmgHc6E0z9SdQ@mail.gmail.com>
 <d5b76cae-043b-f61e-8841-78adb5763e2d@oracle.com>
 <b631e3fc-bb66-79b6-85fb-3dc3316d52dd@status6.com>
 <CAJL5A3nR+1zv609uGM_8YW37GXtZAdHBLMiCRgcq0hYr7Geo7w@mail.gmail.com>
Message-ID: <4ad51ddc-2638-9b21-c6cb-d3498f760154@status6.com>

On 3/30/23 11:17 AM, Glavo wrote:
> I compiled OpenJFX for RISC-V and MIPS64el platforms with reference to 
> your patch, thereby porting our JavaFX applications to these platforms, 
> and it worked well.

A better patch, then, would be to remove the platform test entirely so 
that there are no unsupported build architectures. In other words, 
remove this failure:

   fail("Unknown and unsupported build architecture: $OS_ARCH")

My current patch is too conservative and just extends the list of 
supported architectures. I'll keep that in mind when I create the pull 
request (unless anyone else beats me to it).

allow-armhf-i386-ppc64el-s390x.patch
https://github.com/jgneff/openjfx/blob/edge/snap/local/allow-armhf-i386-ppc64el-s390x.patch

Thanks,
John


From jhendrikx at openjdk.org  Fri Mar 31 18:10:26 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 31 Mar 2023 18:10:26 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <wdh-VgOI2ECyhVbv1CyQIc1otNfgFYGUOTlOBh27vKQ=.86e11b84-760a-4795-9988-187b1b3a7e81@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
 <wdh-VgOI2ECyhVbv1CyQIc1otNfgFYGUOTlOBh27vKQ=.86e11b84-760a-4795-9988-187b1b3a7e81@github.com>
Message-ID: <LhfqzUyQYhZgk5JBHpaKdYbs0x0oJjVArpz4EWHY7QI=.6a4d2e2c-fc6c-47df-828c-cc2127e943bf@github.com>

On Fri, 31 Mar 2023 15:32:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify ImmutablePseudoClassSetsCache and avoid an unnecessary copy
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 584:
> 
>> 582:      * @param obj the object to cast, cannot be {@code null}
>> 583:      * @return a type T, or {@code null} if the argument was not of this type
>> 584:      * @throws NullPointerException when {@code obj} is {@code null}
> 
> Previously, this method always returned an instance of `T`. Now that is not the case, it might also simply return `null` if the argument passed into it is an instance of a different class. I think it makes sense to also return `null` when the argument passed into the method is `null`.

I'm a bit unsure why that would be an improvement. Passing `null` to a function that doesn't expect it should IMHO never just return `null` but should instead be considered a programming error and result in a stack trace.  Passing in a non-null value that can't be casted is explicitly documented now that it would result in `null`.  One is a caller error, the other isn't IMHO (as the caller can't check if it is castable without another method -- I considered adding an `instanceof` method).

Or maybe I'm reading too much in to this and you are just pointing out that the function has changed from its previous contract -- I think this is okay as `BitSet` is not public API, nor are any of its subclasses.

> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 588:
> 
>> 586:     protected abstract T cast(Object obj);
>> 587: 
>> 588:     protected long[] getBits() {
> 
> Since your patch already contains some cleanup work: can you make this method `final`? The way it's specified at the moment looks like it was made to be overridable, which is clearly not useful.

Sure, I don't mind, the class is not public though, nor are its subclasses.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1154758868
PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1154758778

From jhendrikx at openjdk.org  Fri Mar 31 21:25:32 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 31 Mar 2023 21:25:32 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <RKtdH7x8Hz6za5AuALr0W6sipDxDJdR2J_wciUaMPrs=.63d1b491-bce8-4f68-9d03-88e0e303a527@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <gZuJvXvOzVA4GUjV1vAaO_7TBjZzrJedUddtR7pWvDA=.926aee0f-cecd-41c9-a2ac-6cf6f7f7cab8@github.com>
 <RKtdH7x8Hz6za5AuALr0W6sipDxDJdR2J_wciUaMPrs=.63d1b491-bce8-4f68-9d03-88e0e303a527@github.com>
Message-ID: <ukmeJ1hPEDiGIfB1Yd3ZYS8iPAZF0WOsTGJGCIlfAHY=.244a8697-ab84-4f39-86f7-44ec80f02968@github.com>

On Thu, 30 Mar 2023 20:23:59 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/ImmutablePseudoClassSetsCache.java line 55:
>> 
>>> 53:          *
>>> 54:          * If the given set was already immutable; the copyOf will return the same
>>> 55:          * set; however, that may or may not be the set that is already in the cache.
>> 
>> Do we want to depend on this behavior? The specification of `Set.copyOf` says:
>> 
>> @implNote
>> If the given Collection is an unmodifiable Set, calling copyOf will generally not create a copy.
>> 
>> 
>> While the actual implementation _never_ creates a copy if the given collection is immutable, the specification does not guarantee that in all cases, but only in the general case. This behavior could theoretically change without changing the specification of `Set.copyOf`.
>
>> Do we want to depend on this behavior? The specification of `Set.copyOf` says:
>> 
>> ```
>> @implNote
>> If the given Collection is an unmodifiable Set, calling copyOf will generally not create a copy.
>> ```
>> 
>> While the actual implementation _never_ creates a copy if the given collection is immutable, the specification does not guarantee that in all cases, but only in the general case. This behavior could theoretically change without changing the specification of `Set.copyOf`.
> 
> If it ever changes implementation, I suppose we could do this logic ourselves -- however, you did give me an idea... before making the copy, I could check if it is in the cache already.  In the case that the set you pass is mutable, but I have an immutable copy already then no copy would need to be made.  The only time a copy is made then is if it wasn't in the cache yet.
> 
> Before arriving at this solution I had a class `ImmutablePseudoClassState` which extended `AbstractSet`.  But after stripping everything out that I didn't need, the only thing that was left was a single private field... which was also a `Set`.  I then concluded that there is no need for this wrapper at all, as everything in the CSS code can deal with `Set<PseudoClass>` directly.
> 
> EDIT: I changed this, and the `computeIfAbsent` now looks much better, no need for the long explanatory comment... not sure what I was thinking at the time :)

I've looked into this part a bit further, and I noticed that `BitSet` is also violating the equals/hashCode contract that are supposed to apply to all `Set` implementations.  As I'm now using a `Set` as key for the cache, this contract needs to be adhered to.  I'll see if I can test if this is indeed causing problems as I suspect, and fix it if so.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1154919651

From jhendrikx at openjdk.org  Fri Mar 31 21:56:08 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 31 Mar 2023 21:56:08 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v3]
In-Reply-To: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
Message-ID: <KkqjwcygUXab3Nr7nMOzhjGz4DP_ml5ERZ5160U2AeI=.2fc9b762-795f-461b-9b5f-7c73dd61b636@github.com>

> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified.  These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
> 
> In order to make this work, `BitSet` had to be cleaned up.  It made assumptions about the collections it is given (which may no longer always be another `BitSet`).  I also added the appropriate null checks to ensure there weren't any other bugs lurking.
> 
> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
> 
> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`.  This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`) -- I fixed this bug because I need to call `Set.copyOf` which uses `toArray` -- as the same bug was also present in `StyleClassSet`, I fixed it there as well.
> 
> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
> 
> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
> 
> Although the test case above was extreme, this change should have positive effects for most applications.

John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:

 - Base BitSet on AbstractSet to inherit correct equals/hashCode/toArray
   
   - Removed faulty toArray implementations in PseudoClassState and
   StyleClassSet
   - Added test that verifies equals/hashCode for PseudoClassState respect
   Set contract now
   - Made getBits package private so it can't be inherited
 - Remove unused code
 - Ensure Match doesn't allow modification

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1076/files
  - new: https://git.openjdk.org/jfx/pull/1076/files/e9300e9f..dd5949b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1076&range=01-02

  Stats: 159 lines in 6 files changed: 37 ins; 101 del; 21 mod
  Patch: https://git.openjdk.org/jfx/pull/1076.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1076/head:pull/1076

PR: https://git.openjdk.org/jfx/pull/1076

From jhendrikx at openjdk.org  Fri Mar 31 22:18:30 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 31 Mar 2023 22:18:30 GMT
Subject: RFR: JDK-8199216: Memory leak and quadratic layout time with
 nested nodes (hbox) and pseudo-class in style sheet [v2]
In-Reply-To: <LhfqzUyQYhZgk5JBHpaKdYbs0x0oJjVArpz4EWHY7QI=.6a4d2e2c-fc6c-47df-828c-cc2127e943bf@github.com>
References: <w6MvtKCTc3cEk2UhHlHyIBUzzFYY3XCcEyeiGoRnogc=.c1cbca2e-ffb8-4a5e-b735-160e3a0bff9d@github.com>
 <40ndHnnBPYAx7mytmvt-Qe31S-F7KkBU6jxhEA03QGc=.19921c69-18e2-492c-8b50-782e41ce3b0a@github.com>
 <wdh-VgOI2ECyhVbv1CyQIc1otNfgFYGUOTlOBh27vKQ=.86e11b84-760a-4795-9988-187b1b3a7e81@github.com>
 <LhfqzUyQYhZgk5JBHpaKdYbs0x0oJjVArpz4EWHY7QI=.6a4d2e2c-fc6c-47df-828c-cc2127e943bf@github.com>
Message-ID: <34pEg7DtxSq8VCaTlyGljXfTPCMBnoJrz4mYfnH8bKc=.af2d80a0-d96a-458c-99ca-b93f06661044@github.com>

On Fri, 31 Mar 2023 18:07:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 588:
>> 
>>> 586:     protected abstract T cast(Object obj);
>>> 587: 
>>> 588:     protected long[] getBits() {
>> 
>> Since your patch already contains some cleanup work: can you make this method `final`? The way it's specified at the moment looks like it was made to be overridable, which is clearly not useful.
>
> Sure, I don't mind, the class is not public though, nor are its subclasses.

I've made this method package private instead of protected.  The only reason it was protected was so that `toArray` implementations in the two subclasses could access it.  However, those implementations are totally unnecessary as `AbstractCollection` provides them, without bugs and likely with perfectly acceptable performance.

By basing `BitSet` on `AbstractSet`, which it probably should have been from the beginning, I also inherit contract respecting equals/hashCode implementations -- the only concession I did here is to provide a fast(er?) path when both sets are `BitSet`s.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1154949274