From arapte at openjdk.org  Thu Sep  1 05:37:17 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 1 Sep 2022 05:37:17 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5]
In-Reply-To: <uOY7x_gCJCrB6BFYbizqNK2KncWYcBehGSv9LCgnpoM=.27fb0c6a-015a-43e6-a943-f4ec0cb1bb85@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <y41FjTqpEIQNjPCkWLDBr18Oef418P6dVZohpnij1Gs=.d56157a7-ad13-4689-9a01-5d3a755d9833@github.com>
 <fFCboaSUOldbfvgVtm1J-klb94agQazljFH6KosbIAA=.cd41c0a2-adb9-4d5b-80ea-b13cd9995a43@github.com>
 <F7wDrTiZEinKdHlxjsTXT3SVsryvmJPD-MB3P58SkzA=.8aa20fe6-e83c-47de-b841-541102519c8a@github.com>
 <h2mbU_VxdIfwiaz22E6LEBUCapqJQ-zTQwzpdWODlOs=.9ba003fe-7b8d-42a5-8de2-f23686d6697e@github.com>
 <uOY7x_gCJCrB6BFYbizqNK2KncWYcBehGSv9LCgnpoM=.27fb0c6a-015a-43e6-a943-f4ec0cb1bb85@github.com>
Message-ID: <HyJGMGelARB_fHsLvX21ArG0VxPmvsUi-Y5z3DPjzcY=.24631547-0002-4883-9696-e72c1bce972d@github.com>

On Tue, 30 Aug 2022 18:37:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>>> What do you mean by "revert the type function parameter here"?
>> 
>> `VsOutput main(VsInput vsInput)`: in the declaration, the type of function parameter `VsInput vsInput` should be reverted with change in build.gradle.
>> `VsOutput main(VsInput vsInput)` should be changed to `VsOutput main(VertexType vsInput)`
>
> I still don't understand. What is `VertexType`? I see a comment on `VsInput` "// this is a .hlsl mirror of the vertex format, see VertexTypes.h". If the gradle file has `"/DVertexType=VsInput"`, shouldn't it be fine with `VsInput` as the main function argument?

Referring code without this PR changes:

- `/DVertexType=ObjVertex`  -> Is a macro definition passed to DirectX shader compiler.
- This macro is used only once in `Mtl1VS.hlsl` as a type of main function's argument: `ObjVsOutput main(VertexType i)`
- So, if we directly use struct name in `Mtl1VS.hlsl` then the Macro in build.gradle goes unused. So can/should be removed from build.gradle.

With current changes in PR:
- With this change `VsOutput main(VsInput vsInput)` in Mtl1VS.hlsl the macro def `/DVertexType=VSInput` in build.gradle can/should also be removed:-> 
`["$FXC", "/nologo", "/T", "vs_3_0", "/Fh", "$buildDir/headers/PrismD3D/hlsl/Mtl1VS_Obj.h", "$VS_3D_SRC"]`

OR

- In build.gradle:  Change `"/DVertexType=ObjVertex"` to `"/DVertexType=VsInput"` and,
In Mtl1VS.hlsl:  Change `VsOutput main(VsInput vsInput)` to `VsOutput main(VertexType vsInput)`

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

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

From mhanl at openjdk.org  Thu Sep  1 08:04:20 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 1 Sep 2022 08:04:20 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE
In-Reply-To: <_RYmhV_lrstbXUeSswFtZt9AF5o2eR3STqAqX829b28=.7e2be545-1909-498e-91d1-dfb7402527bc@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <_RYmhV_lrstbXUeSswFtZt9AF5o2eR3STqAqX829b28=.7e2be545-1909-498e-91d1-dfb7402527bc@github.com>
Message-ID: <Ewi8zkJKAP_JRHZzTFD9tFXR22E_PkyySrntxpei12k=.da7afb38-6386-4eed-b01e-477bb1737147@github.com>

On Mon, 22 Aug 2022 17:49:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> you are right! unless, of course, someone writes code to invoke these methods directly. For example, simpleSelect() is protected, so any Behavior that extends CellBehaviorBase might encounter an NPE.

No strong opinion here but I think in this case it doesn't really matter since all behaviours are anyway in `com.sun.javafx` and since `simpleSelect` is called by `doSelect`, there won't be any problem. 
But another null check does not hurt on the other hand.

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

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

From nlisker at openjdk.org  Thu Sep  1 11:23:44 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 1 Sep 2022 11:23:44 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v7]
In-Reply-To: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
Message-ID: <gb88XEPV8_gqygbTmmrzfvVCS0Bh3EPIIdSeNrRGx8A=.be7297c5-c47a-45f4-96e1-37e2cfcdd25d@github.com>

> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
> 
> Since there are many small changes, I'm giving a full list here:
> 
> **Java**
> 
> * `NGShape3D.java`
>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>   * Normalized the direction here instead of in the native code.
>   * Ambient light is now only set when it exists (and is not black).
> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
> 
> **Native C++**
> 
> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
> * `D3DLight`
>   * Commented out unused methods. Were they supposed to be used at some point?
>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
> * `D3DPhongShader.h`
>   * Renamed some of the register constants for more clarity.
>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
> * `D3DMeshView.cc`
>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
> 
> **Native shaders**
> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
> * `vsConstants`
>   * Removed the light color from here since it's unused, only the position is.
>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
> * `vs2ps`
>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
> * `Mtl1PS` and `psMath`
>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
> 
> No changes in performance were measured and the behavior stayed the same.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Addressed review comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/789/files
  - new: https://git.openjdk.org/jfx/pull/789/files/72305b30..1f66f613

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

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

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

From nlisker at openjdk.org  Thu Sep  1 11:23:45 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 1 Sep 2022 11:23:45 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v5]
In-Reply-To: <HyJGMGelARB_fHsLvX21ArG0VxPmvsUi-Y5z3DPjzcY=.24631547-0002-4883-9696-e72c1bce972d@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <y41FjTqpEIQNjPCkWLDBr18Oef418P6dVZohpnij1Gs=.d56157a7-ad13-4689-9a01-5d3a755d9833@github.com>
 <fFCboaSUOldbfvgVtm1J-klb94agQazljFH6KosbIAA=.cd41c0a2-adb9-4d5b-80ea-b13cd9995a43@github.com>
 <F7wDrTiZEinKdHlxjsTXT3SVsryvmJPD-MB3P58SkzA=.8aa20fe6-e83c-47de-b841-541102519c8a@github.com>
 <h2mbU_VxdIfwiaz22E6LEBUCapqJQ-zTQwzpdWODlOs=.9ba003fe-7b8d-42a5-8de2-f23686d6697e@github.com>
 <uOY7x_gCJCrB6BFYbizqNK2KncWYcBehGSv9LCgnpoM=.27fb0c6a-015a-43e6-a943-f4ec0cb1bb85@github.com>
 <HyJGMGelARB_fHsLvX21ArG0VxPmvsUi-Y5z3DPjzcY=.24631547-0002-4883-9696-e72c1bce972d@github.com>
Message-ID: <068tB1bComeXXF0JzMGE64Nh7AnxxXqX1LEwsLYxqiA=.5b75d4c4-8622-4537-90b5-2645634c3ab2@github.com>

On Thu, 1 Sep 2022 05:35:09 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> I still don't understand. What is `VertexType`? I see a comment on `VsInput` "// this is a .hlsl mirror of the vertex format, see VertexTypes.h". If the gradle file has `"/DVertexType=VsInput"`, shouldn't it be fine with `VsInput` as the main function argument?
>
> Referring code without this PR changes:
> 
> - `/DVertexType=ObjVertex`  -> Is a macro definition passed to DirectX shader compiler.
> - This macro is used only once in `Mtl1VS.hlsl` as a type of main function's argument: `ObjVsOutput main(VertexType i)`
> - So, if we directly use struct name in `Mtl1VS.hlsl` then the Macro in build.gradle goes unused. So can/should be removed from build.gradle.
> 
> With current changes in PR:
> - With this change `VsOutput main(VsInput vsInput)` in Mtl1VS.hlsl the macro def `/DVertexType=VSInput` in build.gradle can/should also be removed:-> 
> `["$FXC", "/nologo", "/T", "vs_3_0", "/Fh", "$buildDir/headers/PrismD3D/hlsl/Mtl1VS_Obj.h", "$VS_3D_SRC"]`
> 
> OR
> 
> - In build.gradle:  Change `"/DVertexType=ObjVertex"` to `"/DVertexType=VsInput"` and,
> In Mtl1VS.hlsl:  Change `VsOutput main(VsInput vsInput)` to `VsOutput main(VertexType vsInput)`

I reverted the input parameter type as you suggested and added a comment referring to the gradle build file.

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

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

From aoqi at openjdk.org  Thu Sep  1 12:38:20 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 1 Sep 2022 12:38:20 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64
Message-ID: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>

LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.

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

Commit messages:
 - 8293214: Add support for Linux/LoongArch64

Changes: https://git.openjdk.org/jfx/pull/888/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=888&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293214
  Stats: 26 lines in 4 files changed: 15 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/888.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/888/head:pull/888

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

From kcr at openjdk.org  Thu Sep  1 12:38:20 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 12:38:20 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <yaJJGvm2ydJJseKi14FD1OIbjdlxTsyI6Hw8wZSRsX4=.55757abf-ba9b-430b-8004-d097e3a60dff@github.com>

On Thu, 1 Sep 2022 12:19:23 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.

This will need careful review to ensure that there are no regressions on other platforms.

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

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

From jhendrikx at openjdk.org  Thu Sep  1 12:39:33 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 12:39:33 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <e-TF0hcc8yeUws13MbAgocUfO2-5cBJMpEf32V5pT4E=.b5123d3c-7e97-4a03-92cd-eea3899a4e35@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <WPzpq-ZDiQkRQGivZrHdmtTqebcwr0q9vvXX09gtnfQ=.bb338b93-3881-48eb-8224-64a186870482@github.com>
 <e-TF0hcc8yeUws13MbAgocUfO2-5cBJMpEf32V5pT4E=.b5123d3c-7e97-4a03-92cd-eea3899a4e35@github.com>
Message-ID: <py2hpNviZloMW6bsUPN_010xdOB-TRQoY3ZMr3mLVIQ=.50db0b8a-5bc0-43df-9aff-15128e10bdde@github.com>

On Wed, 31 Aug 2022 17:33:41 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 311:
>> 
>>> 309:      * @since 20
>>> 310:      */
>>> 311:     default ObservableValue<T> when(ObservableValue<Boolean> condition) {
>> 
>> Discussion: name? `when`, `conditionOn`, other suggestions?  Note that this is not the same as a possible future method `filter`, as a `filter` would still keep observing its source at all times (and would use a `Predicate` as parameter).
>
> `when` sounds fine, but we need to be careful about its relation to the `When` class.
> 
> This reminds me also that some of the new functionality in `ObservableValue` can be used as a replacement for `When`, maybe we should note that like we did with `Bindings.select`.

Do you want me to make this part of the PR? Basically, `Bindings.when` with `map` or `flatMap` depending on whether or not you refer to a value or another property in `then` or `otherwise`.

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

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

From aoqi at openjdk.org  Thu Sep  1 12:42:15 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 1 Sep 2022 12:42:15 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <uwGDdlzVb1BIyKogwdPSN1c1Y9NLHyMVyR_6iZ0vaA8=.55b9c813-cb17-47b2-a71d-1ff448bb54cb@github.com>

On Thu, 1 Sep 2022 12:19:23 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.

I just enable the GitHub Actions after I create the pr. How can I trigger the GHA tests?

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

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

From jhendrikx at openjdk.org  Thu Sep  1 12:55:29 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 12:55:29 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
Message-ID: <5xZzPeWHwfUjntA7ZpW9x3FciZaIeI2qiLj5yztokX8=.a2dc5b2f-6083-43bf-9a73-103da380f188@github.com>

On Wed, 31 Aug 2022 16:54:32 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename showing property to shown as it is already used in subclasses
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 259:
> 
>> 257:      * Returns an {@code ObservableValue} that holds this value whenever the given
>> 258:      * condition evaluates to {@code true}, otherwise holds the last value when
>> 259:      * {@code condition} became {@code false}. The value is updated whenever this
> 
>> became `{@code false}`
> 
> If it was `false` from the start then the observable still holds the initial value. Maybe "was `{@code false}`"?

What I'm trying to communicate here is that the last value held by the parent will be the value held by this observable at the time the condition becomes false.  Perhaps more accurately:

> Returns an `ObservableValue` that holds this value and is updated only when the given condition evaluates to `true`.

This also communicates that it will initially copy the value, and then keeps copying it for as long as condition is `true`. It also implies (with "updated") that the value will remain at the last copied value for the duration of the condition being `false`.

> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 260:
> 
>> 258:      * condition evaluates to {@code true}, otherwise holds the last value when
>> 259:      * {@code condition} became {@code false}. The value is updated whenever this
>> 260:      * {@code ObservableValue} changes, unless the condition currently evaluates
> 
> Maybe it's a bit clearer to indicate when the value changes rather than when it doesn't:
> 
>> The value is updated whenever this `{@code ObservableValue}` changes and `{@code condition}` holds `{@code true}`

Looks like we had the same thought here, I think if I change the first sentence it covers all of this.

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

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

From kcr at openjdk.org  Thu Sep  1 12:55:25 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 12:55:25 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <EU_nzDoXc2i9SBny4gpunaPsP8UeXAcq8MF7hDDcPF8=.e68ba1f3-6b48-414a-b6f2-e72c844398c1@github.com>

On Thu, 1 Sep 2022 12:19:23 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.

The easiest way is to push an empty commit to your branch.

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

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

From aoqi at openjdk.org  Thu Sep  1 12:57:50 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 1 Sep 2022 12:57:50 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v2]
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <pwHCcI462c6OL9_ipRmB_vC7kWScR9IEhPG-uj177t0=.a774da08-0979-4b48-b6c4-939a2811d1e1@github.com>

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  trigger the GHA tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/888/files
  - new: https://git.openjdk.org/jfx/pull/888/files/408f9156..c0bdfe96

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

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

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

From nlisker at openjdk.org  Thu Sep  1 12:59:34 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 1 Sep 2022 12:59:34 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <py2hpNviZloMW6bsUPN_010xdOB-TRQoY3ZMr3mLVIQ=.50db0b8a-5bc0-43df-9aff-15128e10bdde@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <WPzpq-ZDiQkRQGivZrHdmtTqebcwr0q9vvXX09gtnfQ=.bb338b93-3881-48eb-8224-64a186870482@github.com>
 <e-TF0hcc8yeUws13MbAgocUfO2-5cBJMpEf32V5pT4E=.b5123d3c-7e97-4a03-92cd-eea3899a4e35@github.com>
 <py2hpNviZloMW6bsUPN_010xdOB-TRQoY3ZMr3mLVIQ=.50db0b8a-5bc0-43df-9aff-15128e10bdde@github.com>
Message-ID: <nXgkh22g1QGViZU3MTjxzHoqtfGhuOpavSd3f3-gu44=.7fc26fa6-123c-494c-a3ba-44464d48f4cd@github.com>

On Thu, 1 Sep 2022 12:35:21 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> `when` sounds fine, but we need to be careful about its relation to the `When` class.
>> 
>> This reminds me also that some of the new functionality in `ObservableValue` can be used as a replacement for `When`, maybe we should note that like we did with `Bindings.select`.
>
> Do you want me to make this part of the PR? Basically, `Bindings.when` with `map` or `flatMap` depending on whether or not you refer to a value or another property in `then` or `otherwise`.

Changing the documentation for `When` should not be part of this PR I think. What we should do maybe is add a note that this method should not be confused with `Bindings.when`. I'll let others weigh in.

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

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

From aoqi at openjdk.org  Thu Sep  1 13:00:24 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 1 Sep 2022 13:00:24 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  revert

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/888/files
  - new: https://git.openjdk.org/jfx/pull/888/files/c0bdfe96..b225c59a

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

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

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

From jhendrikx at openjdk.org  Thu Sep  1 13:14:35 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 13:14:35 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
Message-ID: <mGqkr2Mvahzn9XNEmYxXSVk1SysfY9mLB1XpVvJXaV0=.cf8cd8ae-8cc7-4f8d-b698-0ca1fce29604@github.com>

On Wed, 31 Aug 2022 17:04:31 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename showing property to shown as it is already used in subclasses
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 266:
> 
>> 264:      * {@code condition} evaluates to {@code true}. This allows this {@code ObservableValue}
>> 265:      * and the conditional {@code ObservableValue} to be garbage collected if neither is
>> 266:      * otherwise strongly referenced when {@code condition} becomes {@code false}.
> 
> What happens if they are GC'd and the conditional becomes `true` later?

There are three objects involved here: the parent observable, the new observable and the conditional.

What `when` should achieve is to make the new observable easy to garbage collect when the conditional is `false` (the parent observable is considered to be long lived so GC doesn't really apply there).  The conditional itself is referred to by the new observable, so it lives at least as long as the new observable (but possibly longer).

If the new observable is GC'd, then it doesn't matter what conditional is; if it becomes `true`, it would normally cause new observable to update its value, but as new observable doesn't exist anymore, and nobody referred to it, nobody is interested.  If it was already `true` then the new observable couldn't have been GC'd as parent observable would be referring to it.

Strong references look like this when conditional is `true`:

      conditional <-- new observable <--> parent observable

When it is `false`:

     conditional <-- new observable --> parent observable

In the first case, GC could only happen if new observable and parent observable are both unreferenced -- as the parent is probably a much longer lived property, this means a whole window is closed or the application is exiting or some such.

In the second case, GC of new observable can happen if it is unreferenced; this could happen when a small piece of UI is replaced with another piece leaving the old piece (and all its bindings) 'orphaned'.  It would not happen if it simply became invisible, as it would still be a child of the larger UI involved, and this child would in turn refer to new observable through a binding.

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

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

From jhendrikx at openjdk.org  Thu Sep  1 13:41:33 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 13:41:33 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
Message-ID: <AmzaDueE1R2s0kyb632Qcy6GjuG2TuXIIJDhhXdUrnY=.300f31f6-0f6e-416c-b8b0-43b75de5377b@github.com>

On Wed, 31 Aug 2022 17:19:37 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename showing property to shown as it is already used in subclasses
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 274:
> 
>> 272:      * <p>
>> 273:      * Returning {@code null} from the given condition is treated the same as
>> 274:      * returning {@code false}.
> 
> I would rephrase to use the "holds" language instead of the "return":
> 
>> `{@code condition}` holding `{@code null}` is treated the same as it holding {@code false}`
> 
> But is this the behavior we want? I would consider throwing when the condition is not a `true` or `false` because it's a boolean condition. `orElse` can be used to create a condition that maps `null` to something else if the user wants to accept `null`s in the condition. I'm not sure if this is really a problem.

I've rephrased it as suggested.

As for `null` -- I've clarified here what it currently does (so it is not left undefined), but I have no strong feelings either way. 

I mainly choose this direction because JavaFX has so far opted to treat `null` as something to be ignored or converted to a default value (for `BooleanProperty`, you can set it to `null` using the generic setter, and it would become `false`).  Since the fluent system is basically built on top of `ObjectProperty` (and thus `Object`) we can't easily exclude the possibility of it being `null` (I have to accept `ObservableValue<Boolean>` instead of `BooleanProperty`).

ie:

     listView.layoutXProperty().setValue(null);

makes no sense at all, but JavaFX accepts it and uses `0.0`.

Ouch, just noticed it always creates (not throws) an exception (with expensive stacktrace) whenever you do that, despite it maybe not getting logged:

    @Override
    public void setValue(Number v) {
        if (v == null) {
            Logging.getLogger().fine("Attempt to set double property to null, using default value instead.", new NullPointerException());
            set(0.0);
        } else {
            set(v.doubleValue());
        }
    }

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

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

From jhendrikx at openjdk.org  Thu Sep  1 13:47:21 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 13:47:21 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
Message-ID: <QemKaX_9Ex1MfHrFzWh4gWPQr82ODUTYLOO1KfSc15s=.b7098310-8e20-4f59-b01d-b2bc2240099f@github.com>

On Wed, 31 Aug 2022 17:21:33 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename showing property to shown as it is already used in subclasses
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 302:
> 
>> 300:      * ObservableValue<String> globalProperty = new SimpleStringProperty("A");
>> 301:      *
>> 302:      * // bind label's text to a global property only when it is shown:
> 
> "a label's"

`label` here is referring to the variable name, I think `a label` might be confusing -- I've changed it to `the label` for now.

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

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

From jhendrikx at openjdk.org  Thu Sep  1 13:47:22 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 13:47:22 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <QemKaX_9Ex1MfHrFzWh4gWPQr82ODUTYLOO1KfSc15s=.b7098310-8e20-4f59-b01d-b2bc2240099f@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
 <QemKaX_9Ex1MfHrFzWh4gWPQr82ODUTYLOO1KfSc15s=.b7098310-8e20-4f59-b01d-b2bc2240099f@github.com>
Message-ID: <boL4qGjlZ47twZVF_Oeer_b0Iq9KWrnHQ5dFXqYBcCE=.d74496f7-93fa-4927-b7d5-bcb884ac91e3@github.com>

On Thu, 1 Sep 2022 13:42:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 302:
>> 
>>> 300:      * ObservableValue<String> globalProperty = new SimpleStringProperty("A");
>>> 301:      *
>>> 302:      * // bind label's text to a global property only when it is shown:
>> 
>> "a label's"
>
> `label` here is referring to the variable name, I think `a label` might be confusing -- I've changed it to `the label` for now.

Never mind, you're next suggestion solves it.

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

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

From jhendrikx at openjdk.org  Thu Sep  1 13:51:21 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 13:51:21 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v3]
In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
Message-ID: <jcnL5gTN02oIwwYbYXAy9NyZ4gqECANrEvCfpbXnOQE=.6119c16a-4ce2-406c-b7e7-1d0cb8f76933@github.com>

> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
> 
> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
> 
> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
> 
>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
> 
> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
> 
> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
> 
> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
> 
> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Update javadoc of "when" with better phrasing

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/830/files
  - new: https://git.openjdk.org/jfx/pull/830/files/fd19fc36..07e9d88a

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

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

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

From john.hendrikx at gmail.com  Thu Sep  1 13:53:53 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 1 Sep 2022 15:53:53 +0200
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <mGqkr2Mvahzn9XNEmYxXSVk1SysfY9mLB1XpVvJXaV0=.cf8cd8ae-8cc7-4f8d-b698-0ca1fce29604@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
 <mGqkr2Mvahzn9XNEmYxXSVk1SysfY9mLB1XpVvJXaV0=.cf8cd8ae-8cc7-4f8d-b698-0ca1fce29604@github.com>
Message-ID: <6d15035f-7843-d35f-70f1-570b472fcc90@gmail.com>

Please ignore the explanation below it is incorrect (I forgot that 
conditional and new observable reference each other).

I've updated the comment on Github, not sure if these edits will show on 
the mailinglist.

--John

On 01/09/2022 15:14, John Hendrikx wrote:
> On Wed, 31 Aug 2022 17:04:31 GMT, Nir Lisker <nlisker at openjdk.org> wrote:
>
>>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Rename showing property to shown as it is already used in subclasses
>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 266:
>>
>>> 264:      * {@code condition} evaluates to {@code true}. This allows this {@code ObservableValue}
>>> 265:      * and the conditional {@code ObservableValue} to be garbage collected if neither is
>>> 266:      * otherwise strongly referenced when {@code condition} becomes {@code false}.
>> What happens if they are GC'd and the conditional becomes `true` later?
> There are three objects involved here: the parent observable, the new observable and the conditional.
>
> What `when` should achieve is to make the new observable easy to garbage collect when the conditional is `false` (the parent observable is considered to be long lived so GC doesn't really apply there).  The conditional itself is referred to by the new observable, so it lives at least as long as the new observable (but possibly longer).
>
> If the new observable is GC'd, then it doesn't matter what conditional is; if it becomes `true`, it would normally cause new observable to update its value, but as new observable doesn't exist anymore, and nobody referred to it, nobody is interested.  If it was already `true` then the new observable couldn't have been GC'd as parent observable would be referring to it.
>
> Strong references look like this when conditional is `true`:
>
>        conditional <-- new observable <--> parent observable
>
> When it is `false`:
>
>       conditional <-- new observable --> parent observable
>
> In the first case, GC could only happen if new observable and parent observable are both unreferenced -- as the parent is probably a much longer lived property, this means a whole window is closed or the application is exiting or some such.
>
> In the second case, GC of new observable can happen if it is unreferenced; this could happen when a small piece of UI is replaced with another piece leaving the old piece (and all its bindings) 'orphaned'.  It would not happen if it simply became invisible, as it would still be a child of the larger UI involved, and this child would in turn refer to new observable through a binding.
>
> -------------
>
> PR: https://git.openjdk.org/jfx/pull/830

From jhendrikx at openjdk.org  Thu Sep  1 13:53:56 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 1 Sep 2022 13:53:56 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
Message-ID: <N8kiDswSsA4Cv69RLvygZByhpEpsauC1Sbs-wFERG3Y=.6d5b4ac3-502a-4c8d-bd3f-7e351df3b33b@github.com>

On Wed, 31 Aug 2022 16:52:12 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename showing property to shown as it is already used in subclasses
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 258:
> 
>> 256:     /**
>> 257:      * Returns an {@code ObservableValue} that holds this value whenever the given
>> 258:      * condition evaluates to {@code true}, otherwise holds the last value when
> 
>> evaluates to
> 
> Maybe "holds"?

I've changed things in several places to use that verb.

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

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

From kcr at openjdk.org  Thu Sep  1 14:46:17 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 14:46:17 GMT
Subject: [jfx17u] RFR: 8292609: Cherry-pick WebKit 614.1 stabilization fixes
Message-ID: <pihjwC64XSgvS2pX4lQYklApAH7_ca2Y7iiep4PwCLU=.2dea7860-05da-44ff-83b2-c9c92a2aecb0@github.com>

Clean backport. CI build passed on all platforms.

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

Commit messages:
 - 8292609: Cherry-pick WebKit 614.1 stabilization fixes

Changes: https://git.openjdk.org/jfx17u/pull/81/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=81&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292609
  Stats: 1228 lines in 111 files changed: 848 ins; 102 del; 278 mod
  Patch: https://git.openjdk.org/jfx17u/pull/81.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/81/head:pull/81

PR: https://git.openjdk.org/jfx17u/pull/81

From aoqi at openjdk.org  Thu Sep  1 14:46:44 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 1 Sep 2022 14:46:44 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64
In-Reply-To: <EU_nzDoXc2i9SBny4gpunaPsP8UeXAcq8MF7hDDcPF8=.e68ba1f3-6b48-414a-b6f2-e72c844398c1@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <EU_nzDoXc2i9SBny4gpunaPsP8UeXAcq8MF7hDDcPF8=.e68ba1f3-6b48-414a-b6f2-e72c844398c1@github.com>
Message-ID: <_A_b-I-T5hux2IEI3aVWBhguaj-rK_CWvrbPBoUD30U=.e3afa852-71bd-42cc-a7dd-8709ee82c256@github.com>

On Thu, 1 Sep 2022 12:51:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The easiest way is to push an empty commit to your branch.

Thanks, @kevinrushforth . The GHA tests passed. Some additional test results were updated in the PR description.

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

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

From kcr at openjdk.org  Thu Sep  1 14:52:54 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 14:52:54 GMT
Subject: [jfx17u] RFR: 8291630: Update attribution in webkit.md file
Message-ID: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>

This is an effectively clean backport. The only difference is that one of the lines removed by the patch (removed both in jfx mainline and here) had been modified in jfx mainline to update the copyright year (modified incorrectly, as it turns out, but that's no longer relevant since the line has been removed).

The net result is that the `webkit.md` file is identical between mainline and jfx17u.

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

Commit messages:
 - 8291630: Update attribution in webkit.md file

Changes: https://git.openjdk.org/jfx17u/pull/82/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=82&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291630
  Stats: 1152 lines in 1 file changed: 931 ins; 189 del; 32 mod
  Patch: https://git.openjdk.org/jfx17u/pull/82.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u pull/82/head:pull/82

PR: https://git.openjdk.org/jfx17u/pull/82

From arapte at openjdk.org  Thu Sep  1 15:08:28 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 1 Sep 2022 15:08:28 GMT
Subject: RFR: 8217853: Cleanup in the D3D native pipeline [v7]
In-Reply-To: <gb88XEPV8_gqygbTmmrzfvVCS0Bh3EPIIdSeNrRGx8A=.be7297c5-c47a-45f4-96e1-37e2cfcdd25d@github.com>
References: <SonGvtSS_AE2MH9gOAk3_QA_JkgeRt81f-LnmaD41Hc=.33b0f727-ea4d-4c71-8f7e-a5e6d19d8dd5@github.com>
 <gb88XEPV8_gqygbTmmrzfvVCS0Bh3EPIIdSeNrRGx8A=.be7297c5-c47a-45f4-96e1-37e2cfcdd25d@github.com>
Message-ID: <TmVH6dIBYzyEdsxEIa2UX8QiYW8SG1L92gqkwYoNtiw=.d12d8015-2d49-46c8-aab7-0abc62198c3b@github.com>

On Thu, 1 Sep 2022 11:23:44 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Refactoring and renaming changes to some of the D3D pipeline files and a few changes on the Java side. These are various "leftovers" from previous issues that we didn't want to touch at the time in order to confine the scope of the changes. They will make future work easier.
>> 
>> Since there are many small changes, I'm giving a full list here:
>> 
>> **Java**
>> 
>> * `NGShape3D.java`
>>   * Extracted methods to help with the cumbersome lighting loop: one method per light type + empty light (reset light) + default point light. This section of the code would benefit from the upcoming pattern matching on `switch`.
>>   * Normalized the direction here instead of in the native code.
>>   * Ambient light is now only set when it exists (and is not black).
>> * `NGPointLight,java` - removed unneeded methods that were used by `NGShape3D` before the per-lighting methods were extracted (point light doesn't need spotlight-specific methods since they each have their own "add" method).
>> * `NGSpotLight.java` - removed `@Override` annotations as a result of the above change.
>> 
>> **Native C++**
>> 
>> * Initialized the class members of `D3DLight`, `D3DMeshView`  and `D3DPhongMaterial` in the header file instead of a more cumbersome initialization in the constructor (this is allowed since C++ 11). 
>> * `D3DLight`
>>   * Commented out unused methods. Were they supposed to be used at some point?
>>   * Renamed the `w` component to `lightOn` since it controls the number of lights for the special pixel shader variant and having it in the 4th position of the color array was confusing.
>> * `D3DPhongShader.h`
>>   * Renamed some of the register constants for more clarity.
>>   * Moved the ambient light color constant from the vertex shader to the pixel shader (see the shader section below). I don't understand the calculation of the number of registers in the comment there: "8 ambient points + 2 coords = 10". There is 1 ambient light, what are the ambient points and coordinates? In `vsConstants` there is `gAmbinetData[10]`, but it is unused.
>>   * Reduced the number of assigned vertex register for the `VSR_LIGHTS` constant since it included both position and color, but color was unused there (it was used directly in the pixel shader), so now it's only the position.
>> * `D3DMeshView.cc`
>>   * Unified the lighting loop that prepares the lights' 4-vetors that are passed to the shaders.
>>   * Removed the direction normalization as stated in the change for `NGShape3D.java`.
>>   * Reordered the shader constant assignment to be the same order as in `D3DPhongShader.h`.
>> 
>> **Native shaders**
>> * Renamed many of the variables to what I think are more descriptive names. This includes noting in which space they exist as some calculations are done in model space, some in world space, and we might need to do some in view space. For vectors, also noted if the vector is to or from (`eye` doesn't tell me if it's from or to the camera).
>> * Commented out many unused functions. I don't know what they are for, so I didn't remove them.
>> * `vsConstants`
>>   * Removed the light color from here since it's unused, only the position is.
>>   * Removed the ambient light color constant from here since it's unused, and added it to `psConstants` instead.
>> * `vs2ps`
>>   * Removed the ambient color interpolation, which frees a register (no change in performance).
>>   * Simplified the structure (what is `LocalBumpOut` and why is it called `light` and contains `LocalBump`?).
>> * `Mtl1PS` and `psMath`
>>   * Moved the shader variant constants (`#ifndef`) to `Mtl1PS` where they are used for better clarity.
>>   * Moved the lights loop to `Mtl1PS`. The calculation itself remains in `psMath`.
>> 
>> No changes in performance were measured and the behavior stayed the same.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comment

LGTM, 
suggested a minor correction in comment.
I will re-approve if any more changes.

modules/javafx.graphics/src/main/native-prism-d3d/hlsl/Mtl1VS.hlsl line 29:

> 27: #include "vsMath.h"
> 28: 
> 29: // VertexType = VsInput as defined the gradle build file

Minor:-  VertexType = VsInput`,` as defined **`in`** the **`build.gradle`** file

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

Marked as reviewed by arapte (Reviewer).

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

From kcr at openjdk.org  Thu Sep  1 15:33:26 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 15:33:26 GMT
Subject: [jfx17u] RFR: 8291630: Update attribution in webkit.md file
In-Reply-To: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>
References: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>
Message-ID: <nsxaGGjVr8U4rPlQIGIhsnqsxUU2n3g2fDPfKqIO7Y4=.d313421a-75a3-45d5-92b9-5ef546fe1945@github.com>

On Thu, 1 Sep 2022 14:47:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is an effectively clean backport. The only difference is that one of the lines removed by the patch (removed both in jfx mainline and here) had been modified in jfx mainline to update the copyright year (modified incorrectly, as it turns out, but that's no longer relevant since the line has been removed).
> 
> The net result is that the `webkit.md` file is identical between mainline and jfx17u.

Reviewer: @arapte

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

PR: https://git.openjdk.org/jfx17u/pull/82

From arapte at openjdk.org  Thu Sep  1 15:57:23 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 1 Sep 2022 15:57:23 GMT
Subject: [jfx17u] RFR: 8291630: Update attribution in webkit.md file
In-Reply-To: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>
References: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>
Message-ID: <gm7_Kgq1NAcagKWclpFnSDG0WUizE6f_o27usH_xYKw=.cc08e7b3-d70f-4786-ae1b-8566e35e7ce1@github.com>

On Thu, 1 Sep 2022 14:47:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is an effectively clean backport. The only difference is that one of the lines removed by the patch (removed both in jfx mainline and here) had been modified in jfx mainline to update the copyright year (modified incorrectly, as it turns out, but that's no longer relevant since the line has been removed).
> 
> The net result is that the `webkit.md` file is identical between mainline and jfx17u.

Marked as reviewed by arapte (Reviewer).

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

PR: https://git.openjdk.org/jfx17u/pull/82

From kcr at openjdk.org  Thu Sep  1 16:23:58 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 16:23:58 GMT
Subject: [jfx17u] Integrated: 8292609: Cherry-pick WebKit 614.1 stabilization
 fixes
In-Reply-To: <pihjwC64XSgvS2pX4lQYklApAH7_ca2Y7iiep4PwCLU=.2dea7860-05da-44ff-83b2-c9c92a2aecb0@github.com>
References: <pihjwC64XSgvS2pX4lQYklApAH7_ca2Y7iiep4PwCLU=.2dea7860-05da-44ff-83b2-c9c92a2aecb0@github.com>
Message-ID: <egB-aAtSmyrc0A1DwTBY4_-AycIfkb3G3Q3JGdpEsIw=.f7905828-4de3-47ba-a804-68fda9313315@github.com>

On Thu, 1 Sep 2022 14:39:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport. CI build passed on all platforms.

This pull request has now been integrated.

Changeset: c6370fb3
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/c6370fb3c15e8cdfc781c2e0e3cccb44091fc0d9
Stats:     1228 lines in 111 files changed: 848 ins; 102 del; 278 mod

8292609: Cherry-pick WebKit 614.1 stabilization fixes

Backport-of: da580ba4a7e743e2a49f5a2c7f3b40fa01a4438a

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

PR: https://git.openjdk.org/jfx17u/pull/81

From kcr at openjdk.org  Thu Sep  1 16:24:19 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 16:24:19 GMT
Subject: [jfx17u] Integrated: 8291630: Update attribution in webkit.md file
In-Reply-To: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>
References: <kl8eRH92W7OLfjFPf1hMsvbivkjMHcVtdXwUflQ0XNk=.18daeb29-8ef1-4744-b2df-4dcef917fe5e@github.com>
Message-ID: <uwyQNARl4MhjJu7axnh66otj5WC-EoaR2RMzjnEyfj8=.b35d7fb7-34c6-4051-b241-594229b2521a@github.com>

On Thu, 1 Sep 2022 14:47:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is an effectively clean backport. The only difference is that one of the lines removed by the patch (removed both in jfx mainline and here) had been modified in jfx mainline to update the copyright year (modified incorrectly, as it turns out, but that's no longer relevant since the line has been removed).
> 
> The net result is that the `webkit.md` file is identical between mainline and jfx17u.

This pull request has now been integrated.

Changeset: f8c5391e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/f8c5391efdc0bd7c4638d431b79754381bc6be52
Stats:     1152 lines in 1 file changed: 931 ins; 189 del; 32 mod

8291630: Update attribution in webkit.md file

Reviewed-by: arapte
Backport-of: 33534cb9e0524e91ed717b22fab667b284c52252

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

PR: https://git.openjdk.org/jfx17u/pull/82

From nlisker at openjdk.org  Thu Sep  1 17:12:49 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 1 Sep 2022 17:12:49 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <AmzaDueE1R2s0kyb632Qcy6GjuG2TuXIIJDhhXdUrnY=.300f31f6-0f6e-416c-b8b0-43b75de5377b@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
 <AmzaDueE1R2s0kyb632Qcy6GjuG2TuXIIJDhhXdUrnY=.300f31f6-0f6e-416c-b8b0-43b75de5377b@github.com>
Message-ID: <6qABDuw9RtUepX9fQATSTRcCx0J-Tl5WjcOKa_H4j-Y=.d097d1a8-9c5a-4296-bedd-4e382eff8751@github.com>

On Thu, 1 Sep 2022 13:38:46 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 274:
>> 
>>> 272:      * <p>
>>> 273:      * Returning {@code null} from the given condition is treated the same as
>>> 274:      * returning {@code false}.
>> 
>> I would rephrase to use the "holds" language instead of the "return":
>> 
>>> `{@code condition}` holding `{@code null}` is treated the same as it holding `{@code false}`
>> 
>> But is this the behavior we want? I would consider throwing when the condition is not a `true` or `false` because it's a boolean condition. `orElse` can be used to create a condition that maps `null` to something else if the user wants to accept `null`s in the condition. I'm not sure if this is really a problem.
>
> I've rephrased it as suggested.
> 
> As for `null` -- I've clarified here what it currently does (so it is not left undefined), but I have no strong feelings either way. 
> 
> I mainly choose this direction because JavaFX has so far opted to treat `null` as something to be ignored or converted to a default value (for `BooleanProperty`, you can set it to `null` using the generic setter, and it would become `false`).  Since the fluent system is basically built on top of `ObjectProperty` (and thus `Object`) we can't easily exclude the possibility of it being `null` (I have to accept `ObservableValue<Boolean>` instead of `BooleanProperty`).
> 
> ie:
> 
>      listView.layoutXProperty().setValue(null);
> 
> makes no sense at all, but JavaFX accepts it and uses `0.0`.
> 
> Ouch, just noticed it always creates (not throws) an exception (with expensive stacktrace) whenever you do that, despite it maybe not getting logged:
> 
>     @Override
>     public void setValue(Number v) {
>         if (v == null) {
>             Logging.getLogger().fine("Attempt to set double property to null, using default value instead.", new NullPointerException());
>             set(0.0);
>         } else {
>             set(v.doubleValue());
>         }
>     }

Yeah, the behavior of the layout property is not the best in my opinion. Let's see what others think.

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

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

From nlisker at openjdk.org  Thu Sep  1 17:42:18 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 1 Sep 2022 17:42:18 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <mGqkr2Mvahzn9XNEmYxXSVk1SysfY9mLB1XpVvJXaV0=.cf8cd8ae-8cc7-4f8d-b698-0ca1fce29604@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
 <mGqkr2Mvahzn9XNEmYxXSVk1SysfY9mLB1XpVvJXaV0=.cf8cd8ae-8cc7-4f8d-b698-0ca1fce29604@github.com>
Message-ID: <B9MqxJPx34wN3m4Wnlx4BNAcAGcsHR6Rtdh46uva10o=.9fea7801-20bb-4c25-ae3c-e84d81af2b6d@github.com>

On Thu, 1 Sep 2022 13:10:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 266:
>> 
>>> 264:      * {@code condition} evaluates to {@code true}. This allows this {@code ObservableValue}
>>> 265:      * and the conditional {@code ObservableValue} to be garbage collected if neither is
>>> 266:      * otherwise strongly referenced when {@code condition} becomes {@code false}.
>> 
>> What happens if they are GC'd and the conditional becomes `true` later?
>
> Edit: I missed some nuance, below is the correct version.
> 
> There are three objects involved here: the parent observable, the new observable and the conditional.
> 
> What `when` should achieve is to make the new observable and conditional easy to garbage collect when the conditional is `false` (the parent observable is considered to be long lived so GC doesn't really apply there).  The conditional and new observable refer to each other so they must have a similar life cycle.
> 
>> What happens if they are GC'd and the conditional becomes `true` later?
> 
> This can't happen, the conditional refers to the new observable, their life cycles are tied to each other.
> 
> Strong references look like this when conditional is `true`:
> 
>       conditional <--> new observable <--> parent observable
> 
> When it is `false`:
> 
>      conditional <--> new observable --> parent observable
> 
> Conditional must have a similar life cycle as new observable if your purpose is to use `when` to break strong references to allow for GC.

If I have a (dumb) method


void someMethod(ObservableValue<String> longLivedProperty) {
    ObservableValue<Boolean> condition = new SimpleBooleanProperty(true);
    ObservableValue<String> whenProperty = longLivedProperty.when(condition)
}


then shouldn't `condition` and `whenProperty` be eligible for GC even when `condition` holds `true`? If not, do I not get a memory leak because I can't change `condition` to `false` to allow garbage collection?

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

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

From nlisker at openjdk.org  Thu Sep  1 17:55:25 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 1 Sep 2022 17:55:25 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v3]
In-Reply-To: <jcnL5gTN02oIwwYbYXAy9NyZ4gqECANrEvCfpbXnOQE=.6119c16a-4ce2-406c-b7e7-1d0cb8f76933@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <jcnL5gTN02oIwwYbYXAy9NyZ4gqECANrEvCfpbXnOQE=.6119c16a-4ce2-406c-b7e7-1d0cb8f76933@github.com>
Message-ID: <GQqS17hG9eKKcJyHbxEyq3GFSkLxUqYO49CtG3H31PE=.67c43081-b454-4b93-a679-0cc4b2299f84@github.com>

On Thu, 1 Sep 2022 13:51:21 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
>> 
>> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
>> 
>> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
>> 
>>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
>> 
>> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
>> 
>> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
>> 
>> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
>> 
>> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update javadoc of "when" with better phrasing

modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 268:

> 266:      * for garbage collection while its source isn't. However, when using {@code when} this {@code ObservableValue}
> 267:      * can still be eligible for garbage collection when {@code condition} holds {@code false} and {@code condition}
> 268:      * itself is also eligible for garbage collection.

I think that these 2 paragraphs can be combined. There is some repetition in the last sentence ("However...") of the 1st paragraph. Maybe add to the 1st paragraph at the end:

> This is in contrast to the general behavior of bindings, where the binding is never eligible for GC as long as the source isn't.

If you think it's important to note that. Then remove the 2nd paragraph?

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

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

From kcr at openjdk.org  Thu Sep  1 21:55:59 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 21:55:59 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <IvhiipxaVw_tJWqz_Kk7fOOrQ-kvkc2yMQMVp6M_ApM=.6411525f-0e1b-4989-b51b-c5e7d0ce74c1@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
 <IvhiipxaVw_tJWqz_Kk7fOOrQ-kvkc2yMQMVp6M_ApM=.6411525f-0e1b-4989-b51b-c5e7d0ce74c1@github.com>
Message-ID: <EUiNikwD4n7k0M5IOPsRDhbZZNmDQHkuXMycdSJPErA=.4133120b-1d84-468a-bc32-6a83c000b337@github.com>

On Wed, 24 Aug 2022 16:16:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> the problem, as i see it, is that dispose() of the previous skin is executed after the new skin is attached. literally nothing can be done to work around the issues caused by this design mistake, but to fix it outright - dispose() the old skin first, then install the new one.
> 
> then, and only then, all the requirements concerning user-settable properties and clean uninstallation can be met.

I agree with this conclusion. What might help is a concrete example of an application that would hit this bug, and an explanation of how the app would fail. That way we'll know that this new API is enabling the fixing of actual (as opposed to theoretical) problems.

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

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

From kcr at openjdk.org  Thu Sep  1 22:01:47 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 22:01:47 GMT
Subject: RFR: 8279514: NPE on clearing value of IntegerSpinnerValueFactory
 [v2]
In-Reply-To: <FhNO9PYcXmSNq2JOAXMIcj7MTgt2zg-_BUQIoqYrvEY=.64f9221c-1d16-4ccc-a4b3-9828ac4e9d65@github.com>
References: <dju911lYdrm2VXawY0dIUOnsFoYUbVN2Cm1R_IYnF_0=.da5c9cdf-5ca0-493b-a5d8-065eb0550247@github.com>
 <FhNO9PYcXmSNq2JOAXMIcj7MTgt2zg-_BUQIoqYrvEY=.64f9221c-1d16-4ccc-a4b3-9828ac4e9d65@github.com>
Message-ID: <bQw9CR-rexBXF8OiUcpe7ZF1pOJsbdZ9k1Xrk_nSUQY=.fd8f3f7b-fa3c-4bea-8949-9dab0576903e@github.com>

On Wed, 10 Aug 2022 09:40:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> A null check has been added to below SpinnerValueFactory classes in valueProperty() ChangeListeners-
>> - `IntegerSpinnerValueFactory`
>> - `LocalDateSpinnerValueFactory`
>> - `LocalTimeSpinnerValueFactory`
>> - `ListSpinnerValueFactory`
>> 
>> Added 5 tests that detect NPE for above 4 Spinner factories.
>> Only `DoubleSpinnerValueFactory` already had a valid null check - so the test for it passes before and after.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify null asserts

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From duke at openjdk.org  Thu Sep  1 22:56:16 2022
From: duke at openjdk.org (Douglas Held)
Date: Thu, 1 Sep 2022 22:56:16 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
Message-ID: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>

Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.

It's my first commit, so please comment if I haven't followed the commit protocol per expectations.

Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

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

Commit messages:
 - Update ScrollPane.java

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

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

From kcr at openjdk.org  Thu Sep  1 22:56:16 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 1 Sep 2022 22:56:16 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <s8VkWvMDn2P3O3cPbknFTTT6mvOw7TU2jvnku-aim2g=.6fb46536-f8ca-4cf6-8e0b-2e61970771b9@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Note, I no longer have a handle to the JBS title for record 9073896.

That's because it is a temporary, internal ID. Once it is transferred to the JDK project in JBS, it will be assigned a (different) permanent ID. I just did that, so here it is:

https://bugs.openjdk.org/browse/JDK-8293171

You will need to change this PR title to match the bug ID and title of the JBS issue.

> Please allow for a few business days to verify that your employer has signed the OCA.

@robilad will reach out to you regarding this.

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

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

From angorya at openjdk.org  Thu Sep  1 23:03:53 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 1 Sep 2022 23:03:53 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <nlz6LrDqz0-Z32GfkitCW9brT4m9th9_jnCmoohUVDE=.9c2c000d-526b-411d-b5ea-050efb361133@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
> 
> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
> 
> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

thank you for fixing this!

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

Marked as reviewed by angorya (Author).

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

From aghaisas at openjdk.org  Fri Sep  2 03:18:02 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 2 Sep 2022 03:18:02 GMT
Subject: Integrated: 8279514: NPE on clearing value of
 IntegerSpinnerValueFactory
In-Reply-To: <dju911lYdrm2VXawY0dIUOnsFoYUbVN2Cm1R_IYnF_0=.da5c9cdf-5ca0-493b-a5d8-065eb0550247@github.com>
References: <dju911lYdrm2VXawY0dIUOnsFoYUbVN2Cm1R_IYnF_0=.da5c9cdf-5ca0-493b-a5d8-065eb0550247@github.com>
Message-ID: <tHh-7cCEWV8t3HsS76ZXF57z2bL7z2aIvZ8uBrggYuE=.b17d5bd8-9005-4d54-8ae5-18aa2d8996b3@github.com>

On Wed, 10 Aug 2022 06:56:50 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> A null check has been added to below SpinnerValueFactory classes in valueProperty() ChangeListeners-
> - `IntegerSpinnerValueFactory`
> - `LocalDateSpinnerValueFactory`
> - `LocalTimeSpinnerValueFactory`
> - `ListSpinnerValueFactory`
> 
> Added 5 tests that detect NPE for above 4 Spinner factories.
> Only `DoubleSpinnerValueFactory` already had a valid null check - so the test for it passes before and after.

This pull request has now been integrated.

Changeset: d1a7ebdc
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d1a7ebdc3374066f1c1f2739551185cbb34bdf96
Stats:     46 lines in 2 files changed: 46 ins; 0 del; 0 mod

8279514: NPE on clearing value of IntegerSpinnerValueFactory

Reviewed-by: mhanl, kcr

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

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

From jhendrikx at openjdk.org  Fri Sep  2 03:50:53 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Sep 2022 03:50:53 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <B9MqxJPx34wN3m4Wnlx4BNAcAGcsHR6Rtdh46uva10o=.9fea7801-20bb-4c25-ae3c-e84d81af2b6d@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
 <mGqkr2Mvahzn9XNEmYxXSVk1SysfY9mLB1XpVvJXaV0=.cf8cd8ae-8cc7-4f8d-b698-0ca1fce29604@github.com>
 <B9MqxJPx34wN3m4Wnlx4BNAcAGcsHR6Rtdh46uva10o=.9fea7801-20bb-4c25-ae3c-e84d81af2b6d@github.com>
Message-ID: <E3o500emUn2I77dPlF1Rr1t8Lf1A9lVCbrbQnUV4zhw=.ce9f71e5-e956-40c4-ae40-eabfadbf9e4a@github.com>

On Thu, 1 Sep 2022 17:38:39 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Edit: I missed some nuance, below is the correct version.
>> 
>> There are three objects involved here: the parent observable, the new observable and the conditional.
>> 
>> What `when` should achieve is to make the new observable and conditional easy to garbage collect when the conditional is `false` (the parent observable is considered to be long lived so GC doesn't really apply there).  The conditional and new observable refer to each other so they must have a similar life cycle.
>> 
>>> What happens if they are GC'd and the conditional becomes `true` later?
>> 
>> This can't happen, the conditional refers to the new observable, their life cycles are tied to each other.
>> 
>> Strong references look like this when conditional is `true`:
>> 
>>       conditional <--> new observable <--> parent observable
>> 
>> When it is `false`:
>> 
>>      conditional <--> new observable --> parent observable
>> 
>> Conditional must have a similar life cycle as new observable if your purpose is to use `when` to break strong references to allow for GC.
>
> If I have a (dumb) method
> 
> 
> void someMethod(ObservableValue<String> longLivedProperty) {
>     ObservableValue<Boolean> condition = new SimpleBooleanProperty(true);
>     ObservableValue<String> whenProperty = longLivedProperty.when(condition)
> }
> 
> 
> then shouldn't `condition` and `whenProperty` be eligible for GC even when `condition` holds `true`? If not, do I not get a memory leak because I can't change `condition` to `false` to allow garbage collection?

Well, this specific example, yes, they'll be both eligible for GC, but that's because you're not observing `whenProperty` anywhere. When not observed, it won't create a listener on `longLivedProperty`.

Assuming that `whenProperty` is observed and with `condition` being always `true` it is basically the same as:

     ObservableValue<String> whenProperty = longLivedProperty.map(x -> x);

As long as `whenProperty` is observed, `longLivedProperty` has a direct reference to it (via listener).  With `when` however, the `condition` can be used to (temporarily or permanently) break this reference. You could set it to `false` in `dispose` for example, triggering the unregistration of the listener on `longLivedProperty` (for multiple properties at once if desired):

      ObservableValue<Boolean> active = new SimpleBooleanProperty(true);

      MySkin() {
           getSkinnable().textProperty().when(active).addListener(this::updateSkinStuffs);
           getSkinnable().fontProperty().when(active).addListener(this::updateSkinStuffs);
           getSkinnable().wrapTextProperty().when(active).addListener(this::updateSkinStuffs);
      }

      void dispose() {
           active.set(false);  // kills all listeners/bindings/etc in a single line
      }

Or the other case I really like:

     label.textProperty().bind(longLivedProperty.when(label::isShownProperty));

As long as `label` is showing, it takes updates from `longLivedProperty`; if the screen is closed, it detaches, and (assuming all such bindings are nicely detached) the label (and the rest of the UI it may be part of) can be GC'd without problem.

If you kept a reference to the UI (containing that label), then you also kept a reference to the label, to its text property, and to that binding with then `when` in it -- making that UI visible again restores the listener on `longLivedProperty` and the label immediately receives whatever the latest value is in that property if it changed while the UI was invisible.

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

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

From jhendrikx at openjdk.org  Fri Sep  2 04:14:49 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 2 Sep 2022 04:14:49 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <qwL4H2ySnx79zLHQr1H7WdDJ0Cr_cUVF_fwf7oc_4Wg=.ed54f24c-00f6-4800-88f9-14087d0816a3@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
> 
> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
> 
> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

You'll need to update the copyright year on the file you changed:

    Copyright (c) 2010, 2022, Oracle and/or its affiliates. All rights reserved.

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

Changes requested by jhendrikx (Author).

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

From duke at openjdk.org  Fri Sep  2 18:45:21 2022
From: duke at openjdk.org (Douglas Held)
Date: Fri, 2 Sep 2022 18:45:21 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
Message-ID: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>

Replacement pull request per https://github.com/openjdk/jfx/pull/887#pullrequestreview-1094288791

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

Commit messages:
 - Update ScrollPane.java
 - Merge pull request #1 from douglasheldoracle/douglasheldoracle-jfx-doc-typos-1
 - Update ScrollPane.java

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

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

From duke at openjdk.org  Fri Sep  2 18:52:14 2022
From: duke at openjdk.org (Douglas Held)
Date: Fri, 2 Sep 2022 18:52:14 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
References: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
Message-ID: <DRRfiemGWiJP-KG_Fmuxnv_RoS8KBy0xc8b4121IzRc=.3cb5eedf-913f-472c-aa30-0d51823a66a2@github.com>

On Fri, 2 Sep 2022 18:39:42 GMT, Douglas Held <duke at openjdk.org> wrote:

> Replacement pull request per https://github.com/openjdk/jfx/pull/887#pullrequestreview-1094288791

> ?? @douglasheldoracle ...t**hese changes will be squashed**....

I believe that is what is expected.

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

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

From angorya at openjdk.org  Fri Sep  2 18:52:15 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Sep 2022 18:52:15 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
References: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
Message-ID: <1Qxo_omQZKuKttVbkuKuhYRtKgiy0hqu_DbVYGIz5IY=.273def6f-de0b-46a8-be63-c1927f881081@github.com>

On Fri, 2 Sep 2022 18:39:42 GMT, Douglas Held <duke at openjdk.org> wrote:

> Replacement pull request per https://github.com/openjdk/jfx/pull/887#pullrequestreview-1094288791

You could have just pushed another commit to your original branch douglasheldoracle-jfx-doc-typos-1.  The original PR would update automatically, checks re-run, etc.

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

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

From angorya at openjdk.org  Fri Sep  2 21:24:54 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Sep 2022 21:24:54 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <EUiNikwD4n7k0M5IOPsRDhbZZNmDQHkuXMycdSJPErA=.4133120b-1d84-468a-bc32-6a83c000b337@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
 <IvhiipxaVw_tJWqz_Kk7fOOrQ-kvkc2yMQMVp6M_ApM=.6411525f-0e1b-4989-b51b-c5e7d0ce74c1@github.com>
 <EUiNikwD4n7k0M5IOPsRDhbZZNmDQHkuXMycdSJPErA=.4133120b-1d84-468a-bc32-6a83c000b337@github.com>
Message-ID: <vgMVutItUObbUfHWcBavZ5Y-wSdbTfTyFp1mZYHfnUY=.67b70498-5978-47e3-91d1-d9f54cd454a7@github.com>

On Thu, 1 Sep 2022 21:52:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> What might help is a concrete example of an application that would hit this bug, and an explanation of how the app would fail.

Let's consider this scenario: an application sets a custom input method on a control, followed by the user loading a new skin via a menu  (i.e. after the default skin has been installed).

// 1. control is created
control = new Control();

// 2. user wants to provide a custom input method
control.setInputMethodRequests(USER1);

// 3. Stage.show applies CSS and creates a default skin
control.setInputMethodRequests(SKIN1);

// 4. user loads a new L&F via menu

// 5. new skin is created, constructor sets the control property while the old skin is still attached
new UserSkin(control);
control.setInputMethodRequests(SKIN2);

// 6. user calls setSkin() to install the new skin
oldSkin.dispose()
control.setInputMethodRequests(null); // current implementation


The problem here is that the skin code is unable to decide in step 5 whether to overwrite the input method or keep the current value - because it does not know whether the current value was set by the user (step 2) or the old skin (step 3).  Furthermore, if we were to add any kind of conditional logic to step 3 and 5, the problem moves down the line to the dispose(0 method in step 6. since at that moment it is unclear whether the current value was set by the user or by the new skin.

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

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

From falcon.sheep at gmail.com  Sat Sep  3 05:18:42 2022
From: falcon.sheep at gmail.com (Abu Abdullah)
Date: Sat, 3 Sep 2022 09:18:42 +0400
Subject: JavaFX Media Enhancements Survey
In-Reply-To: <EFE2E1A8-B200-48E1-9943-5DDFC50BF417@oracle.com>
References: <EFE2E1A8-B200-48E1-9943-5DDFC50BF417@oracle.com>
Message-ID: <CAD678-BsKxeSQ+=ZHCvMisAtZHd=T_xN_-ei0s-qTKKDw=E-Kw@mail.gmail.com>

1) ID3 metadata support for MP4 files.
Rating: 3

2) Support for multichannel audio rendering (more than 2 channels).
Rating: 3

3) Subtitles support for MP4 files and HTTP Live Streaming.
Rating: 3

4) HDR support.
Rating: 2

5) InputStream for AudioClip with PCM support.
Rating: 3

6) Public APIs to access raw audio and video frames.
Rating: 3

7) Support for multiple audio tracks in MP4 files and alternate audio
streams in HTTP Live Streaming provided via #EXT-X-MEDIA tag.
Rating: 3

8) Media recording/capture.
Rating: 2

9) Opus audio codec.
Rating: 1

10) MKV (matroska) file format.
Rating: 3

11) WebM/VP9/Opus
Rating: 2

12) RTSP (Real Time Streaming Protocol)
Rating: 1

13) Pluggable codecs
Rating: 3

On Fri, Jul 22, 2022 at 8:48 AM Alexander Matveev
<alexander.matveev at oracle.com> wrote:
>
> Greetings!
>
> We are running a little survey to get input on possible JavaFX Media enhancements. Below you can find a list of possible JavaFX Media enhancements, which we might implement in the future, although there is no commitment. We will appreciate if you can rate each enhancement on how useful/important it will be for JavaFX mainline. Put ?1" for very important and I need this feature; ?2" for looks important, but I am not planning to use it; ?3" for not important and I do not need it.
>
> 1) ID3 metadata support for MP4 files.
> Rating:
>
> 2) Support for multichannel audio rendering (more than 2 channels).
> Rating:
>
> 3) Subtitles support for MP4 files and HTTP Live Streaming.
> Rating:
>
> 4) HDR support.
> Rating:
>
> 5) InputStream for AudioClip with PCM support.
> Rating:
>
> 6) Public APIs to access raw audio and video frames.
> Rating:
>
> 7) Support for multiple audio tracks in MP4 files and alternate audio streams in HTTP Live Streaming provided via #EXT-X-MEDIA tag.
> Rating:
>
> 8) Media recording/capture.
> Rating:
>
> 9) Opus audio codec.
> Rating:
>
> 10) MKV (matroska) file format.
> Rating:
>
> 11) WebM/VP9/Opus
> Rating:
>
> 12) RTSP (Real Time Streaming Protocol)
> Rating:
>
> 13) Pluggable codecs
> Rating:
>
> Please, list any additional media formats (codecs) / protocols you would like to see in upcoming JavaFX releases:
>
> List any additional media enhancements you consider important to JavaFX Media:
>
> Thanks,
> Alexander

From gli at openjdk.org  Sat Sep  3 10:10:08 2022
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 3 Sep 2022 10:10:08 GMT
Subject: RFR: 8293338: Enable manually triggering the GitHub workflow
Message-ID: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>

Hi all,

In [8293214: Add support for Linux/LoongArch64](https://github.com/openjdk/jfx/pull/888), the contributor was suggested  to push a empty commit to trigger the GHA tests. But actually it seems not a good dev flow because the newly added commits are not related to the issue the patch want to solve.

The GitHub provides related configuration to enable the develoers to trigger the workflow manually. Please see the documents [1][2] for more detail. This patch adds such config to enable it.

Thanks for taking the time to review.

[1] https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
[2] https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch

Best Regards,
-- Guoxiong

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

Commit messages:
 - JDK-8293338

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

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

From fastegal at openjdk.org  Sat Sep  3 10:18:47 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Sat, 3 Sep 2022 10:18:47 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
Message-ID: <2SmmCOEg8EYPnEfQPxFmljcELbI30gpAoc62MoEzky4=.d2fe4c50-2f79-43dc-9cf9-9f9a6534ed09@github.com>

On Fri, 12 Aug 2022 18:15:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - added Skin.install()
>> - javadoc changes for Skinnable.setSkin(Skin)
>> 
>> no code changes for Skinnable.setSkin(Skin) yet.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290844: review comments

that's basically the problem we identified as not solvable by current api, though I would formulate slightly differently: there are two bugs in our current implementation, one in step 3 and one in step 6

    // bug in step 3: should be replacing the property only if not set be the user
    if  (control.getInputMethodRequest() == USER1) { // no means to detect user vs. skin installed
             // do nothing
    }  else {
            control.setInputMethodRequest(SKIN1);
    }

    // bug in step 6: nulling unconditionally in dispose is wrong, should only do if installed by the skin
    if (control.getInputMethodRequest() == SKIN1) control.setInputMethodRequest(null);

Yes: there is no way to differentiate USER1 from SKIN1 in step 5 without new API :) There are options besides a new life-cycle, but I agree that adding a life-cycle state is the most clean.

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

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

From jhendrikx at openjdk.org  Sun Sep  4 19:49:42 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Sep 2022 19:49:42 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v4]
In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
Message-ID: <eN3dZMOxmHn4gp17E-kamzPntKK7Kvi1PXjxJDgcSp8=.71e5b9d2-f835-44d7-8943-af87ec1c57d5@github.com>

> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
> 
> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
> 
> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
> 
>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
> 
> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
> 
> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
> 
> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
> 
> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Small wording fixes

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/830/files
  - new: https://git.openjdk.org/jfx/pull/830/files/07e9d88a..13c6e39a

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

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

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

From jhendrikx at openjdk.org  Sun Sep  4 19:49:45 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Sep 2022 19:49:45 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v3]
In-Reply-To: <GQqS17hG9eKKcJyHbxEyq3GFSkLxUqYO49CtG3H31PE=.67c43081-b454-4b93-a679-0cc4b2299f84@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <jcnL5gTN02oIwwYbYXAy9NyZ4gqECANrEvCfpbXnOQE=.6119c16a-4ce2-406c-b7e7-1d0cb8f76933@github.com>
 <GQqS17hG9eKKcJyHbxEyq3GFSkLxUqYO49CtG3H31PE=.67c43081-b454-4b93-a679-0cc4b2299f84@github.com>
Message-ID: <Ds9jnf1Q3oIxueRyWQtkFAjaZSpvxIhlEqlEoFLX3aI=.fe644049-a201-44ea-a213-c68ae73076ec@github.com>

On Thu, 1 Sep 2022 17:51:20 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update javadoc of "when" with better phrasing
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 268:
> 
>> 266:      * for garbage collection while its source isn't. However, when using {@code when} this {@code ObservableValue}
>> 267:      * can still be eligible for garbage collection when {@code condition} holds {@code false} and {@code condition}
>> 268:      * itself is also eligible for garbage collection.
> 
> I think that these 2 paragraphs can be combined. There is some repetition in the last sentence ("However...") of the 1st paragraph. Maybe add to the 1st paragraph at the end:
> 
>> This is in contrast to the general behavior of bindings, where the binding is never eligible for GC as long as the source isn't.
> 
> If you think it's important to note that. Then remove the 2nd paragraph?

Yes, I've changed it.  I had to rephrase it to: "This is in contrast to the general behavior of bindings, where the binding is only eligible for garbage collection when not observed itself." -- with `when` there are two options for allowing GC, the one I just mentioned and when `condition` is `false` and not referenced itself.

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

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

From jhendrikx at openjdk.org  Sun Sep  4 19:49:48 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 4 Sep 2022 19:49:48 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v2]
In-Reply-To: <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <OtzMZt3XK5a333Krf5cuYZxMgjieDovDOW7kPGaATNU=.4bf64236-feec-4a53-abcf-cbdb4604ff4a@github.com>
 <4KddGY0QfTivXdzMboTGsp5rOXaPYtCj1keuM43sOx4=.d08216e0-cbdc-43b7-babc-178e61bcc1ae@github.com>
Message-ID: <9cd_kWi5FKL5r-_XcGUlTkP797Q02QENPiDr3sS3VlI=.2a25dbd3-d704-4392-8872-e9d140a5a176@github.com>

On Wed, 31 Aug 2022 17:07:17 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename showing property to shown as it is already used in subclasses
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 271:
> 
>> 269:      * for garbage collection while source isn't. However, using {@code when} this {@code ObservableValue}
>> 270:      * can still be eligible for garbage collection when the condition is {@code false} and the
>> 271:      * conditional itself is also eligible for garbage collection.
> 
> Wasn't this explained in the previous paragraph?

I rephrased it now as per your suggestion.

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

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

From aghaisas at openjdk.org  Mon Sep  5 06:01:35 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 5 Sep 2022 06:01:35 GMT
Subject: RFR: 8087673: [TableView] TableView and TreeTableView menu button
 overlaps columns when using a constrained resize policy. [v3]
In-Reply-To: <l4D2COJccAAV8UHxWqjUpKmgTvj8XujQlD2fH3F8yhM=.1eed446e-097b-4488-aead-a4fdb3957734@github.com>
References: <oT2Rgu0gYV1-V358AcAlctFPzbzMdmCMZRDHGH1lpyE=.01d63447-ccc9-467f-918d-05c1b38b625c@github.com>
 <l4D2COJccAAV8UHxWqjUpKmgTvj8XujQlD2fH3F8yhM=.1eed446e-097b-4488-aead-a4fdb3957734@github.com>
Message-ID: <buH7i0le46uzSAi9beDUAEsfnL3rAof5jgs3Z4Ruu7c=.726ad879-e671-4992-9684-3b94db9aff5c@github.com>

On Tue, 30 Aug 2022 11:21:26 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> The corner region is currently laid out with this assumption:
>> 
>>         // position the top-right rectangle (which sits above the scrollbar)
>> 
>> However, the vertical scrollbar is not always visible. Therefore, when that is the case, the corner region is laid out on top of the table column headers, overlapping any of their graphic or text content. In case of the last visible column header, it is not always possible to scroll horizontally to see the full content, either because of a constrained resize policy or because there is no more space left after the last column.
>> 
>> This PR fixes this issue by considering as padding for the last visible column header the presence of the corner region over it, only when the vertical scrollbar is not visible and the corner region is.
>> 
>> A couple of tests have been added to both TableViewTest and TreeTableViewTest.
>> 
>> Test 1: Before and after the changes :
>> 
>> <img width="312" alt="image" src="https://user-images.githubusercontent.com/2043230/187190928-efc29e38-8de2-4daf-8eff-a218d6fae181.png">
>> <img width="312" alt="image" src="https://user-images.githubusercontent.com/2043230/187190991-deaa88b3-2f52-48bc-b3ec-107a5151f7b5.png">
>> 
>> Test 2:  Before (sort arrow is there, but not visible) and after the changes:
>> <img width="412" alt="image" src="https://user-images.githubusercontent.com/2043230/187191310-fb348d8c-84fc-4254-a1a5-91811bf09b79.png">
>> <img width="412" alt="image" src="https://user-images.githubusercontent.com/2043230/187191358-0d4937cb-b3b4-4530-9489-ff8cbf0c8443.png">
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor tests to use global stageloader

Looks good to me!

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

Marked as reviewed by aghaisas (Reviewer).

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

From daniel.peintner at gmail.com  Mon Sep  5 13:34:24 2022
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Mon, 5 Sep 2022 15:34:24 +0200
Subject: ConcurrentModificationException when calling stage.show()
Message-ID: <CAAoP7T6sdiVkhEf0t6RP5CGkNjnv2mE-BJ+1+rRoiuJZChZiuA@mail.gmail.com>

All,

I have a strange issue popping up once in a while.
I have an application (FXML+ Controller) that has a "new" button opening a
new window. In 99% percent of the cases this works just fine.

In some rare cases though, stage.show() fails due to a
ConcurrentModificationException. Since this issue does not happen in my
code but rather in JavaFX code I wanted to ask whether there is a specific
prerequisite I am not aware of or whether this is a bug in JavaFX.

Attached the stack trace. Unfortunately I am not able to create a
reproducible example that fails always.

I am grateful for any tip.

Thanks,

-- Daniel


Exception in thread "JavaFX Application Thread" java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1857)
at
javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1724)
at
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
at javafx.event.Event.fireEvent(Event.java:198)
at javafx.scene.Node.fireEvent(Node.java:8797)
at javafx.scene.control.Button.fire(Button.java:203)
at
com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:208)
at com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
at
com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
at
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
at javafx.event.Event.fireEvent(Event.java:198)
at javafx.scene.Scene$MouseHandler.process(Scene.java:3881)
at javafx.scene.Scene.processMouseEvent(Scene.java:1874)
at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2607)
at
com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411)
at
com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:301)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at
com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:450)
at
com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
at
com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449)
at com.sun.glass.ui.View.handleMouseEvent(View.java:551)
at com.sun.glass.ui.View.notifyMouse(View.java:937)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at
com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.javafx.reflect.Trampoline.invoke(MethodUtil.java:77)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.javafx.reflect.MethodUtil.invoke(MethodUtil.java:275)
at com.sun.javafx.fxml.MethodHelper.invoke(MethodHelper.java:84)
at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1854)
... 50 more
Caused by: java.util.ConcurrentModificationException
at
java.base/java.util.AbstractList$Itr.checkForComodification(AbstractList.java:399)
at java.base/java.util.AbstractList$Itr.next(AbstractList.java:368)
at
javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:810)
at
javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:811)
at javafx.scene.control.skin.MenuBarSkin.rebuildUI(MenuBarSkin.java:1017)
at javafx.scene.control.skin.MenuBarSkin.<init>(MenuBarSkin.java:356)
at javafx.scene.control.MenuBar.createDefaultSkin(MenuBar.java:202)
at javafx.scene.control.Control.doProcessCSS(Control.java:899)
at javafx.scene.control.Control$1.doProcessCSS(Control.java:89)
at
com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67)
at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
at javafx.scene.Node.processCSS(Node.java:9477)
at javafx.scene.Scene.doCSSPass(Scene.java:572)
at javafx.scene.Scene.preferredSize(Scene.java:1770)
at javafx.scene.Scene$2.preferredSize(Scene.java:396)
at com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
at javafx.stage.Window$12.invalidated(Window.java:1163)
at
javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
at
javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
at javafx.stage.Window.setShowing(Window.java:1239)
at javafx.stage.Window.show(Window.java:1254)
at javafx.stage.Stage.show(Stage.java:277)
at
com.foo.MainLayoutController.openNewWindow(MainLayoutController.java:3851)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220905/53173252/attachment-0001.htm>

From kcr at openjdk.org  Mon Sep  5 14:13:44 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 14:13:44 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <qwL4H2ySnx79zLHQr1H7WdDJ0Cr_cUVF_fwf7oc_4Wg=.ed54f24c-00f6-4800-88f9-14087d0816a3@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
 <qwL4H2ySnx79zLHQr1H7WdDJ0Cr_cUVF_fwf7oc_4Wg=.ed54f24c-00f6-4800-88f9-14087d0816a3@github.com>
Message-ID: <aQnXmjqHhOgpR8X7vHjKtbFdCmU_kllTzE5hChi7Szk=.840d7590-d095-4b5a-b3be-398ea05f8f21@github.com>

On Fri, 2 Sep 2022 04:11:08 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> You'll need to update the copyright year on the file you changed:

That's an optional step, and in general I don't ask that developers do this (although I certainly don't object if they do). We (Ambarish) periodically run a script that bumps all the needed copyrights.

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

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

From kcr at openjdk.org  Mon Sep  5 14:16:59 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 14:16:59 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
References: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
Message-ID: <b4-J2uxxtggNmCL2KTZOioq9BBrqn2on7LUgb9Tt6qc=.00336912-c5ff-46bc-8dfb-d0f5bbb9c163@github.com>

On Fri, 2 Sep 2022 18:39:42 GMT, Douglas Held <duke at openjdk.org> wrote:

> Replacement pull request per https://github.com/openjdk/jfx/pull/887#pullrequestreview-1094288791

Not only could you have done this, it is way too confusing to do otherwise. I am closing this PR.

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

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

From kcr at openjdk.org  Mon Sep  5 14:16:59 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 14:16:59 GMT
Subject: Withdrawn: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
References: <okNlNnMrL-9lRMGN23e19XAD28SgvSYdotHZyeVfwYQ=.d52d204a-0898-4323-b8e8-4e836f7cb56b@github.com>
Message-ID: <VDIAaUQhflEzJ_Uxjn83i1fcOwTn9oYrYFe8lmVsewI=.10387127-99b9-4b85-9eaf-72f9d6194a7e@github.com>

On Fri, 2 Sep 2022 18:39:42 GMT, Douglas Held <duke at openjdk.org> wrote:

> Replacement pull request per https://github.com/openjdk/jfx/pull/887#pullrequestreview-1094288791

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Mon Sep  5 14:17:50 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 14:17:50 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <niwVnts3g_LAA8FSGg80VFXoKk0_MIQAhfrkDW_XHjs=.5d296d0b-8228-4bee-88c4-7e0ab08aef85@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
> 
> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
> 
> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

@douglasheldoracle regardless of whether or not you fix this, please do _not_ create a new pull request. Any update to a PR based on review comments should be done by pushing new commits to your feature branch. I closed PR #890

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

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

From kcr at openjdk.org  Mon Sep  5 15:11:57 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 15:11:57 GMT
Subject: RFR: 8293338: Enable manually triggering the GitHub workflow
In-Reply-To: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>
References: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>
Message-ID: <e7N1RgtPgSd4b9lf6lChDQTyFGh8YiX49SQiqx-PpPY=.8ca903d2-3b65-44b9-85c7-a313b60df989@github.com>

On Sat, 3 Sep 2022 09:56:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> In [8293214: Add support for Linux/LoongArch64](https://github.com/openjdk/jfx/pull/888), the contributor was suggested  to push a empty commit to trigger the GHA tests. But actually it seems not a good dev flow because the newly added commits are not related to the issue the patch want to solve.
> 
> The GitHub provides related configuration to enable the develoers to trigger the workflow manually. Please see the documents [1][2] for more detail. This patch adds such config to enable it.
> 
> Thanks for taking the time to review.
> 
> [1] https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
> [2] https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
> 
> Best Regards,
> -- Guoxiong

This seems fine. I see that the [jdk](https://github.com/openjdk/jdk) repo already enables [manually triggering the GHA workflow](https://github.com/openjdk/jdk/blob/master/.github/workflows/main.yml#L33). I tested it in my repo and it works as expected.

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

Marked as reviewed by kcr (Lead).

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

From duke at openjdk.org  Mon Sep  5 15:41:30 2022
From: duke at openjdk.org (Douglas Held)
Date: Mon, 5 Sep 2022 15:41:30 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <hle9W3x7X_S9rNhW1KvNS_XmKqfH6nSXWFGJtkJ_dN0=.d9981816-5266-42d2-8449-741e93b577f0@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
> 
> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
> 
> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

> ### Progress
> * [x]  Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer))
> * [x]  Change must not contain extraneous whitespace
> * [x]  Commit message must refer to an issue

As the requestor am I responsible for checking the boxes in this first automated comment? (I have checked the final one now)

> Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

Is my GitHub user account now OCA-verified for future requests? And if not, where can I go to try to more adequately resolve the OCA flag?

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

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

From kcr at openjdk.org  Mon Sep  5 15:45:48 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 15:45:48 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <hle9W3x7X_S9rNhW1KvNS_XmKqfH6nSXWFGJtkJ_dN0=.d9981816-5266-42d2-8449-741e93b577f0@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
 <hle9W3x7X_S9rNhW1KvNS_XmKqfH6nSXWFGJtkJ_dN0=.d9981816-5266-42d2-8449-741e93b577f0@github.com>
Message-ID: <--1vOSsYFI6Yn5C7gG0QDvP-_-6CsGk7OHFS_HJDONA=.9ea03ae6-0b8f-44e7-8afb-999da1b6021a@github.com>

On Mon, 5 Sep 2022 15:35:32 GMT, Douglas Held <duke at openjdk.org> wrote:

> As the requestor am I responsible for checking the boxes in this first automated comment? (I have checked the final one now)

No. As you may notice, the Skara bot has (correctly) unchecked the review box.

> Is my GitHub user account now OCA-verified for future requests?

Yes, verifying your GitHub account is a one-time step good for all subsequent PRs (in any openjdk project).

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

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

From jpereda at openjdk.org  Mon Sep  5 15:48:45 2022
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 5 Sep 2022 15:48:45 GMT
Subject: Integrated: 8087673: [TableView] TableView and TreeTableView menu
 button overlaps columns when using a constrained resize policy.
In-Reply-To: <oT2Rgu0gYV1-V358AcAlctFPzbzMdmCMZRDHGH1lpyE=.01d63447-ccc9-467f-918d-05c1b38b625c@github.com>
References: <oT2Rgu0gYV1-V358AcAlctFPzbzMdmCMZRDHGH1lpyE=.01d63447-ccc9-467f-918d-05c1b38b625c@github.com>
Message-ID: <111NSirD_z1a1ODWT5nXEMviAe-Z6ZJ-1_7sshi2vYI=.d8420edc-a932-4071-bec6-7deefd90b490@github.com>

On Mon, 29 Aug 2022 11:37:46 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> The corner region is currently laid out with this assumption:
> 
>         // position the top-right rectangle (which sits above the scrollbar)
> 
> However, the vertical scrollbar is not always visible. Therefore, when that is the case, the corner region is laid out on top of the table column headers, overlapping any of their graphic or text content. In case of the last visible column header, it is not always possible to scroll horizontally to see the full content, either because of a constrained resize policy or because there is no more space left after the last column.
> 
> This PR fixes this issue by considering as padding for the last visible column header the presence of the corner region over it, only when the vertical scrollbar is not visible and the corner region is.
> 
> A couple of tests have been added to both TableViewTest and TreeTableViewTest.
> 
> Test 1: Before and after the changes :
> 
> <img width="312" alt="image" src="https://user-images.githubusercontent.com/2043230/187190928-efc29e38-8de2-4daf-8eff-a218d6fae181.png">
> <img width="312" alt="image" src="https://user-images.githubusercontent.com/2043230/187190991-deaa88b3-2f52-48bc-b3ec-107a5151f7b5.png">
> 
> Test 2:  Before (sort arrow is there, but not visible) and after the changes:
> <img width="412" alt="image" src="https://user-images.githubusercontent.com/2043230/187191310-fb348d8c-84fc-4254-a1a5-91811bf09b79.png">
> <img width="412" alt="image" src="https://user-images.githubusercontent.com/2043230/187191358-0d4937cb-b3b4-4530-9489-ff8cbf0c8443.png">

This pull request has now been integrated.

Changeset: 2baa10ee
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/2baa10eed777574e40e5104278e8690941911018
Stats:     256 lines in 4 files changed: 247 ins; 4 del; 5 mod

8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy.

Reviewed-by: angorya, aghaisas

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

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

From gli at openjdk.org  Mon Sep  5 15:49:55 2022
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 5 Sep 2022 15:49:55 GMT
Subject: RFR: 8293338: Enable manually triggering the GitHub workflow
In-Reply-To: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>
References: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>
Message-ID: <ugdqLdmS35VATcy08eHyVkZXe8HI_wf2O-qkMXO06xQ=.e3f2ab5e-1c10-4353-9701-24f450d8a4dd@github.com>

On Sat, 3 Sep 2022 09:56:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> In [8293214: Add support for Linux/LoongArch64](https://github.com/openjdk/jfx/pull/888), the contributor was suggested  to push a empty commit to trigger the GHA tests. But actually it seems not a good dev flow because the newly added commits are not related to the issue the patch want to solve.
> 
> The GitHub provides related configuration to enable the develoers to trigger the workflow manually. Please see the documents [1][2] for more detail. This patch adds such config to enable it.
> 
> Thanks for taking the time to review.
> 
> [1] https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
> [2] https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
> 
> Best Regards,
> -- Guoxiong

Thanks for the review. Could I get your help to sponsor this patch?

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

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

From kcr at openjdk.org  Mon Sep  5 16:06:55 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 16:06:55 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <8kj3y6ddbr04JxxeFw6Rw6bF0nL-2riehnx_8syBnJY=.fe1b4f05-9450-482e-91a8-6ae90d839c06@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
> 
> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
> 
> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

Looks good to me.

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

Marked as reviewed by kcr (Lead).

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

From gli at openjdk.org  Mon Sep  5 16:07:53 2022
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 5 Sep 2022 16:07:53 GMT
Subject: Integrated: 8293338: Enable manually triggering the GitHub workflow
In-Reply-To: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>
References: <sxfQSeQeyE-SvafdcTLGO7fNp3TE4YyRm6A6VJgf3TQ=.0c6a9ca6-bd7d-48a2-a2dd-bd5ec99e8051@github.com>
Message-ID: <rMh8o4WkrHyukzsw4Cc5A-ZNGYykhwxopA8crlHk3Oc=.82fb6db7-e29d-4215-afd3-87015d3f27c1@github.com>

On Sat, 3 Sep 2022 09:56:04 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> In [8293214: Add support for Linux/LoongArch64](https://github.com/openjdk/jfx/pull/888), the contributor was suggested  to push a empty commit to trigger the GHA tests. But actually it seems not a good dev flow because the newly added commits are not related to the issue the patch want to solve.
> 
> The GitHub provides related configuration to enable the develoers to trigger the workflow manually. Please see the documents [1][2] for more detail. This patch adds such config to enable it.
> 
> Thanks for taking the time to review.
> 
> [1] https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
> [2] https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: 77f19951
Author:    Guoxiong Li <gli at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/77f19951e5931817a452b612a72c4c67c4fcc05e
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8293338: Enable manually triggering the GitHub workflow

Reviewed-by: kcr

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

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

From kcr at openjdk.org  Mon Sep  5 17:35:18 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 17:35:18 GMT
Subject: [jfx11u] RFR: 8291630: Update attribution in webkit.md file
Message-ID: <3rf50YdK0VqBdDah53x1Crlzq9TVQP4GtcghfR6ibAQ=.4b7d894b-0652-483c-b6e7-81f6aa38167c@github.com>

Clean backport.

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

Commit messages:
 - 8291630: Update attribution in webkit.md file

Changes: https://git.openjdk.org/jfx11u/pull/112/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291630
  Stats: 1152 lines in 1 file changed: 931 ins; 189 del; 32 mod
  Patch: https://git.openjdk.org/jfx11u/pull/112.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/112/head:pull/112

PR: https://git.openjdk.org/jfx11u/pull/112

From kcr at openjdk.org  Mon Sep  5 17:38:27 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 17:38:27 GMT
Subject: [jfx11u] RFR: 8292609: Cherry-pick WebKit 614.1 stabilization fixes
Message-ID: <q86w86RleM6WAW6gS4rBNS5tqOtyLbg81FlmwloV7Rk=.a97d14ae-f496-4838-9f80-61ba6491e883@github.com>

Clean backport.

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

Commit messages:
 - 8292609: Cherry-pick WebKit 614.1 stabilization fixes

Changes: https://git.openjdk.org/jfx11u/pull/113/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx11u&pr=113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292609
  Stats: 1228 lines in 111 files changed: 848 ins; 102 del; 278 mod
  Patch: https://git.openjdk.org/jfx11u/pull/113.diff
  Fetch: git fetch https://git.openjdk.org/jfx11u pull/113/head:pull/113

PR: https://git.openjdk.org/jfx11u/pull/113

From kcr at openjdk.org  Mon Sep  5 17:40:30 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 17:40:30 GMT
Subject: [jfx11u] Integrated: 8292609: Cherry-pick WebKit 614.1 stabilization
 fixes
In-Reply-To: <q86w86RleM6WAW6gS4rBNS5tqOtyLbg81FlmwloV7Rk=.a97d14ae-f496-4838-9f80-61ba6491e883@github.com>
References: <q86w86RleM6WAW6gS4rBNS5tqOtyLbg81FlmwloV7Rk=.a97d14ae-f496-4838-9f80-61ba6491e883@github.com>
Message-ID: <Z_oaC8ajnxtEL0T4aWahJqF6s-WqonadbkbxNX-3Ht4=.85f81957-027d-45f6-a1fa-9479b2c8ca88@github.com>

On Mon, 5 Sep 2022 17:24:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 4eaaf34e
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/4eaaf34e97f925abcb7e0f622f8ba1159a96f3ba
Stats:     1228 lines in 111 files changed: 848 ins; 102 del; 278 mod

8292609: Cherry-pick WebKit 614.1 stabilization fixes

Backport-of: da580ba4a7e743e2a49f5a2c7f3b40fa01a4438a

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

PR: https://git.openjdk.org/jfx11u/pull/113

From kcr at openjdk.org  Mon Sep  5 17:42:52 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 17:42:52 GMT
Subject: [jfx11u] Integrated: 8291630: Update attribution in webkit.md file
In-Reply-To: <3rf50YdK0VqBdDah53x1Crlzq9TVQP4GtcghfR6ibAQ=.4b7d894b-0652-483c-b6e7-81f6aa38167c@github.com>
References: <3rf50YdK0VqBdDah53x1Crlzq9TVQP4GtcghfR6ibAQ=.4b7d894b-0652-483c-b6e7-81f6aa38167c@github.com>
Message-ID: <hM53b2e9UC-enl_pODdB1qUMje-k7Bnsfqul_U11zsI=.ad761ff4-4f14-4254-9e43-f49dc2d4db33@github.com>

On Mon, 5 Sep 2022 17:23:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 4c5c3f9b
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx11u/commit/4c5c3f9b78ec2a305a2ad8f01fc7d56c4f34d8ec
Stats:     1152 lines in 1 file changed: 931 ins; 189 del; 32 mod

8291630: Update attribution in webkit.md file

Backport-of: f8c5391efdc0bd7c4638d431b79754381bc6be52

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

PR: https://git.openjdk.org/jfx11u/pull/112

From duke at openjdk.org  Mon Sep  5 17:44:43 2022
From: duke at openjdk.org (Alex)
Date: Mon, 5 Sep 2022 17:44:43 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening
Message-ID: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>

This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.

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

Commit messages:
 - Update submit.yml

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

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

From kcr at openjdk.org  Mon Sep  5 17:44:44 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 5 Sep 2022 17:44:44 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening
In-Reply-To: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
Message-ID: <yvl_c7QeKLnRTgYgTBSi9berZZOe38BUAjNpuTWH6FA=.defc363a-41ff-401b-9514-55b6aa752ef8@github.com>

On Thu, 1 Sep 2022 20:37:27 GMT, Alex <duke at openjdk.org> wrote:

> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.

@sashashura You need to enable running GHA workflows in your personal fork of the `jfx` repo. Given that you are changing the GHA workflow, we will need to see the results from your run in this PR.

This seems worth evaluating. Given that we don't enable workflows in any of the repos of the openjdk organization, the impact of not doing this is limited (the workflow only runs in the context of the user pushing to their own branch), but as long as it doesn't preclude doing anything legitimate, it might be a good idea. I filed a new JBS issue -- [JDK-8293368](https://bugs.openjdk.org/browse/JDK-8293368) -- for this.

@sashashura Please change the title of this PR to:


8293368: GitHub Workflows security hardening

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

Changes requested by kcr (Lead).

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

From kevin.rushforth at oracle.com  Mon Sep  5 17:47:15 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 5 Sep 2022 10:47:15 -0700
Subject: ConcurrentModificationException when calling stage.show()
In-Reply-To: <CAAoP7T6sdiVkhEf0t6RP5CGkNjnv2mE-BJ+1+rRoiuJZChZiuA@mail.gmail.com>
References: <CAAoP7T6sdiVkhEf0t6RP5CGkNjnv2mE-BJ+1+rRoiuJZChZiuA@mail.gmail.com>
Message-ID: <f2825357-6943-05d8-5e12-31a1692ab443@oracle.com>

I suspect a JavaFX bug, unless there some other thread not shown in your 
stack trace that is modifying any object in the now-live scene graph.

-- Kevin


On 9/5/2022 6:34 AM, Daniel Peintner wrote:
> All,
>
> I have a strange issue popping up once in a while.
> I have an application (FXML+ Controller) that has a "new" button 
> opening a new window. In 99% percent of the cases this works just fine.
>
> In some rare cases though, stage.show() fails due to a 
> ConcurrentModificationException. Since this issue does not happen in 
> my code but rather in JavaFX code I wanted to ask whether there is a 
> specific prerequisite I am not aware of or whether this is a bug in 
> JavaFX.
>
> Attached the stack trace. Unfortunately I am not able to create a 
> reproducible example that fails always.
>
> I am grateful for any tip.
>
> Thanks,
>
> -- Daniel
>
>
> Exception in thread "JavaFX Application Thread" 
> java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1857)
> at 
> javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1724)
> at 
> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
> at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> at 
> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
> at javafx.event.Event.fireEvent(Event.java:198)
> at javafx.scene.Node.fireEvent(Node.java:8797)
> at javafx.scene.control.Button.fire(Button.java:203)
> at 
> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:208)
> at 
> com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
> at 
> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
> at 
> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
> at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> at 
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> at 
> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at 
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> at 
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
> at javafx.event.Event.fireEvent(Event.java:198)
> at javafx.scene.Scene$MouseHandler.process(Scene.java:3881)
> at javafx.scene.Scene.processMouseEvent(Scene.java:1874)
> at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2607)
> at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411)
> at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:301)
> at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:450)
> at 
> com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
> at 
> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449)
> at com.sun.glass.ui.View.handleMouseEvent(View.java:551)
> at com.sun.glass.ui.View.notifyMouse(View.java:937)
> at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> at 
> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InvocationTargetException
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javafx.reflect.Trampoline.invoke(MethodUtil.java:77)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javafx.reflect.MethodUtil.invoke(MethodUtil.java:275)
> at com.sun.javafx.fxml.MethodHelper.invoke(MethodHelper.java:84)
> at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1854)
> ... 50 more
> Caused by: java.util.ConcurrentModificationException
> at 
> java.base/java.util.AbstractList$Itr.checkForComodification(AbstractList.java:399)
> at java.base/java.util.AbstractList$Itr.next(AbstractList.java:368)
> at 
> javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:810)
> at 
> javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:811)
> at javafx.scene.control.skin.MenuBarSkin.rebuildUI(MenuBarSkin.java:1017)
> at javafx.scene.control.skin.MenuBarSkin.<init>(MenuBarSkin.java:356)
> at javafx.scene.control.MenuBar.createDefaultSkin(MenuBar.java:202)
> at javafx.scene.control.Control.doProcessCSS(Control.java:899)
> at javafx.scene.control.Control$1.doProcessCSS(Control.java:89)
> at 
> com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67)
> at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
> at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
> at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
> at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
> at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
> at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
> at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
> at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
> at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
> at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> at javafx.scene.Node.processCSS(Node.java:9477)
> at javafx.scene.Scene.doCSSPass(Scene.java:572)
> at javafx.scene.Scene.preferredSize(Scene.java:1770)
> at javafx.scene.Scene$2.preferredSize(Scene.java:396)
> at com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
> at javafx.stage.Window$12.invalidated(Window.java:1163)
> at 
> javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
> at 
> javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
> at javafx.stage.Window.setShowing(Window.java:1239)
> at javafx.stage.Window.show(Window.java:1254)
> at javafx.stage.Stage.show(Stage.java:277)
> at 
> com.foo.MainLayoutController.openNewWindow(MainLayoutController.java:3851)
>
>
>
>
>
>


From duke at openjdk.org  Mon Sep  5 18:20:48 2022
From: duke at openjdk.org (Alex)
Date: Mon, 5 Sep 2022 18:20:48 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening
In-Reply-To: <yvl_c7QeKLnRTgYgTBSi9berZZOe38BUAjNpuTWH6FA=.defc363a-41ff-401b-9514-55b6aa752ef8@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
 <yvl_c7QeKLnRTgYgTBSi9berZZOe38BUAjNpuTWH6FA=.defc363a-41ff-401b-9514-55b6aa752ef8@github.com>
Message-ID: <JICpGZbZiRGYcF1sF-4PmZN4_jaQuV9a9qo5_82xOMI=.47ca3578-91fe-4630-9db2-3d284d054c9b@github.com>

On Mon, 5 Sep 2022 16:32:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> @sashashura You need to enable running GHA workflows in your personal fork of the `jfx` repo. Given that you are changing the GHA workflow, we will need to see the results from your run in this PR.

https://github.com/sashashura/jfx/actions/runs/2995229526

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

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

From lzhai at openjdk.org  Tue Sep  6 01:25:25 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Tue, 6 Sep 2022 01:25:25 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC
 is ON
Message-ID: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>

Hi,

jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:


jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
  #include <bmalloc/BPlatform.h>
           ^~~~~~~~~~~~~~~~~~~~~
 compilation terminated.


After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:


diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
index 70c047813f..d30291697a 100644
--- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
+++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h

...

 #if PLATFORM(IOS_FAMILY)
 #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
 #endif
+
+#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
+#include <bmalloc/BPlatform.h>
+#if BENABLE(LIBPAS)
+#if PLATFORM(MAC) && CPU(ARM64)
+#define USE_LIBPAS_JIT_HEAP 1
+#endif
+#endif
+#endif
+


Please review my patch.

Thanks,
Leslie Zhai

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

Commit messages:
 - 8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON

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

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

From fastegal at openjdk.org  Tue Sep  6 10:16:49 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Tue, 6 Sep 2022 10:16:49 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v10]
In-Reply-To: <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
Message-ID: <NdqqSwAGRS_yNYy_1B-UIDcq2mGIu8lSuIzGXgqDktQ=.1c314622-0bdd-4f97-8328-396697c599b8@github.com>

On Wed, 24 Aug 2022 22:03:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: whitespace

Never thought that I would ever feel on the verge of arguing against adding tests ;) 

> I haven't looked at these specific tests in detail, but as a general practice I see value in having both types of tests: unit tests that test a specific thing, and tests of various scenarios.

Yeah, we could do additional testing of broader scenarios - assuming the tightly bounded specific tests are done. We should answer two questions:

- what _exactly_ do we expect to gain, that is which additional safety do they give?
- what is the boundary of those scenarios, why add one and not another? 

In this particular case we have a tighly bounded problem: the row updates itself incorrectly based on the state of the selection model. We know that all other potential collaborators talk to the selection model directly. Given we fixed the problem (done), and have failing/passing tests before/after the fix involving an isolated, fully configured cell (not yet done), my answers:

- nothing I can see (might be missing something, of course :)
- the choice of scenarios (scene only, simulating mouse input) feels arbitrary, why not key input (or touch, accessiblity .. )? They all are at the same level of unrelatedness, IMO - we are not testing the effectiveness of this bug fix, but something else (for the mouse input f.i. tableCell - behaviour)

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

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

From fastegal at openjdk.org  Tue Sep  6 10:40:56 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Tue, 6 Sep 2022 10:40:56 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v10]
In-Reply-To: <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
Message-ID: <sh7sy1g-8EcbOtFUoMrH1zFMNWtAZMVCTGABj95OZEA=.5311f24f-5ef3-4ec7-931d-b359f2220b3c@github.com>

On Wed, 24 Aug 2022 22:03:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: whitespace

modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlUtils.java line 157:

> 155:         }
> 156:         throw new Error("TableRow not found at " + row);
> 157:     }

no review, just a couple of comments:

Generally, should prefer api over lookup - we have shims to access package/protected api. 

In this particular case, the lookup is brittle: it assumes that

- either there is a single row configured with the given index 
- or that it's the first when iterating over the set

With the first being incorrect (corner case, of course :)

    @Test
    public void testLookupLastNotEmptyCell() {
        stageLoader = new StageLoader(table);
        int index = table.getItems().size()- 1;
        Set<Node> tableRows = table.lookupAll(".table-row-cell").stream()
                .filter(n -> n instanceof TableRow<?> && ((TableRow<?>) n).getIndex() == index)
                .collect(Collectors.toSet());
        assertEquals(1, tableRows.size());
    }

we fall back to the second assumption, which is implementation dependent (and unspecified) - it's accidental that we actually do get the row we want.

Having done a bit of digging into VirtualFlowTestUtils (see [JDK-8293356](https://bugs.openjdk.org/browse/JDK-8293356)) I now think it's safe enough to use it (even though it's on the oldish side, not using recently added api, probably needs some polish) - as long as  we keep the scenegraph stable during the test, f.i. by manually adding the table to a stage (either via StageLoader or showing in our own).

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

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

From aoqi at openjdk.org  Tue Sep  6 10:34:56 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Tue, 6 Sep 2022 10:34:56 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
Message-ID: <RudSNEE51o5uO0yfoU5-JXRdzFzGttD53Tgs-0PRgwI=.34246493-97d3-4f2e-956e-5b472de13d68@github.com>

On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
> 
> 
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>   #include <bmalloc/BPlatform.h>
>            ^~~~~~~~~~~~~~~~~~~~~
>  compilation terminated.
> 
> 
> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
> 
> 
> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> index 70c047813f..d30291697a 100644
> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> 
> ...
> 
>  #if PLATFORM(IOS_FAMILY)
>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>  #endif
> +
> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
> +#include <bmalloc/BPlatform.h>
> +#if BENABLE(LIBPAS)
> +#if PLATFORM(MAC) && CPU(ARM64)
> +#define USE_LIBPAS_JIT_HEAP 1
> +#endif
> +#endif
> +#endif
> +
> 
> 
> Please review my patch.
> 
> Thanks,
> Leslie Zhai

Hi @xiangzhai , I suggest that you enable [the GitHub Actions of your repo](https://github.com/xiangzhai/jfx/actions) and trigger the tests. FYI, [8293338: Enable manually triggering the GitHub workflow](https://github.com/openjdk/jfx/pull/891).

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

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

From kcr at openjdk.org  Tue Sep  6 13:59:51 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Sep 2022 13:59:51 GMT
Subject: RFR: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <hle9W3x7X_S9rNhW1KvNS_XmKqfH6nSXWFGJtkJ_dN0=.d9981816-5266-42d2-8449-741e93b577f0@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
 <hle9W3x7X_S9rNhW1KvNS_XmKqfH6nSXWFGJtkJ_dN0=.d9981816-5266-42d2-8449-741e93b577f0@github.com>
Message-ID: <KUgVj3MFN8SQcKcKWqac8Qn5xLsh8rQu5A1sYe1n9uA=.cbbe2b50-e13e-4504-abb9-670f12ee4352@github.com>

On Mon, 5 Sep 2022 15:38:21 GMT, Douglas Held <duke at openjdk.org> wrote:

>> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
>> 
>> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
>> 
>> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896
>
>> Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!
> 
> Is my GitHub user account now OCA-verified for future requests? And if not, where can I go to try to more adequately resolve the OCA flag?

@douglasheldoracle The next step is for you to issue the `/integrate` command, whenever you are ready.

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

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

From kcr at openjdk.org  Tue Sep  6 14:04:10 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Sep 2022 14:04:10 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
Message-ID: <Cmj3_56RKH6con8PYsGpCDBKKnmYkseGyYTzFdJChGk=.7a85b15f-a5a3-4c8f-86fc-f11801ed1c5b@github.com>

On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
> 
> 
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>   #include <bmalloc/BPlatform.h>
>            ^~~~~~~~~~~~~~~~~~~~~
>  compilation terminated.
> 
> 
> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
> 
> 
> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> index 70c047813f..d30291697a 100644
> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> 
> ...
> 
>  #if PLATFORM(IOS_FAMILY)
>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>  #endif
> +
> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
> +#include <bmalloc/BPlatform.h>
> +#if BENABLE(LIBPAS)
> +#if PLATFORM(MAC) && CPU(ARM64)
> +#define USE_LIBPAS_JIT_HEAP 1
> +#endif
> +#endif
> +#endif
> +
> 
> 
> Please review my patch.
> 
> Thanks,
> Leslie Zhai

Have you tested this to ensure that there is no change in the default case?

@jaybhaskar @HimaBinduMeda Can you also review this?

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

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

From kcr at openjdk.org  Tue Sep  6 14:21:51 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Sep 2022 14:21:51 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening
In-Reply-To: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
Message-ID: <_R1tNHg_Z8AH5Pb0UuOb45q9kj84uVwMvV-4jBusc_I=.7b4c2bea-0054-400f-b482-fda23b92ded7@github.com>

On Thu, 1 Sep 2022 20:37:27 GMT, Alex <duke at openjdk.org> wrote:

> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.

Your GHA tests look good. Can you merge (_not_ rebase) the current upstream master into your branch? A recent commit that is not currently in your branch also touches `submit.yml` and I'd like to see a run with both fixes (also, since that patch touches adjacent lines, it will be helpful to see the results of the merge before integration).

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

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

From angorya at openjdk.org  Tue Sep  6 15:08:55 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 6 Sep 2022 15:08:55 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <2SmmCOEg8EYPnEfQPxFmljcELbI30gpAoc62MoEzky4=.d2fe4c50-2f79-43dc-9cf9-9f9a6534ed09@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
 <2SmmCOEg8EYPnEfQPxFmljcELbI30gpAoc62MoEzky4=.d2fe4c50-2f79-43dc-9cf9-9f9a6534ed09@github.com>
Message-ID: <nqdOT-utM61_LAdnn-Oy0Gpj6aZh4TtS1PnvpsD85cU=.11aeb7e7-c466-43eb-aac0-082dae9a8976@github.com>

On Sat, 3 Sep 2022 10:14:53 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290844: review comments
>
> that's basically the problem we identified as not solvable by current api, though I would formulate slightly differently: there are two bugs in our current implementation, one in step 3 and one in step 6
> 
>     // bug in step 3: should be replacing the property only if not set be the user
>     if  (control.getInputMethodRequest() == USER1) { // no means to detect user vs. skin installed
>              // do nothing
>     }  else {
>             control.setInputMethodRequest(SKIN1);
>     }
> 
>     // bug in step 6: nulling unconditionally in dispose is wrong, should only do if installed by the skin
>     if (control.getInputMethodRequest() == SKIN1) control.setInputMethodRequest(null);
> 
> Yes: there is no way to differentiate USER1 from SKIN1 in step 5 without new API :) There are options besides a new life-cycle, but I agree that adding a life-cycle state is the most clean.

Thank you!  I am glad we are on the same wavelength, @kleopatra .
Could we get this PR approved?  Do you think we should expand the Skin javadoc?

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

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

From duke at openjdk.org  Tue Sep  6 15:08:55 2022
From: duke at openjdk.org (Douglas Held)
Date: Tue, 6 Sep 2022 15:08:55 GMT
Subject: Integrated: JDK-8293171: Minor typographical errors in JavaDoc
 javafx.scene.control.ScrollPane.java
In-Reply-To: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
References: <V6mbzwdnEG6Eu3lC7Y2qFvw00FYxa_Qb1chZGNuo4WM=.8a4a73be-b6ee-4fe3-b4e4-59d4c62fbfbb@github.com>
Message-ID: <T-k9sG1SgCXXrVSrkV9jOEexJ8JIQtXlbunvjfYdjhA=.03aac42d-6a30-4522-8aa1-519bd7b9b686@github.com>

On Wed, 31 Aug 2022 14:19:03 GMT, Douglas Held <duke at openjdk.org> wrote:

> Fix two typos in the JavaDoc. The links for the vertical property link to the horizontal property.
> 
> It's my first commit, so please comment if I haven't followed the commit protocol per expectations.
> 
> Note, I no longer have a handle to the JBS title for record 9073896. The record is not available to me: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=9073896

This pull request has now been integrated.

Changeset: 160be032
Author:    Douglas Held <doug.held at oracle.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/160be032a5f06968934204bc5223751bd82dba5b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8293171: Minor typographical errors in JavaDoc javafx.scene.control.ScrollPane.java

Reviewed-by: angorya, kcr

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

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

From kcr at openjdk.org  Tue Sep  6 15:31:52 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 6 Sep 2022 15:31:52 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <nqdOT-utM61_LAdnn-Oy0Gpj6aZh4TtS1PnvpsD85cU=.11aeb7e7-c466-43eb-aac0-082dae9a8976@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
 <2SmmCOEg8EYPnEfQPxFmljcELbI30gpAoc62MoEzky4=.d2fe4c50-2f79-43dc-9cf9-9f9a6534ed09@github.com>
 <nqdOT-utM61_LAdnn-Oy0Gpj6aZh4TtS1PnvpsD85cU=.11aeb7e7-c466-43eb-aac0-082dae9a8976@github.com>
Message-ID: <5kqJp8AIwdg2fbh4UGNa2_apTO2xMehSP4cIgrjk8UU=.50c282dc-44e9-4e67-81a9-fdfc18bbba7e@github.com>

On Tue, 6 Sep 2022 15:06:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Could we get this PR approved?

The PR isn't ready to be approved, but the API changes and javadoc are ready to be reviewed.

> Do you think we should expand the Skin javadoc?

Quite possibly. Related to this, I wonder whether we want to add an `@implNote` indicating that most implementations of Skin in the `javafx.controls` module do not implement `Skin::install` unless noted? I hesitate to document what is effectively an implementation detail, but sometimes that's what we use `@implNote` for in cases where a subclass might want to know.

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

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

From almatvee at openjdk.org  Tue Sep  6 23:02:56 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 6 Sep 2022 23:02:56 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
Message-ID: <tddCOqYDvII_t0MOrMtDes8B9xwO2I7kdU-Ek1dI15M=.9ffe5a3e-abe2-4f1d-9838-def0edecffd3@github.com>

On Thu, 1 Sep 2022 13:00:24 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

Media changes looks good.

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

Marked as reviewed by almatvee (Reviewer).

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

From aoqi at openjdk.org  Wed Sep  7 01:05:45 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 7 Sep 2022 01:05:45 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <tddCOqYDvII_t0MOrMtDes8B9xwO2I7kdU-Ek1dI15M=.9ffe5a3e-abe2-4f1d-9838-def0edecffd3@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
 <tddCOqYDvII_t0MOrMtDes8B9xwO2I7kdU-Ek1dI15M=.9ffe5a3e-abe2-4f1d-9838-def0edecffd3@github.com>
Message-ID: <r9QjuM-uGM7XRaqWTN-wNYVvScDqdyO40txXWEpXUZU=.61c7cc66-8825-48bb-b43c-0ae5f98eaa07@github.com>

On Tue, 6 Sep 2022 23:00:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> Media changes looks good.

Thanks for the review, @sashamatveev.

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

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

From lzhai at openjdk.org  Wed Sep  7 01:12:57 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Wed, 7 Sep 2022 01:12:57 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <Cmj3_56RKH6con8PYsGpCDBKKnmYkseGyYTzFdJChGk=.7a85b15f-a5a3-4c8f-86fc-f11801ed1c5b@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
 <Cmj3_56RKH6con8PYsGpCDBKKnmYkseGyYTzFdJChGk=.7a85b15f-a5a3-4c8f-86fc-f11801ed1c5b@github.com>
Message-ID: <R4oqhr3Q0JsKXcoxtzdU6gY26xLG1hOryKM2L84UXFY=.0d258d5f-c3ed-4142-91e5-7bb232699a9b@github.com>

On Tue, 6 Sep 2022 14:01:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi,
>> 
>> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
>> 
>> 
>> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
>> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
>> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
>> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
>> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
>> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>>   #include <bmalloc/BPlatform.h>
>>            ^~~~~~~~~~~~~~~~~~~~~
>>  compilation terminated.
>> 
>> 
>> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
>> 
>> 
>> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
>> index 70c047813f..d30291697a 100644
>> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
>> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
>> 
>> ...
>> 
>>  #if PLATFORM(IOS_FAMILY)
>>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>>  #endif
>> +
>> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
>> +#include <bmalloc/BPlatform.h>
>> +#if BENABLE(LIBPAS)
>> +#if PLATFORM(MAC) && CPU(ARM64)
>> +#define USE_LIBPAS_JIT_HEAP 1
>> +#endif
>> +#endif
>> +#endif
>> +
>> 
>> 
>> Please review my patch.
>> 
>> Thanks,
>> Leslie Zhai
>
> @jaybhaskar @HimaBinduMeda Can you also review this?

Hi  @kevinrushforth 

Thanks for your kind response!

> Have you tested this to ensure that there is no change in the default case?

I have tested the upstream WebKit for LoongArch64, x86_64 and AArch64 already:  https://github.com/WebKit/WebKit/pull/3908 

The default case `USE_SYSTEM_MALLOC` is `OFF` x86_64 and AArch64 succesfully include `bmalloc/BPlatform.h` header file.

Please point out my fault if I misunderstanding.

Thanks,
Leslie Zhai

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

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

From jbhaskar at openjdk.org  Wed Sep  7 03:00:54 2022
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Wed, 7 Sep 2022 03:00:54 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
Message-ID: <k-IXu8wA8lSHiuQOQ5ZujYD_EiqC10ah836lt2StGF0=.56657d22-3739-4dd1-b8ac-739c267384c9@github.com>

On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
> 
> 
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>   #include <bmalloc/BPlatform.h>
>            ^~~~~~~~~~~~~~~~~~~~~
>  compilation terminated.
> 
> 
> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
> 
> 
> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> index 70c047813f..d30291697a 100644
> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> 
> ...
> 
>  #if PLATFORM(IOS_FAMILY)
>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>  #endif
> +
> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
> +#include <bmalloc/BPlatform.h>
> +#if BENABLE(LIBPAS)
> +#if PLATFORM(MAC) && CPU(ARM64)
> +#define USE_LIBPAS_JIT_HEAP 1
> +#endif
> +#endif
> +#endif
> +
> 
> 
> Please review my patch.
> 
> Thanks,
> Leslie Zhai

+looks good

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

Marked as reviewed by jbhaskar (Author).

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

From duke at openjdk.org  Wed Sep  7 11:27:02 2022
From: duke at openjdk.org (Alex)
Date: Wed, 7 Sep 2022 11:27:02 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening [v2]
In-Reply-To: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
Message-ID: <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>

> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.

Alex has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into patch-1
 - Update submit.yml
   
   Signed-off-by: sashashura <93376818+sashashura at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/889/files
  - new: https://git.openjdk.org/jfx/pull/889/files/ae6132c2..20840ce8

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

  Stats: 306 lines in 8 files changed: 295 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/889.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/889/head:pull/889

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

From jvos at openjdk.org  Wed Sep  7 11:46:52 2022
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 7 Sep 2022 11:46:52 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
Message-ID: <u-2e8I4utTAZLjMJYkL3XLMrPHLVOIG2yhJjnq0AxG4=.3b5ab59a-8450-44d1-8b63-1e5b2157ced7@github.com>

On Thu, 1 Sep 2022 13:00:24 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

modules/javafx.media/src/main/native/gstreamer/projects/linux/avplugin/Makefile line 36:

> 34:          -ffunction-sections -fdata-sections
> 35: 
> 36: ifeq (,$(findstring $(ARCH), aarch64 loongarch64))

This will work, but I wonder if we should revert the test: we now always assume that msse2 is supported, unless we are on an architecture which we know doesn't support it. It might be safer to only ask for msse2 support if we are really sure it is supported by the architecture (which currently means a check on x32 and x64)

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

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

From kcr at openjdk.org  Wed Sep  7 11:52:45 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 Sep 2022 11:52:45 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening [v2]
In-Reply-To: <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
 <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>
Message-ID: <B1_rW3B7uFqt-39xo4ebAWlRjDxYFLCF5coVMBJSzh8=.eec7d133-ead4-48e3-91ed-0e81e89d4be6@github.com>

On Wed, 7 Sep 2022 11:27:02 GMT, Alex <duke at openjdk.org> wrote:

>> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
>> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.
>
> Alex has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into patch-1
>  - Update submit.yml
>    
>    Signed-off-by: sashashura <93376818+sashashura at users.noreply.github.com>

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From jvos at openjdk.org  Wed Sep  7 12:01:48 2022
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 7 Sep 2022 12:01:48 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
Message-ID: <pTGhVRGObETWphD4X4sb28z9Uk60fjPeS_SLzFG5MPY=.ee3bd5f5-7acd-4103-87df-6652e968dff4@github.com>

On Thu, 1 Sep 2022 13:00:24 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

build.gradle line 313:

> 311: } else if (IS_MAC && OS_ARCH != "x86_64" && OS_ARCH != "aarch64") {
> 312:     fail("Unknown and unsupported build architecture: $OS_ARCH")
> 313: } else if (IS_LINUX && OS_ARCH != "i386" && OS_ARCH != "amd64" && OS_ARCH != "aarch64" && OS_ARCH != "loongarch64") {

this could be simplified with 
`... && !IS_LOONGARCH64` which avoids the more error-prone duplicate "loongarch64" string.
(the same applies to replacing the aarch64 check with !IS_AARCH64)

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

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

From jvos at openjdk.org  Wed Sep  7 12:05:50 2022
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 7 Sep 2022 12:05:50 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
Message-ID: <wdfslkH3ca19e5lvPXkV4hyWzG6bVbobHf3uCmkFZYg=.69d5feb9-95a7-46e2-b8d9-33a0ce0ee9f5@github.com>

On Thu, 1 Sep 2022 13:00:24 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert

This PR looks safe to me. I don't see a scenario where this can cause regression. I can't say if those changes are enough to build for LoongArch64 though, but as long as there is no regression I am ok.
There are a few minor optimizations that I suggested -- in general, there are more places in the build.gradle file where we could benefit from optimizations but I don't recommend doing that as part of this PR.

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

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

From kcr at openjdk.org  Wed Sep  7 12:46:56 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 Sep 2022 12:46:56 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
Message-ID: <rztIwUGEVvJwaqACUQiFnEE4rn5xlmB9AjYocNPqdo0=.68c608fb-65ab-4f66-bd2d-ec8cb92de6d2@github.com>

On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
> 
> 
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>   #include <bmalloc/BPlatform.h>
>            ^~~~~~~~~~~~~~~~~~~~~
>  compilation terminated.
> 
> 
> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
> 
> 
> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> index 70c047813f..d30291697a 100644
> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> 
> ...
> 
>  #if PLATFORM(IOS_FAMILY)
>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>  #endif
> +
> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
> +#include <bmalloc/BPlatform.h>
> +#if BENABLE(LIBPAS)
> +#if PLATFORM(MAC) && CPU(ARM64)
> +#define USE_LIBPAS_JIT_HEAP 1
> +#endif
> +#endif
> +#endif
> +
> 
> 
> Please review my patch.
> 
> Thanks,
> Leslie Zhai

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.org  Wed Sep  7 20:58:57 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 Sep 2022 20:58:57 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
Message-ID: <sz-GULAz7JwqO4ZImtGl1jyqKNckleqD0tp3fRd6nj8=.07445d17-2f3f-4b69-87bd-ac497fd43fcc@github.com>

On Fri, 12 Aug 2022 18:15:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - added Skin.install()
>> - javadoc changes for Skinnable.setSkin(Skin)
>> 
>> no code changes for Skinnable.setSkin(Skin) yet.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290844: review comments

I left feedback on the API docs.

Once we get to the implementation review, this will need some unit tests.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 267:

> 265: 
> 266:             // let the new skin modify this control
> 267:             if(skin != null) {

Minor: add a space after the `if`

modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 35:

> 33:  * A user interface control is abstracted behind the {@link Skinnable} interface.
> 34:  * <p>
> 35:  * A Skin implementation should generally avoid modifying its control outside of

I think this is a good start. As discussed elsewhere, additional implementation notes for Skin implementers would be helpful.

modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 82:

> 80:      * required properties and/or event handlers.
> 81:      * <p>
> 82:      * The default implementation of this method does nothing.

You need to add `@since 20` here.

modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 39:

> 37: public interface Skinnable {
> 38:     /**
> 39:      * Skin is responsible for rendering this {@code Skinnable}. From the

Suggestion:

"The Skin that is responsible for..."

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

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

From kcr at openjdk.org  Wed Sep  7 20:58:58 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 Sep 2022 20:58:58 GMT
Subject: RFR: 8290844: Add Skin.install() method [v2]
In-Reply-To: <zZzAu45drvLELBvaNzDrLtePlUig86kXQTbL1dhlZK0=.9352d943-8f35-4668-8a36-d5b63aa1051d@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <DGrfLZMvKR7iNzIydpn_Cfgc4YD27TmcFwMEPq2JdvI=.7179b37a-7f72-43b5-8939-506958648cae@github.com>
 <zZzAu45drvLELBvaNzDrLtePlUig86kXQTbL1dhlZK0=.9352d943-8f35-4668-8a36-d5b63aa1051d@github.com>
Message-ID: <LB-6ZxN7pRh7gYzlfbjTNtDokxXjIeGqF3bFJCBWv6c=.ac023f3e-32cd-4cf9-904f-f0ef5c9efd59@github.com>

On Thu, 11 Aug 2022 12:16:35 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290844: javadoc
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 33:
> 
>> 31:  * An interface for defining the visual representation of user interface controls
>> 32:  * by defining a scene graph of nodes to represent the skin.
>> 33:  * A user interface control is abstracted behind the {@link Skinnable} interface.
> 
> shouldn't that be _to represent the skinnable_?

I think what @kleopatra meant was that the portion of the sentence _after_ the one you changed should read:


 * by defining a scene graph of nodes to represent the skinnable.


I think she's right. The scene graph of nodes _is_ the implementation of the Skin, which represents the Skinnable. I wonder if it would be clearer to just remove that last part and put a period after `user interface controls`?

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

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

From kcr at openjdk.org  Wed Sep  7 20:58:59 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 7 Sep 2022 20:58:59 GMT
Subject: RFR: 8290844: Add Skin.install() method [v3]
In-Reply-To: <4e0CXICdrqox7rR1RzRzitJdpPcNyDmZYbe6C-oGSp0=.94d3b817-2190-4987-966c-8222aad3c4d7@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com>
 <c8fHaC3pq3zDgtL17byHXdz0j7y3Rv4QOZXuWLj2uZE=.edfe3014-2f27-4d2d-bda1-ceb997c95ddb@github.com>
 <4e0CXICdrqox7rR1RzRzitJdpPcNyDmZYbe6C-oGSp0=.94d3b817-2190-4987-966c-8222aad3c4d7@github.com>
Message-ID: <ZQYbC4xIguELzy8MgT9D_CjYLNYmosMRMMUrRzRyFGI=.ae89aca5-187c-4778-bcbe-00789d7a57cd@github.com>

On Fri, 12 Aug 2022 17:39:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 59:
>> 
>>> 57:      * {@code Skin}, this method may check the return value of
>>> 58:      * {@link Skin#getSkinnable()} against this Skinnable,
>>> 59:      * and may throw an {@code IllegalArgumentException} if it is not the same.
>> 
>> Since most implementations of `Skinnable` will do this check, we probably want to strengthen this statement. I like the language you added to the `@throws` tag, which says that it will throw an exception if the Skin does not "correspond to" this Skinnable. Is there a way to work this in, by defining what we mean to "correspond to"?
>
> @throws IllegalArgumentException if {@link Skin#getSkinnable()} returns a different {@code Skinnable}
> 
> is this better?

As discussed elsewhere, only the property method should have javadoc comments, so this should be moved up to the property method, and the existing javadoc comments for this method should be deleted.

I think we need a clearer statement here, given that there are only two top-level classes that implement `Skinnable`, `Control` and `PopupControl`, and thus override this method. `Control` enforces the 1-to-1 relationship by throwing an IAE if the `Skinnable` of the `Skin` doesn't match the `Control`, while `PopupControl` does not.

So maybe something a little more definitive, like this?


     * To ensure a one-to-one relationship between a {@code Skinnable} and its
     * {@code Skin}, some implementations of this method will check the return value of
     * {@link Skin#getSkinnable()} against this Skinnable,
     * and throw an {@code IllegalArgumentException} if it is not the same.


And then the exception could be changed to say....


     * @throws IllegalArgumentException if {@code skin.getSkinnable() != this}, for
     * implementations that enforce this restriction


This information would then be repeated in the `Control` class, but without the qualification.

>> modules/javafx.controls/src/main/java/javafx/scene/control/Skinnable.java line 64:
>> 
>>> 62:      * @throws IllegalArgumentException if {@code Skin} does not correspond to this {@code Skinnable}
>>> 63:      */
>>> 64:     public void setSkin(Skin<?> value);
>> 
>> Generally docs for properties should go on just the property and not the setter or getter. The docs will be copied and cross linked by the javadoc tool. Can you try that, and generate a javadoc, and see if that holds in this case (we don't have many cases where a property is in an interface).
>
> So javadoc tool ignores the interface, resulting in Control.setSkin(skin) method inheriting the property's description.  
> 
> Curiously, eclipse does show the interface's version, which I think helps more than having three identical descriptions for the property, its getter and setter.
> 
> What would you recommend we do here?

I recommend that we follow the existing practice of only putting the docs on the `xxxProperty` method, which includes removing the docs from `{set|get}Skin` in `Skinnable`, `Control`, and `PopupControl`. I checked it and it does what I would expect (except for a minor issue in that the `@throws` doesn't generate any docs, but since the Description indicates the conditions under which it will throw IAE, that's not a big problem; I'll file an RFE against the javadoc tool).

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

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

From lzhai at openjdk.org  Thu Sep  8 01:00:57 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Thu, 8 Sep 2022 01:00:57 GMT
Subject: RFR: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
Message-ID: <mAkeV3-47dRL8wCLAf93K_M4eqSEHl5EqreGfDEnZFk=.b22b9009-59e0-4b03-be2b-89a7945c9256@github.com>

On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
> 
> 
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>   #include <bmalloc/BPlatform.h>
>            ^~~~~~~~~~~~~~~~~~~~~
>  compilation terminated.
> 
> 
> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
> 
> 
> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> index 70c047813f..d30291697a 100644
> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> 
> ...
> 
>  #if PLATFORM(IOS_FAMILY)
>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>  #endif
> +
> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
> +#include <bmalloc/BPlatform.h>
> +#if BENABLE(LIBPAS)
> +#if PLATFORM(MAC) && CPU(ARM64)
> +#define USE_LIBPAS_JIT_HEAP 1
> +#endif
> +#endif
> +#endif
> +
> 
> 
> Please review my patch.
> 
> Thanks,
> Leslie Zhai

Thanks for your review! Could you sponsor it?

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

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

From daniel.peintner at gmail.com  Thu Sep  8 06:57:23 2022
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 8 Sep 2022 08:57:23 +0200
Subject: ConcurrentModificationException when calling stage.show()
In-Reply-To: <f2825357-6943-05d8-5e12-31a1692ab443@oracle.com>
References: <CAAoP7T6sdiVkhEf0t6RP5CGkNjnv2mE-BJ+1+rRoiuJZChZiuA@mail.gmail.com>
 <f2825357-6943-05d8-5e12-31a1692ab443@oracle.com>
Message-ID: <CAAoP7T74BXGLd=5gG9LHjWWc0Jum1GQEsb0me1CK_Pt5HG-_PA@mail.gmail.com>

Hi Kevin, all,

I investigated further and I think I found the problem (or at least a
solution).

In my application I use FXML+Controller approach.

The issue I described arises if in controller.initialize(...).
I update the menu-items of a menu. In my case, the menu list is empty in
FXML and while initializing I update the menu with the "recently" opened
files so that people can restart their work with files they opened before.

The solution that works in my case is to wrap these menu updates in
Platform.runLater() even though I think this should not be needed. Am I
right?

public class MyLayoutController extends BorderPane implements Initializable
{
    @Override
    public void initialize(URL location, ResourceBundle resources) {
        // updating the menu updates within runLater() does not cause
ConcurrentModificationException
        Platform.runLater(() -> {
           // anyhow, I think this should not be needed
           this.menu.getItems().add(new MenuItem("A"));
           this.menu.getItems().add(new MenuItem("B"));
           this.menu.getItems().add(new MenuItem("C"));
        });
    }
}

Is this sufficient to create a bug report?

Thanks,

-- Daniel




On Mon, Sep 5, 2022 at 7:47 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> I suspect a JavaFX bug, unless there some other thread not shown in your
> stack trace that is modifying any object in the now-live scene graph.
>
> -- Kevin
>
>
> On 9/5/2022 6:34 AM, Daniel Peintner wrote:
> > All,
> >
> > I have a strange issue popping up once in a while.
> > I have an application (FXML+ Controller) that has a "new" button
> > opening a new window. In 99% percent of the cases this works just fine.
> >
> > In some rare cases though, stage.show() fails due to a
> > ConcurrentModificationException. Since this issue does not happen in
> > my code but rather in JavaFX code I wanted to ask whether there is a
> > specific prerequisite I am not aware of or whether this is a bug in
> > JavaFX.
> >
> > Attached the stack trace. Unfortunately I am not able to create a
> > reproducible example that fails always.
> >
> > I am grateful for any tip.
> >
> > Thanks,
> >
> > -- Daniel
> >
> >
> > Exception in thread "JavaFX Application Thread"
> > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> > at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1857)
> > at
> >
> javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1724)
> > at
> >
> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
> > at
> >
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> > at
> >
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> > at
> >
> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
> > at javafx.event.Event.fireEvent(Event.java:198)
> > at javafx.scene.Node.fireEvent(Node.java:8797)
> > at javafx.scene.control.Button.fire(Button.java:203)
> > at
> >
> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:208)
> > at
> > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
> > at
> >
> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
> > at
> >
> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
> > at
> >
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
> > at
> >
> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
> > at
> >
> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at
> >
> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
> > at
> >
> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
> > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
> > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
> > at javafx.event.Event.fireEvent(Event.java:198)
> > at javafx.scene.Scene$MouseHandler.process(Scene.java:3881)
> > at javafx.scene.Scene.processMouseEvent(Scene.java:1874)
> > at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2607)
> > at
> >
> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411)
> > at
> >
> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:301)
> > at
> >
> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
> > at
> >
> com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:450)
> > at
> >
> com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
> > at
> >
> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449)
> > at com.sun.glass.ui.View.handleMouseEvent(View.java:551)
> > at com.sun.glass.ui.View.notifyMouse(View.java:937)
> > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
> > at
> >
> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
> > at java.base/java.lang.Thread.run(Thread.java:833)
> > Caused by: java.lang.reflect.InvocationTargetException
> > at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > at
> >
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> > at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> > at com.sun.javafx.reflect.Trampoline.invoke(MethodUtil.java:77)
> > at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> > at
> >
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> > at
> >
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> > at com.sun.javafx.reflect.MethodUtil.invoke(MethodUtil.java:275)
> > at com.sun.javafx.fxml.MethodHelper.invoke(MethodHelper.java:84)
> > at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1854)
> > ... 50 more
> > Caused by: java.util.ConcurrentModificationException
> > at
> >
> java.base/java.util.AbstractList$Itr.checkForComodification(AbstractList.java:399)
> > at java.base/java.util.AbstractList$Itr.next(AbstractList.java:368)
> > at
> >
> javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:810)
> > at
> >
> javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:811)
> > at javafx.scene.control.skin.MenuBarSkin.rebuildUI(MenuBarSkin.java:1017)
> > at javafx.scene.control.skin.MenuBarSkin.<init>(MenuBarSkin.java:356)
> > at javafx.scene.control.MenuBar.createDefaultSkin(MenuBar.java:202)
> > at javafx.scene.control.Control.doProcessCSS(Control.java:899)
> > at javafx.scene.control.Control$1.doProcessCSS(Control.java:89)
> > at
> >
> com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67)
> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
> > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
> > at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
> > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
> > at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
> > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
> > at com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
> > at javafx.scene.Node.processCSS(Node.java:9477)
> > at javafx.scene.Scene.doCSSPass(Scene.java:572)
> > at javafx.scene.Scene.preferredSize(Scene.java:1770)
> > at javafx.scene.Scene$2.preferredSize(Scene.java:396)
> > at com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
> > at javafx.stage.Window$12.invalidated(Window.java:1163)
> > at
> >
> javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
> > at
> >
> javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
> > at javafx.stage.Window.setShowing(Window.java:1239)
> > at javafx.stage.Window.show(Window.java:1254)
> > at javafx.stage.Stage.show(Stage.java:277)
> > at
> >
> com.foo.MainLayoutController.openNewWindow(MainLayoutController.java:3851)
> >
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220908/2d1f0b4a/attachment.htm>

From aoqi at openjdk.org  Thu Sep  8 07:26:48 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 8 Sep 2022 07:26:48 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
> 
> Testing:
> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/888/files
  - new: https://git.openjdk.org/jfx/pull/888/files/b225c59a..29e4b883

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

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

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

From aoqi at openjdk.org  Thu Sep  8 07:26:51 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 8 Sep 2022 07:26:51 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <pTGhVRGObETWphD4X4sb28z9Uk60fjPeS_SLzFG5MPY=.ee3bd5f5-7acd-4103-87df-6652e968dff4@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
 <pTGhVRGObETWphD4X4sb28z9Uk60fjPeS_SLzFG5MPY=.ee3bd5f5-7acd-4103-87df-6652e968dff4@github.com>
Message-ID: <JpG9zaMWQ1GJNRcQl2UbyxVB0On-3957STHsfAN0758=.aba22805-a216-4e88-bebb-a3bcd5a004c5@github.com>

On Wed, 7 Sep 2022 11:59:42 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> build.gradle line 313:
> 
>> 311: } else if (IS_MAC && OS_ARCH != "x86_64" && OS_ARCH != "aarch64") {
>> 312:     fail("Unknown and unsupported build architecture: $OS_ARCH")
>> 313: } else if (IS_LINUX && OS_ARCH != "i386" && OS_ARCH != "amd64" && OS_ARCH != "aarch64" && OS_ARCH != "loongarch64") {
> 
> this could be simplified with 
> `... && !IS_LOONGARCH64` which avoids the more error-prone duplicate "loongarch64" string.
> (the same applies to replacing the aarch64 check with !IS_AARCH64)

Done.

> modules/javafx.media/src/main/native/gstreamer/projects/linux/avplugin/Makefile line 36:
> 
>> 34:          -ffunction-sections -fdata-sections
>> 35: 
>> 36: ifeq (,$(findstring $(ARCH), aarch64 loongarch64))
> 
> This will work, but I wonder if we should revert the test: we now always assume that msse2 is supported, unless we are on an architecture which we know doesn't support it. It might be safer to only ask for msse2 support if we are really sure it is supported by the architecture (which currently means a check on x32 and x64)

Done.

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

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

From lzhai at openjdk.org  Thu Sep  8 12:01:41 2022
From: lzhai at openjdk.org (Leslie Zhai)
Date: Thu, 8 Sep 2022 12:01:41 GMT
Subject: Integrated: 8293375: add_definitions USE_SYSTEM_MALLOC when
 USE_SYSTEM_MALLOC is ON
In-Reply-To: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
References: <yPpB7Cxze2tmrs0McMN4kMW6TVDd28Zg0KZygZiYQgQ=.2c57fb79-8d33-4717-bd8c-d760427187c2@github.com>
Message-ID: <k9ywlgLXEPH1IStudzlHnqyadZXGvMSS9IH8DwkyPmA=.263b5626-97c8-4f17-8086-619431befbfb@github.com>

On Tue, 6 Sep 2022 01:19:07 GMT, Leslie Zhai <lzhai at openjdk.org> wrote:

> Hi,
> 
> jfx web failed to build when `USE_SYSTEM_MALLOC` is `ON`:
> 
> 
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Platform.h:58,
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/Assertions.h:28,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.h:31,
> jfx/modules/javafx.web/src/main/native/Source/WebCore/platform/java/WebKitLogging.cpp:28,
> jfx/modules/javafx.web/build/linux/Release/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-47.cpp:1:
> jfx/modules/javafx.web/build/linux/Release/WTF/Headers/wtf/PlatformUse.h:351:10: fatal error: bmalloc/BPlatform.h: No such file or directory
>   #include <bmalloc/BPlatform.h>
>            ^~~~~~~~~~~~~~~~~~~~~
>  compilation terminated.
> 
> 
> After commit `6f28d912024495278c4c35ab054bc2aab480b3e4`:
> 
> 
> diff --git a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> index 70c047813f..d30291697a 100644
> --- a/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> +++ b/modules/javafx.web/src/main/native/Source/WTF/wtf/PlatformUse.h
> 
> ...
> 
>  #if PLATFORM(IOS_FAMILY)
>  #define USE_SANDBOX_EXTENSIONS_FOR_CACHE_AND_TEMP_DIRECTORY_ACCESS 1
>  #endif
> +
> +#if !defined(USE_LIBPAS_JIT_HEAP) && !USE(SYSTEM_MALLOC)
> +#include <bmalloc/BPlatform.h>
> +#if BENABLE(LIBPAS)
> +#if PLATFORM(MAC) && CPU(ARM64)
> +#define USE_LIBPAS_JIT_HEAP 1
> +#endif
> +#endif
> +#endif
> +
> 
> 
> Please review my patch.
> 
> Thanks,
> Leslie Zhai

This pull request has now been integrated.

Changeset: 28f8fa9c
Author:    Leslie Zhai <lzhai at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/28f8fa9c20363ced9a94787ecfd45735b3e6b82e
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8293375: add_definitions USE_SYSTEM_MALLOC when USE_SYSTEM_MALLOC is ON

Reviewed-by: jbhaskar, kcr

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

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

From kevin.rushforth at oracle.com  Thu Sep  8 12:26:28 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 8 Sep 2022 05:26:28 -0700
Subject: [External] : Re: ConcurrentModificationException when calling
 stage.show()
In-Reply-To: <CAAoP7T74BXGLd=5gG9LHjWWc0Jum1GQEsb0me1CK_Pt5HG-_PA@mail.gmail.com>
References: <CAAoP7T6sdiVkhEf0t6RP5CGkNjnv2mE-BJ+1+rRoiuJZChZiuA@mail.gmail.com>
 <f2825357-6943-05d8-5e12-31a1692ab443@oracle.com>
 <CAAoP7T74BXGLd=5gG9LHjWWc0Jum1GQEsb0me1CK_Pt5HG-_PA@mail.gmail.com>
Message-ID: <7834a82a-479d-9647-aa16-e4ba9070132b@oracle.com>

Presuming that you aren't calling initialize directly from some other 
thread, and aren't concurrently accessing the menu from some other 
thread, I agree that adding a runLater shouldn't be needed. So yes, this 
does seem like our bug. Can you file a bug report at 
https://bugreport.java.com/ with a complete standalone test case?

-- Kevin

On 9/7/2022 11:57 PM, Daniel Peintner wrote:
> Hi Kevin, all,
>
> I investigated further and I think I found the problem (or at least a 
> solution).
>
> In my application I use FXML+Controller approach.
>
> The issue I described arises if in controller.initialize(...).
> I update the menu-items of a menu. In my case, the menu list is empty 
> in FXML and while initializing I update the menu with the "recently" 
> opened files so that people can restart their work with files they 
> opened before.
>
> The solution that works in my case is to wrap these menu updates in 
> Platform.runLater() even though I think this should not be needed. Am 
> I right?
>
> public class MyLayoutController extends BorderPane implements 
> Initializable {
> ? ? @Override
> ? ? public void initialize(URL location, ResourceBundle resources) {
> ? ? ? ? // updating the menu updates within runLater() does not cause 
> ConcurrentModificationException
> ? ? ? ? Platform.runLater(() -> {
> ? ? ? ? ? ?// anyhow, I think this should not be needed
> ? ? ? ? ? ?this.menu.getItems().add(new MenuItem("A"));
> ? ? ? ? ? ?this.menu.getItems().add(new MenuItem("B"));
> ? ? ? ? ? ?this.menu.getItems().add(new MenuItem("C"));
> ? ? ? ? });
> ? ? }
> }
>
> Is this sufficient to create a bug report?
>
> Thanks,
>
> -- Daniel
>
>
>
>
> On Mon, Sep 5, 2022 at 7:47 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     I suspect a JavaFX bug, unless there some other thread not shown
>     in your
>     stack trace that is modifying any object in the now-live scene graph.
>
>     -- Kevin
>
>
>     On 9/5/2022 6:34 AM, Daniel Peintner wrote:
>     > All,
>     >
>     > I have a strange issue popping up once in a while.
>     > I have an application (FXML+ Controller) that has a "new" button
>     > opening a new window. In 99% percent of the cases this works
>     just fine.
>     >
>     > In some rare cases though, stage.show() fails due to a
>     > ConcurrentModificationException. Since this issue does not
>     happen in
>     > my code but rather in JavaFX code I wanted to ask whether there
>     is a
>     > specific prerequisite I am not aware of or whether this is a bug in
>     > JavaFX.
>     >
>     > Attached the stack trace. Unfortunately I am not able to create a
>     > reproducible example that fails always.
>     >
>     > I am grateful for any tip.
>     >
>     > Thanks,
>     >
>     > -- Daniel
>     >
>     >
>     > Exception in thread "JavaFX Application Thread"
>     > java.lang.RuntimeException:
>     java.lang.reflect.InvocationTargetException
>     > at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1857)
>     > at
>     >
>     javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1724)
>     > at
>     >
>     com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
>     > at
>     >
>     com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
>     > at
>     >
>     com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>     > at
>     >
>     com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>     > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
>     > at javafx.event.Event.fireEvent(Event.java:198)
>     > at javafx.scene.Node.fireEvent(Node.java:8797)
>     > at javafx.scene.control.Button.fire(Button.java:203)
>     > at
>     >
>     com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:208)
>     > at
>     >
>     com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
>     > at
>     >
>     com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
>     > at
>     >
>     com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
>     > at
>     >
>     com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
>     > at
>     >
>     com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>     > at
>     >
>     com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at
>     >
>     com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>     > at
>     >
>     com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>     > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>     > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
>     > at javafx.event.Event.fireEvent(Event.java:198)
>     > at javafx.scene.Scene$MouseHandler.process(Scene.java:3881)
>     > at javafx.scene.Scene.processMouseEvent(Scene.java:1874)
>     > at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2607)
>     > at
>     >
>     com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411)
>     > at
>     >
>     com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:301)
>     > at
>     >
>     java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
>     > at
>     >
>     com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:450)
>     > at
>     >
>     com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
>     > at
>     >
>     com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449)
>     > at com.sun.glass.ui.View.handleMouseEvent(View.java:551)
>     > at com.sun.glass.ui.View.notifyMouse(View.java:937)
>     > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>     > at
>     >
>     com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
>     > at java.base/java.lang.Thread.run(Thread.java:833)
>     > Caused by: java.lang.reflect.InvocationTargetException
>     > at
>     >
>     java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>
>     > Method)
>     > at
>     >
>     java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>     > at
>     >
>     java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>     > at com.sun.javafx.reflect.Trampoline.invoke(MethodUtil.java:77)
>     > at
>     >
>     java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>
>     > Method)
>     > at
>     >
>     java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>     > at
>     >
>     java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     > at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>     > at com.sun.javafx.reflect.MethodUtil.invoke(MethodUtil.java:275)
>     > at com.sun.javafx.fxml.MethodHelper.invoke(MethodHelper.java:84)
>     > at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1854)
>     > ... 50 more
>     > Caused by: java.util.ConcurrentModificationException
>     > at
>     >
>     java.base/java.util.AbstractList$Itr.checkForComodification(AbstractList.java:399)
>     > at java.base/java.util.AbstractList$Itr.next(AbstractList.java:368)
>     > at
>     >
>     javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:810)
>     > at
>     >
>     javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:811)
>     > at
>     javafx.scene.control.skin.MenuBarSkin.rebuildUI(MenuBarSkin.java:1017)
>     > at
>     javafx.scene.control.skin.MenuBarSkin.<init>(MenuBarSkin.java:356)
>     > at javafx.scene.control.MenuBar.createDefaultSkin(MenuBar.java:202)
>     > at javafx.scene.control.Control.doProcessCSS(Control.java:899)
>     > at javafx.scene.control.Control$1.doProcessCSS(Control.java:89)
>     > at
>     >
>     com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67)
>     > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>     > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
>     > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
>     > at
>     com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
>     > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>     > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
>     > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
>     > at
>     com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
>     > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>     > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
>     > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
>     > at
>     com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
>     > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>     > at javafx.scene.Node.processCSS(Node.java:9477)
>     > at javafx.scene.Scene.doCSSPass(Scene.java:572)
>     > at javafx.scene.Scene.preferredSize(Scene.java:1770)
>     > at javafx.scene.Scene$2.preferredSize(Scene.java:396)
>     > at
>     com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
>     > at javafx.stage.Window$12.invalidated(Window.java:1163)
>     > at
>     >
>     javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
>     > at
>     >
>     javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
>     > at javafx.stage.Window.setShowing(Window.java:1239)
>     > at javafx.stage.Window.show(Window.java:1254)
>     > at javafx.stage.Stage.show(Stage.java:277)
>     > at
>     >
>     com.foo.MainLayoutController.openNewWindow(MainLayoutController.java:3851)
>     >
>     >
>     >
>     >
>     >
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220908/bfbd3d9b/attachment-0001.htm>

From hmeda at openjdk.org  Thu Sep  8 15:12:29 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 8 Sep 2022 15:12:29 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1
Message-ID: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>

Updated icu to v71.1.
Verified build and sanity testing on windows,Mac and Linux.
Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

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

Commit messages:
 - Update file permission for rbbicst.pl
 - update file permission
 - Remove tabs
 - whitespace corrections
 - Remove white spaces
 - Update icu version and checksum
 - Update icu to v71-1

Changes: https://git.openjdk.org/jfx/pull/893/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289541
  Stats: 152378 lines in 757 files changed: 11009 ins; 123550 del; 17819 mod
  Patch: https://git.openjdk.org/jfx/pull/893.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/893/head:pull/893

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

From kcr at openjdk.org  Thu Sep  8 15:37:48 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 8 Sep 2022 15:37:48 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <WyVCFb9pSd8FKJ0uxkXWVGSZxeiB0w9owskq4y3Sd1w=.7b447d50-e070-4cc7-b0fe-14022d5bb8dc@github.com>

On Wed, 7 Sep 2022 18:13:43 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

One quick comment. I noticed that several files have changed from Unix-style line endings to DOS-style (CRLF) line endings. These are all extensions that aren't in our list of ones to check for whitespace (so jcheck won't catch them), but they should be converted back to Unix-style line endings to minimize diffs and avoid churn. Here is the list:


Source/ThirdParty/icu/source/common/common.rc
Source/ThirdParty/icu/source/common/common.vcxproj
Source/ThirdParty/icu/source/common/common.vcxproj.filters
Source/ThirdParty/icu/source/common/common_uwp.vcxproj
Source/ThirdParty/icu/source/common/rbbicst.pl
Source/ThirdParty/icu/source/common/rbbirpt.txt
Source/ThirdParty/icu/source/common/sources.txt
Source/ThirdParty/icu/source/i18n/i18n.rc
Source/ThirdParty/icu/source/i18n/i18n.vcxproj
Source/ThirdParty/icu/source/i18n/i18n.vcxproj.filters
Source/ThirdParty/icu/source/i18n/i18n_uwp.vcxproj
Source/ThirdParty/icu/source/i18n/regexcst.pl
Source/ThirdParty/icu/source/i18n/regexcst.txt
Source/ThirdParty/icu/source/i18n/sources.txt
Source/ThirdParty/icu/source/stubdata/sources.txt
Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj
Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj.filters
Source/ThirdParty/icu/source/tools/toolutil/sources.txt
Source/ThirdParty/icu/source/tools/toolutil/toolutil.vcxproj

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

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

From hmeda at openjdk.org  Thu Sep  8 16:58:32 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 8 Sep 2022 16:58:32 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v2]
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <79KJKsmMCCew0gXDF0HnKJEVVnN2dWh5_GNJiBK1Oxg=.0ea115ec-fd01-46c1-8d7b-23f550c6a9d3@github.com>

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Convert Line Endings to UNIX and update mainifest.txt

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/893/files
  - new: https://git.openjdk.org/jfx/pull/893/files/cc800aba..8135a606

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

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

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

From hmeda at openjdk.org  Thu Sep  8 16:58:34 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 8 Sep 2022 16:58:34 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1
In-Reply-To: <WyVCFb9pSd8FKJ0uxkXWVGSZxeiB0w9owskq4y3Sd1w=.7b447d50-e070-4cc7-b0fe-14022d5bb8dc@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <WyVCFb9pSd8FKJ0uxkXWVGSZxeiB0w9owskq4y3Sd1w=.7b447d50-e070-4cc7-b0fe-14022d5bb8dc@github.com>
Message-ID: <3fDA1CTlpVr-aT0JhhpYX2PVygmdcTM8-WwSAzbwDu8=.5b8e98e8-d301-4283-bf58-60f582729182@github.com>

On Thu, 8 Sep 2022 15:34:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> One quick comment. I noticed that several files have changed from Unix-style line endings to DOS-style (CRLF) line endings. These are all extensions that aren't in our list of ones to check for whitespace (so jcheck won't catch them), but they should be converted back to Unix-style line endings to minimize diffs and avoid churn. Here is the list:
> 
> ```
> Source/ThirdParty/icu/source/common/common.rc
> Source/ThirdParty/icu/source/common/common.vcxproj
> Source/ThirdParty/icu/source/common/common.vcxproj.filters
> Source/ThirdParty/icu/source/common/common_uwp.vcxproj
> Source/ThirdParty/icu/source/common/rbbicst.pl
> Source/ThirdParty/icu/source/common/rbbirpt.txt
> Source/ThirdParty/icu/source/common/sources.txt
> Source/ThirdParty/icu/source/i18n/i18n.rc
> Source/ThirdParty/icu/source/i18n/i18n.vcxproj
> Source/ThirdParty/icu/source/i18n/i18n.vcxproj.filters
> Source/ThirdParty/icu/source/i18n/i18n_uwp.vcxproj
> Source/ThirdParty/icu/source/i18n/regexcst.pl
> Source/ThirdParty/icu/source/i18n/regexcst.txt
> Source/ThirdParty/icu/source/i18n/sources.txt
> Source/ThirdParty/icu/source/stubdata/sources.txt
> Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj
> Source/ThirdParty/icu/source/stubdata/stubdata.vcxproj.filters
> Source/ThirdParty/icu/source/tools/toolutil/sources.txt
> Source/ThirdParty/icu/source/tools/toolutil/toolutil.vcxproj
> ```

Changed Line Endings to Unix-style

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

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

From kcr at openjdk.org  Thu Sep  8 17:04:56 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 8 Sep 2022 17:04:56 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v2]
In-Reply-To: <79KJKsmMCCew0gXDF0HnKJEVVnN2dWh5_GNJiBK1Oxg=.0ea115ec-fd01-46c1-8d7b-23f550c6a9d3@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <79KJKsmMCCew0gXDF0HnKJEVVnN2dWh5_GNJiBK1Oxg=.0ea115ec-fd01-46c1-8d7b-23f550c6a9d3@github.com>
Message-ID: <rvil6IBTQc_uup6G9v8jlVswrpDmhPymUlWH_idMiWg=.c01e13b0-b998-43b6-8d00-eb7aad74c6f8@github.com>

On Thu, 8 Sep 2022 16:58:32 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated icu to v71.1.
>> Verified build and sanity testing on windows,Mac and Linux.
>> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert Line Endings to UNIX and update mainifest.txt

modules/javafx.web/src/main/native/Source/WTF/CMakeLists.txt line 6:

> 4: 
> 5: add_subdirectory(wtf)
> 6: 

It looks like when you reverted some debugging changes, you removed an extra blank line. Since this file is otherwise now unchanged from master, can you revert the whole file (e.g., by using `git checkout master -- FILENAME`)?

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

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

From hmeda at openjdk.org  Thu Sep  8 17:13:32 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 8 Sep 2022 17:13:32 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v3]
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <Onzpf_EZhm76Ozc9G_cfaE2XXjJZAcn8VGoCtcYlosc=.1bc6af3c-e868-4ee5-bc42-db6449e292cf@github.com>

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Revert CMakelists.txt to be same as master

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/893/files
  - new: https://git.openjdk.org/jfx/pull/893/files/8135a606..84ef0a31

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

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

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

From hmeda at openjdk.org  Thu Sep  8 17:13:34 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 8 Sep 2022 17:13:34 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v3]
In-Reply-To: <rvil6IBTQc_uup6G9v8jlVswrpDmhPymUlWH_idMiWg=.c01e13b0-b998-43b6-8d00-eb7aad74c6f8@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <79KJKsmMCCew0gXDF0HnKJEVVnN2dWh5_GNJiBK1Oxg=.0ea115ec-fd01-46c1-8d7b-23f550c6a9d3@github.com>
 <rvil6IBTQc_uup6G9v8jlVswrpDmhPymUlWH_idMiWg=.c01e13b0-b998-43b6-8d00-eb7aad74c6f8@github.com>
Message-ID: <AVguKyvG3n8Xh0iewp01qVZwEeKQEuNhxtX_WT5zM9I=.8373a0cd-5757-4386-95ea-f3be6214c4f1@github.com>

On Thu, 8 Sep 2022 17:00:56 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert CMakelists.txt to be same as master
>
> modules/javafx.web/src/main/native/Source/WTF/CMakeLists.txt line 6:
> 
>> 4: 
>> 5: add_subdirectory(wtf)
>> 6: # Apple builds have the ICU headers checked into ${WTF_DIR}/icu
> 
> It looks like when you reverted some debugging changes, you removed an extra blank line. Since this file is otherwise now unchanged from master, can you revert the whole file (e.g., by using `git checkout master -- FILENAME`)?

Reverted the file to be same as master.

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

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

From hmeda at openjdk.org  Thu Sep  8 17:31:29 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 8 Sep 2022 17:31:29 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v4]
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <I_mqhqEi0sOBiQzLdpSEb9XVd0dztYibcN4d5Dn6p9w=.0db7a20c-9700-47e7-9cd5-e5eec464abf0@github.com>

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Space Corrections

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/893/files
  - new: https://git.openjdk.org/jfx/pull/893/files/84ef0a31..c9678a25

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

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

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

From daniel.peintner at gmail.com  Fri Sep  9 10:02:18 2022
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Fri, 9 Sep 2022 12:02:18 +0200
Subject: [External] : Re: ConcurrentModificationException when calling
 stage.show()
In-Reply-To: <7834a82a-479d-9647-aa16-e4ba9070132b@oracle.com>
References: <CAAoP7T6sdiVkhEf0t6RP5CGkNjnv2mE-BJ+1+rRoiuJZChZiuA@mail.gmail.com>
 <f2825357-6943-05d8-5e12-31a1692ab443@oracle.com>
 <CAAoP7T74BXGLd=5gG9LHjWWc0Jum1GQEsb0me1CK_Pt5HG-_PA@mail.gmail.com>
 <7834a82a-479d-9647-aa16-e4ba9070132b@oracle.com>
Message-ID: <CAAoP7T5GnPPr0ALH5d4ySTX6w_+xFb4wM9TK2V6qA8mWu7F=Ng@mail.gmail.com>

All,

Thanks for the confirmation.

I am currently trying to come up with a standalone test-case. Unfortunately
I failed to do so (so far). In the simple case the issue does not show up.
I will try further and file a bug report once I succeed.

-- Daniel




On Thu, Sep 8, 2022 at 2:26 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Presuming that you aren't calling initialize directly from some other
> thread, and aren't concurrently accessing the menu from some other thread,
> I agree that adding a runLater shouldn't be needed. So yes, this does seem
> like our bug. Can you file a bug report at https://bugreport.java.com/
> with a complete standalone test case?
>
> -- Kevin
>
> On 9/7/2022 11:57 PM, Daniel Peintner wrote:
>
> Hi Kevin, all,
>
> I investigated further and I think I found the problem (or at least a
> solution).
>
> In my application I use FXML+Controller approach.
>
> The issue I described arises if in controller.initialize(...).
> I update the menu-items of a menu. In my case, the menu list is empty in
> FXML and while initializing I update the menu with the "recently" opened
> files so that people can restart their work with files they opened before.
>
> The solution that works in my case is to wrap these menu updates in
> Platform.runLater() even though I think this should not be needed. Am I
> right?
>
> public class MyLayoutController extends BorderPane implements
> Initializable {
>     @Override
>     public void initialize(URL location, ResourceBundle resources) {
>         // updating the menu updates within runLater() does not cause
> ConcurrentModificationException
>         Platform.runLater(() -> {
>            // anyhow, I think this should not be needed
>            this.menu.getItems().add(new MenuItem("A"));
>            this.menu.getItems().add(new MenuItem("B"));
>            this.menu.getItems().add(new MenuItem("C"));
>         });
>     }
> }
>
> Is this sufficient to create a bug report?
>
> Thanks,
>
> -- Daniel
>
>
>
>
> On Mon, Sep 5, 2022 at 7:47 PM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> I suspect a JavaFX bug, unless there some other thread not shown in your
>> stack trace that is modifying any object in the now-live scene graph.
>>
>> -- Kevin
>>
>>
>> On 9/5/2022 6:34 AM, Daniel Peintner wrote:
>> > All,
>> >
>> > I have a strange issue popping up once in a while.
>> > I have an application (FXML+ Controller) that has a "new" button
>> > opening a new window. In 99% percent of the cases this works just fine.
>> >
>> > In some rare cases though, stage.show() fails due to a
>> > ConcurrentModificationException. Since this issue does not happen in
>> > my code but rather in JavaFX code I wanted to ask whether there is a
>> > specific prerequisite I am not aware of or whether this is a bug in
>> > JavaFX.
>> >
>> > Attached the stack trace. Unfortunately I am not able to create a
>> > reproducible example that fails always.
>> >
>> > I am grateful for any tip.
>> >
>> > Thanks,
>> >
>> > -- Daniel
>> >
>> >
>> > Exception in thread "JavaFX Application Thread"
>> > java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
>> > at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1857)
>> > at
>> >
>> javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(FXMLLoader.java:1724)
>> > at
>> >
>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
>> > at
>> >
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
>> > at
>> >
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>> > at
>> >
>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>> > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
>> > at javafx.event.Event.fireEvent(Event.java:198)
>> > at javafx.scene.Node.fireEvent(Node.java:8797)
>> > at javafx.scene.control.Button.fire(Button.java:203)
>> > at
>> >
>> com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:208)
>> > at
>> > com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
>> > at
>> >
>> com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
>> > at
>> >
>> com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
>> > at
>> >
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
>> > at
>> >
>> com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
>> > at
>> >
>> com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at
>> >
>> com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
>> > at
>> >
>> com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
>> > at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
>> > at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:54)
>> > at javafx.event.Event.fireEvent(Event.java:198)
>> > at javafx.scene.Scene$MouseHandler.process(Scene.java:3881)
>> > at javafx.scene.Scene.processMouseEvent(Scene.java:1874)
>> > at javafx.scene.Scene$ScenePeerListener.mouseEvent(Scene.java:2607)
>> > at
>> >
>> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:411)
>> > at
>> >
>> com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(GlassViewEventHandler.java:301)
>> > at
>> >
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
>> > at
>> >
>> com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(GlassViewEventHandler.java:450)
>> > at
>> >
>> com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(QuantumToolkit.java:424)
>> > at
>> >
>> com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(GlassViewEventHandler.java:449)
>> > at com.sun.glass.ui.View.handleMouseEvent(View.java:551)
>> > at com.sun.glass.ui.View.notifyMouse(View.java:937)
>> > at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
>> > at
>> >
>> com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:184)
>> > at java.base/java.lang.Thread.run(Thread.java:833)
>> > Caused by: java.lang.reflect.InvocationTargetException
>> > at
>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> > Method)
>> > at
>> >
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> > at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> > at com.sun.javafx.reflect.Trampoline.invoke(MethodUtil.java:77)
>> > at
>> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> > Method)
>> > at
>> >
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
>> > at
>> >
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> > at com.sun.javafx.reflect.MethodUtil.invoke(MethodUtil.java:275)
>> > at com.sun.javafx.fxml.MethodHelper.invoke(MethodHelper.java:84)
>> > at javafx.fxml.FXMLLoader$MethodHandler.invoke(FXMLLoader.java:1854)
>> > ... 50 more
>> > Caused by: java.util.ConcurrentModificationException
>> > at
>> >
>> java.base/java.util.AbstractList$Itr.checkForComodification(AbstractList.java:399)
>> > at java.base/java.util.AbstractList$Itr.next(AbstractList.java:368)
>> > at
>> >
>> javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:810)
>> > at
>> >
>> javafx.scene.control.skin.MenuBarSkin.updateActionListeners(MenuBarSkin.java:811)
>> > at
>> javafx.scene.control.skin.MenuBarSkin.rebuildUI(MenuBarSkin.java:1017)
>> > at javafx.scene.control.skin.MenuBarSkin.<init>(MenuBarSkin.java:356)
>> > at javafx.scene.control.MenuBar.createDefaultSkin(MenuBar.java:202)
>> > at javafx.scene.control.Control.doProcessCSS(Control.java:899)
>> > at javafx.scene.control.Control$1.doProcessCSS(Control.java:89)
>> > at
>> >
>> com.sun.javafx.scene.control.ControlHelper.processCSSImpl(ControlHelper.java:67)
>> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>> > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
>> > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
>> > at
>> com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
>> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>> > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
>> > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
>> > at
>> com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
>> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>> > at javafx.scene.Parent.doProcessCSS(Parent.java:1400)
>> > at javafx.scene.Parent$1.doProcessCSS(Parent.java:125)
>> > at
>> com.sun.javafx.scene.ParentHelper.processCSSImpl(ParentHelper.java:98)
>> > at com.sun.javafx.scene.NodeHelper.processCSS(NodeHelper.java:146)
>> > at javafx.scene.Node.processCSS(Node.java:9477)
>> > at javafx.scene.Scene.doCSSPass(Scene.java:572)
>> > at javafx.scene.Scene.preferredSize(Scene.java:1770)
>> > at javafx.scene.Scene$2.preferredSize(Scene.java:396)
>> > at com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
>> > at javafx.stage.Window$12.invalidated(Window.java:1163)
>> > at
>> >
>> javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
>> > at
>> >
>> javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
>> > at javafx.stage.Window.setShowing(Window.java:1239)
>> > at javafx.stage.Window.show(Window.java:1254)
>> > at javafx.stage.Stage.show(Stage.java:277)
>> > at
>> >
>> com.foo.MainLayoutController.openNewWindow(MainLayoutController.java:3851)
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220909/06ac3b00/attachment-0001.htm>

From angorya at openjdk.org  Fri Sep  9 20:27:41 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 20:27:41 GMT
Subject: RFR: 8290844: Add Skin.install() method [v2]
In-Reply-To: <LB-6ZxN7pRh7gYzlfbjTNtDokxXjIeGqF3bFJCBWv6c=.ac023f3e-32cd-4cf9-904f-f0ef5c9efd59@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <DGrfLZMvKR7iNzIydpn_Cfgc4YD27TmcFwMEPq2JdvI=.7179b37a-7f72-43b5-8939-506958648cae@github.com>
 <zZzAu45drvLELBvaNzDrLtePlUig86kXQTbL1dhlZK0=.9352d943-8f35-4668-8a36-d5b63aa1051d@github.com>
 <LB-6ZxN7pRh7gYzlfbjTNtDokxXjIeGqF3bFJCBWv6c=.ac023f3e-32cd-4cf9-904f-f0ef5c9efd59@github.com>
Message-ID: <L-xJmQgTS57uKWRzCGyiT0Pvats24rF79T6LP20L1z4=.a6e775ee-20b8-413c-9586-695388d90afd@github.com>

On Wed, 7 Sep 2022 19:11:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 33:
>> 
>>> 31:  * An interface for defining the visual representation of user interface controls
>>> 32:  * by defining a scene graph of nodes to represent the skin.
>>> 33:  * A user interface control is abstracted behind the {@link Skinnable} interface.
>> 
>> shouldn't that be _to represent the skinnable_?
>
> I think what @kleopatra meant was that the portion of the sentence _after_ the one you changed should read:
> 
> 
>  * by defining a scene graph of nodes to represent the skinnable.
> 
> 
> I think she's right. The scene graph of nodes _is_ the implementation of the Skin, which represents the Skinnable. I wonder if it would be clearer to just remove that last part and put a period after `user interface controls`?

removed the part after ```user interface controls```.

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

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

From angorya at openjdk.org  Fri Sep  9 20:27:43 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 20:27:43 GMT
Subject: RFR: 8290844: Add Skin.install() method [v4]
In-Reply-To: <sz-GULAz7JwqO4ZImtGl1jyqKNckleqD0tp3fRd6nj8=.07445d17-2f3f-4b69-87bd-ac497fd43fcc@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <uMYCL8T8q4rhHiPwGemALYTx2W5Tupchli7XXT6AeAI=.a80580b3-c8f8-4632-90ab-62e3e5ed9d0f@github.com>
 <sz-GULAz7JwqO4ZImtGl1jyqKNckleqD0tp3fRd6nj8=.07445d17-2f3f-4b69-87bd-ac497fd43fcc@github.com>
Message-ID: <UAbTGmuRN2fRbBgZySWRfPg-Accq8q-AHQz1HpYnCCw=.439f8529-ee04-4319-958f-ca67031a6f11@github.com>

On Wed, 7 Sep 2022 20:49:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290844: review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 35:
> 
>> 33:  * A user interface control is abstracted behind the {@link Skinnable} interface.
>> 34:  * <p>
>> 35:  * A Skin implementation should generally avoid modifying its control outside of
> 
> I think this is a good start. As discussed elsewhere, additional implementation notes for Skin implementers would be helpful.

added @ImplNote to install().

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

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

From angorya at openjdk.org  Fri Sep  9 20:36:48 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 20:36:48 GMT
Subject: RFR: 8290844: Add Skin.install() method [v3]
In-Reply-To: <ZQYbC4xIguELzy8MgT9D_CjYLNYmosMRMMUrRzRyFGI=.ae89aca5-187c-4778-bcbe-00789d7a57cd@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com>
 <c8fHaC3pq3zDgtL17byHXdz0j7y3Rv4QOZXuWLj2uZE=.edfe3014-2f27-4d2d-bda1-ceb997c95ddb@github.com>
 <4e0CXICdrqox7rR1RzRzitJdpPcNyDmZYbe6C-oGSp0=.94d3b817-2190-4987-966c-8222aad3c4d7@github.com>
 <ZQYbC4xIguELzy8MgT9D_CjYLNYmosMRMMUrRzRyFGI=.ae89aca5-187c-4778-bcbe-00789d7a57cd@github.com>
Message-ID: <PaIHUUuHmtjblLLDR6k4YTWAA2EqKerLIFptRe2znv4=.1ed021a1-431c-4bca-a16e-8dd4489cb773@github.com>

On Wed, 7 Sep 2022 19:06:29 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @throws IllegalArgumentException if {@link Skin#getSkinnable()} returns a different {@code Skinnable}
>> 
>> is this better?
>
> As discussed elsewhere, only the property method should have javadoc comments, so this should be moved up to the property method, and the existing javadoc comments for this method should be deleted.
> 
> I think we need a clearer statement here, given that there are only two top-level classes that implement `Skinnable`, `Control` and `PopupControl`, and thus override this method. `Control` enforces the 1-to-1 relationship by throwing an IAE if the `Skinnable` of the `Skin` doesn't match the `Control`, while `PopupControl` does not.
> 
> So maybe something a little more definitive, like this?
> 
> 
>      * To ensure a one-to-one relationship between a {@code Skinnable} and its
>      * {@code Skin}, some implementations of this method will check the return value of
>      * {@link Skin#getSkinnable()} against this Skinnable,
>      * and throw an {@code IllegalArgumentException} if it is not the same.
> 
> 
> And then the exception could be changed to say....
> 
> 
>      * @throws IllegalArgumentException if {@code skin.getSkinnable() != this}, for
>      * implementations that enforce this restriction
> 
> 
> This information would then be repeated in the `Control` class, but without the qualification.

also updated Control skinProperty javadoc, please review.

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

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

From angorya at openjdk.org  Fri Sep  9 20:43:47 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 20:43:47 GMT
Subject: RFR: 8290844: Add Skin.install() method [v3]
In-Reply-To: <ZQYbC4xIguELzy8MgT9D_CjYLNYmosMRMMUrRzRyFGI=.ae89aca5-187c-4778-bcbe-00789d7a57cd@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <0mPSqBJK004uUxWtMStMuw9Aep_3qiFezuzk6ZgvLbQ=.def313ce-60e0-489e-bf60-5f8dd8ecff06@github.com>
 <c8fHaC3pq3zDgtL17byHXdz0j7y3Rv4QOZXuWLj2uZE=.edfe3014-2f27-4d2d-bda1-ceb997c95ddb@github.com>
 <4e0CXICdrqox7rR1RzRzitJdpPcNyDmZYbe6C-oGSp0=.94d3b817-2190-4987-966c-8222aad3c4d7@github.com>
 <ZQYbC4xIguELzy8MgT9D_CjYLNYmosMRMMUrRzRyFGI=.ae89aca5-187c-4778-bcbe-00789d7a57cd@github.com>
Message-ID: <-jHequZtQGiRWmmPXVlA5bK7e3W0lTsgAskt3aaahSI=.e287799e-e1a4-44ee-91ad-423e7e461947@github.com>

On Wed, 7 Sep 2022 19:07:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> So javadoc tool ignores the interface, resulting in Control.setSkin(skin) method inheriting the property's description.  
>> 
>> Curiously, eclipse does show the interface's version, which I think helps more than having three identical descriptions for the property, its getter and setter.
>> 
>> What would you recommend we do here?
>
> I recommend that we follow the existing practice of only putting the docs on the `xxxProperty` method, which includes removing the docs from `{set|get}Skin` in `Skinnable`, `Control`, and `PopupControl`. I checked it and it does what I would expect (except for a minor issue in that the `@throws` doesn't generate any docs, but since the Description indicates the conditions under which it will throw IAE, that's not a big problem; I'll file an RFE against the javadoc tool).

done

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

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

From angorya at openjdk.org  Fri Sep  9 20:47:56 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 20:47:56 GMT
Subject: RFR: 8290844: Add Skin.install() method [v5]
In-Reply-To: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
Message-ID: <94JWlhRZbd8ERyHGxsu_W0pkZVHYbCooIsRtAyvBrmk=.d5ffe60f-bf8d-4cc1-a980-e77eaa907150@github.com>

> - added Skin.install()
> - javadoc changes for Skinnable.setSkin(Skin)
> 
> no code changes for Skinnable.setSkin(Skin) yet.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - 8290844: review comments
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: review comments
 - 8290844: review comments
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: javadoc
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8289397: added space
 - 8290844: skin.install
 - 8290844: whitespace
 - ... and 6 more: https://git.openjdk.org/jfx/compare/04fd1ec9...7d5db78b

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/845/files
  - new: https://git.openjdk.org/jfx/pull/845/files/108efb89..7d5db78b

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

  Stats: 8691 lines in 255 files changed: 5937 ins; 1760 del; 994 mod
  Patch: https://git.openjdk.org/jfx/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845

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

From angorya at openjdk.org  Fri Sep  9 21:19:15 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 21:19:15 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy
Message-ID: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>

Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810

This PR might need a CSR since a public method is added to VirtualFlow:


    /**
     * Suppresses the breadth bar from appearing.
     */
    public void setSuppressBreadthBar(boolean suppress) {
        this.suppressBreadthBar = suppress;
    }

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

Commit messages:
 - 8089280: constrained resize policy suppresses horizontal scroll bar

Changes: https://git.openjdk.org/jfx/pull/894/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8089280
  Stats: 38 lines in 5 files changed: 23 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/894.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/894/head:pull/894

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

From kcr at openjdk.org  Fri Sep  9 21:31:51 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 Sep 2022 21:31:51 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <2bvI4dMoJSlM7d7RvjGZi2HQvmfp7R6sSfeHpSEd_9s=.137a4c8e-689b-4683-9278-a4174f3c7027@github.com>

On Fri, 9 Sep 2022 21:13:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
> 
> This PR might need a CSR since a public method is added to VirtualFlow:
> 
> 
>     /**
>      * Suppresses the breadth bar from appearing.
>      */
>     public void setSuppressBreadthBar(boolean suppress) {
>         this.suppressBreadthBar = suppress;
>     }

This should be done without adding any new public API, since that is beyond the scope of a simple bug fix. Adding new public API has implications that are better discussed when adding the additional functionality being worked on in [JDK-8293119](https://bugs.openjdk.org/browse/JDK-8293119).

Btw, in addition to the new `VirtualFlow` method, this PR adds `TableViewSkinBase::updateSuppressBreadthBar` to the public API. Both look like implementation details.

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

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

From kcr at openjdk.org  Fri Sep  9 21:35:48 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 9 Sep 2022 21:35:48 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <pz_-llO13WXm7DcNT3ZxgOiSkN0_hXlEa753jxwjbHw=.ddfaed32-8564-40f7-9763-ed4df5542732@github.com>

On Fri, 9 Sep 2022 21:13:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
> 
> This PR might need a CSR since a public method is added to VirtualFlow:
> 
> 
>     /**
>      * Suppresses the breadth bar from appearing.
>      */
>     public void setSuppressBreadthBar(boolean suppress) {
>         this.suppressBreadthBar = suppress;
>     }

Both of the two implementation methods can be made package-scope, since they are not used outside the package (so no need for accessors or anything else complicated to hide the details).

Is it feasible to provide a unit test for this?

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 898:

> 896:     }
> 897: 
> 898:     protected void updateSuppressBreadthBar() {

This should be package-scope.

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

> 2381:      * Suppresses the breadth bar from appearing.
> 2382:      */
> 2383:     public void setSuppressBreadthBar(boolean suppress) {

This should be package-scope.

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

Changes requested by kcr (Lead).

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

From angorya at openjdk.org  Fri Sep  9 21:40:18 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 21:40:18 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy
In-Reply-To: <pz_-llO13WXm7DcNT3ZxgOiSkN0_hXlEa753jxwjbHw=.ddfaed32-8564-40f7-9763-ed4df5542732@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <pz_-llO13WXm7DcNT3ZxgOiSkN0_hXlEa753jxwjbHw=.ddfaed32-8564-40f7-9763-ed4df5542732@github.com>
Message-ID: <zGHvbk6ULONSo-ttirsu1_b6yaKxApNjlQmAPJqIseo=.27f3a88e-743a-47f3-ab3f-590146b4e75e@github.com>

On Fri, 9 Sep 2022 21:30:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>> 
>> This PR might need a CSR since a public method is added to VirtualFlow:
>> 
>> 
>>     /**
>>      * Suppresses the breadth bar from appearing.
>>      */
>>     public void setSuppressBreadthBar(boolean suppress) {
>>         this.suppressBreadthBar = suppress;
>>     }
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 898:
> 
>> 896:     }
>> 897: 
>> 898:     protected void updateSuppressBreadthBar() {
> 
> This should be package-scope.

good point

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 2383:
> 
>> 2381:      * Suppresses the breadth bar from appearing.
>> 2382:      */
>> 2383:     public void setSuppressBreadthBar(boolean suppress) {
> 
> This should be package-scope.

yes

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

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

From angorya at openjdk.org  Fri Sep  9 22:00:39 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 22:00:39 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
> 
> This PR might need a CSR since a public method is added to VirtualFlow:
> 
> 
>     /**
>      * Suppresses the breadth bar from appearing.
>      */
>     public void setSuppressBreadthBar(boolean suppress) {
>         this.suppressBreadthBar = suppress;
>     }

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8089280: added tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/894/files
  - new: https://git.openjdk.org/jfx/pull/894/files/ac97fb72..dc1dc25c

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

  Stats: 147 lines in 4 files changed: 99 ins; 37 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/894.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/894/head:pull/894

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

From angorya at openjdk.org  Fri Sep  9 22:00:41 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 9 Sep 2022 22:00:41 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <MrNaFQCKJ83hXj6ODS7-d8-kOEeLvZtYXsuBZpCUWEY=.ebabe911-f59e-48e1-81b6-52f37773ff36@github.com>

On Fri, 9 Sep 2022 21:13:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
> 
> This PR might need a CSR since a public method is added to VirtualFlow:
> 
> 
>     /**
>      * Suppresses the breadth bar from appearing.
>      */
>     public void setSuppressBreadthBar(boolean suppress) {
>         this.suppressBreadthBar = suppress;
>     }

added unit tests for Tree- and TableView

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

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

From kcr at openjdk.org  Sat Sep 10 15:18:54 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 10 Sep 2022 15:18:54 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
Message-ID: <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>

On Fri, 9 Sep 2022 22:00:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8089280: added tests

The fix looks good to me. I verified that the new tests fail without the fix and pass with the fix. I was also able to reproduce the problem using the [HorizontalConstrainedTableScrollingMin test](https://bugs.openjdk.org/browse/JDK-8089280?focusedCommentId=14521664&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521664) from the bug report without the fix, and verified that it works as expected with the fix.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableSkinUtils.java line 215:

> 213:     public static boolean isConstrainedResizePolicy(Callback<? extends ResizeFeaturesBase,Boolean> x) {
> 214:         return (x == (Object)TableView.CONSTRAINED_RESIZE_POLICY) ||
> 215:                (x == (Object)TreeTableView.CONSTRAINED_RESIZE_POLICY);

Is the cast to `(Object)` needed?

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

> 305:     private boolean needLengthBar;
> 306:     private boolean tempVisibility = false;
> 307:     private boolean suppressBreadthBar;

Suggestion (optional) : You might want to explicitly initialize this to `false`, since we rely on this for other controls (e.g., `ListView`) which don't call `setSuppressBreadthBar`. (yes, I know Java will initialize it to false anyway, but setting it explicitly could be helpful to a reader of the code)

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

Marked as reviewed by kcr (Lead).

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

From john.hendrikx at gmail.com  Sun Sep 11 06:08:36 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sun, 11 Sep 2022 08:08:36 +0200
Subject: LayoutChildren documentation
Message-ID: <dd31f819-30da-d3ce-b1cb-bfab203e8a26@gmail.com>

TLDR; I think layoutChildren should mention it is not a good practice to 
modify the list of children during the layout pass as CSS won't be 
applied to them for 1 rendered frame, and perhaps mention a solution 
(Scene#addPreLayoutPulseListener?)

I've been recently bit by an issue that I think might need to be 
documented a bit better.

LayoutChildren is typically overriden for custom layouts.

It's documentation:

 ???? * Invoked during the layout pass to layout the children in this
 ???? * {@code Parent}. By default it will only set the size of managed,
 ???? * resizable content to their preferred sizes and does not do any node
 ???? * positioning.
 ???? * <p>
 ???? * Subclasses should override this function to layout content as 
needed.

A custom layout can be simple, but sometimes may involve adding or 
removing children dynamically based on the content of the control. What 
layoutChildren here does not mention is that if you add children during 
layoutChildren, there will be 1 rendered frame where these children 
don't have any CSS styling applied. The system detects however that 
children were modified and layoutChildren will be called again (in the 
same pass AFAIK), resulting hopefully in a stable set of children.

The problem here is the fact that a frame is rendered without any CSS 
applied. For applications using a black background in general, the new 
children with a white background will cause a temporary "white flash" to 
be rendered. It took me ages to figure out where it came from, and it 
wasn't always easy to reproduce (if the children already existed, they 
were just modified, it only happened for cases where new children had to 
be added during the layout pass and which were clearly visible somewhere).

Obviously, changes to CSS files had no effect on solving this (like 
setting everything to have a black or transparent) background at ".root" 
level.

Calling #applyCSS on the newly added children during #layoutChildren 
does not solve the problem. Still one frame is rendered without CSS, and 
a white flash occurs.

Adding the children during the #computeXXX methods is too late as well, 
the CSS pass has finished already by that time.? This does however avoid 
having #layoutChildren called again in the same pass if children are 
added. There is this issue that relates to this: 
https://bugs.openjdk.org/browse/JDK-8091873 where it is suggested to 
perhaps add a more general method for this.

What I needed is a callback for my control before layout occurs and 
before CSS is applied.

Scene has a #addPreLayoutPulseListener which mentions it is called 
before CSS is applied. Its #addPostLayoutPulseListener counterpart also 
mentions `AnimationTimer` as a way to get a callback before CSS is 
applied. Implementing this call back and changing the list of children 
there solved the "white flash" problem. It feels a bit overkill though 
to listen to every pulse on a Scene just for the layout of one control 
(that may not need layout during most passes).

Aside from changing the documentation to ensure people understand that 
modifying the list of children during layout can have temporary CSS 
issues, I'm wondering what would be the preferred solution to this 
problem. Is there a different way of handling this that I haven't found, 
aside from the #addPreLayoutPulseListener or AnimationTimer ?? If not, 
could the issue (https://bugs.openjdk.org/browse/JDK-8091873) perhaps be 
resolved by adding two methods?? One that is called before CSS is 
applied, and one before any compute methods are called?? If adding a 
method that is called before CSS, is there even a way to determine if a 
Node needs this call to prevent calling it on every Node on every layout 
pulse?

The current solution I'm using is like 15 lines of code as part of a 
ListView skin:

 ??? private final Runnable pulseListener = () -> content.manageCells();

 ??? private void updatePreLayoutPulseListener(Scene old, Scene current) {
 ????? if(old != null) {
 ??????? old.removePreLayoutPulseListener(pulseListener);
 ????? }
 ????? if(current != null) {
 ??????? current.addPreLayoutPulseListener(pulseListener);
 ????? }
 ??? }

And in the constructor:

 ??? updatePreLayoutPulseListener(null, skinnable.getScene());

 ??? skinnable.sceneProperty().addListener((obs, old, current) -> 
updatePreLayoutPulseListener(old, current));

And in dispose:

 ??? updatePreLayoutPulseListener(skinnable.getScene(), null);

--John






From johan.vos at gluonhq.com  Sun Sep 11 08:52:48 2022
From: johan.vos at gluonhq.com (Johan Vos)
Date: Sun, 11 Sep 2022 10:52:48 +0200
Subject: LayoutChildren documentation
In-Reply-To: <dd31f819-30da-d3ce-b1cb-bfab203e8a26@gmail.com>
References: <dd31f819-30da-d3ce-b1cb-bfab203e8a26@gmail.com>
Message-ID: <CABxFH2E9itLk2Q8yCD_TEexxRwR-mJswdHXaAi1=euDis138hA@mail.gmail.com>

Hi John,

This is not a solution for your specific problem (new children added
without CSS being applied), but in general, I have run into similar issues
many times. I find the JavaFX JavaDoc very valuable for most JavaFX
application developers, but for lower-level library development, or for
JavaFX core development, there are a number of things that are crucial but
not in the javadoc.

One of the key things I often have to almost reverse engineer, is the exact
flow that happens when a pulse is requested (e.g. Toolkit.java,
QuantumToolkit.java and the Scene.ScenePulseListener).
I personally don't think JavaDoc is the best place to address this, as it
might confuse the app developers. I think the openjfx wiki would be a good
place for this but it requires time and a good understanding (which
requires even more time).
The page at https://wiki.openjdk.org/display/OpenJFX/Graphics provides the
skeleton that can be the basis for this. As usual, the problem is that time
spent on this can not be spent in fixing bugs -- although in the
medium/long term, having this improved semi-internal (or at least
lower-level) doc would allow more developers to fix issues faster.

- Johan



On Sun, Sep 11, 2022 at 8:10 AM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> TLDR; I think layoutChildren should mention it is not a good practice to
> modify the list of children during the layout pass as CSS won't be
> applied to them for 1 rendered frame, and perhaps mention a solution
> (Scene#addPreLayoutPulseListener?)
>
> I've been recently bit by an issue that I think might need to be
> documented a bit better.
>
> LayoutChildren is typically overriden for custom layouts.
>
> It's documentation:
>
>       * Invoked during the layout pass to layout the children in this
>       * {@code Parent}. By default it will only set the size of managed,
>       * resizable content to their preferred sizes and does not do any node
>       * positioning.
>       * <p>
>       * Subclasses should override this function to layout content as
> needed.
>
> A custom layout can be simple, but sometimes may involve adding or
> removing children dynamically based on the content of the control. What
> layoutChildren here does not mention is that if you add children during
> layoutChildren, there will be 1 rendered frame where these children
> don't have any CSS styling applied. The system detects however that
> children were modified and layoutChildren will be called again (in the
> same pass AFAIK), resulting hopefully in a stable set of children.
>
> The problem here is the fact that a frame is rendered without any CSS
> applied. For applications using a black background in general, the new
> children with a white background will cause a temporary "white flash" to
> be rendered. It took me ages to figure out where it came from, and it
> wasn't always easy to reproduce (if the children already existed, they
> were just modified, it only happened for cases where new children had to
> be added during the layout pass and which were clearly visible somewhere).
>
> Obviously, changes to CSS files had no effect on solving this (like
> setting everything to have a black or transparent) background at ".root"
> level.
>
> Calling #applyCSS on the newly added children during #layoutChildren
> does not solve the problem. Still one frame is rendered without CSS, and
> a white flash occurs.
>
> Adding the children during the #computeXXX methods is too late as well,
> the CSS pass has finished already by that time.  This does however avoid
> having #layoutChildren called again in the same pass if children are
> added. There is this issue that relates to this:
> https://bugs.openjdk.org/browse/JDK-8091873 where it is suggested to
> perhaps add a more general method for this.
>
> What I needed is a callback for my control before layout occurs and
> before CSS is applied.
>
> Scene has a #addPreLayoutPulseListener which mentions it is called
> before CSS is applied. Its #addPostLayoutPulseListener counterpart also
> mentions `AnimationTimer` as a way to get a callback before CSS is
> applied. Implementing this call back and changing the list of children
> there solved the "white flash" problem. It feels a bit overkill though
> to listen to every pulse on a Scene just for the layout of one control
> (that may not need layout during most passes).
>
> Aside from changing the documentation to ensure people understand that
> modifying the list of children during layout can have temporary CSS
> issues, I'm wondering what would be the preferred solution to this
> problem. Is there a different way of handling this that I haven't found,
> aside from the #addPreLayoutPulseListener or AnimationTimer ?  If not,
> could the issue (https://bugs.openjdk.org/browse/JDK-8091873) perhaps be
> resolved by adding two methods?  One that is called before CSS is
> applied, and one before any compute methods are called?  If adding a
> method that is called before CSS, is there even a way to determine if a
> Node needs this call to prevent calling it on every Node on every layout
> pulse?
>
> The current solution I'm using is like 15 lines of code as part of a
> ListView skin:
>
>      private final Runnable pulseListener = () -> content.manageCells();
>
>      private void updatePreLayoutPulseListener(Scene old, Scene current) {
>        if(old != null) {
>          old.removePreLayoutPulseListener(pulseListener);
>        }
>        if(current != null) {
>          current.addPreLayoutPulseListener(pulseListener);
>        }
>      }
>
> And in the constructor:
>
>      updatePreLayoutPulseListener(null, skinnable.getScene());
>
>      skinnable.sceneProperty().addListener((obs, old, current) ->
> updatePreLayoutPulseListener(old, current));
>
> And in dispose:
>
>      updatePreLayoutPulseListener(skinnable.getScene(), null);
>
> --John
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220911/47ba6850/attachment-0001.htm>

From fastegal at openjdk.org  Sun Sep 11 09:42:48 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Sun, 11 Sep 2022 09:42:48 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
Message-ID: <BxWvgf6XK6nsYF--f1nnNpzmrGDNumtRbCz5LhBn01w=.3de1982f-5143-46f0-8646-bb646f046bf1@github.com>

On Sat, 10 Sep 2022 15:15:01 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The fix looks good to me. I verified that the new tests fail without the fix and pass with the fix. I was also able to reproduce the problem using the [HorizontalConstrainedTableScrollingMin test](https://bugs.openjdk.org/browse/JDK-8089280?focusedCommentId=14521664&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14521664) from the bug report without the fix, and verified that it works as expected with the fix.

wondering about your comment in the bug report: you stated that you can reproduce it on Win, does this imply you couldn't on Mac?

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

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

From jvos at openjdk.org  Sun Sep 11 12:19:25 2022
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 11 Sep 2022 12:19:25 GMT
Subject: RFR: 8254676: Alert disables Tab selection when TabDragPolicy REORDER
 is usedDon't set TabHeader to mouseTransparent,
 since it might get stuck in =?UTF-8?B?4oCm?=
Message-ID: <M_UldTEZfn072rPUS8OvvUfEOv_PbDZi4K7xrbEHJ0Q=.944ed2b9-fd84-4d0f-ae10-5d680ef605c9@github.com>

Don't set TabHeader to mouseTransparent, since it might get stuck in that state (e.g. in case an Alert is shown).
The TabPaneSkin deals with the dragging internally, and does not require the dragged node to be mouseTransparent.

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

Commit messages:
 - Don't set TabHeader to mouseTransparent, since it might get stuck in that

Changes: https://git.openjdk.org/jfx/pull/895/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=895&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/jfx/pull/895.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/895/head:pull/895

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

From mhanl at openjdk.org  Sun Sep 11 19:27:51 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 11 Sep 2022 19:27:51 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v2]
In-Reply-To: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
Message-ID: <gjsbkNRDv0_vQ2AWsMrn1muD3OyO4W37bhjpwkS1-oE=.7dfc82b4-e4db-4918-ba26-8d5ad7746af3@github.com>

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");

Marius Hanl has updated the pull request incrementally with three additional commits since the last revision:

 - Fix NPE for null selection/focus -model in queryAccessibleAttribute(..)
 - Still set anchor when the selection model is null
 - Using global StageLoader

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/711/files
  - new: https://git.openjdk.org/jfx/pull/711/files/d31d3ecc..ffe781dd

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

  Stats: 89 lines in 4 files changed: 71 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/711.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/711/head:pull/711

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

From mhanl at openjdk.org  Sun Sep 11 19:30:18 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 11 Sep 2022 19:30:18 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v3]
In-Reply-To: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
Message-ID: <LpCtvf1YJSHmIoMwI1TEBU_GNXhpbNyirxwab2rmP_Q=.b9e63fdd-1bfe-46d5-a7bf-e3ec5adb3b8c@github.com>

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");

Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jfx into 8279640-list-view-null-selection-focus-model
 - Fix NPE for null selection/focus -model in queryAccessibleAttribute(..)
 - Still set anchor when the selection model is null
 - Using global StageLoader
 - 8279640: ListView with null SelectionModel/FocusModel throws NPE

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/711/files
  - new: https://git.openjdk.org/jfx/pull/711/files/ffe781dd..9146e080

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

  Stats: 982567 lines in 11349 files changed: 579480 ins; 264970 del; 138117 mod
  Patch: https://git.openjdk.org/jfx/pull/711.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/711/head:pull/711

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

From mhanl at openjdk.org  Sun Sep 11 19:31:34 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 11 Sep 2022 19:31:34 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v3]
In-Reply-To: <S9bFfAz5zgVxQa51R941PV89Jo2OEXdYU8xnqvEBSQo=.e5e7ad36-134a-4dd2-8992-c7a49e08d5fe@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <S9bFfAz5zgVxQa51R941PV89Jo2OEXdYU8xnqvEBSQo=.e5e7ad36-134a-4dd2-8992-c7a49e08d5fe@github.com>
Message-ID: <jI6hMioU_3Xnw_r3PDSugTPt4JfRZyIn8vEPuWY3CNA=.8bfcc9c4-5307-47d0-a31f-7442d6b18516@github.com>

On Sun, 21 Aug 2022 11:54:05 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> Fix and tests look rather complete, NPEs are fixed
> 
> There is still one unguarded access to the selectionModel in ListViewSkin.queryAccessibleAttributes: don't know if that's ever reached without actually having a selectionModel?
> 
> As we have similar NPEs in all our behaviors (of virtualized controls), we might decided here which behavior we want to support and then apply that decision everywhere. In particular what should happen if we have a null selection and a not-null focusModel with
> 
> * activate/edit: that happens on the focusedIndex/Cell with selection only an after-thought
> * focus navigation (often ctrl-somekey): is inconsistently either supported (ctrl-end) or not (ctrl-pageDown)
> 
> Personally, I think that we should support both - we have a separate focusModel so should use it independently of the selectionModel where possible. A good starter for this issue might be to implement the activate such that it doesn't back out on null selection (just leave out the select statement). The consistent support of navigation might be done in a follow-up issue.

`queryAccessibleAttributes` is now fixed, as well as the other things you mentioned. :)

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

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

From mhanl at openjdk.org  Sun Sep 11 22:34:52 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 11 Sep 2022 22:34:52 GMT
Subject: RFR: 8264591: HBox/VBox child widths pixel-snap to wrong value
 [v6]
In-Reply-To: <Ba_WtrpY71Q7pH7T-LgfNlUO1YMK-scaJ6mawML_3GI=.ae9d1bdd-8ccd-4320-9c9d-6defcff30b3e@github.com>
References: <G4CV48fRvM_Z0Pr3TOLAY30nRkXFiJt0_Dok6nZia0c=.06e485d2-727a-4e54-acf8-208397a7af90@github.com>
 <Ba_WtrpY71Q7pH7T-LgfNlUO1YMK-scaJ6mawML_3GI=.ae9d1bdd-8ccd-4320-9c9d-6defcff30b3e@github.com>
Message-ID: <revc_ZKFAyg3JGZ0UBmHIAgiDt7GM1T5rvJlVVSmupc=.2a56fb30-3f4b-48bd-be6b-6a662f52de4e@github.com>

On Fri, 8 Jul 2022 23:12:50 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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - 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
>  - Fix pixel-snapping glitches in VBox/HBox
>  - Failing test

Tested the changes with some easy and more complex layout and it looks good

modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java line 804:

> 802:      */
> 803:     @Test public void testPixelSnappedContentHeightIsSameAsBoxHeight() {
> 804:         class testPixelSnapConfig {

should be `TestPixelSnapConfig`. 
And I think for the sake of testing, this can be a standalone class or inner class as well

modules/javafx.graphics/src/test/java/test/javafx/scene/layout/VBoxTest.java line 819:

> 817:             // For these tests, VBox.prefHeight is specified, so we expect the final height to be exactly that.
> 818:             // Child heights will be adjusted appropriately such that the sum of child widths corresponds to VBox.prefHeight.
> 819:             new testPixelSnapConfig(76.0, 1.0, true),

I would prefer the initialization of the array before looping so the code looks more clean

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

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

From jvos at openjdk.org  Mon Sep 12 09:18:36 2022
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 12 Sep 2022 09:18:36 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19
Message-ID: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>

Create the release notes for JavaFX 19

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

Commit messages:
 - Create the release notes for JavaFX 19

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

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

From kcr at openjdk.org  Mon Sep 12 11:49:58 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 11:49:58 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <BxWvgf6XK6nsYF--f1nnNpzmrGDNumtRbCz5LhBn01w=.3de1982f-5143-46f0-8646-bb646f046bf1@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
 <BxWvgf6XK6nsYF--f1nnNpzmrGDNumtRbCz5LhBn01w=.3de1982f-5143-46f0-8646-bb646f046bf1@github.com>
Message-ID: <GXfGIOKMXLFVY_SAT1O0mKJ1f9utzkR2G_1mPk3cTME=.e86eb0aa-966d-422b-87c9-7b5db74618c4@github.com>

On Sun, 11 Sep 2022 09:39:20 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> wondering about your comment in the bug report: you stated that you can reproduce it on Win, does this imply you couldn't on Mac?

I hadn't tried running `HorizontalConstrainedTableScrollingMin` on Mac, since Andy said he couldn't reproduce it with that program. I just now ran it, and no, that specific program doesn't show the bug on Mac. However, the unit test in this PR _does_ fail on Mac without the fix, and passes with the fix.

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

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

From kcr at openjdk.org  Mon Sep 12 12:12:04 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 12:12:04 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19
In-Reply-To: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
Message-ID: <Xmfbk9eHU6gxLsNLmYvsHcfewGJLsbcMSiDrb_5izUg=.67a1ff37-9f17-40f7-a141-f6b3f73ecdc7@github.com>

On Mon, 12 Sep 2022 09:10:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Create the release notes for JavaFX 19

While reviewing this, I found two more bugs that should be excluded from the list of fixed bugs (they are cleanup bug that don't affect functionality at all). I just now added the `noreg-cleanup` keyword to those two bugs in JBS, so they no longer show up in the filter.

This looks good to me (aside from the two bugs that can be removed from the list).

doc-files/release-notes-19.md line 50:

> 48: [JDK-8285197](https://bugs.openjdk.java.net/browse/JDK-8285197)|TableColumnHeader: calc of cell width must respect row styling (TreeTableView)|controls
> 49: [JDK-8286261](https://bugs.openjdk.java.net/browse/JDK-8286261)|Selection of non-expanded non-leaf treeItem grows unexpectedly when adding two-level descendants|controls
> 50: [JDK-8289171](https://bugs.openjdk.java.net/browse/JDK-8289171)|Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521|controls

This is a cleanup fix with no observable change in behavior.

doc-files/release-notes-19.md line 55:

> 53: [JDK-8277572](https://bugs.openjdk.java.net/browse/JDK-8277572)|ImageStorage should correctly handle MIME types for images encoded in data URIs|graphics
> 54: [JDK-8279013](https://bugs.openjdk.java.net/browse/JDK-8279013)|ES2Pipeline fails to detect AMD vega20 graphics card|graphics
> 55: [JDK-8279297](https://bugs.openjdk.java.net/browse/JDK-8279297)|Remove Shape::setMode method|graphics

This is a cleanup fix with no observable change in behavior.

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

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

From jhendrikx at openjdk.org  Mon Sep 12 12:21:00 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 12 Sep 2022 12:21:00 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19
In-Reply-To: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
Message-ID: <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>

On Mon, 12 Sep 2022 09:10:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Create the release notes for JavaFX 19

doc-files/release-notes-19.md line 23:

> 21: Issue key|Summary|Subcomponent
> 22: ---------|-------|------------
> 23: [JDK-8290331](https://bugs.openjdk.java.net/browse/JDK-8290331)|Binding value left null when immediately revalidated in invalidation listener|base

Should this be included? It was basically introduced in 19 and fixed in 19 (introduced by [JDK-8274771](https://bugs.openjdk.java.net/browse/JDK-8274771)|Map, FlatMap and OrElse fluent bindings for ObservableValue|base)

doc-files/release-notes-19.md line 24:

> 22: ---------|-------|------------
> 23: [JDK-8290331](https://bugs.openjdk.java.net/browse/JDK-8290331)|Binding value left null when immediately revalidated in invalidation listener|base
> 24: [JDK-8290393](https://bugs.openjdk.java.net/browse/JDK-8290393)|Code sample in javadoc of ObservableValue flatMap is incorrect|base

Same for this one, introduced in 19 and fixed in 19.

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

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

From jvos at openjdk.org  Mon Sep 12 12:25:23 2022
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 12 Sep 2022 12:25:23 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v2]
In-Reply-To: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
Message-ID: <h540FOrsu-FixfVs51-m-6LUwnTu706Hmw_EbvEl0Y0=.09d79371-4b72-4137-a122-bec06ff18ebf@github.com>

> Create the release notes for JavaFX 19

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Remove 2 noreg-cleanup marked issues from the list

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/896/files
  - new: https://git.openjdk.org/jfx/pull/896/files/6a2016d3..1b5eefa0

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

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

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

From kcr at openjdk.org  Mon Sep 12 12:30:50 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 12:30:50 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v2]
In-Reply-To: <h540FOrsu-FixfVs51-m-6LUwnTu706Hmw_EbvEl0Y0=.09d79371-4b72-4137-a122-bec06ff18ebf@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <h540FOrsu-FixfVs51-m-6LUwnTu706Hmw_EbvEl0Y0=.09d79371-4b72-4137-a122-bec06ff18ebf@github.com>
Message-ID: <xy1AG_n9zpayGFXX121Itm0VGvDMfDSYO7RlLDWg-lM=.cf8652b4-9ede-4c6b-9728-5af3a6befcf8@github.com>

On Mon, 12 Sep 2022 12:25:23 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Create the release notes for JavaFX 19
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove 2 noreg-cleanup marked issues from the list

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.org  Mon Sep 12 12:30:53 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 12:30:53 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v2]
In-Reply-To: <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
Message-ID: <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>

On Mon, 12 Sep 2022 12:16:00 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove 2 noreg-cleanup marked issues from the list
>
> doc-files/release-notes-19.md line 23:
> 
>> 21: Issue key|Summary|Subcomponent
>> 22: ---------|-------|------------
>> 23: [JDK-8290331](https://bugs.openjdk.java.net/browse/JDK-8290331)|Binding value left null when immediately revalidated in invalidation listener|base
> 
> Should this be included? It was basically introduced in 19 and fixed in 19 (introduced by [JDK-8274771](https://bugs.openjdk.java.net/browse/JDK-8274771)|Map, FlatMap and OrElse fluent bindings for ObservableValue|base)

That's a fair question. We generally have included these sort of bug fixes, although I realize that they are only relevant for those developers who picked up an early access build that had the bug.

> doc-files/release-notes-19.md line 24:
> 
>> 22: ---------|-------|------------
>> 23: [JDK-8290331](https://bugs.openjdk.java.net/browse/JDK-8290331)|Binding value left null when immediately revalidated in invalidation listener|base
>> 24: [JDK-8290393](https://bugs.openjdk.java.net/browse/JDK-8290393)|Code sample in javadoc of ObservableValue flatMap is incorrect|base
> 
> Same for this one, introduced in 19 and fixed in 19.

Hmm. This one especially seems not useful to mention in the release notes. @johanvos can decide whether or not to include it.

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

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

From fastegal at openjdk.org  Mon Sep 12 12:34:59 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Mon, 12 Sep 2022 12:34:59 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <GXfGIOKMXLFVY_SAT1O0mKJ1f9utzkR2G_1mPk3cTME=.e86eb0aa-966d-422b-87c9-7b5db74618c4@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
 <BxWvgf6XK6nsYF--f1nnNpzmrGDNumtRbCz5LhBn01w=.3de1982f-5143-46f0-8646-bb646f046bf1@github.com>
 <GXfGIOKMXLFVY_SAT1O0mKJ1f9utzkR2G_1mPk3cTME=.e86eb0aa-966d-422b-87c9-7b5db74618c4@github.com>
Message-ID: <8Gr0x182U2OXsrt_8o8hbXJVDxJYoFBQFDYXWOR4jJ4=.144d88a5-b8c8-494f-9d01-c276ba4b79a1@github.com>

On Mon, 12 Sep 2022 11:46:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> 
> I hadn't tried running `HorizontalConstrainedTableScrollingMin` on Mac, since Andy said he couldn't reproduce it with that program. I just now ran it, and no, that specific program doesn't show the bug on Mac. However, the unit test in this PR _does_ fail on Mac without the fix, and passes with the fix.

thanks for checking, really wanted to know :) 

Yes, the tests here are failing/passing before/after (no real wonder if the hbar is hidden in constraint mode) - what bothered me was this on/off at certain widths, which I could see in a visual test but not reproduce with the stub toolkit. We have/had seen similar issues related to hidpi on Win. And I think I have a system test that passes with scale 1 and fails with scale > 1 (both before the fix here). Naturally passing after ..

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

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

From jvos at openjdk.org  Mon Sep 12 12:40:57 2022
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 12 Sep 2022 12:40:57 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v2]
In-Reply-To: <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
 <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
Message-ID: <3ABjP-P9QuObMjpFCkwOc035QZ5Wo9wDOrNzMUgc51k=.71a3e047-91cb-45b8-989a-6fef5c43558f@github.com>

On Mon, 12 Sep 2022 12:24:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> doc-files/release-notes-19.md line 23:
>> 
>>> 21: Issue key|Summary|Subcomponent
>>> 22: ---------|-------|------------
>>> 23: [JDK-8290331](https://bugs.openjdk.java.net/browse/JDK-8290331)|Binding value left null when immediately revalidated in invalidation listener|base
>> 
>> Should this be included? It was basically introduced in 19 and fixed in 19 (introduced by [JDK-8274771](https://bugs.openjdk.java.net/browse/JDK-8274771)|Map, FlatMap and OrElse fluent bindings for ObservableValue|base)
>
> That's a fair question. We generally have included these sort of bug fixes, although I realize that they are only relevant for those developers who picked up an early access build that had the bug.

I prefer to keep this. I understand that this fixes a situation that could not occur on 18 or earlier, but still this is something that got changed in the course of 19, so to me it counts as an issue that is fixed and that would be noticeable if it wasn't fixed. 
If people or bots later parse the release notes, it could be confusing if they don't find this issue (it would be ok for issues with noreg-cleanup.)

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

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

From jvos at openjdk.org  Mon Sep 12 13:12:24 2022
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 12 Sep 2022 13:12:24 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
Message-ID: <X9g9HvY8XI2tRVAYAnL3MjK4Otq_M5v5y7YUqVJ8HWM=.de4e8c51-a438-4037-8687-71d85f04114b@github.com>

> Create the release notes for JavaFX 19

Johan Vos has updated the pull request incrementally with one additional commit since the last revision:

  Remove issue that fix an issue in documentation (introduced in 19)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/896/files
  - new: https://git.openjdk.org/jfx/pull/896/files/1b5eefa0..4f8f5d5e

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

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

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

From jvos at openjdk.org  Mon Sep 12 13:12:27 2022
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 12 Sep 2022 13:12:27 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
 <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
Message-ID: <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>

On Mon, 12 Sep 2022 12:27:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> doc-files/release-notes-19.md line 24:
>> 
>>> 22: ---------|-------|------------
>>> 23: [JDK-8290331](https://bugs.openjdk.java.net/browse/JDK-8290331)|Binding value left null when immediately revalidated in invalidation listener|base
>>> 24: [JDK-8290393](https://bugs.openjdk.java.net/browse/JDK-8290393)|Code sample in javadoc of ObservableValue flatMap is incorrect|base
>> 
>> Same for this one, introduced in 19 and fixed in 19.
>
> Hmm. This one especially seems not useful to mention in the release notes. @johanvos can decide whether or not to include it.

This is different to me indeed, as it only touches documentation. I'll remove this one.
In the future, it might be good to have a label for these kinds of issues that (1) fix issues caused in the same release version and (2) do not have a runtime impact; so that the algorithm for creating release notes does not require human judgement. Unless we want to explicitly discuss some of the items -- which I'm not strongly opposed to either.

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

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

From kcr at openjdk.org  Mon Sep 12 13:22:01 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 13:22:01 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <X9g9HvY8XI2tRVAYAnL3MjK4Otq_M5v5y7YUqVJ8HWM=.de4e8c51-a438-4037-8687-71d85f04114b@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <X9g9HvY8XI2tRVAYAnL3MjK4Otq_M5v5y7YUqVJ8HWM=.de4e8c51-a438-4037-8687-71d85f04114b@github.com>
Message-ID: <cf7ruiky6KukOfOKIrkO0JBGsmVM0nUCxQApXN4qFkE=.c24a3fda-42e0-4094-960b-662e0f3382c8@github.com>

On Mon, 12 Sep 2022 13:12:24 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Create the release notes for JavaFX 19
>
> Johan Vos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove issue that fix an issue in documentation (introduced in 19)

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.org  Mon Sep 12 13:27:46 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 13:27:46 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
 <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
 <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>
Message-ID: <Lj8y4NtksvPuI_xalGQSWGtgbzdUiMicFo6pUFe3oRc=.f347c323-0fd4-44ad-a561-90a185e8b227@github.com>

On Mon, 12 Sep 2022 13:07:29 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Hmm. This one especially seems not useful to mention in the release notes. @johanvos can decide whether or not to include it.
>
> This is different to me indeed, as it only touches documentation. I'll remove this one.
> In the future, it might be good to have a label for these kinds of issues that (1) fix issues caused in the same release version and (2) do not have a runtime impact; so that the algorithm for creating release notes does not require human judgement. Unless we want to explicitly discuss some of the items -- which I'm not strongly opposed to either.

I agree with this reasoning. The best way to note this is to use the `Introduced In Version` field. The filter could exclude bugs with a `noreg-doc` label and an `Introduced In Version` that is the same as the `fixVersion`.

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

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

From kcr at openjdk.org  Mon Sep 12 14:03:57 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 14:03:57 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
 <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
 <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>
Message-ID: <FWgT25kLet6eJFhptdes_xIRuV9h4z68Kll7f0zXR2Y=.f8329146-58fa-437e-93e2-c737d0ca71ff@github.com>

On Mon, 12 Sep 2022 13:07:29 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Hmm. This one especially seems not useful to mention in the release notes. @johanvos can decide whether or not to include it.
>
> This is different to me indeed, as it only touches documentation. I'll remove this one.
> In the future, it might be good to have a label for these kinds of issues that (1) fix issues caused in the same release version and (2) do not have a runtime impact; so that the algorithm for creating release notes does not require human judgement. Unless we want to explicitly discuss some of the items -- which I'm not strongly opposed to either.

@johanvos In order to automate this, I propose adding the following logic to the release notes JBS filter:


AND ("Introduced In Version" is EMPTY OR "Introduced In Version" != openjfx19 OR
     labels is EMPTY OR labels not in (noreg-doc))


Does this look OK to you?

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

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

From jvos at openjdk.org  Mon Sep 12 14:46:56 2022
From: jvos at openjdk.org (Johan Vos)
Date: Mon, 12 Sep 2022 14:46:56 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <FWgT25kLet6eJFhptdes_xIRuV9h4z68Kll7f0zXR2Y=.f8329146-58fa-437e-93e2-c737d0ca71ff@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
 <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
 <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>
 <FWgT25kLet6eJFhptdes_xIRuV9h4z68Kll7f0zXR2Y=.f8329146-58fa-437e-93e2-c737d0ca71ff@github.com>
Message-ID: <V-xrAoWqCEykIgD49mkPcVVHsnFgrQMrauobgFFhqSA=.6567c1b7-32de-485a-b790-87d3c8efb9ab@github.com>

On Mon, 12 Sep 2022 14:00:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This is different to me indeed, as it only touches documentation. I'll remove this one.
>> In the future, it might be good to have a label for these kinds of issues that (1) fix issues caused in the same release version and (2) do not have a runtime impact; so that the algorithm for creating release notes does not require human judgement. Unless we want to explicitly discuss some of the items -- which I'm not strongly opposed to either.
>
> @johanvos In order to automate this, I propose adding the following logic to the release notes JBS filter:
> 
> 
> AND ("Introduced In Version" is EMPTY OR "Introduced In Version" != openjfx19 OR
>      labels is EMPTY OR labels not in (noreg-doc))
> 
> 
> Does this look OK to you?

yes, that looks like a good algorithm.

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

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

From kcr at openjdk.org  Mon Sep 12 15:03:56 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 15:03:56 GMT
Subject: RFR: 8293615: Create release notes for JavaFX 19 [v3]
In-Reply-To: <V-xrAoWqCEykIgD49mkPcVVHsnFgrQMrauobgFFhqSA=.6567c1b7-32de-485a-b790-87d3c8efb9ab@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
 <XDvklP4am2-JosSqaW9S1mD4O9I6XuPRoVjDYSkz_nU=.bed0fce1-4dfa-4aa1-9d26-4713fb299d95@github.com>
 <Lu0qk-STrbqRVX5Snem0Kk6YDI6xR9n2REE2pxFZrVY=.499fb04c-484b-4c07-8a64-423b56923c64@github.com>
 <_rq6nVUifYPyQd0P3kOyFf_RticLNV31WZFZp92H-HU=.720e4964-549e-49de-81ff-74eeb0e174e0@github.com>
 <FWgT25kLet6eJFhptdes_xIRuV9h4z68Kll7f0zXR2Y=.f8329146-58fa-437e-93e2-c737d0ca71ff@github.com>
 <V-xrAoWqCEykIgD49mkPcVVHsnFgrQMrauobgFFhqSA=.6567c1b7-32de-485a-b790-87d3c8efb9ab@github.com>
Message-ID: <jYuQ9BSvDtiXzpd2eTyFn9IVWHZmAOti6_BGVMPhn44=.f726de40-a0fa-4fe0-9335-1669e410c29c@github.com>

On Mon, 12 Sep 2022 14:43:26 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> @johanvos In order to automate this, I propose adding the following logic to the release notes JBS filter:
>> 
>> 
>> AND ("Introduced In Version" is EMPTY OR "Introduced In Version" != openjfx19 OR
>>      labels is EMPTY OR labels not in (noreg-doc))
>> 
>> 
>> Does this look OK to you?
>
> yes, that looks like a good algorithm.

I've made the change (and added `Introduced In Version = openjfx19` to 8290393).

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

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

From angorya at openjdk.org  Mon Sep 12 15:26:54 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Sep 2022 15:26:54 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
Message-ID: <S0vhAQDzCO7lFMq03qz-pRaa7e-pN8_EMHgRLFJ1P0M=.645b9bd0-184f-467b-99c7-07d70ef10407@github.com>

On Sat, 10 Sep 2022 14:57:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8089280: added tests
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableSkinUtils.java line 215:
> 
>> 213:     public static boolean isConstrainedResizePolicy(Callback<? extends ResizeFeaturesBase,Boolean> x) {
>> 214:         return (x == (Object)TableView.CONSTRAINED_RESIZE_POLICY) ||
>> 215:                (x == (Object)TreeTableView.CONSTRAINED_RESIZE_POLICY);
> 
> Is the cast to `(Object)` needed?

you are right, it's unnecessary.  thanks!

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

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

From angorya at openjdk.org  Mon Sep 12 15:33:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Sep 2022 15:33:29 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/8089280.suppress' into 8089280.suppress
 - 8089280: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/894/files
  - new: https://git.openjdk.org/jfx/pull/894/files/dc1dc25c..bf4aac22

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

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

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

From angorya at openjdk.org  Mon Sep 12 15:33:32 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Sep 2022 15:33:32 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
Message-ID: <THCqwKy0LNP35J4X-vqfAkxJ_RqddaWvsVR9YF9qBtI=.1b2b566a-61f9-49bf-8a92-55886e321b1c@github.com>

On Sat, 10 Sep 2022 15:13:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8089280: added tests
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 307:
> 
>> 305:     private boolean needLengthBar;
>> 306:     private boolean tempVisibility = false;
>> 307:     private boolean suppressBreadthBar;
> 
> Suggestion (optional) : You might want to explicitly initialize this to `false`, since we rely on this for other controls (e.g., `ListView`) which don't call `setSuppressBreadthBar`. (yes, I know Java will initialize it to false anyway, but setting it explicitly could be helpful to a reader of the code)

I would argue otherwise: not only it adds visual noise, but any time one steps into the constructor in a debugger, it goes through every field assignment.

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

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

From kcr at openjdk.org  Mon Sep 12 15:49:59 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 15:49:59 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
Message-ID: <l14MWGwktYTqk5wp0LOcHjrFX7K4kGULoJ7OTeFdA8c=.85efd071-ada2-43d7-a6f3-0131d2637e43@github.com>

On Mon, 12 Sep 2022 15:33:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8089280.suppress' into 8089280.suppress
>  - 8089280: review comments

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.org  Mon Sep 12 15:50:00 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 15:50:00 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <THCqwKy0LNP35J4X-vqfAkxJ_RqddaWvsVR9YF9qBtI=.1b2b566a-61f9-49bf-8a92-55886e321b1c@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
 <THCqwKy0LNP35J4X-vqfAkxJ_RqddaWvsVR9YF9qBtI=.1b2b566a-61f9-49bf-8a92-55886e321b1c@github.com>
Message-ID: <J_rG5dFY0dBiGD-E7CktXi7sQZM7iMfG-UD-Wl23RrA=.9aecd851-c81a-49d3-8957-ab62c1c7cda8@github.com>

On Mon, 12 Sep 2022 15:26:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 307:
>> 
>>> 305:     private boolean needLengthBar;
>>> 306:     private boolean tempVisibility = false;
>>> 307:     private boolean suppressBreadthBar;
>> 
>> Suggestion (optional) : You might want to explicitly initialize this to `false`, since we rely on this for other controls (e.g., `ListView`) which don't call `setSuppressBreadthBar`. (yes, I know Java will initialize it to false anyway, but setting it explicitly could be helpful to a reader of the code)
>
> I would argue otherwise: not only it adds visual noise, but any time one steps into the constructor in a debugger, it goes through every field assignment.

I don't see it as visual noise (and don't really care about the minor impact on the debugger), but not a big deal either way. I'll re-approve it now.

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

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

From angorya at openjdk.org  Mon Sep 12 15:58:52 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 12 Sep 2022 15:58:52 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v3]
In-Reply-To: <LpCtvf1YJSHmIoMwI1TEBU_GNXhpbNyirxwab2rmP_Q=.b9e63fdd-1bfe-46d5-a7bf-e3ec5adb3b8c@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <LpCtvf1YJSHmIoMwI1TEBU_GNXhpbNyirxwab2rmP_Q=.b9e63fdd-1bfe-46d5-a7bf-e3ec5adb3b8c@github.com>
Message-ID: <IIMW2bQXqxg2gTkkOxj65uSVMifUX7JdS1-7IzjyA4Y=.ff25c48d-4d26-453f-803c-45ca5285252d@github.com>

On Sun, 11 Sep 2022 19:30:18 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
>> 
>> The following NPEs are fixed (all are also covered by exactly one test case):
>> NPEs with null selection model:
>> - Mouse click on a `ListCell`
>> - SPACE key press
>> - KP_UP (arrow up) key press
>> - HOME key press
>> - END key press
>> - BACK_SLASH + CTRL key press
>> 
>> NPEs with null focus model:
>> - SPACE key press
>> - Select an items: getSelectionModel().select(1)
>> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`
>
> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8279640-list-view-null-selection-focus-model
>  - Fix NPE for null selection/focus -model in queryAccessibleAttribute(..)
>  - Still set anchor when the selection model is null
>  - Using global StageLoader
>  - 8279640: ListView with null SelectionModel/FocusModel throws NPE

lgtm

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

Marked as reviewed by angorya (Author).

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

From duke at openjdk.org  Mon Sep 12 16:10:03 2022
From: duke at openjdk.org (danielpeintner)
Date: Mon, 12 Sep 2022 16:10:03 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v3]
In-Reply-To: <LpCtvf1YJSHmIoMwI1TEBU_GNXhpbNyirxwab2rmP_Q=.b9e63fdd-1bfe-46d5-a7bf-e3ec5adb3b8c@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <LpCtvf1YJSHmIoMwI1TEBU_GNXhpbNyirxwab2rmP_Q=.b9e63fdd-1bfe-46d5-a7bf-e3ec5adb3b8c@github.com>
Message-ID: <HH7YX1r6PKycZuHGYMR_b1Q1xFh7EFISbxlrKhwdjVw=.af276c51-a17c-4e55-afdb-8731d9708b5f@github.com>

On Sun, 11 Sep 2022 19:30:18 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
>> 
>> The following NPEs are fixed (all are also covered by exactly one test case):
>> NPEs with null selection model:
>> - Mouse click on a `ListCell`
>> - SPACE key press
>> - KP_UP (arrow up) key press
>> - HOME key press
>> - END key press
>> - BACK_SLASH + CTRL key press
>> 
>> NPEs with null focus model:
>> - SPACE key press
>> - Select an items: getSelectionModel().select(1)
>> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`
>
> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8279640-list-view-null-selection-focus-model
>  - Fix NPE for null selection/focus -model in queryAccessibleAttribute(..)
>  - Still set anchor when the selection model is null
>  - Using global StageLoader
>  - 8279640: ListView with null SelectionModel/FocusModel throws NPE

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 581:

> 579: 
> 580:         MultipleSelectionModel<T> selectionModel = getNode().getSelectionModel();
> 581:         if (selectionModel == null) return;

VERY MINOR style issue: this seems to be the only place where you use a _one-liner_ return

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

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

From mhanl at openjdk.org  Mon Sep 12 16:16:58 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 12 Sep 2022 16:16:58 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v4]
In-Reply-To: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
Message-ID: <QrbI4KHDsG4zMabvD7qrloWCth-7ykYOFaoazTIe9v8=.85be69c3-66fd-4957-a6b6-69f086f24e3f@github.com>

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup unneeded Toolkit.getToolkit().firePulse() and stageLoader.dispose();

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/711/files
  - new: https://git.openjdk.org/jfx/pull/711/files/9146e080..5f61fe0a

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

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

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

From mhanl at openjdk.org  Mon Sep 12 16:27:06 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 12 Sep 2022 16:27:06 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
Message-ID: <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`

Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:

  Do selection/focus logic after the null check
  
  No need to prepare selection/focus stuff just to return later as one of them is null

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/711/files
  - new: https://git.openjdk.org/jfx/pull/711/files/5f61fe0a..2cc2bd16

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

  Stats: 29 lines in 2 files changed: 16 ins; 12 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/711.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/711/head:pull/711

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

From mhanl at openjdk.org  Mon Sep 12 16:28:22 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Mon, 12 Sep 2022 16:28:22 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v3]
In-Reply-To: <HH7YX1r6PKycZuHGYMR_b1Q1xFh7EFISbxlrKhwdjVw=.af276c51-a17c-4e55-afdb-8731d9708b5f@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <LpCtvf1YJSHmIoMwI1TEBU_GNXhpbNyirxwab2rmP_Q=.b9e63fdd-1bfe-46d5-a7bf-e3ec5adb3b8c@github.com>
 <HH7YX1r6PKycZuHGYMR_b1Q1xFh7EFISbxlrKhwdjVw=.af276c51-a17c-4e55-afdb-8731d9708b5f@github.com>
Message-ID: <6gkRizA_R54mYcM6_XVDksmcBXhOHQh3GN_PqCeScw0=.15d3fc0e-32d8-4251-aa6e-abe1ec9942b1@github.com>

On Mon, 12 Sep 2022 16:06:20 GMT, danielpeintner <duke at openjdk.org> wrote:

>> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8279640-list-view-null-selection-focus-model
>>  - Fix NPE for null selection/focus -model in queryAccessibleAttribute(..)
>>  - Still set anchor when the selection model is null
>>  - Using global StageLoader
>>  - 8279640: ListView with null SelectionModel/FocusModel throws NPE
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/ListViewBehavior.java line 581:
> 
>> 579: 
>> 580:         MultipleSelectionModel<T> selectionModel = getNode().getSelectionModel();
>> 581:         if (selectionModel == null) return;
> 
> VERY MINOR style issue: this seems to be the only place where you use a _one-liner_ return

Yes, this is unfortunately different everywhere in JavaFX and I usually just adapt to the already existing code, but in this case I didn't. Just changed it.

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

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

From kcr at openjdk.org  Mon Sep 12 16:32:53 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 12 Sep 2022 16:32:53 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v2]
In-Reply-To: <8Gr0x182U2OXsrt_8o8hbXJVDxJYoFBQFDYXWOR4jJ4=.144d88a5-b8c8-494f-9d01-c276ba4b79a1@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <suF_re4vfAZdop9BD64CwIRCet6TEUW3L5b91GLdJ4k=.37a696ab-9da5-4eff-9b0e-d1002f33f423@github.com>
 <Bq-TvzzVpZOlFqYFUDjqAc21H9mDyYF_8NENxuX2H7M=.1682e0f9-0369-4e7c-b007-669d2a2a0e32@github.com>
 <BxWvgf6XK6nsYF--f1nnNpzmrGDNumtRbCz5LhBn01w=.3de1982f-5143-46f0-8646-bb646f046bf1@github.com>
 <GXfGIOKMXLFVY_SAT1O0mKJ1f9utzkR2G_1mPk3cTME=.e86eb0aa-966d-422b-87c9-7b5db74618c4@github.com>
 <8Gr0x182U2OXsrt_8o8hbXJVDxJYoFBQFDYXWOR4jJ4=.144d88a5-b8c8-494f-9d01-c276ba4b79a1@github.com>
Message-ID: <Cfc5reMvJEdiEVTx2UdL57P3aBaUAFRLUbv-Yh0x9tM=.85b437c4-d8cc-42da-9875-0c864360ecd7@github.com>

On Mon, 12 Sep 2022 12:31:12 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>>> wondering about your comment in the bug report: you stated that you can reproduce it on Win, does this imply you couldn't on Mac?
>> 
>> I hadn't tried running `HorizontalConstrainedTableScrollingMin` on Mac, since Andy said he couldn't reproduce it with that program. I just now ran it, and no, that specific program doesn't show the bug on Mac. However, the unit test in this PR _does_ fail on Mac without the fix, and passes with the fix.
>
>> 
>> I hadn't tried running `HorizontalConstrainedTableScrollingMin` on Mac, since Andy said he couldn't reproduce it with that program. I just now ran it, and no, that specific program doesn't show the bug on Mac. However, the unit test in this PR _does_ fail on Mac without the fix, and passes with the fix.
> 
> thanks for checking, really wanted to know :) 
> 
> Yes, the tests here are failing/passing before/after (no real wonder if the hbar is hidden in constraint mode) - what bothered me was this on/off at certain widths, which I could see in a visual test but not reproduce with the stub toolkit. We have/had seen similar issues related to hidpi on Win. And I think I have a system test that passes with scale 1 and fails with scale > 1 (both before the fix here). Naturally passing after ..

@kleopatra or @aghaisas can one of you be a second reviewer?

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

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

From arapte at openjdk.org  Tue Sep 13 05:06:58 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 13 Sep 2022 05:06:58 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening [v2]
In-Reply-To: <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
 <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>
Message-ID: <pSv-8LFcAgzzx4p39PHxY10mKvpmmk3H8LKJMKYTMrw=.ad0824ea-5cb5-4241-96bb-e613ae795943@github.com>

On Wed, 7 Sep 2022 11:27:02 GMT, Alex <duke at openjdk.org> wrote:

>> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
>> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.
>
> Alex has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into patch-1
>  - Update submit.yml
>    
>    Signed-off-by: sashashura <93376818+sashashura at users.noreply.github.com>

Marked as reviewed by arapte (Reviewer).

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

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

From jvos at openjdk.org  Tue Sep 13 08:37:55 2022
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 13 Sep 2022 08:37:55 GMT
Subject: Integrated: 8293615: Create release notes for JavaFX 19
In-Reply-To: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
References: <SNR9d3qo6hrnyV72qVnQMAiBkZQBQsBJ0zR-tevuo70=.226f1a3b-1b1d-4471-abab-d45a1ec42b37@github.com>
Message-ID: <w_SxQsu90mE0P9NultyOrGzP6DcmyteoJstYjn2Qz14=.b1369def-9f7b-4a0e-81f3-32a00d908e13@github.com>

On Mon, 12 Sep 2022 09:10:25 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Create the release notes for JavaFX 19

This pull request has now been integrated.

Changeset: 205b7211
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/205b7211bde0e468e81a135fe37952b7f2b11d45
Stats:     88 lines in 1 file changed: 88 ins; 0 del; 0 mod

8293615: Create release notes for JavaFX 19

Reviewed-by: kcr

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

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

From johan.vos at gluonhq.com  Tue Sep 13 09:02:16 2022
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 13 Sep 2022 11:02:16 +0200
Subject: Virtual Flow enhancements
Message-ID: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>

Hi,

OpenJFX 17 contains a fix for JDK-8089589  [1] ([ListView] ScrollBar
content moves toward-backward during scrolling.) Before this fix, the
scrollbar in the VirtualFlow backing List/Table/TreeTableView controls was
treating every cell of equal height. That generated an awkward scrolling
experience, especially when there are major differences in sizes in the
backing list.

The original fix introduced some new issues, and most of these are
meanwhile fixed, and tests are added (thanks to e.g. Florian Kirmaier who
created a good amount of tests).

However, people have in the past been relying on undocumented behavior
while creating apps and libraries, and that behavior is not guaranteed
anymore with the fix for JDK-8089589 that went into OpenJFX 17.
Most of these cases are related to
(1) assuming that IndexedCell.updateItem() is only called when an item is
(about to be) shown and
(2) assuming that the value returned by the positionProperty of the
scrollbar thumb is linearly related to the index of the item in the
backinglist being shown.

Both of these assumptions are invalid, but were (more or less) happening
before JavaFX 17.
I have seen a fair amount of creative implementations that somehow get and
process information about the position of elements in the controls. Some of
these relied on the false assumptions above, and are obviously no longer
working.
Instead of providing fixes per case, I think it would be good to capture
the common use cases, and make it easier for developers to achieve what
they want to achieve. I didn't yet encounter a use case that can not be
implemented with the current approach (using public API's only), but
granted, implementations often require too much boilerplate and wiring
code.

Crucial in this exercise are tests. There are a fair amount of tests for
the list/table/treetableview controls, but only few of them are focused on
external access and behavior.
For all the fixes done so far in VirtualFlow, additional tests have been
written which are now excellent regression tests. The last thing we want is
that a fix for usecase A is not working anymore after a fix for usecase B.

Hence, I'd like us to do 2 things:
1) for issues that are clearly bugs (*violating the JavaDoc*), please
create JBS issues as usual (with failing test code).
2) for issues that are not violating the specs now, but are "common sense",
please create a description and test scenario with expected versus actual
outcome.

I am not 100% sure what the best approach is to tackle issues that fall in
the second category, but I suggest this: if you have a rather vague,
abstract issue (e.g. "listview should always scroll to the bottom of the
list IF it was at the bottom before and a new element is added") , it
probably makes sense to first discuss it here. If on the other hand you
have a very clear issue with a clear failing test, it can be a JBS issue as
well -- but we need to keep in mind then that it might be in the category
of "this fixes usescase A but blocks usecase B"

Thanks,

- Johan

[1] https://bugs.openjdk.org/browse/JDK-8089589
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220913/f0cb10fc/attachment.htm>

From aghaisas at openjdk.org  Tue Sep 13 12:13:01 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 13 Sep 2022 12:13:01 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
Message-ID: <6JswPJNR8NgpWRJoD548nSR6LMrpkAGYSl6_XwQyOaM=.e38390ac-c6b6-40df-85cc-cdd81e9bf2f0@github.com>

On Mon, 12 Sep 2022 16:27:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
>> 
>> The following NPEs are fixed (all are also covered by exactly one test case):
>> NPEs with null selection model:
>> - Mouse click on a `ListCell`
>> - SPACE key press
>> - KP_UP (arrow up) key press
>> - HOME key press
>> - END key press
>> - BACK_SLASH + CTRL key press
>> 
>> NPEs with null focus model:
>> - SPACE key press
>> - Select an items: getSelectionModel().select(1)
>> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do selection/focus logic after the null check
>   
>   No need to prepare selection/focus stuff just to return later as one of them is null

The fix looks good to me!

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

Marked as reviewed by aghaisas (Reviewer).

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

From tsayao at openjdk.org  Tue Sep 13 12:19:05 2022
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 13 Sep 2022 12:19:05 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
Message-ID: <yVWQvxMI8YXcjF4lffZUe-7CYIc6N-D83vsQJ5CusJc=.10774ca2-4863-4209-a260-d71733ca761a@github.com>

On Mon, 12 Sep 2022 16:27:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
>> 
>> The following NPEs are fixed (all are also covered by exactly one test case):
>> NPEs with null selection model:
>> - Mouse click on a `ListCell`
>> - SPACE key press
>> - KP_UP (arrow up) key press
>> - HOME key press
>> - END key press
>> - BACK_SLASH + CTRL key press
>> 
>> NPEs with null focus model:
>> - SPACE key press
>> - Select an items: getSelectionModel().select(1)
>> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do selection/focus logic after the null check
>   
>   No need to prepare selection/focus stuff just to return later as one of them is null

Just updated to JavaFX 19 (without this fix) and noticed this NPE:

Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.scene.control.TableView$TableViewSelectionModel.getSelectedCells()" because the return value of "javafx.scene.control.TableView.getSelectionModel()" is null

This is when setting SelectionModel to null (because I don't want the TableView to be selectable) and clicking on the headerbar to sort.

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

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

From mhanl at openjdk.org  Tue Sep 13 13:03:51 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Tue, 13 Sep 2022 13:03:51 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <yVWQvxMI8YXcjF4lffZUe-7CYIc6N-D83vsQJ5CusJc=.10774ca2-4863-4209-a260-d71733ca761a@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
 <yVWQvxMI8YXcjF4lffZUe-7CYIc6N-D83vsQJ5CusJc=.10774ca2-4863-4209-a260-d71733ca761a@github.com>
Message-ID: <LtPsffSczXUxRONeVQNJIVgiilHwrnpEdyay2ih5spU=.92e4a027-d235-4c25-b583-6f4417376864@github.com>

On Tue, 13 Sep 2022 12:16:28 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Just updated to JavaFX 19 (without this fix) and noticed this NPE:
> 
> Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.scene.control.TableView$TableViewSelectionModel.getSelectedCells()" because the return value of "javafx.scene.control.TableView.getSelectionModel()" is null
> 
> This is when setting SelectionModel to null (because I don't want the TableView to be selectable) and clicking on the headerbar to sort.

This PR is only touching the `ListView`, not the `TableView`.
The behaviour you mentioned is fixed in another PR: https://github.com/openjdk/jfx/pull/876

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

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

From aghaisas at openjdk.org  Tue Sep 13 13:22:04 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 13 Sep 2022 13:22:04 GMT
Subject: RFR: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during
 autosize [v6]
In-Reply-To: <LHXgiGmsHCgLSYGZY6yjgI03HZUpjLsxEy-3Ee4tYGo=.012f7bd4-0fe2-4665-91ba-f914bef32c77@github.com>
References: <WCHEhEDavyurM7pzPSehJ1n4NVw5n2K8_RONKTVKZ1A=.7e1e8160-0bcb-467c-a7ba-72f0ddf471e8@github.com>
 <LHXgiGmsHCgLSYGZY6yjgI03HZUpjLsxEy-3Ee4tYGo=.012f7bd4-0fe2-4665-91ba-f914bef32c77@github.com>
Message-ID: <yCNNMdCPqSJAylmZwP4E5F0WwAlOgIhRJq6tBzBVzpY=.358e220e-93a8-4d87-867a-66ef56f73f84@github.com>

On Wed, 10 Aug 2022 08:14:13 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Initialize the `(Tree)TableView` when creating the measure row.
>> This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise).
>> 
>> With this change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). I guard against this now.
>> I remembered, that there is a ticket for the above behaviour here: https://bugs.openjdk.org/browse/JDK-8274065
>> 
>> Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events.
>
> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Added other ticket as reference in javadoc
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin
>    
>    
 Conflicts:
>    
	modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TableRowSkinTest.java
>    
	modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TreeTableRowSkinTest.java
>  - Enable tests again
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin
>  - Merge branch 'master' of https://github.com/openjdk/jfx into 8289357-table-view-null-in-table-row-skin
>  - 8289357: Added test to verify, that no (Tree)TableRows remain after auto sizing
>  - 8289357: Fix test which failed as the coutner increased by one due to the now correct row setup
>  - 8289357: Remove (Tree)TableRow after autosizing and update the index to -1 to prevent triggering of listener
>  - 8289357: Initialize the (Tree)TableView when creating the measure row. Also prevent a NPE as we don't have a VirtualFlow in the context of autosizing

Looks good to me!

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

Marked as reviewed by aghaisas (Reviewer).

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

From tsayao at openjdk.org  Tue Sep 13 13:28:02 2022
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 13 Sep 2022 13:28:02 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
Message-ID: <__XTd9jcRE6RKD472OjIv0TUj9HJRTsRET_-FGyGsFA=.5cff1f63-8cf0-4b28-9c95-3b356f62459e@github.com>

On Mon, 12 Sep 2022 16:27:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
>> 
>> The following NPEs are fixed (all are also covered by exactly one test case):
>> NPEs with null selection model:
>> - Mouse click on a `ListCell`
>> - SPACE key press
>> - KP_UP (arrow up) key press
>> - HOME key press
>> - END key press
>> - BACK_SLASH + CTRL key press
>> 
>> NPEs with null focus model:
>> - SPACE key press
>> - Select an items: getSelectionModel().select(1)
>> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do selection/focus logic after the null check
>   
>   No need to prepare selection/focus stuff just to return later as one of them is null

> > Just updated to JavaFX 19 (without this fix) and noticed this NPE:
> > Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "javafx.scene.control.TableView$TableViewSelectionModel.getSelectedCells()" because the return value of "javafx.scene.control.TableView.getSelectionModel()" is null
> > This is when setting SelectionModel to null (because I don't want the TableView to be selectable) and clicking on the headerbar to sort.
> 
> This PR is only touching the `ListView`, not the `TableView`. The behaviour you mentioned is fixed in another PR: #876

My mistake.

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

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

From florian.kirmaier at gmail.com  Tue Sep 13 15:10:47 2022
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Tue, 13 Sep 2022 17:10:47 +0200
Subject: Provide Quit handler for system menu bar
Message-ID: <CA+4mSqYU9msq=x2xftj8XFuq4BaxYnku+Y7B-LKncNeAsL0FLw@mail.gmail.com>

Hi Everyone,

In one project, we have to handle the quit-logic for MacOS ourselves,
when the <quit app> menu entry is used.
As background information - this menu entry is set in the
class com.sun.glass.ui.mac.MacApplication.
It's basically hard coded. Currently, in this project, the menu entry
doesn't work in some cases.

My Solution would be:

Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
This handler is called when quit <appname> from the menu is called.
If the handler returns true, all windows are closed. Otherwise, nothing
happens.

It would look like the following:
```
/**
 * Sets the handler to be called when the application is about to quit.
 * Currently, this can only happen on MacOS.
 *
 * This handler is called, when the user selects
 * the "Quit <appname>" from the application menu.
 * When the provided handler returns true,
 * the application will close all windows.
 * If the handler returns false, the application will not quit.
 *
 * @param The new quit handler.
 */
public static void setQuitHandler(Supplier x) {
    ...
}
```
I've created a ticket for this topic.
https://bugs.openjdk.org/browse/JDK-8293700

I've got a working version for this change.
According to Kevin Rushforth this need a prior dicussion on the mailing
list.
Any opinion regarding this?

I could provide a pullrequest, if someone is interested.

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

From swpalmer at gmail.com  Tue Sep 13 17:57:59 2022
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 13 Sep 2022 13:57:59 -0400
Subject: Link to Release Notes is broken
Message-ID: <C8FF4C5F-42C7-4277-851E-1E07AF575C69@gmail.com>

The link to the Release Notes at https://openjfx.io/ goes to https://github.com/openjdk/jfx/blob/jfx19/doc-files/release-notes-19.md which is giving me a 404 error.

It seems the release note files at https://github.com/openjdk/jfx/tree/jfx19/doc-files only go up to v18.  
The same folder on the master branch does have the notes for v19 https://github.com/openjdk/jfx/tree/master/doc-files

Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220913/4519a00d/attachment.htm>

From john.hendrikx at gmail.com  Tue Sep 13 18:16:28 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 13 Sep 2022 20:16:28 +0200
Subject: Virtual Flow enhancements
In-Reply-To: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
References: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
Message-ID: <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>

I think it would be very good to add high level tests for those general 
use cases -- I've always found the VirtualFlow code quite complicated, 
but most of that comes from the need to allow different heights.

Not sure if this is relevant, but perhaps it is one of those "common 
sense" cases: one thing I missed since the inception of these controls 
is a way to position them in a such a way that they (pixel perfectly) 
show a certain state, tracking a cell or position, to allow me to show 
the control exactly the same as it was last time, or that the control 
tracks the position of a cell that may still be in flux (due to 
background loading of data).

For example, I scrolled my list so that the first Item is half visible 
(at the top), and the fifth item is a quarter visible (at the bottom) 
and I double click the 3rd item to go to a new screen (destroying the 
original list view in the process), I find there is no way to recreate 
the list view in the exact same state as it was before.


[ The part below turned out to be a bit of ramble... I could perhaps 
turn it into a ticket if others agree -- I think it also shows that 
there may not be one correct way to handle the scroll / positioning 
behavior of a list view, and that more user control could be warranted ]:


Preferably, I'd be able to tell the view, show item X (the one I double 
clicked) at the same vertical position as it was before. If the list 
meanwhile changed and there are other items before/after it, then those 
are allowed to be different, but the item I clicked should be in the 
exact same position. The only exception is if there are insufficient 
items before item X now, then it is acceptable to show X in a higher 
position.? The scrollTo function doesn't quite capture that (and has 
been generally unreliable IIRC requiring `Platform.runLater` wrapping 
for example).

Perhaps support something like an anchor position, which is updated 
**only** when there is user interaction (selecting, scrolling, using 
scroll keys). The only other way to change it would be programmatically. 
The anchor would indicate the preferred cell or part of the view to keep 
in an exact stable position and is never changed by the view itself 
unless there was some interaction (ie. size changes of cells and the 
view do not change the anchor, and neither do changes in the underlying 
list of items).? Not even a removal of the anchored index or item should 
update the anchor -- instead the view should fall back to a secondary 
anchor of its own choosing.? If the index or item later is available 
again, it will start using the primary anchor again.

The anchor should support I think three use cases:

- Anchoring an index
- Anchoring an item T
- Anchoring a scroll percentage

Anchoring an index would allow you to simply keep whatever item is at a 
certain index at a stable position.? This could be the first item or the 
current last item, regardless of size changes or new items being 
added/removed.? Using an index of Integer.MAX_VALUE could be supported 
here as an alternative to anchoring the bottom scroll position to the 
bottom of the view.

Similarly, anchoring a specific item T would keep that item in a stable 
position, even if the list is sorted, items around it are added or 
removed or the item itself changes size.

Anchoring a scroll percentage allows you to keep the view at a fixed 
position. Anchoring it at the bottom for example would be suitable for 
lists where the latest added items should be kept in view at all times.

The anchor is changed by the view code when the user selects an item to 
that specific item in that specific position (Item X should appear at 
25% of the control height).? The anchor is also changed when the user 
uses the scroll bar, fixing it at percentage 0 or 100 if the bar was 
moved all the way to the top or bottom, and on the top item otherwise 
(this behavior may need to be selectable).? Similar changes of the 
anchor are allowed for navigation keys, up, down, pg up, pg down, home, end.

To show the 42nd item in the exact center of the view do (and keep it 
there regardless of items appearing/disappearing/growing/shrinking):

 ???? setAnchoredIndex(42, 0.5, 0.5);? // item 42's center is shown at 
the view center

To show the 42nd item's top exactly at 25% of the view:

 ???? setAnchoredIndex(42.0, 0.0, 0.25);? // item 42's top is shown at 
25% of the views height

Item anchors:

 ???? setAnchoredItem(itemX, 0.5, 0.5); ?? // itemX's center is shown at 
the exact center

Scroll anchors:

 ??? setAnchoredPosition(1.0, 1.0);? // keep bottom of list at all times 
at bottom of view

Note that you could also ensure there is 50% empty space with an anchor 
at the top or bottom, like this:

 ??? setAnchoredPosition(1.0, 0.5);? // keep bottom of list at all times 
at 50% of the view

For a list with images for example, which are often lazily loaded and 
have various sizes, the anchor would allow a user to easily say which 
item should be visible and where it is should appear relatively in the 
view, even if the item is not yet fully loaded; ie. setting the anchor 
with `setAnchoredItem(myLazyImageItem, 0.5, 0.5)` might initially 
display a small place holder cell in the exact center of the view, but 
once the image is loaded it might be much bigger and the view would jump 
to allow this; with the anchor, the image would remain in the exact 
center.? Only if the image is higher than the view itself it would be 
scrolled a bit to show its top.

--John


On 13/09/2022 11:02, Johan Vos wrote:
> Hi,
>
> OpenJFX 17 contains a fix for JDK-8089589? [1] ([ListView] ScrollBar 
> content moves toward-backward during scrolling.) Before this fix, the 
> scrollbar in the VirtualFlow backing List/Table/TreeTableView controls 
> was treating every cell of equal height. That generated an awkward 
> scrolling experience, especially when there are major differences in 
> sizes in the backing list.
>
> The original fix introduced some new issues, and most of these are 
> meanwhile fixed, and tests are added (thanks to e.g. Florian Kirmaier 
> who created a good amount of tests).
>
> However, people have in the past been relying on undocumented behavior 
> while creating apps and libraries, and that behavior is not guaranteed 
> anymore with the fix for JDK-8089589 that went into OpenJFX 17.
> Most of these cases are related to
> (1) assuming that IndexedCell.updateItem() is only called when an item 
> is (about to be) shown and
> (2) assuming that the value returned by the positionProperty of the 
> scrollbar thumb is linearly related to the index of the item in the 
> backinglist being shown.
>
> Both of these assumptions are invalid, but were (more or less) 
> happening before JavaFX 17.
> I have seen a fair amount of creative implementations that somehow get 
> and process information about the position of elements in the 
> controls. Some of these relied on the false assumptions above, and are 
> obviously no longer working.
> Instead of providing fixes per case, I think it would be good to 
> capture the common use cases, and make it easier for developers to 
> achieve what they want to achieve. I didn't yet encounter a use case 
> that can not be implemented with the current approach (using public 
> API's only), but granted, implementations often require too much 
> boilerplate and wiring code.
>
> Crucial in this exercise are tests. There are a fair amount of tests 
> for the list/table/treetableview controls, but only few of them are 
> focused on external access and behavior.
> For all the fixes done so far in VirtualFlow, additional tests have 
> been written which are now excellent regression tests. The last thing 
> we want is that a fix for usecase?A is not working anymore after a fix 
> for usecase?B.
>
> Hence, I'd like us to do 2 things:
> 1) for issues that are clearly bugs (*violating the JavaDoc*), please 
> create JBS issues as usual (with failing test code).
> 2) for issues that are not violating the specs now, but are "common 
> sense", please create a description and test scenario with expected 
> versus actual outcome.
>
> I am not 100% sure what the best approach is to tackle issues that 
> fall in the second category, but I suggest this: if you have a rather 
> vague, abstract issue (e.g. "listview should always scroll to the 
> bottom of the list IF it was at the bottom before and a new element is 
> added") , it probably makes sense to first discuss it here. If on the 
> other hand you have a very clear issue with a clear failing test, it 
> can be a JBS issue as well -- but we need to keep in mind then that it 
> might be in the category of "this fixes usescase?A but blocks usecase B"
>
> Thanks,
>
> - Johan
>
> [1] https://bugs.openjdk.org/browse/JDK-8089589

From kevin.rushforth at oracle.com  Tue Sep 13 18:32:43 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 13 Sep 2022 11:32:43 -0700
Subject: Link to Release Notes is broken
In-Reply-To: <C8FF4C5F-42C7-4277-851E-1E07AF575C69@gmail.com>
References: <C8FF4C5F-42C7-4277-851E-1E07AF575C69@gmail.com>
Message-ID: <4cee62dc-de76-72fb-d588-3ced81014681@oracle.com>

Ah. I know why. The PR was targeted to master, which I missed when 
reviewing the PR, and noticed it only earlier this morning.

We can get this fixed.

-- Kevin


On 9/13/2022 10:57 AM, Scott Palmer wrote:
> The link to the Release Notes at https://openjfx.io/?goes to 
> https://github.com/openjdk/jfx/blob/jfx19/doc-files/release-notes-19.md?which 
> is giving me a 404 error.
>
> It seems the release note files at 
> https://github.com/openjdk/jfx/tree/jfx19/doc-files?only go up to v18.
> The same folder on the master branch does have the notes for v19 
> https://github.com/openjdk/jfx/tree/master/doc-files
>
> Scott
>


From kcr at openjdk.org  Tue Sep 13 19:27:32 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Sep 2022 19:27:32 GMT
Subject: [jfx19] RFR: 8293615: Create release notes for JavaFX 19
Message-ID: <DPWqMhVrViaUS-GVYdI4u2QYnlsvtTefXPD0uVsIPGA=.528bf44a-d3a7-42e1-83a4-9074d286fe0f@github.com>

Clean backport of JavaFX 19 release notes to `jfx19` branch.

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

Commit messages:
 - 8293615: Create release notes for JavaFX 19

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

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

From angorya at openjdk.org  Tue Sep 13 19:36:49 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Sep 2022 19:36:49 GMT
Subject: [jfx19] RFR: 8293615: Create release notes for JavaFX 19
In-Reply-To: <DPWqMhVrViaUS-GVYdI4u2QYnlsvtTefXPD0uVsIPGA=.528bf44a-d3a7-42e1-83a4-9074d286fe0f@github.com>
References: <DPWqMhVrViaUS-GVYdI4u2QYnlsvtTefXPD0uVsIPGA=.528bf44a-d3a7-42e1-83a4-9074d286fe0f@github.com>
Message-ID: <5Q7PEqZULa98qhADpM_xNJCN7Tigs5b6-2Fb14erKY0=.6cae7148-4072-45e0-b1f5-74ca8fc3b06e@github.com>

On Tue, 13 Sep 2022 19:20:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of JavaFX 19 release notes to `jfx19` branch.

Marked as reviewed by angorya (Author).

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

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

From kcr at openjdk.org  Tue Sep 13 20:04:53 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 13 Sep 2022 20:04:53 GMT
Subject: [jfx19] Integrated: 8293615: Create release notes for JavaFX 19
In-Reply-To: <DPWqMhVrViaUS-GVYdI4u2QYnlsvtTefXPD0uVsIPGA=.528bf44a-d3a7-42e1-83a4-9074d286fe0f@github.com>
References: <DPWqMhVrViaUS-GVYdI4u2QYnlsvtTefXPD0uVsIPGA=.528bf44a-d3a7-42e1-83a4-9074d286fe0f@github.com>
Message-ID: <GjQFDihyaDf-ZlWEolAzFN3SBvbAiw-HzGwMoKEfTrA=.cc5da1c9-bc17-4637-a7a5-be6db83c6cc2@github.com>

On Tue, 13 Sep 2022 19:20:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of JavaFX 19 release notes to `jfx19` branch.

This pull request has now been integrated.

Changeset: 0db91abc
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0db91abc0d97d45b05cc543bff024c9b36d53d11
Stats:     88 lines in 1 file changed: 88 ins; 0 del; 0 mod

8293615: Create release notes for JavaFX 19

Reviewed-by: angorya
Backport-of: 205b7211bde0e468e81a135fe37952b7f2b11d45

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

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

From angorya at openjdk.org  Tue Sep 13 21:12:55 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 13 Sep 2022 21:12:55 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v10]
In-Reply-To: <sh7sy1g-8EcbOtFUoMrH1zFMNWtAZMVCTGABj95OZEA=.5311f24f-5ef3-4ec7-931d-b359f2220b3c@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
 <sh7sy1g-8EcbOtFUoMrH1zFMNWtAZMVCTGABj95OZEA=.5311f24f-5ef3-4ec7-931d-b359f2220b3c@github.com>
Message-ID: <dDMtKBkQf6yiQsHssHIXzPNoX6T0d5X3j3spPEjo_nw=.1d537cef-ee9a-489e-bff0-ccd0ff1e4494@github.com>

On Tue, 6 Sep 2022 10:38:44 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292353: whitespace
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlUtils.java line 157:
> 
>> 155:         }
>> 156:         throw new Error("TableRow not found at " + row);
>> 157:     }
> 
> no review, just a couple of comments:
> 
> Generally, should prefer api over lookup - we have shims to access package/protected api. 
> 
> In this particular case, the lookup is brittle: it assumes that
> 
> - either there is a single row configured with the given index 
> - or that it's the first when iterating over the set
> 
> With the first being incorrect (corner case, of course :)
> 
>     @Test
>     public void testLookupLastNotEmptyCell() {
>         stageLoader = new StageLoader(table);
>         int index = table.getItems().size()- 1;
>         Set<Node> tableRows = table.lookupAll(".table-row-cell").stream()
>                 .filter(n -> n instanceof TableRow<?> && ((TableRow<?>) n).getIndex() == index)
>                 .collect(Collectors.toSet());
>         assertEquals(1, tableRows.size());
>     }
> 
> we fall back to the second assumption, which is implementation dependent (and unspecified) - it's accidental that we actually do get the row we want.
> 
> Having done a bit of digging into VirtualFlowTestUtils (see [JDK-8293356](https://bugs.openjdk.org/browse/JDK-8293356)) I now think it's safe enough to use it (even though it's on the oldish side, not using recently added api, probably needs some polish) - as long as  we keep the scenegraph stable during the test, f.i. by manually adding the table to a stage (either via StageLoader or showing in our own).

Is it possible to have two or more rows with the same row index?  i would imagine that will break a lot of things.

I am not sure why you think the lookup is brittle - after all, VirtualFlowTestUtils uses lookup to get a pointer to the VirtualFlow, is it not (line 333)?  Is it because the lookup may not return a cell if it is outside of the current view port area and therefore has not been created (while the .getCell() guarantees to create one)? 

Is this the only objection to the changes in this PR?  I suppose i could change the tests to use VirtualFlowTestUtils, though my preference would be still to test close to the real world scenario, using public APIs (as opposed to getting into internals using some internal test utils), given the fact that I *do* expect these cells to be visible given the dimensions of the table and columns.

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

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

From mhanl at openjdk.org  Wed Sep 14 07:05:51 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Sep 2022 07:05:51 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
Message-ID: <UeVUoOc3BIQDI7GSHB_fZ1UKhivf0m3gSVFurKUmEL0=.d78806a2-bbb4-441a-9f45-33b867880426@github.com>

On Mon, 12 Sep 2022 15:33:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8089280.suppress' into 8089280.suppress
>  - 8089280: review comments

Just a question here: 
By suppressing the horizontal scrollbar, aren't we fighting the symptom here rather than investigating why it is sometimes still shown?

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

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

From mariushanl at web.de  Wed Sep 14 09:26:51 2022
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 14 Sep 2022 11:26:51 +0200
Subject: Aw: CSS Transitions
In-Reply-To: <CAJEpuXQn962rnCx36B426HVn4M-0X=rgaJHXBrTN1DsUubkL8w@mail.gmail.com>
References: <CAJEpuXQn962rnCx36B426HVn4M-0X=rgaJHXBrTN1DsUubkL8w@mail.gmail.com>
Message-ID: <trinity-56d5ffd6-748c-4caa-8bbd-f5eea9e975b4-1663147611229@3c-app-webde-bs45>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220914/aa9b6dd4/attachment.htm>

From mariushanl at web.de  Wed Sep 14 09:46:37 2022
From: mariushanl at web.de (Marius Hanl)
Date: Wed, 14 Sep 2022 11:46:37 +0200
Subject: Add Platform.canStartNestedEventLoop()
Message-ID: <trinity-2259052d-17f9-47a7-af1d-621063b0bec6-1663148797252@3c-app-webde-bs45>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220914/ff15bed3/attachment-0001.htm>

From dlemmermann at gmail.com  Wed Sep 14 10:18:00 2022
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 14 Sep 2022 12:18:00 +0200
Subject: Virtual Flow enhancements
In-Reply-To: <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>
References: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
 <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>
Message-ID: <3845162C-7988-45A2-A474-177286C3B343@gmail.com>

Hi,

for me the most important aspect regarding the future work on VirtualFlow right now is to get back a piece of functionality that I require for the FlexGanttFX framework and and I am sure others also need. It is the ability to synchronize the scrolling of two VirtualFlows with each other. In the case of FlexGanttFX it is the VirtualFlow of the left-hand side of the GanttChart control (a TreeTableView) and the right-hand side of the same control (a ListView). 

FlexGanttFX used to make this work via bidirectional bindings of the properties of the vertical scrollbars of both VirtualFlows. With the latest fixes to the VirtualFlow the assumption that two identically populated VirtualFlows would provide identical values to the ScrollBar properties is no longer true. The attempt to bind the ?position? property also failed and a work-around that Johan provided also has not been successful, yet (a customer of mine is still evaluating it).

For the FlexGanttFX framework it would be super important to have a proper / recommended way to get the behaviour / the ability back to synchronise scrolling (backed up by public API). 

Dirk

P.S.: at the moment I am asking my customers to stay on JavaFX 16, but some of them are starting to ask for newer versions because of fixes made in those.


> On 13 Sep 2022, at 20:16, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> I think it would be very good to add high level tests for those general use cases -- I've always found the VirtualFlow code quite complicated, but most of that comes from the need to allow different heights.
> 
> Not sure if this is relevant, but perhaps it is one of those "common sense" cases: one thing I missed since the inception of these controls is a way to position them in a such a way that they (pixel perfectly) show a certain state, tracking a cell or position, to allow me to show the control exactly the same as it was last time, or that the control tracks the position of a cell that may still be in flux (due to background loading of data).
> 
> For example, I scrolled my list so that the first Item is half visible (at the top), and the fifth item is a quarter visible (at the bottom) and I double click the 3rd item to go to a new screen (destroying the original list view in the process), I find there is no way to recreate the list view in the exact same state as it was before.
> 
> 
> [ The part below turned out to be a bit of ramble... I could perhaps turn it into a ticket if others agree -- I think it also shows that there may not be one correct way to handle the scroll / positioning behavior of a list view, and that more user control could be warranted ]:
> 
> 
> Preferably, I'd be able to tell the view, show item X (the one I double clicked) at the same vertical position as it was before. If the list meanwhile changed and there are other items before/after it, then those are allowed to be different, but the item I clicked should be in the exact same position. The only exception is if there are insufficient items before item X now, then it is acceptable to show X in a higher position.  The scrollTo function doesn't quite capture that (and has been generally unreliable IIRC requiring `Platform.runLater` wrapping for example).
> 
> Perhaps support something like an anchor position, which is updated **only** when there is user interaction (selecting, scrolling, using scroll keys). The only other way to change it would be programmatically. The anchor would indicate the preferred cell or part of the view to keep in an exact stable position and is never changed by the view itself unless there was some interaction (ie. size changes of cells and the view do not change the anchor, and neither do changes in the underlying list of items).  Not even a removal of the anchored index or item should update the anchor -- instead the view should fall back to a secondary anchor of its own choosing.  If the index or item later is available again, it will start using the primary anchor again.
> 
> The anchor should support I think three use cases:
> 
> - Anchoring an index
> - Anchoring an item T
> - Anchoring a scroll percentage
> 
> Anchoring an index would allow you to simply keep whatever item is at a certain index at a stable position.  This could be the first item or the current last item, regardless of size changes or new items being added/removed.  Using an index of Integer.MAX_VALUE could be supported here as an alternative to anchoring the bottom scroll position to the bottom of the view.
> 
> Similarly, anchoring a specific item T would keep that item in a stable position, even if the list is sorted, items around it are added or removed or the item itself changes size.
> 
> Anchoring a scroll percentage allows you to keep the view at a fixed position. Anchoring it at the bottom for example would be suitable for lists where the latest added items should be kept in view at all times.
> 
> The anchor is changed by the view code when the user selects an item to that specific item in that specific position (Item X should appear at 25% of the control height).  The anchor is also changed when the user uses the scroll bar, fixing it at percentage 0 or 100 if the bar was moved all the way to the top or bottom, and on the top item otherwise (this behavior may need to be selectable).  Similar changes of the anchor are allowed for navigation keys, up, down, pg up, pg down, home, end.
> 
> To show the 42nd item in the exact center of the view do (and keep it there regardless of items appearing/disappearing/growing/shrinking):
> 
>      setAnchoredIndex(42, 0.5, 0.5);  // item 42's center is shown at the view center
> 
> To show the 42nd item's top exactly at 25% of the view:
> 
>      setAnchoredIndex(42.0, 0.0, 0.25);  // item 42's top is shown at 25% of the views height
> 
> Item anchors:
> 
>      setAnchoredItem(itemX, 0.5, 0.5);    // itemX's center is shown at the exact center
> 
> Scroll anchors:
> 
>     setAnchoredPosition(1.0, 1.0);  // keep bottom of list at all times at bottom of view
> 
> Note that you could also ensure there is 50% empty space with an anchor at the top or bottom, like this:
> 
>     setAnchoredPosition(1.0, 0.5);  // keep bottom of list at all times at 50% of the view
> 
> For a list with images for example, which are often lazily loaded and have various sizes, the anchor would allow a user to easily say which item should be visible and where it is should appear relatively in the view, even if the item is not yet fully loaded; ie. setting the anchor with `setAnchoredItem(myLazyImageItem, 0.5, 0.5)` might initially display a small place holder cell in the exact center of the view, but once the image is loaded it might be much bigger and the view would jump to allow this; with the anchor, the image would remain in the exact center.  Only if the image is higher than the view itself it would be scrolled a bit to show its top.
> 
> --John
> 
> 
> On 13/09/2022 11:02, Johan Vos wrote:
>> Hi,
>> 
>> OpenJFX 17 contains a fix for JDK-8089589  [1] ([ListView] ScrollBar content moves toward-backward during scrolling.) Before this fix, the scrollbar in the VirtualFlow backing List/Table/TreeTableView controls was treating every cell of equal height. That generated an awkward scrolling experience, especially when there are major differences in sizes in the backing list.
>> 
>> The original fix introduced some new issues, and most of these are meanwhile fixed, and tests are added (thanks to e.g. Florian Kirmaier who created a good amount of tests).
>> 
>> However, people have in the past been relying on undocumented behavior while creating apps and libraries, and that behavior is not guaranteed anymore with the fix for JDK-8089589 that went into OpenJFX 17.
>> Most of these cases are related to
>> (1) assuming that IndexedCell.updateItem() is only called when an item is (about to be) shown and
>> (2) assuming that the value returned by the positionProperty of the scrollbar thumb is linearly related to the index of the item in the backinglist being shown.
>> 
>> Both of these assumptions are invalid, but were (more or less) happening before JavaFX 17.
>> I have seen a fair amount of creative implementations that somehow get and process information about the position of elements in the controls. Some of these relied on the false assumptions above, and are obviously no longer working.
>> Instead of providing fixes per case, I think it would be good to capture the common use cases, and make it easier for developers to achieve what they want to achieve. I didn't yet encounter a use case that can not be implemented with the current approach (using public API's only), but granted, implementations often require too much boilerplate and wiring code.
>> 
>> Crucial in this exercise are tests. There are a fair amount of tests for the list/table/treetableview controls, but only few of them are focused on external access and behavior.
>> For all the fixes done so far in VirtualFlow, additional tests have been written which are now excellent regression tests. The last thing we want is that a fix for usecase A is not working anymore after a fix for usecase B.
>> 
>> Hence, I'd like us to do 2 things:
>> 1) for issues that are clearly bugs (*violating the JavaDoc*), please create JBS issues as usual (with failing test code).
>> 2) for issues that are not violating the specs now, but are "common sense", please create a description and test scenario with expected versus actual outcome.
>> 
>> I am not 100% sure what the best approach is to tackle issues that fall in the second category, but I suggest this: if you have a rather vague, abstract issue (e.g. "listview should always scroll to the bottom of the list IF it was at the bottom before and a new element is added") , it probably makes sense to first discuss it here. If on the other hand you have a very clear issue with a clear failing test, it can be a JBS issue as well -- but we need to keep in mind then that it might be in the category of "this fixes usescase A but blocks usecase B"
>> 
>> Thanks,
>> 
>> - Johan
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8089589


From fastegal at openjdk.org  Wed Sep 14 10:35:54 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Wed, 14 Sep 2022 10:35:54 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v10]
In-Reply-To: <dDMtKBkQf6yiQsHssHIXzPNoX6T0d5X3j3spPEjo_nw=.1d537cef-ee9a-489e-bff0-ccd0ff1e4494@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
 <sh7sy1g-8EcbOtFUoMrH1zFMNWtAZMVCTGABj95OZEA=.5311f24f-5ef3-4ec7-931d-b359f2220b3c@github.com>
 <dDMtKBkQf6yiQsHssHIXzPNoX6T0d5X3j3spPEjo_nw=.1d537cef-ee9a-489e-bff0-ccd0ff1e4494@github.com>
Message-ID: <eEnt_H44uiYl-BE-BOM8WHu3T_Ya_JGfkblJIMnCrkE=.bd666284-5726-46fc-b1fd-7b8e63a55540@github.com>

On Tue, 13 Sep 2022 21:10:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Is it possible to have two or more rows with the same row index? i would imagine that will break a lot of things.

don't imagine, verify ;) What happens when you run the test? What happens when you look at the scenegraph (f.i. with ScenicView)? Don't know why they are there but they are - well outside the viewport.

> 
> Is this the only objection to the changes in this PR?

I honestly cannot understand how you possibly could have reached the conclusion that this is the _only_ objection given my comments .. 

Anyway, I'm off here - don't know how to abort a review, but not going to waste more time and nerves on who doesn't seem to listen (that's my personal feeling, of course ;)

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

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

From fastegal at openjdk.org  Wed Sep 14 12:21:52 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Wed, 14 Sep 2022 12:21:52 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <jI6hMioU_3Xnw_r3PDSugTPt4JfRZyIn8vEPuWY3CNA=.8bfcc9c4-5307-47d0-a31f-7442d6b18516@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <S9bFfAz5zgVxQa51R941PV89Jo2OEXdYU8xnqvEBSQo=.e5e7ad36-134a-4dd2-8992-c7a49e08d5fe@github.com>
 <jI6hMioU_3Xnw_r3PDSugTPt4JfRZyIn8vEPuWY3CNA=.8bfcc9c4-5307-47d0-a31f-7442d6b18516@github.com>
Message-ID: <iMkxS1U2EmETbuEIFMeOhQgcBHu8T26KHX7n4XjI43A=.49657404-c6b8-4ad7-993a-4d9bb5a131b6@github.com>

On Sun, 11 Sep 2022 19:29:05 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> 
> Personally, I think that we should support both - we have a separate focusModel so should use it independently of the selectionModel where possible. A good starter for this issue might be to implement the activate such that it doesn't back out on null selection (just leave out the select statement). The consistent support of navigation might be done in a follow-up issue.

Seeing you on a similar path :) Just to summarize, with null selectionModel

- appropriate keys on the focused row starts the edit with null selection model
- focus navigation is left for a future issue 

two suggestions: 

- we might want a test to capture the start edit, f.i. on SPACE
- file an issue covering the focus navigation to not forget?

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

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

From fastegal at openjdk.org  Wed Sep 14 12:29:05 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Wed, 14 Sep 2022 12:29:05 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <6q8klKykI2gjv-oU-AxL2aKMZBRLUfRN936fxBZSzGM=.eabd70db-9476-40f4-bc67-5a411407838f@github.com>
Message-ID: <gXR45xfVOAZn5vA8ZbsXf-Fk-sV7HUKOgxUoYnBgC68=.dfdc9581-6b18-426b-a76f-33c859b89065@github.com>

On Mon, 12 Sep 2022 16:27:06 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
>> 
>> The following NPEs are fixed (all are also covered by exactly one test case):
>> NPEs with null selection model:
>> - Mouse click on a `ListCell`
>> - SPACE key press
>> - KP_UP (arrow up) key press
>> - HOME key press
>> - END key press
>> - BACK_SLASH + CTRL key press
>> 
>> NPEs with null focus model:
>> - SPACE key press
>> - Select an items: getSelectionModel().select(1)
>> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do selection/focus logic after the null check
>   
>   No need to prepare selection/focus stuff just to return later as one of them is null

left a comment - which is only tangentially related to the issue to fix here. 

So this looks good. Cool tests for the code in the accessibility block, my learn item of the day :))

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

Marked as reviewed by fastegal (Reviewer).

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

From mhanl at openjdk.org  Wed Sep 14 13:11:52 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Sep 2022 13:11:52 GMT
Subject: RFR: 8279640: ListView with null SelectionModel/FocusModel throws
 NPE [v5]
In-Reply-To: <iMkxS1U2EmETbuEIFMeOhQgcBHu8T26KHX7n4XjI43A=.49657404-c6b8-4ad7-993a-4d9bb5a131b6@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
 <S9bFfAz5zgVxQa51R941PV89Jo2OEXdYU8xnqvEBSQo=.e5e7ad36-134a-4dd2-8992-c7a49e08d5fe@github.com>
 <jI6hMioU_3Xnw_r3PDSugTPt4JfRZyIn8vEPuWY3CNA=.8bfcc9c4-5307-47d0-a31f-7442d6b18516@github.com>
 <iMkxS1U2EmETbuEIFMeOhQgcBHu8T26KHX7n4XjI43A=.49657404-c6b8-4ad7-993a-4d9bb5a131b6@github.com>
Message-ID: <k-Ekk2D76Nk5AWb5eaZByxZM7E9mJyp03DNOWycqURM=.62c7dcf8-c0c0-4298-b90e-5de802909863@github.com>

On Wed, 14 Sep 2022 12:18:22 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> Seeing you on a similar path :) Just to summarize, with null selectionModel
> 
> * appropriate keys on the focused row starts the edit with null selection model
> * focus navigation is left for a future issue
> 
> two suggestions:
> 
> * we might want a test to capture the start edit, f.i. on SPACE
> * file an issue covering the focus navigation to not forget?

I agree, we should look into this. 
The question is: Can we activate/edit a focused cell without a `selectionModel` (only `focusModel` set)?
And fix all inconsistencies in e.g. navigation.

I filed https://bugs.openjdk.org/browse/JDK-8293803.
Feel free to modify/comment. :)

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

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

From mhanl at openjdk.org  Wed Sep 14 13:18:00 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Sep 2022 13:18:00 GMT
Subject: Integrated: 8279640: ListView with null SelectionModel/FocusModel
 throws NPE
In-Reply-To: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
References: <Bd20At8O-y7TgqZ7p5YGPlm7goxlw_hZ3PfOB1-O-rs=.98efbf5e-8430-4c37-9297-84f30304a212@github.com>
Message-ID: <coW-HoWOSXkLqVELNKrNpfrtsqe7hTeWqtlUQ7tESao=.522269e7-0ac6-491c-820d-d424880c9db3@github.com>

On Sat, 8 Jan 2022 00:17:36 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bunch of NPEs when a null `SelectionModel` or `FocusModel` is set on a `ListView`.
> 
> The following NPEs are fixed (all are also covered by exactly one test case):
> NPEs with null selection model:
> - Mouse click on a `ListCell`
> - SPACE key press
> - KP_UP (arrow up) key press
> - HOME key press
> - END key press
> - BACK_SLASH + CTRL key press
> 
> NPEs with null focus model:
> - SPACE key press
> - Select an items: getSelectionModel().select(1)
> - Clear-Select an item and add one after: `listView.getSelectionModel().clearAndSelect(1); listView.getItems().add("3");`

This pull request has now been integrated.

Changeset: 27f19050
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/27f1905077cbc475fbce1b0f8d950d014dbb07a4
Stats:     236 lines in 5 files changed: 205 ins; 18 del; 13 mod

8279640: ListView with null SelectionModel/FocusModel throws NPE

Reviewed-by: fastegal, aghaisas

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

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

From angorya at openjdk.org  Wed Sep 14 15:19:59 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Sep 2022 15:19:59 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <UeVUoOc3BIQDI7GSHB_fZ1UKhivf0m3gSVFurKUmEL0=.d78806a2-bbb4-441a-9f45-33b867880426@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
 <UeVUoOc3BIQDI7GSHB_fZ1UKhivf0m3gSVFurKUmEL0=.d78806a2-bbb4-441a-9f45-33b867880426@github.com>
Message-ID: <8ZHMDoSaLh53ZeBw47ebvoCsCnXHLXiwtcf4lJW0S3E=.fb018a96-6a4c-42be-8b38-c01c293c1311@github.com>

On Wed, 14 Sep 2022 07:03:42 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> By suppressing the horizontal scrollbar, aren't we fighting the symptom here rather than investigating why it is sometimes still shown?

We **know** why it is shown - due to the minimum width constraint set on column(s).  The default value is 10, (TableColumnBase:122), the existing logic would show the HSB when the sum of column widths exceeds the allotted space.

This is a follow up fix for JDK-8089009, to be followed by fixing the constrained resize policy in JDK-8293119

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

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

From mhanl at openjdk.org  Wed Sep 14 18:54:14 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Sep 2022 18:54:14 GMT
Subject: RFR: 8279214: Memory leak in Scene after dragging a cell
Message-ID: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>

This PR fixes a memory leak in dnd code in the `MouseHandler` of a `Scene`.
The memory leak occurs after calling `startFullDrag()`. The `fullPDRTmpTargetWrapper` is then populated but never cleared.
Fix is to call `clear()` on the `fullPDRTmpTargetWrapper`, very similar to https://github.com/openjdk/jfx/pull/448 ([JDK-8264330](https://bugs.openjdk.java.net/browse/JDK-8264330)).

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

Commit messages:
 - 8279214: Memory leak in Scene after dragging a cell

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

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

From angorya at openjdk.org  Wed Sep 14 20:33:10 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Sep 2022 20:33:10 GMT
Subject: RFR: 8279214: Memory leak in Scene after dragging a cell
In-Reply-To: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>
References: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>
Message-ID: <dw_pchUdpFXQtUpTsxIGjKObogvuvGW4tT6AR2JjxDI=.5174aba4-2491-4a15-8f4e-658752f088ae@github.com>

On Wed, 14 Sep 2022 18:44:14 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a memory leak in dnd code in the `MouseHandler` of a `Scene`.
> The memory leak occurs after calling `startFullDrag()`. The `fullPDRTmpTargetWrapper` is then populated but never cleared.
> Fix is to call `clear()` on the `fullPDRTmpTargetWrapper`, very similar to https://github.com/openjdk/jfx/pull/448 ([JDK-8264330](https://bugs.openjdk.java.net/browse/JDK-8264330)).

Marked as reviewed by angorya (Author).

modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3671:

> 3669:             pdrEventTarget.clear();
> 3670:             pdrEventTargets.clear();
> 3671:             fullPDRTmpTargetWrapper.clear();

the change looks ok to me.
is this the only place where the clear() is needed?

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

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

From thiago.sayao at gmail.com  Wed Sep 14 20:38:40 2022
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 14 Sep 2022 17:38:40 -0300
Subject: JavaFX 19-ea+11 Crashes
Message-ID: <CAAP_wumukSKB00uCr3TVaDLz-oskHaW4__vrGVpON=8nZVprmA@mail.gmail.com>

Hi,

Anybody experiencing crashes with javafx 19-ea+11?

I have replaced it with javafx 19 final to test.

By the look of the log, it has something to do with the garbage collector
and  MenuButtonSkinBase .

I have suppressed some parts.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f4547fbd31f, pid=133481, tid=133520
#
# JRE version: OpenJDK Runtime Environment (17.0.4+8) (build
17.0.4+8-Ubuntu-120.04)
# Java VM: OpenJDK 64-Bit Server VM (17.0.4+8-Ubuntu-120.04, mixed mode,
tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x59931f]
 ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f

---------------  S U M M A R Y ------------

Command Line: -Xmx350m -Xms135m -Djava.net.preferIPv4Stack=true
-Dsun.awt.disablegrab=true
--add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media
fl.jar

Host: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz, 8 cores, 7G, Ubuntu 20.04.4
LTS
Time: Wed Sep 14 17:18:28 2022 -03 elapsed time: 47.851666 seconds (0d 0h
0m 47s)

---------------  T H R E A D  ---------------

Current thread (0x00007f450c00d690):  GCTaskThread "GC Thread#6" [stack:
0x00007f44b1bc7000,0x00007f44b1cc7000] [id=133520]

Stack: [0x00007f44b1bc7000,0x00007f44b1cc7000],  sp=0x00007f44b1cc5ac0,
 free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x59931f]
 ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
V  [libjvm.so+0x7476ad]  G1CLDScanClosure::do_cld(ClassLoaderData*)+0x3d
V  [libjvm.so+0x59e351]  ClassLoaderDataGraph::roots_cld_do(CLDClosure*,
CLDClosure*)+0x41
V  [libjvm.so+0x76f1bc]
 G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*,
unsigned int)+0xcc
V  [libjvm.so+0x76f835]
 G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x65
V  [libjvm.so+0x705b16]
 G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x26
V  [libjvm.so+0x7062b7]  G1EvacuateRegionsBaseTask::work(unsigned int)+0x87
V  [libjvm.so+0xf8e907]  GangWorker::loop()+0x67
V  [libjvm.so+0xf8e963]
V  [libjvm.so+0xedbe42]  Thread::call_run()+0xe2
V  [libjvm.so+0xc324f9]  thread_native_entry(Thread*)+0xe9


RAX=0x000000000000007a is an unknown value
RBX=0x00007f44a53f26f8 points into unknown readable memory:
0x0000000000000001 | 01 00 00 00 00 00 00 00
RCX=0x0000000000000014 is an unknown value
RDX=0x00000000000031e6 is an unknown value
RSP=0x00007f44b1cc5ac0 points into unknown readable memory:
0x00007f4488003ac8 | c8 3a 00 88 44 7f 00 00
RBP=0x00007f44b1cc5ae0 points into unknown readable memory:
0x00007f44b1cc5b20 | 20 5b cc b1 44 7f 00 00
RSI=0x00000000f6110495 is pointing into object: java.lang.Class
{0x00000000f6110468} - klass: 'java/lang/Class'
 - ---- fields (total size 14 words):
 - private volatile transient 'classRedefinedCount' 'I' @12  0
 - private volatile transient 'cachedConstructor'
'Ljava/lang/reflect/Constructor;' @40  NULL (0)
 - private transient 'name' 'Ljava/lang/String;' @44
 "javafx.scene.control.skin.MenuButtonSkinBase$$Lambda$2420/0x0000000100ff7248"{0x00000000f4078820}
(f4078820)
 - private transient 'module' 'Ljava/lang/Module;' @48  a
'java/lang/Module'{0x00000000ea298020} (ea298020)
 - private final 'classLoader' 'Ljava/lang/ClassLoader;' @52  a
'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000000ea975708}
(ea975708)
 - private transient 'classData' 'Ljava/lang/Object;' @56  NULL (0)
 - private transient 'packageName' 'Ljava/lang/String;' @60
 "javafx.scene.control.skin"{0x00000000ea279b50} (ea279b50)
 - private final 'componentType' 'Ljava/lang/Class;' @64  NULL (0)
 - private volatile transient 'reflectionData'
'Ljava/lang/ref/SoftReference;' @68  NULL (0)
 - private volatile transient 'genericInfo'
'Lsun/reflect/generics/repository/ClassRepository;' @72  NULL (0)
 - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @76
 NULL (0)
 - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @80
 NULL (0)
 - private volatile transient 'annotationData'
'Ljava/lang/Class$AnnotationData;' @84  NULL (0)
 - private volatile transient 'annotationType'
'Lsun/reflect/annotation/AnnotationType;' @88  NULL (0)
 - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @92
 NULL (0)
 - signature:
Ljavafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248;
 - fake entry for mirror:
'javafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248'
 - fake entry for array: NULL
 - fake entry for oop_size: 14
 - fake entry for static_oop_field_count: 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220914/4c4aedfc/attachment.htm>

From mhanl at openjdk.org  Wed Sep 14 20:41:54 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Sep 2022 20:41:54 GMT
Subject: RFR: 8279214: Memory leak in Scene after dragging a cell
In-Reply-To: <dw_pchUdpFXQtUpTsxIGjKObogvuvGW4tT6AR2JjxDI=.5174aba4-2491-4a15-8f4e-658752f088ae@github.com>
References: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>
 <dw_pchUdpFXQtUpTsxIGjKObogvuvGW4tT6AR2JjxDI=.5174aba4-2491-4a15-8f4e-658752f088ae@github.com>
Message-ID: <Y3hN82GlTwp6k-ik_hcV_FfsRaLXtRmdM2cyl6A3_no=.ad51ea82-2769-441e-9e51-b14540c18adc@github.com>

On Wed, 14 Sep 2022 20:29:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR fixes a memory leak in dnd code in the `MouseHandler` of a `Scene`.
>> The memory leak occurs after calling `startFullDrag()`. The `fullPDRTmpTargetWrapper` is then populated but never cleared.
>> Fix is to call `clear()` on the `fullPDRTmpTargetWrapper`, very similar to https://github.com/openjdk/jfx/pull/448 ([JDK-8264330](https://bugs.openjdk.java.net/browse/JDK-8264330)).
>
> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3671:
> 
>> 3669:             pdrEventTarget.clear();
>> 3670:             pdrEventTargets.clear();
>> 3671:             fullPDRTmpTargetWrapper.clear();
> 
> the change looks ok to me.
> is this the only place where the clear() is needed?

Yes, I checked the path of a typical mouse event and this method is always called when a mouse/drag operation is done.

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

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

From angorya at openjdk.org  Wed Sep 14 20:41:54 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Sep 2022 20:41:54 GMT
Subject: RFR: 8279214: Memory leak in Scene after dragging a cell
In-Reply-To: <Y3hN82GlTwp6k-ik_hcV_FfsRaLXtRmdM2cyl6A3_no=.ad51ea82-2769-441e-9e51-b14540c18adc@github.com>
References: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>
 <dw_pchUdpFXQtUpTsxIGjKObogvuvGW4tT6AR2JjxDI=.5174aba4-2491-4a15-8f4e-658752f088ae@github.com>
 <Y3hN82GlTwp6k-ik_hcV_FfsRaLXtRmdM2cyl6A3_no=.ad51ea82-2769-441e-9e51-b14540c18adc@github.com>
Message-ID: <x0Jthc0gLqtC12PH23ElNoDaUQICnx4ac3Vmt-mKgKM=.1b76cb79-1c47-43c4-976d-c279030d0b03@github.com>

On Wed, 14 Sep 2022 20:35:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3671:
>> 
>>> 3669:             pdrEventTarget.clear();
>>> 3670:             pdrEventTargets.clear();
>>> 3671:             fullPDRTmpTargetWrapper.clear();
>> 
>> the change looks ok to me.
>> is this the only place where the clear() is needed?
>
> Yes, I checked the path of a typical mouse event and this method is always called when a mouse/drag operation is done.

ESCAPE key press during dragging?

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

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

From kevin.rushforth at oracle.com  Wed Sep 14 20:58:13 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 14 Sep 2022 13:58:13 -0700
Subject: JavaFX 19-ea+11 Crashes
In-Reply-To: <CAAP_wumukSKB00uCr3TVaDLz-oskHaW4__vrGVpON=8nZVprmA@mail.gmail.com>
References: <CAAP_wumukSKB00uCr3TVaDLz-oskHaW4__vrGVpON=8nZVprmA@mail.gmail.com>
Message-ID: <a252246e-49e2-e11c-3429-20e3a20e46c0@oracle.com>

That looks like a HotSpot crash. Have you tried running with JDK 18 or 
JDK 19 (which is in RC)?

-- Kevin

On 9/14/2022 1:38 PM, Thiago Milczarek Say?o wrote:
> Hi,
>
> Anybody experiencing crashes with javafx 19-ea+11?
>
> I have replaced it with javafx 19 final to test.
>
> By the look of the log, it has something to do with the garbage 
> collector and MenuButtonSkinBase?.
>
> I have suppressed some parts.
>
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # ?SIGSEGV (0xb) at pc=0x00007f4547fbd31f, pid=133481, tid=133520
> #
> # JRE version: OpenJDK Runtime Environment (17.0.4+8) (build 
> 17.0.4+8-Ubuntu-120.04)
> # Java VM: OpenJDK 64-Bit Server VM (17.0.4+8-Ubuntu-120.04, mixed 
> mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V ?[libjvm.so+0x59931f] 
> ?ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
>
> --------------- ?S U M M A R Y ------------
>
> Command Line: -Xmx350m -Xms135m -Djava.net.preferIPv4Stack=true 
> -Dsun.awt.disablegrab=true 
> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media 
> fl.jar
>
> Host: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz, 8 cores, 7G, Ubuntu 
> 20.04.4 LTS
> Time: Wed Sep 14 17:18:28 2022 -03 elapsed time: 47.851666 seconds (0d 
> 0h 0m 47s)
>
> --------------- ?T H R E A D ?---------------
>
> Current thread (0x00007f450c00d690): ?GCTaskThread "GC Thread#6" 
> [stack: 0x00007f44b1bc7000,0x00007f44b1cc7000] [id=133520]
>
> Stack: [0x00007f44b1bc7000,0x00007f44b1cc7000], 
> ?sp=0x00007f44b1cc5ac0, ?free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
> C=native code)
> V ?[libjvm.so+0x59931f] 
> ?ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
> V ?[libjvm.so+0x7476ad] ?G1CLDScanClosure::do_cld(ClassLoaderData*)+0x3d
> V ?[libjvm.so+0x59e351] 
> ?ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x41
> V ?[libjvm.so+0x76f1bc] 
> ?G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, 
> unsigned int)+0xcc
> V ?[libjvm.so+0x76f835] 
> ?G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x65
> V ?[libjvm.so+0x705b16] 
> ?G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned 
> int)+0x26
> V ?[libjvm.so+0x7062b7] ?G1EvacuateRegionsBaseTask::work(unsigned 
> int)+0x87
> V ?[libjvm.so+0xf8e907] ?GangWorker::loop()+0x67
> V ?[libjvm.so+0xf8e963]
> V ?[libjvm.so+0xedbe42] ?Thread::call_run()+0xe2
> V ?[libjvm.so+0xc324f9] ?thread_native_entry(Thread*)+0xe9
>
>
> RAX=0x000000000000007a is an unknown value
> RBX=0x00007f44a53f26f8 points into unknown readable memory: 
> 0x0000000000000001 | 01 00 00 00 00 00 00 00
> RCX=0x0000000000000014 is an unknown value
> RDX=0x00000000000031e6 is an unknown value
> RSP=0x00007f44b1cc5ac0 points into unknown readable memory: 
> 0x00007f4488003ac8 | c8 3a 00 88 44 7f 00 00
> RBP=0x00007f44b1cc5ae0 points into unknown readable memory: 
> 0x00007f44b1cc5b20 | 20 5b cc b1 44 7f 00 00
> RSI=0x00000000f6110495 is pointing into object: java.lang.Class
> {0x00000000f6110468} - klass: 'java/lang/Class'
> ?- ---- fields (total size 14 words):
> ?- private volatile transient 'classRedefinedCount' 'I' @12 ?0
> ?- private volatile transient 'cachedConstructor' 
> 'Ljava/lang/reflect/Constructor;' @40 ?NULL (0)
> ?- private transient 'name' 'Ljava/lang/String;' @44 
> ?"javafx.scene.control.skin.MenuButtonSkinBase$$Lambda$2420/0x0000000100ff7248"{0x00000000f4078820} 
> (f4078820)
> ?- private transient 'module' 'Ljava/lang/Module;' @48 ?a 
> 'java/lang/Module'{0x00000000ea298020} (ea298020)
> ?- private final 'classLoader' 'Ljava/lang/ClassLoader;' @52 ?a 
> 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000000ea975708} 
> (ea975708)
> ?- private transient 'classData' 'Ljava/lang/Object;' @56 ?NULL (0)
> ?- private transient 'packageName' 'Ljava/lang/String;' @60 
> ?"javafx.scene.control.skin"{0x00000000ea279b50} (ea279b50)
> ?- private final 'componentType' 'Ljava/lang/Class;' @64 ?NULL (0)
> ?- private volatile transient 'reflectionData' 
> 'Ljava/lang/ref/SoftReference;' @68 ?NULL (0)
> ?- private volatile transient 'genericInfo' 
> 'Lsun/reflect/generics/repository/ClassRepository;' @72 ?NULL (0)
> ?- private volatile transient 'enumConstants' '[Ljava/lang/Object;' 
> @76 ?NULL (0)
> ?- private volatile transient 'enumConstantDirectory' 
> 'Ljava/util/Map;' @80 ?NULL (0)
> ?- private volatile transient 'annotationData' 
> 'Ljava/lang/Class$AnnotationData;' @84 ?NULL (0)
> ?- private volatile transient 'annotationType' 
> 'Lsun/reflect/annotation/AnnotationType;' @88 ?NULL (0)
> ?- transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' 
> @92 ?NULL (0)
> ?- signature: 
> Ljavafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248;
> ?- fake entry for mirror: 
> 'javafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248'
> ?- fake entry for array: NULL
> ?- fake entry for oop_size: 14
> ?- fake entry for static_oop_field_count: 0


From mhanl at openjdk.org  Wed Sep 14 21:15:14 2022
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 14 Sep 2022 21:15:14 GMT
Subject: RFR: 8279214: Memory leak in Scene after dragging a cell
In-Reply-To: <x0Jthc0gLqtC12PH23ElNoDaUQICnx4ac3Vmt-mKgKM=.1b76cb79-1c47-43c4-976d-c279030d0b03@github.com>
References: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>
 <dw_pchUdpFXQtUpTsxIGjKObogvuvGW4tT6AR2JjxDI=.5174aba4-2491-4a15-8f4e-658752f088ae@github.com>
 <Y3hN82GlTwp6k-ik_hcV_FfsRaLXtRmdM2cyl6A3_no=.ad51ea82-2769-441e-9e51-b14540c18adc@github.com>
 <x0Jthc0gLqtC12PH23ElNoDaUQICnx4ac3Vmt-mKgKM=.1b76cb79-1c47-43c4-976d-c279030d0b03@github.com>
Message-ID: <9eL0Et8T0T7VPcv39uobcu4T7xOs8aJbU9Fjs5Yhrys=.0fc7e306-608b-4c95-bd1d-a00d88348d81@github.com>

On Wed, 14 Sep 2022 20:38:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, I checked the path of a typical mouse event and this method is always called when a mouse/drag operation is done.
>
> ESCAPE key press during dragging?

Yes, in this case it will be cleared when the mouse is released.

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

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

From angorya at openjdk.org  Wed Sep 14 21:15:14 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 14 Sep 2022 21:15:14 GMT
Subject: RFR: 8279214: Memory leak in Scene after dragging a cell
In-Reply-To: <9eL0Et8T0T7VPcv39uobcu4T7xOs8aJbU9Fjs5Yhrys=.0fc7e306-608b-4c95-bd1d-a00d88348d81@github.com>
References: <IaL5jt--ItBNhy9OlngSR-71k3ZYeDzuDWTJIf4tz8Q=.7c55c275-5417-49fe-9db4-9c614972e8ef@github.com>
 <dw_pchUdpFXQtUpTsxIGjKObogvuvGW4tT6AR2JjxDI=.5174aba4-2491-4a15-8f4e-658752f088ae@github.com>
 <Y3hN82GlTwp6k-ik_hcV_FfsRaLXtRmdM2cyl6A3_no=.ad51ea82-2769-441e-9e51-b14540c18adc@github.com>
 <x0Jthc0gLqtC12PH23ElNoDaUQICnx4ac3Vmt-mKgKM=.1b76cb79-1c47-43c4-976d-c279030d0b03@github.com>
 <9eL0Et8T0T7VPcv39uobcu4T7xOs8aJbU9Fjs5Yhrys=.0fc7e306-608b-4c95-bd1d-a00d88348d81@github.com>
Message-ID: <AzdG0InWKjAu5Y-zp1y2DCSpRTACDcnAAN9hkAvLZkE=.2a809199-ac9e-4ab2-b0b0-6a993669732a@github.com>

On Wed, 14 Sep 2022 21:12:09 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> ESCAPE key press during dragging?
>
> Yes, in this case it will be cleared when the mouse is released.

perfect, thank you for verifying.

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

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

From daniel.peintner at gmail.com  Thu Sep 15 06:03:08 2022
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 15 Sep 2022 08:03:08 +0200
Subject: JavaFX 19-ea+11 Crashes
In-Reply-To: <a252246e-49e2-e11c-3429-20e3a20e46c0@oracle.com>
References: <CAAP_wumukSKB00uCr3TVaDLz-oskHaW4__vrGVpON=8nZVprmA@mail.gmail.com>
 <a252246e-49e2-e11c-3429-20e3a20e46c0@oracle.com>
Message-ID: <CAAoP7T4v-4cE-G19o=-0DsYkJafBJh2MiFs+i3BHsurxtLmf-g@mail.gmail.com>

Hi,

In March 2022 we were experiencing some random crashes after upgrading to
JavaFX 18 (see [1]). In the end it didn't have to do with JavaFX but with
Java HotSpot.
I created a bug report [2] which was later closed as a duplicate of
JDK-8275610 (see [3]).

By now (Java18) it should be fixed.
Note: I cannot confirm this, since we are still stuck with Java17.

Which Java version are you using?
Maybe upgrading helps and the issue is related.

IF you need to stick with Java17 (not sure if it gets backported or how I
can check this) you may want to try disabling C2 optimization.

-XX:+TieredCompilation       (enable C1)
-XX:TieredStopAtLevel=1     (disable C2)

I hope this helps,

-- Daniel

[1] https://mail.openjdk.org/pipermail/openjfx-dev/2022-March/033831.html
[2] https://bugs.openjdk.org/browse/JDK-8283386
[3] https://bugs.openjdk.org/browse/JDK-8275610

On Wed, Sep 14, 2022 at 10:58 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> That looks like a HotSpot crash. Have you tried running with JDK 18 or
> JDK 19 (which is in RC)?
>
> -- Kevin
>
> On 9/14/2022 1:38 PM, Thiago Milczarek Say?o wrote:
> > Hi,
> >
> > Anybody experiencing crashes with javafx 19-ea+11?
> >
> > I have replaced it with javafx 19 final to test.
> >
> > By the look of the log, it has something to do with the garbage
> > collector and MenuButtonSkinBase .
> >
> > I have suppressed some parts.
> >
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  SIGSEGV (0xb) at pc=0x00007f4547fbd31f, pid=133481, tid=133520
> > #
> > # JRE version: OpenJDK Runtime Environment (17.0.4+8) (build
> > 17.0.4+8-Ubuntu-120.04)
> > # Java VM: OpenJDK 64-Bit Server VM (17.0.4+8-Ubuntu-120.04, mixed
> > mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> > # Problematic frame:
> > # V  [libjvm.so+0x59931f]
> >  ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
> >
> > ---------------  S U M M A R Y ------------
> >
> > Command Line: -Xmx350m -Xms135m -Djava.net.preferIPv4Stack=true
> > -Dsun.awt.disablegrab=true
> >
> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media
>
> > fl.jar
> >
> > Host: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz, 8 cores, 7G, Ubuntu
> > 20.04.4 LTS
> > Time: Wed Sep 14 17:18:28 2022 -03 elapsed time: 47.851666 seconds (0d
> > 0h 0m 47s)
> >
> > ---------------  T H R E A D  ---------------
> >
> > Current thread (0x00007f450c00d690):  GCTaskThread "GC Thread#6"
> > [stack: 0x00007f44b1bc7000,0x00007f44b1cc7000] [id=133520]
> >
> > Stack: [0x00007f44b1bc7000,0x00007f44b1cc7000],
> >  sp=0x00007f44b1cc5ac0,  free space=1018k
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> > C=native code)
> > V  [libjvm.so+0x59931f]
> >  ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
> > V  [libjvm.so+0x7476ad]  G1CLDScanClosure::do_cld(ClassLoaderData*)+0x3d
> > V  [libjvm.so+0x59e351]
> >  ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x41
> > V  [libjvm.so+0x76f1bc]
> >  G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*,
> > unsigned int)+0xcc
> > V  [libjvm.so+0x76f835]
> >  G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned
> int)+0x65
> > V  [libjvm.so+0x705b16]
> >  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned
> > int)+0x26
> > V  [libjvm.so+0x7062b7]  G1EvacuateRegionsBaseTask::work(unsigned
> > int)+0x87
> > V  [libjvm.so+0xf8e907]  GangWorker::loop()+0x67
> > V  [libjvm.so+0xf8e963]
> > V  [libjvm.so+0xedbe42]  Thread::call_run()+0xe2
> > V  [libjvm.so+0xc324f9]  thread_native_entry(Thread*)+0xe9
> >
> >
> > RAX=0x000000000000007a is an unknown value
> > RBX=0x00007f44a53f26f8 points into unknown readable memory:
> > 0x0000000000000001 | 01 00 00 00 00 00 00 00
> > RCX=0x0000000000000014 is an unknown value
> > RDX=0x00000000000031e6 is an unknown value
> > RSP=0x00007f44b1cc5ac0 points into unknown readable memory:
> > 0x00007f4488003ac8 | c8 3a 00 88 44 7f 00 00
> > RBP=0x00007f44b1cc5ae0 points into unknown readable memory:
> > 0x00007f44b1cc5b20 | 20 5b cc b1 44 7f 00 00
> > RSI=0x00000000f6110495 is pointing into object: java.lang.Class
> > {0x00000000f6110468} - klass: 'java/lang/Class'
> >  - ---- fields (total size 14 words):
> >  - private volatile transient 'classRedefinedCount' 'I' @12  0
> >  - private volatile transient 'cachedConstructor'
> > 'Ljava/lang/reflect/Constructor;' @40  NULL (0)
> >  - private transient 'name' 'Ljava/lang/String;' @44
> >
>  "javafx.scene.control.skin.MenuButtonSkinBase$$Lambda$2420/0x0000000100ff7248"{0x00000000f4078820}
>
> > (f4078820)
> >  - private transient 'module' 'Ljava/lang/Module;' @48  a
> > 'java/lang/Module'{0x00000000ea298020} (ea298020)
> >  - private final 'classLoader' 'Ljava/lang/ClassLoader;' @52  a
> > 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000000ea975708}
> > (ea975708)
> >  - private transient 'classData' 'Ljava/lang/Object;' @56  NULL (0)
> >  - private transient 'packageName' 'Ljava/lang/String;' @60
> >  "javafx.scene.control.skin"{0x00000000ea279b50} (ea279b50)
> >  - private final 'componentType' 'Ljava/lang/Class;' @64  NULL (0)
> >  - private volatile transient 'reflectionData'
> > 'Ljava/lang/ref/SoftReference;' @68  NULL (0)
> >  - private volatile transient 'genericInfo'
> > 'Lsun/reflect/generics/repository/ClassRepository;' @72  NULL (0)
> >  - private volatile transient 'enumConstants' '[Ljava/lang/Object;'
> > @76  NULL (0)
> >  - private volatile transient 'enumConstantDirectory'
> > 'Ljava/util/Map;' @80  NULL (0)
> >  - private volatile transient 'annotationData'
> > 'Ljava/lang/Class$AnnotationData;' @84  NULL (0)
> >  - private volatile transient 'annotationType'
> > 'Lsun/reflect/annotation/AnnotationType;' @88  NULL (0)
> >  - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;'
> > @92  NULL (0)
> >  - signature:
> >
> Ljavafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248;
> >  - fake entry for mirror:
> >
> 'javafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248'
> >  - fake entry for array: NULL
> >  - fake entry for oop_size: 14
> >  - fake entry for static_oop_field_count: 0
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/5204dbe9/attachment.htm>

From duke at openjdk.org  Thu Sep 15 07:06:31 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 07:06:31 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
Message-ID: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>

Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
any synchronisation to have writes of the calling thread be visible in the JavaFX Application
Thread. It is important to document either if callers can rely on runLater to do such synchronisation
internally, or to document is users CAN NOT rely on runLater for this.

This change documents that actions in a thread prior to submitting a runnable to
Platform#runLater happen-before actions performed by the runnable in the JavaFX
Application Thread.

runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
in the same way as it is documented by BlockingDeque.

Other implementations of runLater should have similar memory consistency effects.

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

Commit messages:
 - Remove trailing
 - Document memory consistency effects of runLater

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

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

From kcr at openjdk.org  Thu Sep 15 07:06:32 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Sep 2022 07:06:32 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
Message-ID: <wQEYw_P004gMa8vcF-ce22cZQpdr89cxU01q7G4Hu2c=.ccf72c0e-61b4-4721-a1ca-91cae99081a4@github.com>

On Wed, 17 Aug 2022 07:21:43 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
> internally, or to document is users CAN NOT rely on runLater for this.
> 
> This change documents that actions in a thread prior to submitting a runnable to
> Platform#runLater happen-before actions performed by the runnable in the JavaFX
> Application Thread.
> 
> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
> in the same way as it is documented by BlockingDeque.
> 
> Other implementations of runLater should have similar memory consistency effects.

@jensli I was going through the PRs that are not marked as `rfr` (ready for review), and spotted this one. There are two needed steps before this will be marked as ready:

1. You need to file a bug report
2. You need to fix the whitespace error pointed out by `jcheck`  in the code diffs

See [CONTRIBUTING.md](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) for more information.

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

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

From duke at openjdk.org  Thu Sep 15 07:06:33 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 07:06:33 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <wQEYw_P004gMa8vcF-ce22cZQpdr89cxU01q7G4Hu2c=.ccf72c0e-61b4-4721-a1ca-91cae99081a4@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <wQEYw_P004gMa8vcF-ce22cZQpdr89cxU01q7G4Hu2c=.ccf72c0e-61b4-4721-a1ca-91cae99081a4@github.com>
Message-ID: <DVnUe6LedTez_pEXJ6NzXAd5VEdUVSBh4hLp_4VgvdU=.051f4392-e7cc-4443-ad71-8d649f1fd65e@github.com>

On Tue, 6 Sep 2022 16:20:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
>> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
>> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
>> internally, or to document is users CAN NOT rely on runLater for this.
>> 
>> This change documents that actions in a thread prior to submitting a runnable to
>> Platform#runLater happen-before actions performed by the runnable in the JavaFX
>> Application Thread.
>> 
>> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
>> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
>> in the same way as it is documented by BlockingDeque.
>> 
>> Other implementations of runLater should have similar memory consistency effects.
>
> @jensli I was going through the PRs that are not marked as `rfr` (ready for review), and spotted this one. There are two needed steps before this will be marked as ready:
> 
> 1. You need to file a bug report
> 2. You need to fix the whitespace error pointed out by `jcheck`  in the code diffs
> 
> See [CONTRIBUTING.md](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) for more information.

Thanks for the help, @kevinrushforth. I was not prepared for all the rigour of the OpenJDK contribution process. This has been a perfect opportunity for me to learn about it.

When my bug report submission is accepted then hopefully all formal requirements will be met. (Maybe also the internal review bug ID have to be updated to the proper bug ID.)

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

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

From duke at openjdk.org  Thu Sep 15 08:20:55 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 08:20:55 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <wQEYw_P004gMa8vcF-ce22cZQpdr89cxU01q7G4Hu2c=.ccf72c0e-61b4-4721-a1ca-91cae99081a4@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <wQEYw_P004gMa8vcF-ce22cZQpdr89cxU01q7G4Hu2c=.ccf72c0e-61b4-4721-a1ca-91cae99081a4@github.com>
Message-ID: <fFrVgpyPotwKGy6EWMvOWoPSJ228_NKWEgaqHO-h_gs=.4ad07c10-f128-4648-b0eb-c4ad2a6c7d4d@github.com>

On Tue, 6 Sep 2022 16:20:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
>> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
>> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
>> internally, or to document is users CAN NOT rely on runLater for this.
>> 
>> This change documents that actions in a thread prior to submitting a runnable to
>> Platform#runLater happen-before actions performed by the runnable in the JavaFX
>> Application Thread.
>> 
>> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
>> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
>> in the same way as it is documented by BlockingDeque.
>> 
>> Other implementations of runLater should have similar memory consistency effects.
>
> @jensli I was going through the PRs that are not marked as `rfr` (ready for review), and spotted this one. There are two needed steps before this will be marked as ready:
> 
> 1. You need to file a bug report
> 2. You need to fix the whitespace error pointed out by `jcheck`  in the code diffs
> 
> See [CONTRIBUTING.md](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md) for more information.

@kevinrushforth This is now finished. Can you review?

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

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

From kcr at openjdk.org  Thu Sep 15 11:25:03 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Sep 2022 11:25:03 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
Message-ID: <4pJhZUn_kT_ntTqdlxJQTLsDukkMNyjtxP4Smo-Q6gA=.028ebf34-43f2-4a34-8094-33073da21cb1@github.com>

On Wed, 17 Aug 2022 07:21:43 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
> internally, or to document is users CAN NOT rely on runLater for this.
> 
> This change documents that actions in a thread prior to submitting a runnable to
> Platform#runLater happen-before actions performed by the runnable in the JavaFX
> Application Thread.
> 
> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
> in the same way as it is documented by BlockingDeque.
> 
> Other implementations of runLater should have similar memory consistency effects.

This is now ready to review, so I'll take a look. One thing to note, though, is that the `/summary` is an optional extra line of information that gets recorded into a commit. Most of the time it is unused, but if it is used, it should not be a copy of the title. I recommend removing it with `/summary` in a comment by itself with no other text.

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

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

From kcr at openjdk.org  Thu Sep 15 11:30:53 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Sep 2022 11:30:53 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
Message-ID: <o9h443HIybKoShhoCy-6UxG9EEBtIvBh-xRwhY39GKo=.b2540124-0ea5-4b18-9ba3-468fa91de354@github.com>

On Wed, 17 Aug 2022 07:21:43 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
> internally, or to document is users CAN NOT rely on runLater for this.
> 
> This change documents that actions in a thread prior to submitting a runnable to
> Platform#runLater happen-before actions performed by the runnable in the JavaFX
> Application Thread.
> 
> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
> in the same way as it is documented by BlockingDeque.
> 
> Other implementations of runLater should have similar memory consistency effects.

The added description looks good. I left one suggestion on using code style for the named argument.

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 157:

> 155:      * Memory consistency effects: Actions in a thread prior to submitting a
> 156:      * runnable to this method <i>happen-before</i> actions performed by
> 157:      * the runnable in the JavaFX Application Thread.

I think it would be helpful to use code style for runnable on these two lines (since it refers to the `runnable` argument), like this: `{@code runnable}`

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

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

From duke at openjdk.org  Thu Sep 15 11:45:51 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 11:45:51 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <4pJhZUn_kT_ntTqdlxJQTLsDukkMNyjtxP4Smo-Q6gA=.028ebf34-43f2-4a34-8094-33073da21cb1@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <4pJhZUn_kT_ntTqdlxJQTLsDukkMNyjtxP4Smo-Q6gA=.028ebf34-43f2-4a34-8094-33073da21cb1@github.com>
Message-ID: <_Hm2RRHRQWAKm_NKMRvOfevV4S1H_ArUI_LrLLYA1zs=.ba60a65f-7aeb-4b69-8cc3-8f82c40cbc15@github.com>

On Thu, 15 Sep 2022 11:20:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> One thing to note, though, is that the `/summary` is an optional extra line of information that gets recorded into a commit. 

Ah, okay, thanks.

Do I remove the summary by issuing and empty `/summary`?

Will the commit message of the squshed commit be taken from the PR description?

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

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

From duke at openjdk.org  Thu Sep 15 11:56:56 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 11:56:56 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
Message-ID: <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>

> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
> internally, or to document is users CAN NOT rely on runLater for this.
> 
> This change documents that actions in a thread prior to submitting a runnable to
> Platform#runLater happen-before actions performed by the runnable in the JavaFX
> Application Thread.
> 
> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
> in the same way as it is documented by BlockingDeque.
> 
> Other implementations of runLater should have similar memory consistency effects.

Jens Lidestrom has updated the pull request incrementally with one additional commit since the last revision:

  Use code formatting for 'runnable'

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/872/files
  - new: https://git.openjdk.org/jfx/pull/872/files/79aea1ad..d935dc11

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

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

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

From kcr at openjdk.org  Thu Sep 15 11:56:56 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Sep 2022 11:56:56 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <_Hm2RRHRQWAKm_NKMRvOfevV4S1H_ArUI_LrLLYA1zs=.ba60a65f-7aeb-4b69-8cc3-8f82c40cbc15@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <4pJhZUn_kT_ntTqdlxJQTLsDukkMNyjtxP4Smo-Q6gA=.028ebf34-43f2-4a34-8094-33073da21cb1@github.com>
 <_Hm2RRHRQWAKm_NKMRvOfevV4S1H_ArUI_LrLLYA1zs=.ba60a65f-7aeb-4b69-8cc3-8f82c40cbc15@github.com>
Message-ID: <LdP_F8nJXmCDSXcFAmvrIuW0s25UhvArnYFV4A4I1CM=.51cb193a-1be9-4cb2-b5c7-e53e761f2a41@github.com>

On Thu, 15 Sep 2022 11:43:43 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> Do I remove the summary by issuing and empty `/summary`?
> 
> Will the commit message of the squshed commit be taken from the PR description?

Yes to both questions.

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

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

From nlisker at openjdk.org  Thu Sep 15 11:56:56 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 15 Sep 2022 11:56:56 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>
Message-ID: <OFvlUmGkYbjEPnJjvfSPTBjbdaLfh2yKMatQlk7caAw=.f07c1999-3a56-4345-b568-4177715d6407@github.com>

On Thu, 15 Sep 2022 11:52:00 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
>> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
>> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
>> internally, or to document is users CAN NOT rely on runLater for this.
>> 
>> This change documents that actions in a thread prior to submitting a runnable to
>> Platform#runLater happen-before actions performed by the runnable in the JavaFX
>> Application Thread.
>> 
>> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
>> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
>> in the same way as it is documented by BlockingDeque.
>> 
>> Other implementations of runLater should have similar memory consistency effects.
>
> Jens Lidestrom has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use code formatting for 'runnable'

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 156:

> 154:      * <p>
> 155:      * Memory consistency effects: Actions in a thread prior to submitting a
> 156:      * runnable to this method <i>happen-before</i> actions performed by

I noticed that other classes add the link to the concurrency package summary as in https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/concurrent/BlockingQueue.html

You might want to do so as well.

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

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

From duke at openjdk.org  Thu Sep 15 11:56:57 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 11:56:57 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <o9h443HIybKoShhoCy-6UxG9EEBtIvBh-xRwhY39GKo=.b2540124-0ea5-4b18-9ba3-468fa91de354@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <o9h443HIybKoShhoCy-6UxG9EEBtIvBh-xRwhY39GKo=.b2540124-0ea5-4b18-9ba3-468fa91de354@github.com>
Message-ID: <rjR66th7-ORibQtERep33XwbO4HdAtVg4vxeGAkIUf0=.fa3b99d2-5ffd-493a-9631-d329ba531be5@github.com>

On Thu, 15 Sep 2022 11:24:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Jens Lidestrom has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use code formatting for 'runnable'
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 157:
> 
>> 155:      * Memory consistency effects: Actions in a thread prior to submitting a
>> 156:      * runnable to this method <i>happen-before</i> actions performed by
>> 157:      * the runnable in the JavaFX Application Thread.
> 
> I think it would be helpful to use code style for runnable on these two lines (since it refers to the `runnable` argument), like this: `{@code runnable}`

Fixed. Whose responsibility is it to press the "Resolve conversation" button?

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

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

From duke at openjdk.org  Thu Sep 15 12:02:08 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 12:02:08 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <OFvlUmGkYbjEPnJjvfSPTBjbdaLfh2yKMatQlk7caAw=.f07c1999-3a56-4345-b568-4177715d6407@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>
 <OFvlUmGkYbjEPnJjvfSPTBjbdaLfh2yKMatQlk7caAw=.f07c1999-3a56-4345-b568-4177715d6407@github.com>
Message-ID: <qMnZAdUQ4SFTm8ym80MQTkMHd9wopgzTPh2_WtlHgWM=.58ba9981-d799-4787-9122-1fa130bd4b45@github.com>

On Thu, 15 Sep 2022 11:50:17 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Jens Lidestrom has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use code formatting for 'runnable'
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 156:
> 
>> 154:      * <p>
>> 155:      * Memory consistency effects: Actions in a thread prior to submitting a
>> 156:      * runnable to this method <i>happen-before</i> actions performed by
> 
> I noticed that other classes add the link to the concurrency package summary as in https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/concurrent/BlockingQueue.html
> 
> You might want to do so as well.

I considered such a link but didn't add it. My reasoning is that for the standard library classes such a link is internal, to the same Javadoc site.

For JavaFX on the other hand such a link is external, pointing to a site outside the control of the JavaFX project. This has the effect, for example that the link must be kept up to date. Should it always point to the latest Java release? What if the URL change? What if the package summary changes format in a future version?

I think it is more sensible to leave out such a link. "_Happens-before_" is a standard concept in Java and readers can locate an explanation for it themselves.

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

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

From kcr at openjdk.org  Thu Sep 15 12:07:11 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Sep 2022 12:07:11 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <qMnZAdUQ4SFTm8ym80MQTkMHd9wopgzTPh2_WtlHgWM=.58ba9981-d799-4787-9122-1fa130bd4b45@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>
 <OFvlUmGkYbjEPnJjvfSPTBjbdaLfh2yKMatQlk7caAw=.f07c1999-3a56-4345-b568-4177715d6407@github.com>
 <qMnZAdUQ4SFTm8ym80MQTkMHd9wopgzTPh2_WtlHgWM=.58ba9981-d799-4787-9122-1fa130bd4b45@github.com>
Message-ID: <I9HjqyCR341srtc-4ssaK0qg1cj13ulVAz243Hf_qx4=.31cd46a4-9860-4a3e-b810-48246751bccf@github.com>

On Thu, 15 Sep 2022 11:59:44 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 156:
>> 
>>> 154:      * <p>
>>> 155:      * Memory consistency effects: Actions in a thread prior to submitting a
>>> 156:      * runnable to this method <i>happen-before</i> actions performed by
>> 
>> I noticed that other classes add the link to the concurrency package summary as in https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/concurrent/BlockingQueue.html
>> 
>> You might want to do so as well.
>
> I considered such a link but didn't add it. My reasoning is that for the standard library classes such a link is internal, to the same Javadoc site.
> 
> For JavaFX on the other hand such a link is external, pointing to a site outside the control of the JavaFX project. This has the effect, for example, that the link must be kept up to date. Should it always point to the latest Java release? What if the URL change? What if the package summary changes format in a future version?
> 
> I think it is more sensible to leave out such a link. "_Happens-before_" is a standard concept in Java and readers can locate an explanation for it themselves.

OK.

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

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

From kcr at openjdk.org  Thu Sep 15 12:07:12 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 15 Sep 2022 12:07:12 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <rjR66th7-ORibQtERep33XwbO4HdAtVg4vxeGAkIUf0=.fa3b99d2-5ffd-493a-9631-d329ba531be5@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <o9h443HIybKoShhoCy-6UxG9EEBtIvBh-xRwhY39GKo=.b2540124-0ea5-4b18-9ba3-468fa91de354@github.com>
 <rjR66th7-ORibQtERep33XwbO4HdAtVg4vxeGAkIUf0=.fa3b99d2-5ffd-493a-9631-d329ba531be5@github.com>
Message-ID: <STIDNV-6GAqjbQU8MC-yrbagc1jTdumVQgz3kYRaDAE=.0ad9c7bd-4278-465d-bfe4-36a57f618371@github.com>

On Thu, 15 Sep 2022 11:51:22 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 157:
>> 
>>> 155:      * Memory consistency effects: Actions in a thread prior to submitting a
>>> 156:      * runnable to this method <i>happen-before</i> actions performed by
>>> 157:      * the runnable in the JavaFX Application Thread.
>> 
>> I think it would be helpful to use code style for runnable on these two lines (since it refers to the `runnable` argument), like this: `{@code runnable}`
>
> Fixed. Whose responsibility is it to press the "Resolve conversation" button?

You can.

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

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

From duke at openjdk.org  Thu Sep 15 12:13:55 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Thu, 15 Sep 2022 12:13:55 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <LdP_F8nJXmCDSXcFAmvrIuW0s25UhvArnYFV4A4I1CM=.51cb193a-1be9-4cb2-b5c7-e53e761f2a41@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <4pJhZUn_kT_ntTqdlxJQTLsDukkMNyjtxP4Smo-Q6gA=.028ebf34-43f2-4a34-8094-33073da21cb1@github.com>
 <_Hm2RRHRQWAKm_NKMRvOfevV4S1H_ArUI_LrLLYA1zs=.ba60a65f-7aeb-4b69-8cc3-8f82c40cbc15@github.com>
 <LdP_F8nJXmCDSXcFAmvrIuW0s25UhvArnYFV4A4I1CM=.51cb193a-1be9-4cb2-b5c7-e53e761f2a41@github.com>
Message-ID: <1tbfqMpro3JJFTlWr_NruPYMphdqIkrU0mZhD-W49hc=.d87bc9ca-117a-47bb-834b-41b0c1b978fe@github.com>

On Thu, 15 Sep 2022 11:52:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> One thing to note, though, is that the `/summary` is an optional extra line of information that gets recorded into a commit. 
>> 
>> Ah, okay, thanks.
>> 
>> Do I remove the summary by issuing and empty `/summary`?
>> 
>> Will the commit message of the squshed commit be taken from the PR description?
>
>> Do I remove the summary by issuing and empty `/summary`?
>> 
>> Will the commit message of the squshed commit be taken from the PR description?
> 
> Yes to both questions.

@kevinrushforth I think this is now finished.

Thanks for teaching me about the OpenJDK contribution process! :)

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

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

From aoqi at openjdk.org  Thu Sep 15 12:24:58 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Sep 2022 12:24:58 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v3]
In-Reply-To: <wdfslkH3ca19e5lvPXkV4hyWzG6bVbobHf3uCmkFZYg=.69d5feb9-95a7-46e2-b8d9-33a0ce0ee9f5@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <ID5OcybOJfDwPCY4iES29iBVuzNNFVMjQmPlw1BIWH0=.3014e625-5543-4c25-a624-85ab40518d33@github.com>
 <wdfslkH3ca19e5lvPXkV4hyWzG6bVbobHf3uCmkFZYg=.69d5feb9-95a7-46e2-b8d9-33a0ce0ee9f5@github.com>
Message-ID: <RYWLeBunmlUgF7RScXxNmndZwZYgmoPmBVMAlvdJR3E=.c1cc75aa-9bfe-4110-9830-27a1e9a105f4@github.com>

On Wed, 7 Sep 2022 12:02:37 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert
>
> This PR looks safe to me. I don't see a scenario where this can cause regression. I can't say if those changes are enough to build for LoongArch64 though, but as long as there is no regression I am ok.
> There are a few minor optimizations that I suggested -- in general, there are more places in the build.gradle file where we could benefit from optimizations but I don't recommend doing that as part of this PR.

Hi @johanvos , I have updated the patch according to your suggestions. Would you like to review it?

I think I need at least one more review, would someone help to review the patch? Thanks!

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

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

From thiago.sayao at gmail.com  Thu Sep 15 12:25:15 2022
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 15 Sep 2022 09:25:15 -0300
Subject: JavaFX 19-ea+11 Crashes
In-Reply-To: <CAAoP7T4v-4cE-G19o=-0DsYkJafBJh2MiFs+i3BHsurxtLmf-g@mail.gmail.com>
References: <CAAP_wumukSKB00uCr3TVaDLz-oskHaW4__vrGVpON=8nZVprmA@mail.gmail.com>
 <a252246e-49e2-e11c-3429-20e3a20e46c0@oracle.com>
 <CAAoP7T4v-4cE-G19o=-0DsYkJafBJh2MiFs+i3BHsurxtLmf-g@mail.gmail.com>
Message-ID: <CAAP_wumN=ZW2QQj4RURm1ZNyF3jNkSGs+9ReDWpe44-AnQC8GA@mail.gmail.com>

Hi,

I'm using java 17.0.4 (ubuntu 20.04 default build).
Random crashes also happen with graalvm 22.2 (the logs look different).

It does not crash constantly, they're somewhat rare random crashes.

I can check other versions of java to explore the problem, but in
deployment I have to stick with 17.

By looking at my log (I'm not an expert on this), it seems to be a crash on
the G1 garbage collector thread.

But thanks for the tips, It's something I can try (disable the
optimization).

Em qui., 15 de set. de 2022 ?s 03:03, Daniel Peintner <
daniel.peintner at gmail.com> escreveu:

> Hi,
>
> In March 2022 we were experiencing some random crashes after upgrading to
> JavaFX 18 (see [1]). In the end it didn't have to do with JavaFX but with
> Java HotSpot.
> I created a bug report [2] which was later closed as a duplicate of
> JDK-8275610 (see [3]).
>
> By now (Java18) it should be fixed.
> Note: I cannot confirm this, since we are still stuck with Java17.
>
> Which Java version are you using?
> Maybe upgrading helps and the issue is related.
>
> IF you need to stick with Java17 (not sure if it gets backported or how I
> can check this) you may want to try disabling C2 optimization.
>
> -XX:+TieredCompilation       (enable C1)
> -XX:TieredStopAtLevel=1     (disable C2)
>
> I hope this helps,
>
> -- Daniel
>
> [1] https://mail.openjdk.org/pipermail/openjfx-dev/2022-March/033831.html
> [2] https://bugs.openjdk.org/browse/JDK-8283386
> [3] https://bugs.openjdk.org/browse/JDK-8275610
>
> On Wed, Sep 14, 2022 at 10:58 PM Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>> That looks like a HotSpot crash. Have you tried running with JDK 18 or
>> JDK 19 (which is in RC)?
>>
>> -- Kevin
>>
>> On 9/14/2022 1:38 PM, Thiago Milczarek Say?o wrote:
>> > Hi,
>> >
>> > Anybody experiencing crashes with javafx 19-ea+11?
>> >
>> > I have replaced it with javafx 19 final to test.
>> >
>> > By the look of the log, it has something to do with the garbage
>> > collector and MenuButtonSkinBase .
>> >
>> > I have suppressed some parts.
>> >
>> > # A fatal error has been detected by the Java Runtime Environment:
>> > #
>> > #  SIGSEGV (0xb) at pc=0x00007f4547fbd31f, pid=133481, tid=133520
>> > #
>> > # JRE version: OpenJDK Runtime Environment (17.0.4+8) (build
>> > 17.0.4+8-Ubuntu-120.04)
>> > # Java VM: OpenJDK 64-Bit Server VM (17.0.4+8-Ubuntu-120.04, mixed
>> > mode, tiered, compressed oops, compressed class ptrs, g1 gc,
>> linux-amd64)
>> > # Problematic frame:
>> > # V  [libjvm.so+0x59931f]
>> >  ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
>> >
>> > ---------------  S U M M A R Y ------------
>> >
>> > Command Line: -Xmx350m -Xms135m -Djava.net.preferIPv4Stack=true
>> > -Dsun.awt.disablegrab=true
>> >
>> --add-modules=javafx.controls,javafx.fxml,javafx.web,javafx.swing,javafx.media
>>
>> > fl.jar
>> >
>> > Host: Intel(R) Core(TM) i3-10100 CPU @ 3.60GHz, 8 cores, 7G, Ubuntu
>> > 20.04.4 LTS
>> > Time: Wed Sep 14 17:18:28 2022 -03 elapsed time: 47.851666 seconds (0d
>> > 0h 0m 47s)
>> >
>> > ---------------  T H R E A D  ---------------
>> >
>> > Current thread (0x00007f450c00d690):  GCTaskThread "GC Thread#6"
>> > [stack: 0x00007f44b1bc7000,0x00007f44b1cc7000] [id=133520]
>> >
>> > Stack: [0x00007f44b1bc7000,0x00007f44b1cc7000],
>> >  sp=0x00007f44b1cc5ac0,  free space=1018k
>> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
>> > C=native code)
>> > V  [libjvm.so+0x59931f]
>> >  ClassLoaderData::ChunkedHandleList::oops_do(OopClosure*)+0x5f
>> > V  [libjvm.so+0x7476ad]  G1CLDScanClosure::do_cld(ClassLoaderData*)+0x3d
>> > V  [libjvm.so+0x59e351]
>> >  ClassLoaderDataGraph::roots_cld_do(CLDClosure*, CLDClosure*)+0x41
>> > V  [libjvm.so+0x76f1bc]
>> >  G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*,
>> > unsigned int)+0xcc
>> > V  [libjvm.so+0x76f835]
>> >  G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned
>> int)+0x65
>> > V  [libjvm.so+0x705b16]
>> >  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned
>> > int)+0x26
>> > V  [libjvm.so+0x7062b7]  G1EvacuateRegionsBaseTask::work(unsigned
>> > int)+0x87
>> > V  [libjvm.so+0xf8e907]  GangWorker::loop()+0x67
>> > V  [libjvm.so+0xf8e963]
>> > V  [libjvm.so+0xedbe42]  Thread::call_run()+0xe2
>> > V  [libjvm.so+0xc324f9]  thread_native_entry(Thread*)+0xe9
>> >
>> >
>> > RAX=0x000000000000007a is an unknown value
>> > RBX=0x00007f44a53f26f8 points into unknown readable memory:
>> > 0x0000000000000001 | 01 00 00 00 00 00 00 00
>> > RCX=0x0000000000000014 is an unknown value
>> > RDX=0x00000000000031e6 is an unknown value
>> > RSP=0x00007f44b1cc5ac0 points into unknown readable memory:
>> > 0x00007f4488003ac8 | c8 3a 00 88 44 7f 00 00
>> > RBP=0x00007f44b1cc5ae0 points into unknown readable memory:
>> > 0x00007f44b1cc5b20 | 20 5b cc b1 44 7f 00 00
>> > RSI=0x00000000f6110495 is pointing into object: java.lang.Class
>> > {0x00000000f6110468} - klass: 'java/lang/Class'
>> >  - ---- fields (total size 14 words):
>> >  - private volatile transient 'classRedefinedCount' 'I' @12  0
>> >  - private volatile transient 'cachedConstructor'
>> > 'Ljava/lang/reflect/Constructor;' @40  NULL (0)
>> >  - private transient 'name' 'Ljava/lang/String;' @44
>> >
>>  "javafx.scene.control.skin.MenuButtonSkinBase$$Lambda$2420/0x0000000100ff7248"{0x00000000f4078820}
>>
>> > (f4078820)
>> >  - private transient 'module' 'Ljava/lang/Module;' @48  a
>> > 'java/lang/Module'{0x00000000ea298020} (ea298020)
>> >  - private final 'classLoader' 'Ljava/lang/ClassLoader;' @52  a
>> > 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x00000000ea975708}
>> > (ea975708)
>> >  - private transient 'classData' 'Ljava/lang/Object;' @56  NULL (0)
>> >  - private transient 'packageName' 'Ljava/lang/String;' @60
>> >  "javafx.scene.control.skin"{0x00000000ea279b50} (ea279b50)
>> >  - private final 'componentType' 'Ljava/lang/Class;' @64  NULL (0)
>> >  - private volatile transient 'reflectionData'
>> > 'Ljava/lang/ref/SoftReference;' @68  NULL (0)
>> >  - private volatile transient 'genericInfo'
>> > 'Lsun/reflect/generics/repository/ClassRepository;' @72  NULL (0)
>> >  - private volatile transient 'enumConstants' '[Ljava/lang/Object;'
>> > @76  NULL (0)
>> >  - private volatile transient 'enumConstantDirectory'
>> > 'Ljava/util/Map;' @80  NULL (0)
>> >  - private volatile transient 'annotationData'
>> > 'Ljava/lang/Class$AnnotationData;' @84  NULL (0)
>> >  - private volatile transient 'annotationType'
>> > 'Lsun/reflect/annotation/AnnotationType;' @88  NULL (0)
>> >  - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;'
>> > @92  NULL (0)
>> >  - signature:
>> >
>> Ljavafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248;
>> >  - fake entry for mirror:
>> >
>> 'javafx/scene/control/skin/MenuButtonSkinBase$$Lambda$2420+0x0000000100ff7248'
>> >  - fake entry for array: NULL
>> >  - fake entry for oop_size: 14
>> >  - fake entry for static_oop_field_count: 0
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/b78b75e9/attachment.htm>

From jvos at openjdk.org  Thu Sep 15 13:34:02 2022
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 15 Sep 2022 13:34:02 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
Message-ID: <jzRFSimra5S_oxIPGJENRsFx7fluTEwP58CFBDXGzNk=.3cff9624-b65a-4165-9905-aa918bc00962@github.com>

On Thu, 8 Sep 2022 07:26:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64

It looks good. I'll do a build and then hopefully I can approve (those ifeq/ifneq changes often need more than a few pair of eyes)

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

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

From aoqi at openjdk.org  Thu Sep 15 13:58:02 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 15 Sep 2022 13:58:02 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <jzRFSimra5S_oxIPGJENRsFx7fluTEwP58CFBDXGzNk=.3cff9624-b65a-4165-9905-aa918bc00962@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
 <jzRFSimra5S_oxIPGJENRsFx7fluTEwP58CFBDXGzNk=.3cff9624-b65a-4165-9905-aa918bc00962@github.com>
Message-ID: <zVZoB0q-jXsHl15hfNaZYAhd9UtstGEBidDlr8fEnaE=.1867be62-d257-45d3-8b44-011db1f134e2@github.com>

On Thu, 15 Sep 2022 13:31:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

> It looks good. I'll do a build and then hopefully I can approve (those ifeq/ifneq changes often need more than a few pair of eyes)

Yes. We need to check it carefully:) I did some tests like:

ifneq (,$(findstring $(ARCH), x64 x32 loongarch64))
    CFLAGS += -msse2
endif

and it did cause errors like:

make: *** Waiting for unfinished jobs....
gcc: error: unrecognized command line option '-msse2'

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

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

From dlemmermann at gmail.com  Thu Sep 15 15:16:49 2022
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Thu, 15 Sep 2022 17:16:49 +0200
Subject: Virtual Flow enhancements
In-Reply-To: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
References: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
Message-ID: <5D918C14-C381-4B01-B501-C0D9AA444AF2@gmail.com>

FWIW: I have created a GitHub repository that showcases three different approaches to performing synchronised scrolling between two VirtualFlow instances: https://github.com/dlemmermann/sync-scrolling <https://github.com/dlemmermann/sync-scrolling>

Might come in handy for future testing if anyone thinks they know how it could be done. Each demo creates ?rows? (cells) of different heights, which I guess is one of the tricky things about it.

One approach is the one that I have been using for FlexGanttFX for the last couple of years. The second one is related to it (using the positionProperty()), the third one is the one that Johan started / suggested (scrollTo()).

Dirk


> On 13 Sep 2022, at 11:02, Johan Vos <johan.vos at gluonhq.com> wrote:
> 
> Hi,
> 
> OpenJFX 17 contains a fix for JDK-8089589  [1] ([ListView] ScrollBar content moves toward-backward during scrolling.) Before this fix, the scrollbar in the VirtualFlow backing List/Table/TreeTableView controls was treating every cell of equal height. That generated an awkward scrolling experience, especially when there are major differences in sizes in the backing list.
> 
> The original fix introduced some new issues, and most of these are meanwhile fixed, and tests are added (thanks to e.g. Florian Kirmaier who created a good amount of tests). 
> 
> However, people have in the past been relying on undocumented behavior while creating apps and libraries, and that behavior is not guaranteed anymore with the fix for JDK-8089589 that went into OpenJFX 17. 
> Most of these cases are related to 
> (1) assuming that IndexedCell.updateItem() is only called when an item is (about to be) shown and
> (2) assuming that the value returned by the positionProperty of the scrollbar thumb is linearly related to the index of the item in the backinglist being shown.
> 
> Both of these assumptions are invalid, but were (more or less) happening before JavaFX 17. 
> I have seen a fair amount of creative implementations that somehow get and process information about the position of elements in the controls. Some of these relied on the false assumptions above, and are obviously no longer working.
> Instead of providing fixes per case, I think it would be good to capture the common use cases, and make it easier for developers to achieve what they want to achieve. I didn't yet encounter a use case that can not be implemented with the current approach (using public API's only), but granted, implementations often require too much boilerplate and wiring code. 
> 
> Crucial in this exercise are tests. There are a fair amount of tests for the list/table/treetableview controls, but only few of them are focused on external access and behavior. 
> For all the fixes done so far in VirtualFlow, additional tests have been written which are now excellent regression tests. The last thing we want is that a fix for usecase A is not working anymore after a fix for usecase B.
> 
> Hence, I'd like us to do 2 things:
> 1) for issues that are clearly bugs (*violating the JavaDoc*), please create JBS issues as usual (with failing test code). 
> 2) for issues that are not violating the specs now, but are "common sense", please create a description and test scenario with expected versus actual outcome. 
> 
> I am not 100% sure what the best approach is to tackle issues that fall in the second category, but I suggest this: if you have a rather vague, abstract issue (e.g. "listview should always scroll to the bottom of the list IF it was at the bottom before and a new element is added") , it probably makes sense to first discuss it here. If on the other hand you have a very clear issue with a clear failing test, it can be a JBS issue as well -- but we need to keep in mind then that it might be in the category of "this fixes usescase A but blocks usecase B"
> 
> Thanks,
> 
> - Johan
> 
> [1] https://bugs.openjdk.org/browse/JDK-8089589 <https://bugs.openjdk.org/browse/JDK-8089589>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/d7c956f8/attachment.htm>

From administrator at codedead.com  Thu Sep 15 15:27:01 2022
From: administrator at codedead.com (Alessandro Mercier)
Date: Thu, 15 Sep 2022 17:27:01 +0200
Subject: JavaFX 19 - Media object bug
Message-ID: <CAEN8YAHyhCzNOZS-Yc6gjT2KoMQxoVXkdMErn_7M5zxxJH-j2A@mail.gmail.com>

Hello all,

After this commit:
https://github.com/openjdk/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9

Creating a new Media object using a MP3 file in the resources of a project,
you can get exceptions:

Exception in thread "JavaFX Application Thread" MediaException:
MEDIA_UNSUPPORTED : Unrecognized file signature!
at javafx.media at 20-ea/javafx.scene.media.Media.<init>(Media.java:411)

At first glance, the error is in this Locator file in the JavaFX source
code:
https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java

*Steps to reproduce the bug:*
1. Create a new Media object and load an MP3 from the resources
2. Watch the Media object throw a MediaException: MEDIA_UNSUPPORTED :
Unrecognized file signature!

*Example code that produces the bug:*
final MediaPlayer mediaPlayer = new MediaPlayer(new
Media(getClass().getResource("/path/to/file.mp3").toExternalForm()));

*Extra:*
I've made a free MP3 file available to try with here (royalty free):
https://codedead.com/static.mp3

I've also got a GIT repository in which the exception occurs immediately
when running the Gradle task 'application':
https://github.com/CodeDead/opal/tree/development (please make sure to use
the development branch as this branch makes use of the latest JavaFX
versions)

Oddly enough, it does not always happen, and loading the file directly from
a file location instead of the project resources seems to work, but when
loading from the resources, you get the exception that the media file
signature is not recognized.
I don't see a problem with the media files themselves, encoding is all
fine, at first glance and because it worked in JavaFX 18.0.2, creating a
Media object using a URI to a project resources location should work in
newer versions as well, I think. The same MP3 file does work when you load
it from the disk instead of the project resources so this makes it a bug, I
believe.

The work-around right now is to revert back to JavaFX version 18.0.2.

*System / OS / Runtime info:*
Linux Fedora 36
5.19.8-200.fc36.x86_64
openjdk version "18.0.2" 2022-07-19
OpenJDK Runtime Environment (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build
18.0.2+9)
OpenJDK 64-Bit Server VM (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build
18.0.2+9, mixed mode, sharing)

Thank you and kind regards

Alessandro Mercier
-- 
CodeDead Administrator
https://codedead.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/2312d159/attachment.htm>

From kevin.rushforth at oracle.com  Thu Sep 15 16:11:13 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 15 Sep 2022 09:11:13 -0700
Subject: JavaFX 19 - Media object bug
In-Reply-To: <CAEN8YAHyhCzNOZS-Yc6gjT2KoMQxoVXkdMErn_7M5zxxJH-j2A@mail.gmail.com>
References: <CAEN8YAHyhCzNOZS-Yc6gjT2KoMQxoVXkdMErn_7M5zxxJH-j2A@mail.gmail.com>
Message-ID: <29936ebf-1f9c-572f-dc65-eeaf77c249ff@oracle.com>

This might be a regression introduced by the fix for 
https://bugs.openjdk.org/browse/JDK-8282054

Can you file a bug at https://bugreport.java.com/ ?

Maybe Alexander can comment further.

-- Kevin


On 9/15/2022 8:27 AM, Alessandro Mercier wrote:
> Hello all,
>
> After this commit:
> https://github.com/openjdk/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9
>
> Creating a new Media object using a MP3 file in the resources of a 
> project, you can get exceptions:
>
> Exception in thread "JavaFX Application Thread" MediaException: 
> MEDIA_UNSUPPORTED : Unrecognized file signature!
> at javafx.media at 20-ea/javafx.scene.media.Media.<init>(Media.java:411)
>
> At first glance, the error is in this Locator file in the JavaFX 
> source code:
> https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java
>
> *Steps to reproduce the bug:*
> 1. Create a new Media object and load an MP3 from the resources
> 2. Watch the Media object throw a MediaException: MEDIA_UNSUPPORTED : 
> Unrecognized file signature!
>
> *Example code that produces the bug:*
> final MediaPlayer mediaPlayer = new MediaPlayer(new 
> Media(getClass().getResource("/path/to/file.mp3").toExternalForm()));
>
> *Extra:*
> I've made a free MP3 file available to try with here (royalty free):
> https://codedead.com/static.mp3
>
> I've also got a GIT repository in which the exception occurs 
> immediately when running the Gradle task 'application':
> https://github.com/CodeDead/opal/tree/development (please make sure to 
> use the development branch as this branch makes use of the latest 
> JavaFX versions)
>
> Oddly enough, it does not always happen, and loading the file directly 
> from a file location instead of the project resources seems to work, 
> but when loading from the resources, you get the exception that the 
> media file signature is not recognized.
> I don't see a problem with the media files themselves, encoding is all 
> fine, at first glance and because it worked in JavaFX 18.0.2, creating 
> a Media object using a URI to a project resources location should work 
> in newer versions as well, I think. The same MP3 file does work when 
> you load it from the disk instead of the project?resources so this 
> makes it a bug, I believe.
>
> The work-around right now is to revert back to JavaFX version 18.0.2.
>
> *System / OS / Runtime info:*
> Linux Fedora 36
> 5.19.8-200.fc36.x86_64
> openjdk version "18.0.2" 2022-07-19
> OpenJDK Runtime Environment (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build 
> 18.0.2+9)
> OpenJDK 64-Bit Server VM (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build 
> 18.0.2+9, mixed mode, sharing)
>
> Thank you and kind regards
>
> Alessandro Mercier
> -- 
> CodeDead Administrator
> https://codedead.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/4a9d0703/attachment-0001.htm>

From administrator at codedead.com  Thu Sep 15 16:24:34 2022
From: administrator at codedead.com (Alessandro Mercier)
Date: Thu, 15 Sep 2022 18:24:34 +0200
Subject: JavaFX 19 - Media object bug
In-Reply-To: <29936ebf-1f9c-572f-dc65-eeaf77c249ff@oracle.com>
References: <CAEN8YAHyhCzNOZS-Yc6gjT2KoMQxoVXkdMErn_7M5zxxJH-j2A@mail.gmail.com>
 <29936ebf-1f9c-572f-dc65-eeaf77c249ff@oracle.com>
Message-ID: <CAEN8YAEFUA8MbCGvLH85jm-=eVnenES8G1hMwXJZfCjBoQNYHQ@mail.gmail.com>

Certainly,

A report has been filed.

Kind regards


On Thu, 15 Sep 2022, 18:11 Kevin Rushforth, <kevin.rushforth at oracle.com>
wrote:

> This might be a regression introduced by the fix for
> https://bugs.openjdk.org/browse/JDK-8282054
>
> Can you file a bug at https://bugreport.java.com/ ?
>
> Maybe Alexander can comment further.
>
> -- Kevin
>
>
> On 9/15/2022 8:27 AM, Alessandro Mercier wrote:
>
> Hello all,
>
> After this commit:
>
> https://github.com/openjdk/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9
>
> Creating a new Media object using a MP3 file in the resources of a
> project, you can get exceptions:
>
> Exception in thread "JavaFX Application Thread" MediaException:
> MEDIA_UNSUPPORTED : Unrecognized file signature!
> at javafx.media at 20-ea/javafx.scene.media.Media.<init>(Media.java:411)
>
> At first glance, the error is in this Locator file in the JavaFX source
> code:
>
> https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java
>
> *Steps to reproduce the bug:*
> 1. Create a new Media object and load an MP3 from the resources
> 2. Watch the Media object throw a MediaException: MEDIA_UNSUPPORTED :
> Unrecognized file signature!
>
> *Example code that produces the bug:*
> final MediaPlayer mediaPlayer = new MediaPlayer(new
> Media(getClass().getResource("/path/to/file.mp3").toExternalForm()));
>
> *Extra:*
> I've made a free MP3 file available to try with here (royalty free):
> https://codedead.com/static.mp3
>
> I've also got a GIT repository in which the exception occurs immediately
> when running the Gradle task 'application':
> https://github.com/CodeDead/opal/tree/development (please make sure to
> use the development branch as this branch makes use of the latest JavaFX
> versions)
>
> Oddly enough, it does not always happen, and loading the file directly
> from a file location instead of the project resources seems to work, but
> when loading from the resources, you get the exception that the media file
> signature is not recognized.
> I don't see a problem with the media files themselves, encoding is all
> fine, at first glance and because it worked in JavaFX 18.0.2, creating a
> Media object using a URI to a project resources location should work in
> newer versions as well, I think. The same MP3 file does work when you load
> it from the disk instead of the project resources so this makes it a bug, I
> believe.
>
> The work-around right now is to revert back to JavaFX version 18.0.2.
>
> *System / OS / Runtime info:*
> Linux Fedora 36
> 5.19.8-200.fc36.x86_64
> openjdk version "18.0.2" 2022-07-19
> OpenJDK Runtime Environment (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build
> 18.0.2+9)
> OpenJDK 64-Bit Server VM (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build
> 18.0.2+9, mixed mode, sharing)
>
> Thank you and kind regards
>
> Alessandro Mercier
> --
> CodeDead Administrator
> https://codedead.com/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/09b2e541/attachment.htm>

From johan.vos at gluonhq.com  Thu Sep 15 19:10:29 2022
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 15 Sep 2022 21:10:29 +0200
Subject: Virtual Flow enhancements
In-Reply-To: <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>
References: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
 <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>
Message-ID: <CABxFH2EYgJrhh7o2u9g2ct_M4gQmWJoqrBoG-pjKK6DzsB8eUg@mail.gmail.com>

On Tue, Sep 13, 2022 at 8:18 PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> For example, I scrolled my list so that the first Item is half visible
> (at the top), and the fifth item is a quarter visible (at the bottom)
> and I double click the 3rd item to go to a new screen (destroying the
> original list view in the process), I find there is no way to recreate
> the list view in the exact same state as it was before.
>

Great usecase.
Actually, this is possible already though with the current set of methods
exposed by VirtualFlow.
For example:

IndexedCell ic = getFirstVisibleCell()

gives you the first cell that is visible. You can ask its index, andwhen
you restore the list you scroll to that index.
By asking its layoutY() you know how it is positioned and you can invoke
scrollPixels(double) when you want to restore the list. If the height of
the items didn't change, the item at the bottom will still match the item
before you left the list.

Granted, this requires some boilerplate code. But unless I miss something,
there is in theory nothing that prevents doing this with the current set of
API's?

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/192d25fa/attachment.htm>

From johan.vos at gluonhq.com  Thu Sep 15 19:20:32 2022
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 15 Sep 2022 21:20:32 +0200
Subject: Virtual Flow enhancements
In-Reply-To: <3845162C-7988-45A2-A474-177286C3B343@gmail.com>
References: <CABxFH2EOROThmsj3hHJ2SOv9D1onydSG3FD9XByny4fMNc6Rkg@mail.gmail.com>
 <7b5d420e-c81d-6cfa-78b5-349562751269@gmail.com>
 <3845162C-7988-45A2-A474-177286C3B343@gmail.com>
Message-ID: <CABxFH2ECP6Zxwb1NEX7C6mFhD-wJ4WTPqPQqE5aXwo9-h_MMZQ@mail.gmail.com>

On Wed, Sep 14, 2022 at 12:19 PM Dirk Lemmermann <dlemmermann at gmail.com>
wrote:

> Hi,
>
>
> FlexGanttFX used to make this work via bidirectional bindings of the
> properties of the vertical scrollbars of both VirtualFlows. With the latest
> fixes to the VirtualFlow the assumption that two identically populated
> VirtualFlows would provide identical values to the ScrollBar properties is
> no longer true. The attempt to bind the ?position? property also failed and
> a work-around that Johan provided also has not been successful, yet (a
> customer of mine is still evaluating it).
>

I don't know what work-around you refer to, but I often point to public
methods in VirtualFlow that, when properly combined, allow many usecases. I
sometimes see code where the information about the positioning of elements
in the VirtualFlow is obtained via the position of the scrollbar thumb,
which seems a really odd way to get this info (and especially unreliable as
the relation with the real positioning of cells is unspecified). There are
other methods on VirtualFlow that imho are better suited for
getting/setting information.
What I want to avoid is that we have 2 API's that almost achieve the same.
Hence, before considering a new method or property, I think we should make
sure that there is currently no existing (documented) way to achieve it. I
am pretty sure there are cases that can not be solved with the existing set
of API's, and those cases are exactly what I'm looking for.

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220915/03c3d2f2/attachment-0001.htm>

From jvos at openjdk.org  Thu Sep 15 20:31:51 2022
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 15 Sep 2022 20:31:51 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
Message-ID: <nJWhWNgjU7Wzt1dZ02c-2I_79T9bKyix2F-Rtnqpi1E=.40ea66cd-a2af-43e4-9bdd-0dfc925e547a@github.com>

On Thu, 8 Sep 2022 07:26:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64

Marked as reviewed by jvos (Reviewer).

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

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

From angorya at openjdk.org  Thu Sep 15 21:18:30 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Sep 2022 21:18:30 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component causes
 memory leak
Message-ID: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>

Using Weak*Listeners eliminates the memory leak.

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

Commit messages:
 - 8293444: test
 - 8293444: using weak listeners

Changes: https://git.openjdk.org/jfx/pull/900/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=900&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293444
  Stats: 88 lines in 2 files changed: 75 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/900.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/900/head:pull/900

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

From angorya at openjdk.org  Thu Sep 15 22:01:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 15 Sep 2022 22:01:19 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
Message-ID: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>

Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.

Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?

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

Commit messages:
 - 8293883: added tests/.classpath

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

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

From aoqi at openjdk.org  Fri Sep 16 02:59:52 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Fri, 16 Sep 2022 02:59:52 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <jzRFSimra5S_oxIPGJENRsFx7fluTEwP58CFBDXGzNk=.3cff9624-b65a-4165-9905-aa918bc00962@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
 <jzRFSimra5S_oxIPGJENRsFx7fluTEwP58CFBDXGzNk=.3cff9624-b65a-4165-9905-aa918bc00962@github.com>
Message-ID: <lRL91tf8dXvH_pnBNeEaf7fbPur2GbQ8pIjToutFk3E=.86ad7d0f-dd28-44da-bd1e-374ce40c563e@github.com>

On Thu, 15 Sep 2022 13:31:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64
>
> It looks good. I'll do a build and then hopefully I can approve (those ifeq/ifneq changes often need more than a few pair of eyes)

@johanvos, thanks for the review!

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

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

From almatvee at openjdk.org  Fri Sep 16 03:04:52 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 16 Sep 2022 03:04:52 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
Message-ID: <kse-59GCzRn6FG8_5oydFKi0IGgPZdZXsYEVdK2sObw=.42a922d7-e534-432c-a736-a78f2824702e@github.com>

On Thu, 8 Sep 2022 07:26:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64

Marked as reviewed by almatvee (Reviewer).

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

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

From aghaisas at openjdk.org  Fri Sep 16 09:46:58 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 16 Sep 2022 09:46:58 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
Message-ID: <A01NdhHmctzFfog-iA7fg-kGTBZgVIpTmsobsNkT_iE=.bc00492a-4fd2-4c54-bbbb-f5e71a214475@github.com>

On Mon, 12 Sep 2022 15:33:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8089280.suppress' into 8089280.suppress
>  - 8089280: review comments

In general, the fix looks good.
I have observed missing spaces at few places in this fix. I will approve once these are fixed.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableSkinUtils.java line 213:

> 211: 
> 212:     /** returns true if the column resize policy is constrained */
> 213:     public static boolean isConstrainedResizePolicy(Callback<? extends ResizeFeaturesBase,Boolean> x) {

Minor : Need a space after `,`

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 899:

> 897: 
> 898:     void updateSuppressBreadthBar() {
> 899:         Callback<ResizeFeaturesBase,Boolean> p = TableSkinUtils.columnResizePolicyProperty(this).get();

Minor : Need a space after `,`

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java line 5953:

> 5951:         TableView<String> table = new TableView<>();
> 5952:         for (int i = 0; i < 10; i++) {
> 5953:             final TableColumn<String,String> c = new TableColumn<>("C" + i);

Minor : Need a space after `,`

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java line 7109:

> 7107:         TreeTableView<String> table = new TreeTableView<>();
> 7108:         for (int i = 0; i < 10; i++) {
> 7109:             TreeTableColumn<String,String> c = new TreeTableColumn<>("C" + i);

Minor : Need a space after `,`

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

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

From kcr at openjdk.org  Fri Sep 16 14:11:54 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 14:11:54 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
Message-ID: <0vym6kjrSovn5NSNqkzfBhsyeD2KWtgQPb-svu_BT5k=.a175335c-96d7-41ef-9dfd-0ea5ba36029a@github.com>

On Thu, 8 Sep 2022 07:26:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64

The changes look good. I'm doing a final sanity test on our CI system, and then I'll approve.

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

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

From kcr at openjdk.org  Fri Sep 16 15:18:02 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 15:18:02 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
 [v2]
In-Reply-To: <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <nlKgN1nsU3IAnnGftX4VzuHqk342WAiAvO_yCxSTlno=.14f136ed-211a-4bb0-bde8-bed5a140d7be@github.com>
Message-ID: <otQZ0NZQXV7MDCnOoLCSa-ylnxzL9u4Z3A5ZeWpNIEI=.88e4755f-5abc-4f92-8b54-5b4fcfe0d5b2@github.com>

On Thu, 15 Sep 2022 11:56:56 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
>> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
>> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
>> internally, or to document is users CAN NOT rely on runLater for this.
>> 
>> This change documents that actions in a thread prior to submitting a runnable to
>> Platform#runLater happen-before actions performed by the runnable in the JavaFX
>> Application Thread.
>> 
>> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
>> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
>> in the same way as it is documented by BlockingDeque.
>> 
>> Other implementations of runLater should have similar memory consistency effects.
>
> Jens Lidestrom has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use code formatting for 'runnable'

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From kcr at openjdk.org  Fri Sep 16 15:53:10 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 15:53:10 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
Message-ID: <quPWRri3GBPnBs2RjEXvrYGQn4TnuDqLdYVmkuBeMsc=.2ac9cdf1-242b-44a5-b0e7-33ba8c0423ba@github.com>

On Thu, 8 Sep 2022 07:26:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
>> 
>> Testing:
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
>> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
>> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64

Marked as reviewed by kcr (Lead).

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

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

From aoqi at openjdk.org  Fri Sep 16 16:04:53 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Fri, 16 Sep 2022 16:04:53 GMT
Subject: RFR: 8293214: Add support for Linux/LoongArch64 [v4]
In-Reply-To: <0vym6kjrSovn5NSNqkzfBhsyeD2KWtgQPb-svu_BT5k=.a175335c-96d7-41ef-9dfd-0ea5ba36029a@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
 <UpyDbVchf50k0X_R_ausPWiAXRgrfo3vqREOr2CESjM=.495e0fee-1bca-4ad4-b0f4-e68652ff94c9@github.com>
 <0vym6kjrSovn5NSNqkzfBhsyeD2KWtgQPb-svu_BT5k=.a175335c-96d7-41ef-9dfd-0ea5ba36029a@github.com>
Message-ID: <uE0Ro16irjiqrM2haKps-T4_jTdN9SE9_tn9VTKB9WI=.795e9b24-a089-4a38-a114-11695e7a4bfc@github.com>

On Fri, 16 Sep 2022 14:09:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   disable msse2 by default, use IS_LOONGARCH64 and IS_AARCH64
>
> The changes look good. I'm doing a final sanity test on our CI system, and then I'll approve.

@kevinrushforth, thanks!

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

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

From angorya at openjdk.org  Fri Sep 16 16:09:55 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 16:09:55 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <A01NdhHmctzFfog-iA7fg-kGTBZgVIpTmsobsNkT_iE=.bc00492a-4fd2-4c54-bbbb-f5e71a214475@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
 <A01NdhHmctzFfog-iA7fg-kGTBZgVIpTmsobsNkT_iE=.bc00492a-4fd2-4c54-bbbb-f5e71a214475@github.com>
Message-ID: <NBzI7wOK1JldnKWu-MjubBbJy-R4PFzQ-5S41UyX24s=.d75a7c07-fbda-47ae-8848-a8ab4341db10@github.com>

On Fri, 16 Sep 2022 09:40:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/8089280.suppress' into 8089280.suppress
>>  - 8089280: review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableSkinUtils.java line 213:
> 
>> 211: 
>> 212:     /** returns true if the column resize policy is constrained */
>> 213:     public static boolean isConstrainedResizePolicy(Callback<? extends ResizeFeaturesBase,Boolean> x) {
> 
> Minor : Need a space after `,`

will do.

I do not like inconsistency: everywhere else in this file there is no space after comma in type parameters, for example
```TableViewSkinBase<?,?,?,?,?>```
so, if one were to use a formatter, it will format to 
```TableViewSkinBase<?, ?, ?, ?, ?>```

which will look weird.

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

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

From aoqi at openjdk.org  Fri Sep 16 16:11:54 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Fri, 16 Sep 2022 16:11:54 GMT
Subject: Integrated: 8293214: Add support for Linux/LoongArch64
In-Reply-To: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
References: <docQCZnGBde5weuA4YlUJioicvY53FujcSU6zkoIjPI=.711cb7aa-6798-4435-bb23-af875c576114@github.com>
Message-ID: <izRuEZkytwALKyJsKA1UhWpqk213lUzGJqaUyxtIsGY=.e15d2473-ff30-49f0-9b9d-97c75294332d@github.com>

On Thu, 1 Sep 2022 12:19:23 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> LoongArch is a new RISC ISA. This issue proposes adding support for Linux/LoongArch64. Upstream WebKit for LoongArch64 support is not ready, but the OpenJFX part is simple and ready. When the LoongArch64 supported Webkit is updated to OpenJFX, it is supposed to work.
> 
> Testing:
> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/x64
> - [x] base, controls, fxml, graphics and web tests, {Release,Debug}, {with WebKit,without Webkit} on Linux/aarch64
> - [x] base, controls, fxml and graphics tests, {Release,Debug}, without WebKit on Linux/loongarch64

This pull request has now been integrated.

Changeset: cef583ee
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/cef583eef41aff3db55542d5e90423eec5601f41
Stats:     26 lines in 4 files changed: 15 ins; 0 del; 11 mod

8293214: Add support for Linux/LoongArch64

Reviewed-by: almatvee, jvos, kcr

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

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

From angorya at openjdk.org  Fri Sep 16 16:13:57 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 16:13:57 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v4]
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <hxWmEP6Gm2m3_m1E8BhMSAnSsqF32rggiEQTV9GonP8=.219330a4-033b-44d4-8be9-a160c7b05b92@github.com>

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8089280: spaces in type parameters

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/894/files
  - new: https://git.openjdk.org/jfx/pull/894/files/bf4aac22..52e48c48

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

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

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

From angorya at openjdk.org  Fri Sep 16 16:13:58 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 16:13:58 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
Message-ID: <xZFDaE2Q0isvJF-rh4SKmw6Hnul_ftPORncI8R2OHsk=.e53129c5-41ec-47db-9f65-97c6a26e688e@github.com>

On Mon, 12 Sep 2022 15:33:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8089280.suppress' into 8089280.suppress
>  - 8089280: review comments

thank you.
added spaces to type parameters.
updated Eclipse formatter rules.

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

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

From kcr at openjdk.org  Fri Sep 16 16:20:04 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 16:20:04 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v4]
In-Reply-To: <hxWmEP6Gm2m3_m1E8BhMSAnSsqF32rggiEQTV9GonP8=.219330a4-033b-44d4-8be9-a160c7b05b92@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <hxWmEP6Gm2m3_m1E8BhMSAnSsqF32rggiEQTV9GonP8=.219330a4-033b-44d4-8be9-a160c7b05b92@github.com>
Message-ID: <L3s8Ta6Vmo3BRySF42cik6ycPFVglqoRB63X_iNSPH4=.bed4245e-c598-4ec9-9d69-e34c380eb1ef@github.com>

On Fri, 16 Sep 2022 16:13:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8089280: spaces in type parameters

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.org  Fri Sep 16 16:20:04 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 16:20:04 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <NBzI7wOK1JldnKWu-MjubBbJy-R4PFzQ-5S41UyX24s=.d75a7c07-fbda-47ae-8848-a8ab4341db10@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
 <A01NdhHmctzFfog-iA7fg-kGTBZgVIpTmsobsNkT_iE=.bc00492a-4fd2-4c54-bbbb-f5e71a214475@github.com>
 <NBzI7wOK1JldnKWu-MjubBbJy-R4PFzQ-5S41UyX24s=.d75a7c07-fbda-47ae-8848-a8ab4341db10@github.com>
Message-ID: <KKL-DmV_xYi1H-8R6otJ7Gl_SUvyeoxSDg1uykyTBHw=.acf42ed2-aeb2-4cdf-b95c-1e20a26a4008@github.com>

On Fri, 16 Sep 2022 16:06:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> will do.

just this one, though. Please don't reformat any others that you aren't otherwise touching.

And yes, it is an area where we are inconsistent (it varies from file to file and often within the same file).

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

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

From angorya at openjdk.org  Fri Sep 16 16:20:04 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 16:20:04 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v3]
In-Reply-To: <KKL-DmV_xYi1H-8R6otJ7Gl_SUvyeoxSDg1uykyTBHw=.acf42ed2-aeb2-4cdf-b95c-1e20a26a4008@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <-wZl9eHErxEy_QGdJ8wS9M46Cij725QsVHa7PEUoVnw=.87cd0b6f-1d7d-431c-a1d8-c895960ed6fd@github.com>
 <A01NdhHmctzFfog-iA7fg-kGTBZgVIpTmsobsNkT_iE=.bc00492a-4fd2-4c54-bbbb-f5e71a214475@github.com>
 <NBzI7wOK1JldnKWu-MjubBbJy-R4PFzQ-5S41UyX24s=.d75a7c07-fbda-47ae-8848-a8ab4341db10@github.com>
 <KKL-DmV_xYi1H-8R6otJ7Gl_SUvyeoxSDg1uykyTBHw=.acf42ed2-aeb2-4cdf-b95c-1e20a26a4008@github.com>
Message-ID: <EPt23CPbfCf6gV-X16X43uiJvMq68VSTasqiu1C2Its=.daa8c6ce-68b0-460b-be3a-200bbb2381c6@github.com>

On Fri, 16 Sep 2022 16:14:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> will do.
>> 
>> I do not like inconsistency: everywhere else in this file there is no space after comma in type parameters, for example
>> ```TableViewSkinBase<?,?,?,?,?>```
>> so, if one were to use a formatter, it will format to 
>> ```TableViewSkinBase<?, ?, ?, ?, ?>```
>> 
>> which will look weird.
>
>> will do.
> 
> just this one, though. Please don't reformat any others that you aren't otherwise touching.
> 
> And yes, it is an area where we are inconsistent (it varies from file to file and often within the same file).

certainly, I am not going to touch the rest of the code.

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

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

From aghaisas at openjdk.org  Fri Sep 16 16:24:51 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 16 Sep 2022 16:24:51 GMT
Subject: RFR: 8089280: horizontal scrollbar should never become visible in
 TableView with constrained resize policy [v4]
In-Reply-To: <hxWmEP6Gm2m3_m1E8BhMSAnSsqF32rggiEQTV9GonP8=.219330a4-033b-44d4-8be9-a160c7b05b92@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
 <hxWmEP6Gm2m3_m1E8BhMSAnSsqF32rggiEQTV9GonP8=.219330a4-033b-44d4-8be9-a160c7b05b92@github.com>
Message-ID: <JaEmEmv0NwbdYTr0GKrL8boCpkOX3pKt_1vxk8933Ww=.2633e045-644b-4809-b6f1-5e85f4665d40@github.com>

On Fri, 16 Sep 2022 16:13:57 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8089280: spaces in type parameters

Marked as reviewed by aghaisas (Reviewer).

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

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

From angorya at openjdk.org  Fri Sep 16 16:39:55 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 16:39:55 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v10]
In-Reply-To: <eEnt_H44uiYl-BE-BOM8WHu3T_Ya_JGfkblJIMnCrkE=.bd666284-5726-46fc-b1fd-7b8e63a55540@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <avhL8FhRhmuoT3C3nvYYq-rPhYkDccpAubD4wcSf0XY=.4c3a980d-9e3b-47f9-858e-f2249eb8f707@github.com>
 <sh7sy1g-8EcbOtFUoMrH1zFMNWtAZMVCTGABj95OZEA=.5311f24f-5ef3-4ec7-931d-b359f2220b3c@github.com>
 <dDMtKBkQf6yiQsHssHIXzPNoX6T0d5X3j3spPEjo_nw=.1d537cef-ee9a-489e-bff0-ccd0ff1e4494@github.com>
 <eEnt_H44uiYl-BE-BOM8WHu3T_Ya_JGfkblJIMnCrkE=.bd666284-5726-46fc-b1fd-7b8e63a55540@github.com>
Message-ID: <OvP_fJCai2vbKud9uqjzUts-JiO4e1ntl6v8X8S1qyE=.db6c6475-f2ae-4100-9f55-152658fb79f1@github.com>

On Wed, 14 Sep 2022 10:32:19 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Is it possible to have two or more rows with the same row index?  i would imagine that will break a lot of things.
>> 
>> I am not sure why you think the lookup is brittle - after all, VirtualFlowTestUtils uses lookup to get a pointer to the VirtualFlow, is it not (line 333)?  Is it because the lookup may not return a cell if it is outside of the current view port area and therefore has not been created (while the .getCell() guarantees to create one)? 
>> 
>> Is this the only objection to the changes in this PR?  I suppose i could change the tests to use VirtualFlowTestUtils, though my preference would be still to test close to the real world scenario, using public APIs (as opposed to getting into internals using some internal test utils), given the fact that I *do* expect these cells to be visible given the dimensions of the table and columns.
>
>> Is it possible to have two or more rows with the same row index? i would imagine that will break a lot of things.
> 
> don't imagine, verify ;) What happens when you run the test? What happens when you look at the scenegraph (f.i. with ScenicView)? Don't know why they are there but they are - well outside the viewport.
> 
>> 
>> Is this the only objection to the changes in this PR?
> 
> I honestly cannot understand how you possibly could have reached the conclusion that this is the _only_ objection given my comments .. 
> 
> Anyway, I'm off here - don't know how to abort a review, but not going to waste more time and nerves on who doesn't seem to listen (that's my personal feeling, of course ;)

sorry, what I really meant is - are the code changes ok and we are only discussing updating tests?

my goal here is to fix as many bugs as I possibly can, while listening to the feedback of more experienced team members and addressing their concerns.  it is not always clear when an exchange of ideas ends and marching orders begin, especially in situations where several possibilities exist.  perhaps a clearly annunciated request for specific changes would work?

I feel really uncomfortable with thousands of defects logged against openjfx, and all I want is to help.

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

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

From angorya at openjdk.org  Fri Sep 16 16:42:56 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 16:42:56 GMT
Subject: Integrated: 8089280: horizontal scrollbar should never become visible
 in TableView with constrained resize policy
In-Reply-To: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
References: <HwoLGK7YxwevG6PZORJrZajq9dg081QJvpr9VjsjJVE=.fc8228ba-d5b8-4f45-9d2f-8fa2ec19745b@github.com>
Message-ID: <x-jUFPHbHzXOtzgLACjptmVM-E1BxkdJp2fnbX0tN1E=.e6c46372-95fd-4b00-83ab-40310e0f862b@github.com>

On Fri, 9 Sep 2022 21:13:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the tree/table view internals to suppress the horizontal (a.k.a. breadth in VirtualFlow) scroll bar when a constrained resize mode is in effect.  This change complements fixes added in [JDK-8089009](https://bugs.openjdk.org/browse/JDK-8089009) without addressing other bugs found in https://bugs.openjdk.org/browse/JDK-8292810

This pull request has now been integrated.

Changeset: 5e4552db
Author:    Andy Goryachev <angorya at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5e4552db7389d93829e6ecfc61936ccad75c56c2
Stats:     183 lines in 7 files changed: 122 ins; 44 del; 17 mod

8089280: horizontal scrollbar should never become visible in TableView with constrained resize policy

Reviewed-by: kcr, aghaisas

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

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

From kcr at openjdk.org  Fri Sep 16 16:46:51 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 16:46:51 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening [v2]
In-Reply-To: <JICpGZbZiRGYcF1sF-4PmZN4_jaQuV9a9qo5_82xOMI=.47ca3578-91fe-4630-9db2-3d284d054c9b@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
 <yvl_c7QeKLnRTgYgTBSi9berZZOe38BUAjNpuTWH6FA=.defc363a-41ff-401b-9514-55b6aa752ef8@github.com>
 <JICpGZbZiRGYcF1sF-4PmZN4_jaQuV9a9qo5_82xOMI=.47ca3578-91fe-4630-9db2-3d284d054c9b@github.com>
Message-ID: <a0TrEfvMEe3yUg93_Tbtf2hPfVF2MaKiKLr0d-cZjQs=.37304faf-88df-43d2-8fac-0fc33410861a@github.com>

On Mon, 5 Sep 2022 18:17:19 GMT, Alex <duke at openjdk.org> wrote:

>> @sashashura You need to enable running GHA workflows in your personal fork of the `jfx` repo. Given that you are changing the GHA workflow, we will need to see the results from your run in this PR.
>
>> @sashashura You need to enable running GHA workflows in your personal fork of the `jfx` repo. Given that you are changing the GHA workflow, we will need to see the results from your run in this PR.
> 
> https://github.com/sashashura/jfx/actions/runs/2995229526

@sashashura this is ready for you to `/integrate`

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

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

From kcr at openjdk.org  Fri Sep 16 16:52:55 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 16:52:55 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <xIegXIfwGNpc7lQ1XNrDWoIH2ZGEnWyo-UgNAU6goJE=.59761cd6-da9f-4b09-9f93-93509c99645f@github.com>

On Thu, 15 Sep 2022 21:55:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?

That should probably be done via a separate cleanup bug, since it is outside the scope of this IDE-only fix. It would make sense to at least look at all of the manual tests (since they all exist in the unnamed package), even if you want to limit the scope of the follow-on bug to the manual controls tests.

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

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

From duke at openjdk.org  Fri Sep 16 17:15:48 2022
From: duke at openjdk.org (Alex)
Date: Fri, 16 Sep 2022 17:15:48 GMT
Subject: RFR: 8293368: GitHub Workflows security hardening [v2]
In-Reply-To: <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
 <GVq6_BUuDheAwWFTsHVBwBtsn8vUiCOi_jtT2qKTHZ8=.1b4ccb13-9daf-4e5d-8265-75090defc471@github.com>
Message-ID: <g6VF-bttTQgmMjrlZB52vx-VNe_i-TaeOEA0LgMn5bo=.dfe27044-770a-4ec4-8010-5a109fdc7dfd@github.com>

On Wed, 7 Sep 2022 11:27:02 GMT, Alex <duke at openjdk.org> wrote:

>> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
>> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.
>
> Alex has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into patch-1
>  - Update submit.yml
>    
>    Signed-off-by: sashashura <93376818+sashashura at users.noreply.github.com>

Thanks, I missed that the ball in on my side.

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

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

From duke at openjdk.org  Fri Sep 16 17:21:50 2022
From: duke at openjdk.org (Alex)
Date: Fri, 16 Sep 2022 17:21:50 GMT
Subject: Integrated: 8293368: GitHub Workflows security hardening
In-Reply-To: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
References: <GrYlMzeWCyC7Ts2jQm4VWJez0gseieQDXptMtHlUb30=.0fbec6fd-8ddb-40d3-9e0b-e48bed7fb656@github.com>
Message-ID: <8CUdtUehv2Ujk8zW42YZlGAky5RxEmHLtfmZYBGyKXo=.23944c8a-4183-44d9-be8d-38e5d9af4122@github.com>

On Thu, 1 Sep 2022 20:37:27 GMT, Alex <duke at openjdk.org> wrote:

> This PR adds explicit [permissions section](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions) to workflows. This is a security best practice because by default workflows run with [extended set of permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) (except from `on: pull_request` [from external forks](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an [injection](https://securitylab.github.com/research/github-actions-untrusted-input/) or compromised third party tool or action) is restricted.
> It is recommended to have [most strict permissions on the top level](https://github.com/ossf/scorecard/blob/main/docs/checks.md#token-permissions) and grant write permissions on [job level](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) case by case.

This pull request has now been integrated.

Changeset: a27840e8
Author:    sashashura <93376818+sashashura at users.noreply.github.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a27840e8fd7e79b1692488e4de7f6f5fdb930cf4
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8293368: GitHub Workflows security hardening

Reviewed-by: kcr, arapte

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

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

From kcr at openjdk.org  Fri Sep 16 17:41:56 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 16 Sep 2022 17:41:56 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak
In-Reply-To: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
Message-ID: <CFfQwdhS7iM0YerAgKzkt7_cNhHnOAKJV4rqUhFG3EY=.92db469d-ef1c-42b6-974c-7a308c990491@github.com>

On Thu, 15 Sep 2022 17:12:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Weak*Listeners eliminates the memory leak.

This looks like it will eliminate the leak. Using weak listeners like this follows the same pattern as used by some of the other skins. I'll review and test it next week.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 916:

> 914:     }
> 915: 
> 916:     // this should be in common test utils

There already is one that you can use, [JMemoryBuddy](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java).

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

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

From angorya at openjdk.org  Fri Sep 16 18:04:07 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 18:04:07 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
Message-ID: <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>

> Using Weak*Listeners eliminates the memory leak.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8293444: memory buddy

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/900/files
  - new: https://git.openjdk.org/jfx/pull/900/files/b6316bbb..02330d09

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

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

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

From angorya at openjdk.org  Fri Sep 16 18:04:08 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 16 Sep 2022 18:04:08 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <CFfQwdhS7iM0YerAgKzkt7_cNhHnOAKJV4rqUhFG3EY=.92db469d-ef1c-42b6-974c-7a308c990491@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <CFfQwdhS7iM0YerAgKzkt7_cNhHnOAKJV4rqUhFG3EY=.92db469d-ef1c-42b6-974c-7a308c990491@github.com>
Message-ID: <99ntLM0hwx5Uc-g2I0DG59vrwZEtqKEUaTe68UYdJ1w=.e6e9ec65-fe45-4237-a2a1-6bfc91e3507c@github.com>

On Fri, 16 Sep 2022 16:52:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293444: memory buddy
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 916:
> 
>> 914:     }
>> 915: 
>> 916:     // this should be in common test utils
> 
> There already is one that you can use, [JMemoryBuddy](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/test/java/test/util/memory/JMemoryBuddy.java).

.checkCollectable(), thanks!

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

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

From kevin.rushforth at oracle.com  Sat Sep 17 13:56:12 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 17 Sep 2022 06:56:12 -0700
Subject: [External] : Re: JavaFX 19 - Media object bug
In-Reply-To: <CAEN8YAGQvMzsZ9T0HRYn1Aomt9sRkhXgYCCU8H5vS-P8KnLFZQ@mail.gmail.com>
References: <CAEN8YAHyhCzNOZS-Yc6gjT2KoMQxoVXkdMErn_7M5zxxJH-j2A@mail.gmail.com>
 <29936ebf-1f9c-572f-dc65-eeaf77c249ff@oracle.com>
 <CAEN8YAEFUA8MbCGvLH85jm-=eVnenES8G1hMwXJZfCjBoQNYHQ@mail.gmail.com>
 <CAEN8YAGQvMzsZ9T0HRYn1Aomt9sRkhXgYCCU8H5vS-P8KnLFZQ@mail.gmail.com>
Message-ID: <e30d2a9c-501b-ff99-8a14-1b868b547f82@oracle.com>

Looks like there was a little delay in processing it, so I moved it to 
the JDK project myself. It is available here:

https://bugs.openjdk.org/browse/JDK-8293971

I've also added the additional information you sent below to the bug report.

-- Kevin


On 9/16/2022 6:35 PM, Alessandro Mercier wrote:
> Little update:
>
> Filed a bug report at bugreport.java.com 
> <https://urldefense.com/v3/__http://bugreport.java.com__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhn2-IgnQ$> 
> a couple of days ago but it has not been created yet.
> In the in between time I found that this line in the JFX source is 
> responsible for the bug:
> https://github.com/openjdk/jfx/blob/d1110f479567c314ecb6848700bcf4552509d7e9/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java#L622 
> <https://urldefense.com/v3/__https://github.com/openjdk/jfx/blob/d1110f479567c314ecb6848700bcf4552509d7e9/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java*L622__;Iw!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhUNLCS7A$>
>
> Sample code:
>
> package org.example;
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.layout.StackPane;
> import javafx.scene.media.Media;
> import javafx.scene.media.MediaPlayer;
> import javafx.stage.Stage;
>
> import java.net.URISyntaxException;
>
> public class Main extends Application {
> ? ? public static void main(String[] args) {
> ? ? ? ? launch(args);
> ? ? }
>
> ? ? @Override
> ? ? public void start(final Stage primaryStage) throws 
> URISyntaxException {
> ? ? ? ? final StackPane root = new StackPane();
> ? ? ? ? primaryStage.setScene(new Scene(root, 300, 250));
> ? ? ? ? primaryStage.show();
>
> ? ? ? ? final MediaPlayer player1 = new MediaPlayer(new 
> Media(getClass().getResource("/static.mp3").toURI().toString()));
> ? ? ? ? player1.setAutoPlay(true);
> ? ? }
> }
>
> MP3:
> https://codedead.com/static.mp3 
> <https://urldefense.com/v3/__https://codedead.com/static.mp3__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhb65LOH4$> 
> (royalty free)
>
> Occurrence:
> 100% of the time
>
> Kind regards,
>
> Alessandro Mercier
>
> Op do 15 sep. 2022 om 18:24 schreef Alessandro Mercier 
> <administrator at codedead.com>:
>
>     Certainly,
>
>     A report has been filed.
>
>     Kind regards
>
>
>     On Thu, 15 Sep 2022, 18:11 Kevin Rushforth,
>     <kevin.rushforth at oracle.com> wrote:
>
>         This might be a regression introduced by the fix for
>         https://bugs.openjdk.org/browse/JDK-8282054
>
>         Can you file a bug at https://bugreport.java.com/
>         <https://urldefense.com/v3/__https://bugreport.java.com/__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhkXAhSI4$>
>         ?
>
>         Maybe Alexander can comment further.
>
>         -- Kevin
>
>
>         On 9/15/2022 8:27 AM, Alessandro Mercier wrote:
>>         Hello all,
>>
>>         After this commit:
>>         https://github.com/openjdk/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9
>>         <https://urldefense.com/v3/__https://github.com/openjdk/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhZtzPsZM$>
>>
>>         Creating a new Media object using a MP3 file in the resources
>>         of a project, you can get exceptions:
>>
>>         Exception in thread "JavaFX Application Thread"
>>         MediaException: MEDIA_UNSUPPORTED : Unrecognized file signature!
>>         at
>>         javafx.media at 20-ea/javafx.scene.media.Media.<init>(Media.java:411)
>>
>>         At first glance, the error is in this Locator file in the
>>         JavaFX source code:
>>         https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java
>>         <https://urldefense.com/v3/__https://github.com/openjdk/jfx/blob/master/modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhb7Gu6w0$>
>>
>>         *Steps to reproduce the bug:*
>>         1. Create a new Media object and load an MP3 from the resources
>>         2. Watch the Media object throw a MediaException:
>>         MEDIA_UNSUPPORTED : Unrecognized file signature!
>>
>>         *Example code that produces the bug:*
>>         final MediaPlayer mediaPlayer = new MediaPlayer(new
>>         Media(getClass().getResource("/path/to/file.mp3").toExternalForm()));
>>
>>         *Extra:*
>>         I've made a free MP3 file available to try with here (royalty
>>         free):
>>         https://codedead.com/static.mp3
>>         <https://urldefense.com/v3/__https://codedead.com/static.mp3__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhb65LOH4$>
>>
>>         I've also got a GIT repository in which the exception occurs
>>         immediately when running the Gradle task 'application':
>>         https://github.com/CodeDead/opal/tree/development
>>         <https://urldefense.com/v3/__https://github.com/CodeDead/opal/tree/development__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdha9sC5sE$>
>>         (please make sure to use the development branch as this
>>         branch makes use of the latest JavaFX versions)
>>
>>         Oddly enough, it does not always happen, and loading the file
>>         directly from a file location instead of the project
>>         resources seems to work, but when loading from the resources,
>>         you get the exception that the media file signature is not
>>         recognized.
>>         I don't see a problem with the media files themselves,
>>         encoding is all fine, at first glance and because it worked
>>         in JavaFX 18.0.2, creating a Media object using a URI to a
>>         project resources location should work in newer versions as
>>         well, I think. The same MP3 file does work when you load it
>>         from the disk instead of the project?resources so this makes
>>         it a bug, I believe.
>>
>>         The work-around right now is to revert back to JavaFX version
>>         18.0.2.
>>
>>         *System / OS / Runtime info:*
>>         Linux Fedora 36
>>         5.19.8-200.fc36.x86_64
>>         openjdk version "18.0.2" 2022-07-19
>>         OpenJDK Runtime Environment
>>         (Red_Hat-18.0.2.0.9-1.rolling.fc36) (build 18.0.2+9)
>>         OpenJDK 64-Bit Server VM (Red_Hat-18.0.2.0.9-1.rolling.fc36)
>>         (build 18.0.2+9, mixed mode, sharing)
>>
>>         Thank you and kind regards
>>
>>         Alessandro Mercier
>>         -- 
>>         CodeDead Administrator
>>         https://codedead.com/
>>         <https://urldefense.com/v3/__https://codedead.com/__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhCBUBA2g$>
>>
>
>
>
> -- 
> CodeDead Administrator
> https://codedead.com/ 
> <https://urldefense.com/v3/__https://codedead.com/__;!!ACWV5N9M2RV99hQ!OeWMVVpaLY2NEWr0uLfT_Z4m_fQyPCpg1VoPzXGJVl4B5NYW5UHkW4FF1w7Q22gqI2nX6OWhogndXvvg6gsuYwdhCBUBA2g$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220917/5a51e28d/attachment-0001.htm>

From arapte at openjdk.org  Mon Sep 19 11:45:53 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 19 Sep 2022 11:45:53 GMT
Subject: RFR: 8254676: Alert disables Tab selection when TabDragPolicy
 REORDER is used
In-Reply-To: <M_UldTEZfn072rPUS8OvvUfEOv_PbDZi4K7xrbEHJ0Q=.944ed2b9-fd84-4d0f-ae10-5d680ef605c9@github.com>
References: <M_UldTEZfn072rPUS8OvvUfEOv_PbDZi4K7xrbEHJ0Q=.944ed2b9-fd84-4d0f-ae10-5d680ef605c9@github.com>
Message-ID: <zmKf2JzkT5VNQGNUo7waznl9JctUXrLdV8HF6l9-IQg=.e41ca2b3-94cc-4bc5-8a6a-bd704d5091f2@github.com>

On Sun, 11 Sep 2022 12:13:47 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Don't set TabHeader to mouseTransparent, since it might get stuck in that state (e.g. in case an Alert is shown).
> The TabPaneSkin deals with the dragging internally, and does not require the dragged node to be mouseTransparent.

The fix looks good to me. Testing looks good.
But I am not sure why I had included this call at the time of implementation.
Requesting @kevinrushforth to take a look.

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

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

From kevin.rushforth at oracle.com  Mon Sep 19 13:01:46 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Sep 2022 06:01:46 -0700
Subject: Opacity elements broken for svg
In-Reply-To: <d2593885-bab1-ceaf-bb3e-f56ffd199c1b@freigmbh.de>
References: <d2593885-bab1-ceaf-bb3e-f56ffd199c1b@freigmbh.de>
Message-ID: <d68e858f-12e6-618e-0020-2ebbad8fcf71@oracle.com>

This belongs on the openjfx-dev list, so I'm rerouting it (I Bcc'ed 
openjfx-discuss)

I haven't heard other reports of https://bugreport.java.com being 
broken, but I can file the bug for you.

-- Kevin


On 9/19/2022 5:47 AM, Thorsten wrote:
> Hello
>
> This is a bug report that should go through 
> https://bugreport.java.com/ , however the bug report site only gives 
> me 'Access Denied You don't have permission to access 
> "http://splash.oracle.com/bugreport/submit_start.do?" on this server.' 
> whenever I hit submit. Is it broken for everyone or did I get 
> blacklisted?
>
> So since openjx 18 using opacity="<value>" will just behave like 
> opacity was set to 1. -> In the Example: two black circles instead of 
> one black and one teal circle. Version 17.0.2 works fine
>
> Example svg was taken from 
> https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/opacity
>
> Best regards,
>
> Thorsten Goetzke
>
>
>
> package com.example.demo;
>
> import javafx.application.Application;
> import javafx.scene.Scene;
> import javafx.scene.web.WebView;
> import javafx.stage.Stage;
>
>
> public class HelloApplication extends Application {
> ??? @Override
> ??? public void start(Stage stage) {
> ??????? final WebView webView = new WebView();
> ??????? final String svg = "<svg viewBox=\"0 0 200 100\" 
> xmlns=\"http://www.w3.org/2000/svg\">\n" + "? <defs>\n" + "??? 
> <linearGradient id=\"gradient\" x1=\"0%\" y1=\"0%\" x2=\"0\" 
> y2=\"100%\">\n" + "????? <stop offset=\"0%\" 
> style=\"stop-color:skyblue;\" />\n" + "????? <stop offset=\"100%\" 
> style=\"stop-color:seagreen;\" />\n" + " </linearGradient>\n" + "? 
> </defs>\n" + "? <rect x=\"0\" y=\"0\" width=\"100%\" height=\"100%\" 
> fill=\"url(#gradient)\" />\n" + "? <circle cx=\"50\" cy=\"50\" 
> r=\"40\" fill=\"black\" />\n" + "? <circle id=\"circle\" cx=\"150\" 
> cy=\"50\" r=\"40\" fill=\"black\" opacity=\"0.3\" />\n" + "</svg>\n";
> ??????? webView.getEngine().loadContent(svg);
> ??????? stage.setScene(new Scene(webView));
> ??????? stage.show();
> ??? }
>
>
> ??? public static void main(String[] args) {
> ??????? launch();
> ??? }
> }
>


From kevin.rushforth at oracle.com  Mon Sep 19 13:18:05 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Sep 2022 06:18:05 -0700
Subject: [External] : Re: Opacity elements broken for svg
In-Reply-To: <083d2991-5407-3f7b-cb76-7e531190c130@freigmbh.de>
References: <d2593885-bab1-ceaf-bb3e-f56ffd199c1b@freigmbh.de>
 <d68e858f-12e6-618e-0020-2ebbad8fcf71@oracle.com>
 <083d2991-5407-3f7b-cb76-7e531190c130@freigmbh.de>
Message-ID: <0bd9d238-c06d-3f06-2656-fc4bcbfdad48@oracle.com>

Filed here:

https://bugs.openjdk.org/browse/JDK-8294011

-- Kevin

On 9/19/2022 6:08 AM, Thorsten wrote:
> Much appreciated
>
> Am 19/09/2022 um 15:01 schrieb Kevin Rushforth:
>> This belongs on the openjfx-dev list, so I'm rerouting it (I Bcc'ed 
>> openjfx-discuss)
>>
>> I haven't heard other reports of 
>> https://urldefense.com/v3/__https://bugreport.java.com__;!!ACWV5N9M2RV99hQ!OYK4yY--gIMjdd22lb2UY6go0MqS4H_7hStQVu24I6NFYwqm7wbCYhOodgM915n2zG5FJOnOB87WaU9GBg$ 
>> being broken, but I can file the bug for you.
>>
>> -- Kevin
>>
>>
>> On 9/19/2022 5:47 AM, Thorsten wrote:
>>> Hello
>>>
>>> This is a bug report that should go through 
>>> https://urldefense.com/v3/__https://bugreport.java.com/__;!!ACWV5N9M2RV99hQ!OYK4yY--gIMjdd22lb2UY6go0MqS4H_7hStQVu24I6NFYwqm7wbCYhOodgM915n2zG5FJOnOB84K-XLUsw$ 
>>> , however the bug report site only gives me 'Access Denied You don't 
>>> have permission to access 
>>> "http://splash.oracle.com/bugreport/submit_start.do?" on this 
>>> server.' whenever I hit submit. Is it broken for everyone or did I 
>>> get blacklisted?
>>>
>>> So since openjx 18 using opacity="<value>" will just behave like 
>>> opacity was set to 1. -> In the Example: two black circles instead 
>>> of one black and one teal circle. Version 17.0.2 works fine
>>>
>>> Example svg was taken from 
>>> https://urldefense.com/v3/__https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/opacity__;!!ACWV5N9M2RV99hQ!OYK4yY--gIMjdd22lb2UY6go0MqS4H_7hStQVu24I6NFYwqm7wbCYhOodgM915n2zG5FJOnOB84aLGIXnQ$ 
>>>
>>> Best regards,
>>>
>>> Thorsten Goetzke
>>>
>>>
>>>
>>> package com.example.demo;
>>>
>>> import javafx.application.Application;
>>> import javafx.scene.Scene;
>>> import javafx.scene.web.WebView;
>>> import javafx.stage.Stage;
>>>
>>>
>>> public class HelloApplication extends Application {
>>> ??? @Override
>>> ??? public void start(Stage stage) {
>>> ??????? final WebView webView = new WebView();
>>> ??????? final String svg = "<svg viewBox=\"0 0 200 100\" 
>>> xmlns=\"https://urldefense.com/v3/__http://www.w3.org/2000/svg*5C__;JQ!!ACWV5N9M2RV99hQ!OYK4yY--gIMjdd22lb2UY6go0MqS4H_7hStQVu24I6NFYwqm7wbCYhOodgM915n2zG5FJOnOB84Zqi6TUQ$ 
>>> ">\n" + "? <defs>\n" + "??? <linearGradient id=\"gradient\" 
>>> x1=\"0%\" y1=\"0%\" x2=\"0\" y2=\"100%\">\n" + "????? <stop 
>>> offset=\"0%\" style=\"stop-color:skyblue;\" />\n" + "????? <stop 
>>> offset=\"100%\" style=\"stop-color:seagreen;\" />\n" + " 
>>> </linearGradient>\n" + "? </defs>\n" + "? <rect x=\"0\" y=\"0\" 
>>> width=\"100%\" height=\"100%\" fill=\"url(#gradient)\" />\n" + "? 
>>> <circle cx=\"50\" cy=\"50\" r=\"40\" fill=\"black\" />\n" + "? 
>>> <circle id=\"circle\" cx=\"150\" cy=\"50\" r=\"40\" fill=\"black\" 
>>> opacity=\"0.3\" />\n" + "</svg>\n";
>>> ??????? webView.getEngine().loadContent(svg);
>>> ??????? stage.setScene(new Scene(webView));
>>> ??????? stage.show();
>>> ??? }
>>>
>>>
>>> ??? public static void main(String[] args) {
>>> ??????? launch();
>>> ??? }
>>> }
>>>
>>


From angorya at openjdk.org  Mon Sep 19 15:44:58 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 19 Sep 2022 15:44:58 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v11]
In-Reply-To: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
Message-ID: <8G4s2cMFGjWygaMqZmT7UANZb_YxGZUcjFOVdf-At98=.15560f48-acde-4ee0-b546-a7737d93450f@github.com>

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8292353: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/2c7130d9..13ee82f4

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

  Stats: 408 lines in 4 files changed: 59 ins; 26 del; 323 mod
  Patch: https://git.openjdk.org/jfx/pull/875.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875

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

From andy.goryachev at oracle.com  Mon Sep 19 16:06:32 2022
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 19 Sep 2022 16:06:32 +0000
Subject: Provide Quit handler for system menu bar
In-Reply-To: <CA+4mSqYU9msq=x2xftj8XFuq4BaxYnku+Y7B-LKncNeAsL0FLw@mail.gmail.com>
References: <CA+4mSqYU9msq=x2xftj8XFuq4BaxYnku+Y7B-LKncNeAsL0FLw@mail.gmail.com>
Message-ID: <BL0PR10MB2948280A958C35CC26BF3110E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>

Greetings!

Thank you for proposing a solution, Florian.  I wonder if we should extrapolate the problem further.  Given the fact that app developers always need access to platform specific APIs, be it integration with Mac menu, perhaps we should consider a way to do so in such a way that does not require various tricks.

For example, we might invent a way to query whether we are running on a certain platform and get the corresponding APIs.  Let's say the class is PlatformAPI:

These methods allow for querying whether the specific platform APIs are available

PlatformAPI.isWindows();
PlatformAPI.isMacOS();
PlatformAPI.isLinux(); // isUnix()? isPosix() ?


and these will actually return a service object that provides access to the APIs, or throws some kind of exception:

IWindowsAPI PlatformAPI.getWindowsAPI();
IMacOSAPI PlatformAPI.getMacOSAPI();

the service object returned by one of these methods might provide further information about the platform version, as well as access to platform-specific APIs.


Another thought is perhaps we ought to think about expanding functionality that became available on every platform in the XXI century (example: going to sleep/hibernate).  Possibly external shutdown via Mac menu or a signal discussed by the OP would be considered as platform-independent.

What do you think?

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Florian Kirmaier <florian.kirmaier at gmail.com>
Date: Tuesday, 2022/09/13 at 08:11
To: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
Subject: Provide Quit handler for system menu bar
Hi Everyone,

In one project, we have to handle the quit-logic for MacOS ourselves,
when the <quit app> menu entry is used.
As background information - this menu entry is set in the class com.sun.glass.ui.mac.MacApplication.
It's basically hard coded. Currently, in this project, the menu entry doesn't work in some cases.

My Solution would be:

Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
This handler is called when quit <appname> from the menu is called.
If the handler returns true, all windows are closed. Otherwise, nothing happens.

It would look like the following:
```
/**
 * Sets the handler to be called when the application is about to quit.
 * Currently, this can only happen on MacOS.
 *
 * This handler is called, when the user selects
 * the "Quit <appname>" from the application menu.
 * When the provided handler returns true,
 * the application will close all windows.
 * If the handler returns false, the application will not quit.
 *
 * @param The new quit handler.
 */
public static void setQuitHandler(Supplier x) {
    ...
}
```
I've created a ticket for this topic. https://bugs.openjdk.org/browse/JDK-8293700

I've got a working version for this change.
According to Kevin Rushforth this need a prior dicussion on the mailing list.
Any opinion regarding this?

I could provide a pullrequest, if someone is interested.

Florian Kirmaier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220919/7984c3cd/attachment.htm>

From kevin.rushforth at oracle.com  Mon Sep 19 16:33:36 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Sep 2022 09:33:36 -0700
Subject: Provide Quit handler for system menu bar
In-Reply-To: <BL0PR10MB2948280A958C35CC26BF3110E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>
References: <CA+4mSqYU9msq=x2xftj8XFuq4BaxYnku+Y7B-LKncNeAsL0FLw@mail.gmail.com>
 <BL0PR10MB2948280A958C35CC26BF3110E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>
Message-ID: <a919546b-8e51-8be0-38c0-ddbf11f0f440@oracle.com>

I like the idea of looking at this holistically, even if we do end up 
adding such features one at a time.

As for how to expose such an API, I don't much like the idea of exposing 
the underlying platform explicitly unless there is no viable 
alternative. A better approach is one where a feature is optional based 
on whether the platform you are running on supports that feature. 
Especially given, as you pointed out, that features that are only 
available in one platform today might make their way into other 
platforms tomorrow. As for how to let an application know whether they 
can use a particular API, we already have ConditionalFeature, so adding 
to that would be a reasonable thing to consider.

-- Kevin


On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>
> Greetings!
>
> Thank you for proposing a solution, Florian.? I wonder if we should 
> extrapolate the problem further.? Given the fact that app developers 
> always need access to platform specific APIs, be it integration with 
> Mac menu, perhaps we should consider a way to do so in such a way that 
> does not require various tricks.
>
> For example, we might invent a way to query whether we are running on 
> a certain platform and get the corresponding APIs.? Let's say the 
> class is PlatformAPI:
>
> These methods allow for querying whether the specific platform APIs 
> are available
>
> PlatformAPI.isWindows();
>
> PlatformAPI.isMacOS();
>
> PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>
> and these will actually return a service object that provides access 
> to the APIs, or throws some kind of exception:
>
> IWindowsAPI PlatformAPI.getWindowsAPI();
>
> IMacOSAPI PlatformAPI.getMacOSAPI();
>
> the service object returned by one of these methods might provide 
> further information about the platform version, as well as access to 
> platform-specific APIs.
>
> Another thought is perhaps we ought to think about expanding 
> functionality that became available on every platform in the XXI 
> century (example: going to sleep/hibernate).? Possibly external 
> shutdown via Mac menu or a signal discussed by the OP would be 
> considered as platform-independent.
>
> What do you think?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
> Florian Kirmaier <florian.kirmaier at gmail.com>
> *Date: *Tuesday, 2022/09/13 at 08:11
> *To: *openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
> *Subject: *Provide Quit handler for system menu bar
>
> Hi Everyone,
>
>
> In one project, we have to handle the quit-logic for MacOS ourselves,
> when the <quit app> menu entry is used.
> As background information - this menu entry is set in the 
> class?com.sun.glass.ui.mac.MacApplication.
> It's basically hard coded. Currently, in this project, the menu entry 
> doesn't work in some cases.
>
> My Solution would be:
>
> Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
> This handler is called when quit <appname> from the menu is called.
> If the handler returns true, all windows are closed. Otherwise, 
> nothing happens.
>
> It would look like the following:
> ```
> /**
> ?* Sets the handler to be called when the application is about to quit.
> ?* Currently, this can only happen on MacOS.
> ?*
> ?* This handler is called, when the user selects
> ?* the "Quit <appname>" from the application menu.
> ?* When the provided handler returns true,
> ?* the application will close all windows.
> ?* If the handler returns false, the application will not quit.
> ?*
> ?* @param The new quit handler.
> ?*/
> public static void setQuitHandler(Supplier x) {
> ? ? ...
> }
> ```
> I've created a ticket for this topic. 
> https://bugs.openjdk.org/browse/JDK-8293700
>
>
> I've got a working version for this change.
>
> According to Kevin Rushforth this need a prior dicussion?on the 
> mailing list.
>
> Any opinion regarding this?
>
> I could provide a pullrequest, if someone is interested.
>
> Florian Kirmaier
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220919/819328f7/attachment-0001.htm>

From andy.goryachev at oracle.com  Mon Sep 19 20:46:09 2022
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 19 Sep 2022 20:46:09 +0000
Subject: Provide Quit handler for system menu bar
In-Reply-To: <a919546b-8e51-8be0-38c0-ddbf11f0f440@oracle.com>
References: <CA+4mSqYU9msq=x2xftj8XFuq4BaxYnku+Y7B-LKncNeAsL0FLw@mail.gmail.com>
 <BL0PR10MB2948280A958C35CC26BF3110E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>
 <a919546b-8e51-8be0-38c0-ddbf11f0f440@oracle.com>
Message-ID: <BL0PR10MB2948F5480A765DD3F0C73B78E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>

Thank you, Kevin.  Your insightful feedback always pulls the discussion in the right direction.

The initial problem we are facing is access to Mac menu in general and additional API specifically.  I can see a possibility of extending the list of APIs that app devs would want on Mac growing, so there should be a better way to add them.  Using hacks like com.apple.eawt, or system properties is probably not the best solution.  Ideally, there should be away that does not require creative linking of stub classes on non-Mac platforms, i.e. we should be able to use a single code base for all the platforms.

ConditionalFeature might work well internally for openjfx, but I don't think it is a good solution for actually exposing the platform APIs to the user.

So, in order to provide platform-specific API in such a way that still allows for a single code base for multiple platform, and one that potentially scales to tens or hundreds of API calls, I see two solutions:

1. one start starts with a single entry point, like PlatformAPI, described earlier.

2. a lookup-based approach, where the client code requests a (possibly fine-grained and narrowly defined) implementation from the system.  For example:

IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);

(where IMacMenu is an interface that, in this example, provides access to Mac menu, adding shutdown listeners, and so forth).

if we are on windows, this method either returns null or throws an exception, if we are on Mac, we get a working instance (a singleton or a new instance each time, depending on the circumstances).

This way we are free to extend or version the APIs without modifying the core classes.

PlatformAPI.isSupported(IMacMenu.class) might provide a way to see whether the capability is present.

The platform-specific interfaces like IMacMenu might in turn extend some base interface that provides introspection into common properties, such as version, description, possibly a list of other similar capabilities that the platform supports (may be a number of earlier versions?) and so forth.

What do you think?

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
Date: Monday, 2022/09/19 at 09:33
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Provide Quit handler for system menu bar
I like the idea of looking at this holistically, even if we do end up adding such features one at a time.

As for how to expose such an API, I don't much like the idea of exposing the underlying platform explicitly unless there is no viable alternative. A better approach is one where a feature is optional based on whether the platform you are running on supports that feature. Especially given, as you pointed out, that features that are only available in one platform today might make their way into other platforms tomorrow. As for how to let an application know whether they can use a particular API, we already have ConditionalFeature, so adding to that would be a reasonable thing to consider.

-- Kevin

On 9/19/2022 9:06 AM, Andy Goryachev wrote:
Greetings!

Thank you for proposing a solution, Florian.  I wonder if we should extrapolate the problem further.  Given the fact that app developers always need access to platform specific APIs, be it integration with Mac menu, perhaps we should consider a way to do so in such a way that does not require various tricks.

For example, we might invent a way to query whether we are running on a certain platform and get the corresponding APIs.  Let's say the class is PlatformAPI:

These methods allow for querying whether the specific platform APIs are available

PlatformAPI.isWindows();
PlatformAPI.isMacOS();
PlatformAPI.isLinux(); // isUnix()? isPosix() ?


and these will actually return a service object that provides access to the APIs, or throws some kind of exception:

IWindowsAPI PlatformAPI.getWindowsAPI();
IMacOSAPI PlatformAPI.getMacOSAPI();

the service object returned by one of these methods might provide further information about the platform version, as well as access to platform-specific APIs.


Another thought is perhaps we ought to think about expanding functionality that became available on every platform in the XXI century (example: going to sleep/hibernate).  Possibly external shutdown via Mac menu or a signal discussed by the OP would be considered as platform-independent.

What do you think?

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Florian Kirmaier <florian.kirmaier at gmail.com><mailto:florian.kirmaier at gmail.com>
Date: Tuesday, 2022/09/13 at 08:11
To: openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> <openjfx-dev at openjdk.java.net><mailto:openjfx-dev at openjdk.java.net>
Subject: Provide Quit handler for system menu bar
Hi Everyone,

In one project, we have to handle the quit-logic for MacOS ourselves,
when the <quit app> menu entry is used.
As background information - this menu entry is set in the class com.sun.glass.ui.mac.MacApplication.
It's basically hard coded. Currently, in this project, the menu entry doesn't work in some cases.

My Solution would be:

Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
This handler is called when quit <appname> from the menu is called.
If the handler returns true, all windows are closed. Otherwise, nothing happens.

It would look like the following:
```
/**
 * Sets the handler to be called when the application is about to quit.
 * Currently, this can only happen on MacOS.
 *
 * This handler is called, when the user selects
 * the "Quit <appname>" from the application menu.
 * When the provided handler returns true,
 * the application will close all windows.
 * If the handler returns false, the application will not quit.
 *
 * @param The new quit handler.
 */
public static void setQuitHandler(Supplier x) {
    ...
}
```
I've created a ticket for this topic. https://bugs.openjdk.org/browse/JDK-8293700

I've got a working version for this change.
According to Kevin Rushforth this need a prior dicussion on the mailing list.
Any opinion regarding this?

I could provide a pullrequest, if someone is interested.

Florian Kirmaier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220919/9fb837da/attachment-0001.htm>

From kevin.rushforth at oracle.com  Tue Sep 20 00:11:40 2022
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 19 Sep 2022 17:11:40 -0700
Subject: Provide Quit handler for system menu bar
In-Reply-To: <BL0PR10MB2948F5480A765DD3F0C73B78E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>
References: <CA+4mSqYU9msq=x2xftj8XFuq4BaxYnku+Y7B-LKncNeAsL0FLw@mail.gmail.com>
 <BL0PR10MB2948280A958C35CC26BF3110E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>
 <a919546b-8e51-8be0-38c0-ddbf11f0f440@oracle.com>
 <BL0PR10MB2948F5480A765DD3F0C73B78E54D9@BL0PR10MB2948.namprd10.prod.outlook.com>
Message-ID: <636a8ad2-2607-3297-60f8-54d7b90ffc63@oracle.com>

I don't see us adding 100s of OS-specific API calls, but even if we did, 
going down the path of exposing them as Mac APIs or Windows APIs, 
doesn't really seem like the direction we want to go. Whatever we do 
needs to balance the desire to integrate with, e.g., the macOS or 
Windows platform with a desire to leave the door open for it to later be 
implemented on the other platform(s). And the most cross-platform way to 
do that from an API point of view is by defining API that delivers the 
desired functionality in as platform-neutral a way as possible. It also 
needs to fit cleanly into the existing API.

So in the specific case of a quit handler, we could define a platform 
API that an app could call to register a handler that gets called if the 
platform quit menu is selected and is able to cancel the Quit 
action(basically, that's what is being proposed). We could decide to 
provide some way for an app to query whether it is supported, but maybe 
we just don't need to worry about it in this specific case. We could 
just document that it will get called when the platform quit action is 
called, if there is such an action on that platform. Other than maybe 
mentioning in the docs that the macOS system menu "quit" action is an 
example of an action that would invoke this, it doesn't need to be 
platform-specific. One question to answer is whether we should just put 
this in the Platform class (where we have other similar "global" 
application state), the Application class (which has the life-cycle 
APIs), or somewhere else (which might make sense if we wanted to define 
an analog to the AWT Desktop class, although the existing Platform class 
already has some APIs like this).

-- Kevin


On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>
> Thank you, Kevin.? Your insightful feedback always pulls the 
> discussion in the right direction.
>
> The initial problem we are facing is access to Mac menu in general and 
> additional API specifically.? I can see a possibility of extending the 
> list of APIs that app devs would want on Mac growing, so there should 
> be a better way to add them.? Using hacks like com.apple.eawt, or 
> system properties is probably not the best solution. ?Ideally, there 
> should be away that does not require creative linking of stub classes 
> on non-Mac platforms, i.e. we should be able to use a single code base 
> for all the platforms.
>
> ConditionalFeature might work well internally for openjfx, but I don't 
> think it is a good solution for actually exposing the platform APIs to 
> the user.
>
> So, in order to provide platform-specific API in such a way that still 
> allows for a single code base for multiple platform, and one that 
> potentially scales to tens or hundreds of API calls, I see two solutions:
>
> 1. one start starts with a single entry point, like PlatformAPI, 
> described earlier.
>
> 2. a lookup-based approach, where the client code requests a (possibly 
> fine-grained and narrowly defined) implementation from the system.? 
> For example:
>
> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>
> (where IMacMenu is an interface that, in this example, provides access 
> to Mac menu, adding shutdown listeners, and so forth).
>
> if we are on windows, this method either returns null or throws an 
> exception, if we are on Mac, we get a working instance (a singleton or 
> a new instance each time, depending on the circumstances).
>
> This way we are free to extend or version the APIs without modifying 
> the core classes.
>
> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see 
> whether the capability is present.
>
> The platform-specific interfaces like IMacMenu might in turn extend 
> some base interface that provides introspection into common 
> properties, such as version, description, possibly a list of other 
> similar capabilities that the platform supports (may be a number of 
> earlier versions?) and so forth.
>
> What do you think?
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin 
> Rushforth <kevin.rushforth at oracle.com>
> *Date: *Monday, 2022/09/19 at 09:33
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Provide Quit handler for system menu bar
>
> I like the idea of looking at this holistically, even if we do end up 
> adding such features one at a time.
>
> As for how to expose such an API, I don't much like the idea of 
> exposing the underlying platform explicitly unless there is no viable 
> alternative. A better approach is one where a feature is optional 
> based on whether the platform you are running on supports that 
> feature. Especially given, as you pointed out, that features that are 
> only available in one platform today might make their way into other 
> platforms tomorrow. As for how to let an application know whether they 
> can use a particular API, we already have ConditionalFeature, so 
> adding to that would be a reasonable thing to consider.
>
> -- Kevin
>
> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>
>     Greetings!
>
>     Thank you for proposing a solution, Florian.? I wonder if we
>     should extrapolate the problem further.? Given the fact that app
>     developers always need access to platform specific APIs, be it
>     integration with Mac menu, perhaps we should consider a way to do
>     so in such a way that does not require various tricks.
>
>     For example, we might invent a way to query whether we are running
>     on a certain platform and get the corresponding APIs.? Let's say
>     the class is PlatformAPI:
>
>     These methods allow for querying whether the specific platform
>     APIs are available
>
>     PlatformAPI.isWindows();
>
>     PlatformAPI.isMacOS();
>
>     PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>
>     and these will actually return a service object that provides
>     access to the APIs, or throws some kind of exception:
>
>     IWindowsAPI PlatformAPI.getWindowsAPI();
>
>     IMacOSAPI PlatformAPI.getMacOSAPI();
>
>     the service object returned by one of these methods might provide
>     further information about the platform version, as well as access
>     to platform-specific APIs.
>
>     Another thought is perhaps we ought to think about expanding
>     functionality that became available on every platform in the XXI
>     century (example: going to sleep/hibernate).? Possibly external
>     shutdown via Mac menu or a signal discussed by the OP would be
>     considered as platform-independent.
>
>     What do you think?
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Florian
>     Kirmaier <florian.kirmaier at gmail.com>
>     <mailto:florian.kirmaier at gmail.com>
>     *Date: *Tuesday, 2022/09/13 at 08:11
>     *To: *openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
>     <mailto:openjfx-dev at openjdk.java.net>
>     *Subject: *Provide Quit handler for system menu bar
>
>     Hi Everyone,
>
>
>     In one project, we have to handle the quit-logic for MacOS ourselves,
>     when the <quit app> menu entry is used.
>     As background information - this menu entry is set in the
>     class?com.sun.glass.ui.mac.MacApplication.
>     It's basically hard coded. Currently, in this project, the menu
>     entry doesn't work in some cases.
>
>     My Solution would be:
>
>     Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
>     This handler is called when quit <appname> from the menu is called.
>     If the handler returns true, all windows are closed. Otherwise,
>     nothing happens.
>
>     It would look like the following:
>     ```
>     /**
>     ?* Sets the handler to be called when the application is about to
>     quit.
>     ?* Currently, this can only happen on MacOS.
>     ?*
>     ?* This handler is called, when the user selects
>     ?* the "Quit <appname>" from the application menu.
>     ?* When the provided handler returns true,
>     ?* the application will close all windows.
>     ?* If the handler returns false, the application will not quit.
>     ?*
>     ?* @param The new quit handler.
>     ?*/
>     public static void setQuitHandler(Supplier x) {
>     ? ? ...
>     }
>     ```
>     I've created a ticket for this topic.
>     https://bugs.openjdk.org/browse/JDK-8293700
>
>
>     I've got a working version for this change.
>
>     According to Kevin Rushforth this need a prior dicussion?on the
>     mailing list.
>
>     Any opinion regarding this?
>
>     I could provide a pullrequest, if someone is interested.
>
>     Florian Kirmaier
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220919/0bfcb086/attachment-0001.htm>

From swpalmer at gmail.com  Tue Sep 20 04:25:50 2022
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 20 Sep 2022 00:25:50 -0400
Subject: Provide Quit handler for system menu bar
In-Reply-To: <636a8ad2-2607-3297-60f8-54d7b90ffc63@oracle.com>
References: <636a8ad2-2607-3297-60f8-54d7b90ffc63@oracle.com>
Message-ID: <7DF75FDA-F634-4F74-ACDD-B4A8D3FF5634@gmail.com>

Windows applications often have an ?Exit? menu item, but since it isn?t standardized like it is on macOS, calling a quit handler for it would need to be a manual step - but the exact same method for the quit handler could be called, leaving it up to the programmer to continue or not with the application exit depending on the return value. This manual coding isn?t a big deal since you would also need to have some app-specific handling to avoid making an Exit menu item on macOS, where it would look out of place.  

You could add a standard ?requestExit()? method to Platform that you could manually bind to an Exit menu item on Windows or Linux, but it would be automatically called via an internal macOS Quit handler implementation.  The implementation of Platform.requestExit() on *all* platforms would call a boolean method if one was registered and then conditionally call Platform.exit() depending on the return value, the default being to always exit if nothing was registered. On macOS it would pass on the value to veto the native Quit handler as needed.  I haven?t checked, does Application.stop() get called on macOS if you exit via the Quit menu or Command-Q? If it doesn?t, that?s another benefit.  This idea should probably be opt-in via some API or system property, I suppose it would have to be if it changes behaviour of having Application.stop() called in some circumstances. Or you can just make the setting of the handler function the ?opt-in?.

Btw, this reminds me of the long-standing request for system tray support, along with with various other features that have equivalents across multiple OS?, like showing progress on the dock icon, or a numbered badge (for notifications, or unread msgs, etc).  I think there are already issues in Jira for these, maybe just as a general request to support some features that AWT/Swing has that JFX is still missing. Most of these features are available on both Mac and Windows, possibly Linux.  It would be irritating to code to different APIs for each if it can be avoided, so I agree with going for a platform-neutral way.

Cheers, 

Scott

> On Sep 19, 2022, at 8:11 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> ? I don't see us adding 100s of OS-specific API calls, but even if we did, going down the path of exposing them as Mac APIs or Windows APIs, doesn't really seem like the direction we want to go. Whatever we do needs to balance the desire to integrate with, e.g., the macOS or Windows platform with a desire to leave the door open for it to later be implemented on the other platform(s). And the most cross-platform way to do that from an API point of view is by defining API that delivers the desired functionality in as platform-neutral a way as possible. It also needs to fit cleanly into the existing API.
> 
> So in the specific case of a quit handler, we could define a platform API that an app could call to register a handler that gets called if the platform quit menu is selected and is able to cancel the Quit action(basically, that's what is being proposed). We could decide to provide some way for an app to query whether it is supported, but maybe we just don't need to worry about it in this specific case. We could just document that it will get called when the platform quit action is called, if there is such an action on that platform. Other than maybe mentioning in the docs that the macOS system menu "quit" action is an example of an action that would invoke this, it doesn't need to be platform-specific. One question to answer is whether we should just put this in the Platform class (where we have other similar "global" application state), the Application class (which has the life-cycle APIs), or somewhere else (which might make sense if we wanted to define an analog to the AWT Desktop class, although the existing Platform class already has some APIs like this).
> 
> -- Kevin
> 
> 
> On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>> Thank you, Kevin.  Your insightful feedback always pulls the discussion in the right direction.
>>  
>> The initial problem we are facing is access to Mac menu in general and additional API specifically.  I can see a possibility of extending the list of APIs that app devs would want on Mac growing, so there should be a better way to add them.  Using hacks like com.apple.eawt, or system properties is probably not the best solution.  Ideally, there should be away that does not require creative linking of stub classes on non-Mac platforms, i.e. we should be able to use a single code base for all the platforms.
>>  
>> ConditionalFeature might work well internally for openjfx, but I don't think it is a good solution for actually exposing the platform APIs to the user.
>>  
>> So, in order to provide platform-specific API in such a way that still allows for a single code base for multiple platform, and one that potentially scales to tens or hundreds of API calls, I see two solutions:
>>  
>> 1. one start starts with a single entry point, like PlatformAPI, described earlier.
>>  
>> 2. a lookup-based approach, where the client code requests a (possibly fine-grained and narrowly defined) implementation from the system.  For example:
>>  
>> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>>  
>> (where IMacMenu is an interface that, in this example, provides access to Mac menu, adding shutdown listeners, and so forth).
>>  
>> if we are on windows, this method either returns null or throws an exception, if we are on Mac, we get a working instance (a singleton or a new instance each time, depending on the circumstances).
>>  
>> This way we are free to extend or version the APIs without modifying the core classes.
>>  
>> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see whether the capability is present.
>>  
>> The platform-specific interfaces like IMacMenu might in turn extend some base interface that provides introspection into common properties, such as version, description, possibly a list of other similar capabilities that the platform supports (may be a number of earlier versions?) and so forth.
>>  
>> What do you think?
>>  
>> -andy
>>  
>>  
>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
>> Date: Monday, 2022/09/19 at 09:33
>> To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>> Subject: Re: Provide Quit handler for system menu bar
>> 
>> I like the idea of looking at this holistically, even if we do end up adding such features one at a time.
>> 
>> As for how to expose such an API, I don't much like the idea of exposing the underlying platform explicitly unless there is no viable alternative. A better approach is one where a feature is optional based on whether the platform you are running on supports that feature. Especially given, as you pointed out, that features that are only available in one platform today might make their way into other platforms tomorrow. As for how to let an application know whether they can use a particular API, we already have ConditionalFeature, so adding to that would be a reasonable thing to consider.
>> 
>> -- Kevin
>> 
>> 
>> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>> Greetings!
>>  
>> Thank you for proposing a solution, Florian.  I wonder if we should extrapolate the problem further.  Given the fact that app developers always need access to platform specific APIs, be it integration with Mac menu, perhaps we should consider a way to do so in such a way that does not require various tricks.
>>  
>> For example, we might invent a way to query whether we are running on a certain platform and get the corresponding APIs.  Let's say the class is PlatformAPI:
>>  
>> These methods allow for querying whether the specific platform APIs are available
>>  
>> PlatformAPI.isWindows();
>> PlatformAPI.isMacOS();
>> PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>>  
>>  
>> and these will actually return a service object that provides access to the APIs, or throws some kind of exception:
>>  
>> IWindowsAPI PlatformAPI.getWindowsAPI();
>> IMacOSAPI PlatformAPI.getMacOSAPI();
>>  
>> the service object returned by one of these methods might provide further information about the platform version, as well as access to platform-specific APIs.
>>  
>>  
>> Another thought is perhaps we ought to think about expanding functionality that became available on every platform in the XXI century (example: going to sleep/hibernate).  Possibly external shutdown via Mac menu or a signal discussed by the OP would be considered as platform-independent.
>>  
>> What do you think?
>>  
>> -andy
>>  
>>  
>>  
>>  
>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Florian Kirmaier <florian.kirmaier at gmail.com>
>> Date: Tuesday, 2022/09/13 at 08:11
>> To: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
>> Subject: Provide Quit handler for system menu bar
>> 
>> Hi Everyone,
>> 
>> In one project, we have to handle the quit-logic for MacOS ourselves,
>> when the <quit app> menu entry is used.
>> As background information - this menu entry is set in the class com.sun.glass.ui.mac.MacApplication.
>> It's basically hard coded. Currently, in this project, the menu entry doesn't work in some cases.
>> 
>> My Solution would be:
>> 
>> Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
>> This handler is called when quit <appname> from the menu is called.
>> If the handler returns true, all windows are closed. Otherwise, nothing happens.
>> 
>> It would look like the following:
>> ```
>> /**
>>  * Sets the handler to be called when the application is about to quit.
>>  * Currently, this can only happen on MacOS.
>>  *
>>  * This handler is called, when the user selects
>>  * the "Quit <appname>" from the application menu.
>>  * When the provided handler returns true,
>>  * the application will close all windows.
>>  * If the handler returns false, the application will not quit.
>>  *
>>  * @param The new quit handler.
>>  */
>> public static void setQuitHandler(Supplier x) {
>>     ...
>> }
>> ```
>> I've created a ticket for this topic. https://bugs.openjdk.org/browse/JDK-8293700
>> 
>> I've got a working version for this change. 
>> According to Kevin Rushforth this need a prior dicussion on the mailing list.
>> Any opinion regarding this?
>> 
>> I could provide a pullrequest, if someone is interested.
>> 
>> Florian Kirmaier
>>  
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220920/8b687841/attachment-0001.htm>

From duke at openjdk.org  Tue Sep 20 08:27:44 2022
From: duke at openjdk.org (danielpeintner)
Date: Tue, 20 Sep 2022 08:27:44 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v4]
In-Reply-To: <g-Ggzq9Ov8UbontgYfSY-uoKaCA2raJkdl4rpckNiDQ=.337c4778-d6c4-4ed4-804f-6f6d1fcda181@github.com>
References: <ZZ4qI4_kz81SYfN64REeXjIt3lsnJT2FHwkUEuOS3gk=.6922b475-acdd-43b5-ace7-72fe1ec94d76@github.com>
 <g-Ggzq9Ov8UbontgYfSY-uoKaCA2raJkdl4rpckNiDQ=.337c4778-d6c4-4ed4-804f-6f6d1fcda181@github.com>
Message-ID: <fGAB_pkLd7kG2x-vlBSmE_SR4UmHKUR1ZcOzGRziqeE=.a9bfc56c-9ad9-4fc1-8277-27f86fd62c32@github.com>

On Mon, 22 Aug 2022 09:46:24 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> It's "a bit" complicated.
>> In some situations, getRuns get's called because listeners on bounds are set.
>> This causes TextFlow to layout to compute the runs.
>> Afterward, the bounds of the parents get updated. 
>> This triggers a call to compute bounds - which cascades up to the children.
>> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
>> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
>> 
>> In the case it happened - it didn't repair and the application kinda crashed.
>> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
>> It also can cause unpredictable performance issues.
>> 
>> Unit test and example stacktrace are in the ticket.
>> 
>> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. 
>> The Textflow should be layouting by the Parent.
>> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications.
>> 
>> Benefits:
>>  * Better Tooling Support For ScenicView etc.
>>  * Fixes complicated but reproducible crashes
>>  * Might fix some rare crashes, which are hard to reproduce
>>  * Likely improves performance - might fix some edge cases with unpredictable bad performance
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269921
>   Reverted the change to the layout, so we can fix the main-bug without further discussions.

FYI: in the near past we have also many of those "crashes" when the UI gets heavily restructured. Crashes in our case means that on Windows for example you get the loading circle but the UI freezes endlessly. I assume it might be related. 

Question: does the simple `null` check help in such a case?

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

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

From john.hendrikx at gmail.com  Tue Sep 20 09:54:53 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 20 Sep 2022 11:54:53 +0200
Subject: Provide Quit handler for system menu bar
In-Reply-To: <7DF75FDA-F634-4F74-ACDD-B4A8D3FF5634@gmail.com>
References: <636a8ad2-2607-3297-60f8-54d7b90ffc63@oracle.com>
 <7DF75FDA-F634-4F74-ACDD-B4A8D3FF5634@gmail.com>
Message-ID: <38b8838b-a63f-ead2-e498-076e04419cdc@gmail.com>

What about Alt + F4 and Ctrl + F4 on Windows?? Alt + F4 closes the 
application (which works with JavaFX already) and Ctrl + F4 is supposed 
to close a single window, but that doesn't work for JavaFX.

Also very much in favor of Keeping the API platform neutral, that's just 
how Java has worked since its inception.

--John

On 20/09/2022 06:25, Scott Palmer wrote:
> Windows applications often have an ?Exit? menu item, but since it 
> isn?t standardized like it is on macOS, calling a quit handler for it 
> would need to be a manual step - but the exact same method for the 
> quit handler could be called, leaving it up to the programmer to 
> continue or not with the application exit depending on the return 
> value. This manual coding isn?t a big deal since you would also need 
> to have some app-specific handling to avoid making an Exit menu item 
> on macOS, where it would look out of place.
>
> You could add a standard ?requestExit()? method to Platform that you 
> could manually bind to an Exit menu item on Windows or Linux, but it 
> would be automatically called via an internal macOS Quit handler 
> implementation. ?The implementation of Platform.requestExit() on *all* 
> platforms would call a boolean method if one was registered and then 
> conditionally call Platform.exit() depending on the return value, the 
> default being to always exit if nothing was registered. On macOS it 
> would pass on the value to veto the native Quit handler as needed. I 
> haven?t checked, does Application.stop() get called on macOS if you 
> exit via the Quit menu or Command-Q? If it doesn?t, that?s another 
> benefit. ?This idea should probably be opt-in via some API or system 
> property, I suppose it would have to be if it changes behaviour of 
> having Application.stop() called in some circumstances. Or you can 
> just make the setting of the handler function the ?opt-in?.
>
> Btw, this reminds me of the long-standing request for system tray 
> support, along with with various other features that have equivalents 
> across multiple OS?, like showing progress on the dock icon, or a 
> numbered badge (for notifications, or unread msgs, etc). ?I think 
> there are already issues in Jira for these, maybe just as a general 
> request to support some features that AWT/Swing has that JFX is still 
> missing. Most of these features are available on both Mac and Windows, 
> possibly Linux. ?It would be irritating to code to different APIs for 
> each if it can be avoided, so I agree with going for a 
> platform-neutral way.
>
> Cheers,
>
> Scott
>
>> On Sep 19, 2022, at 8:11 PM, Kevin Rushforth 
>> <kevin.rushforth at oracle.com> wrote:
>>
>> ? I don't see us adding 100s of OS-specific API calls, but even if we 
>> did, going down the path of exposing them as Mac APIs or Windows 
>> APIs, doesn't really seem like the direction we want to go. Whatever 
>> we do needs to balance the desire to integrate with, e.g., the macOS 
>> or Windows platform with a desire to leave the door open for it to 
>> later be implemented on the other platform(s). And the most 
>> cross-platform way to do that from an API point of view is by 
>> defining API that delivers the desired functionality in as 
>> platform-neutral a way as possible. It also needs to fit cleanly into 
>> the existing API.
>>
>> So in the specific case of a quit handler, we could define a platform 
>> API that an app could call to register a handler that gets called if 
>> the platform quit menu is selected and is able to cancel the Quit 
>> action(basically, that's what is being proposed). We could decide to 
>> provide some way for an app to query whether it is supported, but 
>> maybe we just don't need to worry about it in this specific case. We 
>> could just document that it will get called when the platform quit 
>> action is called, if there is such an action on that platform. Other 
>> than maybe mentioning in the docs that the macOS system menu "quit" 
>> action is an example of an action that would invoke this, it doesn't 
>> need to be platform-specific. One question to answer is whether we 
>> should just put this in the Platform class (where we have other 
>> similar "global" application state), the Application class (which has 
>> the life-cycle APIs), or somewhere else (which might make sense if we 
>> wanted to define an analog to the AWT Desktop class, although the 
>> existing Platform class already has some APIs like this).
>>
>> -- Kevin
>>
>>
>> On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>>>
>>> Thank you, Kevin.? Your insightful feedback always pulls the 
>>> discussion in the right direction.
>>>
>>> The initial problem we are facing is access to Mac menu in general 
>>> and additional API specifically.? I can see a possibility of 
>>> extending the list of APIs that app devs would want on Mac growing, 
>>> so there should be a better way to add them.? Using hacks like 
>>> com.apple.eawt, or system properties is probably not the best 
>>> solution. ?Ideally, there should be away that does not require 
>>> creative linking of stub classes on non-Mac platforms, i.e. we 
>>> should be able to use a single code base for all the platforms.
>>>
>>> ConditionalFeature might work well internally for openjfx, but I 
>>> don't think it is a good solution for actually exposing the platform 
>>> APIs to the user.
>>>
>>> So, in order to provide platform-specific API in such a way that 
>>> still allows for a single code base for multiple platform, and one 
>>> that potentially scales to tens or hundreds of API calls, I see two 
>>> solutions:
>>>
>>> 1. one start starts with a single entry point, like PlatformAPI, 
>>> described earlier.
>>>
>>> 2. a lookup-based approach, where the client code requests a 
>>> (possibly fine-grained and narrowly defined) implementation from the 
>>> system.? For example:
>>>
>>> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>>>
>>> (where IMacMenu is an interface that, in this example, provides 
>>> access to Mac menu, adding shutdown listeners, and so forth).
>>>
>>> if we are on windows, this method either returns null or throws an 
>>> exception, if we are on Mac, we get a working instance (a singleton 
>>> or a new instance each time, depending on the circumstances).
>>>
>>> This way we are free to extend or version the APIs without modifying 
>>> the core classes.
>>>
>>> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see 
>>> whether the capability is present.
>>>
>>> The platform-specific interfaces like IMacMenu might in turn extend 
>>> some base interface that provides introspection into common 
>>> properties, such as version, description, possibly a list of other 
>>> similar capabilities that the platform supports (may be a number of 
>>> earlier versions?) and so forth.
>>>
>>> What do you think?
>>>
>>> -andy
>>>
>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
>>> Kevin Rushforth <kevin.rushforth at oracle.com>
>>> *Date: *Monday, 2022/09/19 at 09:33
>>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>> *Subject: *Re: Provide Quit handler for system menu bar
>>>
>>> I like the idea of looking at this holistically, even if we do end 
>>> up adding such features one at a time.
>>>
>>> As for how to expose such an API, I don't much like the idea of 
>>> exposing the underlying platform explicitly unless there is no 
>>> viable alternative. A better approach is one where a feature is 
>>> optional based on whether the platform you are running on supports 
>>> that feature. Especially given, as you pointed out, that features 
>>> that are only available in one platform today might make their way 
>>> into other platforms tomorrow. As for how to let an application know 
>>> whether they can use a particular API, we already have 
>>> ConditionalFeature, so adding to that would be a reasonable thing to 
>>> consider.
>>>
>>> -- Kevin
>>>
>>> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>>>
>>>     Greetings!
>>>
>>>     Thank you for proposing a solution, Florian.? I wonder if we
>>>     should extrapolate the problem further.? Given the fact that app
>>>     developers always need access to platform specific APIs, be it
>>>     integration with Mac menu, perhaps we should consider a way to
>>>     do so in such a way that does not require various tricks.
>>>
>>>     For example, we might invent a way to query whether we are
>>>     running on a certain platform and get the corresponding APIs.?
>>>     Let's say the class is PlatformAPI:
>>>
>>>     These methods allow for querying whether the specific platform
>>>     APIs are available
>>>
>>>     PlatformAPI.isWindows();
>>>
>>>     PlatformAPI.isMacOS();
>>>
>>>     PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>>>
>>>     and these will actually return a service object that provides
>>>     access to the APIs, or throws some kind of exception:
>>>
>>>     IWindowsAPI PlatformAPI.getWindowsAPI();
>>>
>>>     IMacOSAPI PlatformAPI.getMacOSAPI();
>>>
>>>     the service object returned by one of these methods might
>>>     provide further information about the platform version, as well
>>>     as access to platform-specific APIs.
>>>
>>>     Another thought is perhaps we ought to think about expanding
>>>     functionality that became available on every platform in the XXI
>>>     century (example: going to sleep/hibernate).? Possibly external
>>>     shutdown via Mac menu or a signal discussed by the OP would be
>>>     considered as platform-independent.
>>>
>>>     What do you think?
>>>
>>>     -andy
>>>
>>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>>>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Florian
>>>     Kirmaier <florian.kirmaier at gmail.com>
>>>     <mailto:florian.kirmaier at gmail.com>
>>>     *Date: *Tuesday, 2022/09/13 at 08:11
>>>     *To: *openjfx-dev at openjdk.java.net
>>>     <openjfx-dev at openjdk.java.net> <mailto:openjfx-dev at openjdk.java.net>
>>>     *Subject: *Provide Quit handler for system menu bar
>>>
>>>     Hi Everyone,
>>>
>>>
>>>     In one project, we have to handle the quit-logic for MacOS
>>>     ourselves,
>>>     when the <quit app> menu entry is used.
>>>     As background information - this menu entry is set in the
>>>     class?com.sun.glass.ui.mac.MacApplication.
>>>     It's basically hard coded. Currently, in this project, the menu
>>>     entry doesn't work in some cases.
>>>
>>>     My Solution would be:
>>>
>>>     Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
>>>     This handler is called when quit <appname> from the menu is called.
>>>     If the handler returns true, all windows are closed. Otherwise,
>>>     nothing happens.
>>>
>>>     It would look like the following:
>>>     ```
>>>     /**
>>>     ?* Sets the handler to be called when the application is about
>>>     to quit.
>>>     ?* Currently, this can only happen on MacOS.
>>>     ?*
>>>     ?* This handler is called, when the user selects
>>>     ?* the "Quit <appname>" from the application menu.
>>>     ?* When the provided handler returns true,
>>>     ?* the application will close all windows.
>>>     ?* If the handler returns false, the application will not quit.
>>>     ?*
>>>     ?* @param The new quit handler.
>>>     ?*/
>>>     public static void setQuitHandler(Supplier x) {
>>>     ? ? ...
>>>     }
>>>     ```
>>>     I've created a ticket for this topic.
>>>     https://bugs.openjdk.org/browse/JDK-8293700
>>>
>>>
>>>     I've got a working version for this change.
>>>
>>>     According to Kevin Rushforth this need a prior dicussion?on the
>>>     mailing list.
>>>
>>>     Any opinion regarding this?
>>>
>>>     I could provide a pullrequest, if someone is interested.
>>>
>>>     Florian Kirmaier
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220920/81f69b2d/attachment-0001.htm>

From aghaisas at openjdk.org  Tue Sep 20 12:57:03 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Tue, 20 Sep 2022 12:57:03 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v11]
In-Reply-To: <8G4s2cMFGjWygaMqZmT7UANZb_YxGZUcjFOVdf-At98=.15560f48-acde-4ee0-b546-a7737d93450f@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <8G4s2cMFGjWygaMqZmT7UANZb_YxGZUcjFOVdf-At98=.15560f48-acde-4ee0-b546-a7737d93450f@github.com>
Message-ID: <qwlX4-0tLGKtM59stCHWzQHt1DeU_fZXkpPTkNeSICE=.81a21c56-4d33-4350-adae-9310ac10fadf@github.com>

On Mon, 19 Sep 2022 15:44:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: review comments

Changes requested by aghaisas (Reviewer).

modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlUtils.java line 201:

> 199:     /**
> 200:      * Finds a Node given the selector and predicate filter, then insures there is
> 201:      * one one such node

Comment has a typo : "one one"?

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeAndTableViewTest.java line 61:

> 59:     }
> 60: 
> 61:     /** TreeTableView with cell selection enabled should not select TreeTableRows */

Comment needs correction. `TreeTableView` should be `TableView` & `TreeTableRows` should be `TableRows`

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 840:

> 838:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
> 839:     @Test
> 840:     public void test_TreeTableView_jdk_8292353_select_all() {

This test passes with or without the code changes.
If test intention is to increase coverage, then the comment `// JDK-8292353 failure` needs to be removed. If not, the test needs some correction.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 875:

> 873:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
> 874:     @Test
> 875:     public void test_TreeTableView_jdk_8292353_select_all_but_one() {

This test passes with or without the code changes.
If test intention is to increase coverage, then the comment `// JDK-8292353 failure` needs to be removed. If not, the test needs some correction.

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

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

From swpalmer at gmail.com  Tue Sep 20 13:38:31 2022
From: swpalmer at gmail.com (Scott Palmer)
Date: Tue, 20 Sep 2022 09:38:31 -0400
Subject: Provide Quit handler for system menu bar
In-Reply-To: <38b8838b-a63f-ead2-e498-076e04419cdc@gmail.com>
References: <38b8838b-a63f-ead2-e498-076e04419cdc@gmail.com>
Message-ID: <0D317235-1194-44F0-B989-AC81A5D40C64@gmail.com>

I always understood Alt+F4 as simply being a keyboard shortcut on Windows for closing the window of the active application.  The same as clicking the close widget.  I don?t think there is anything special about it.  As far as being an equivalent to the macOS Quit action, I don?t think it is quite the same. Does an application even know the difference between a window closed with the widget vs. Alt+F4? CTRL+F4 closes the current document window or tab - similar to Command-W on macOS. 

I?m not aware of any special handlers being called on Windows for these shortcuts other than what is called when the equivalent close widget is pressed. If I?m wrong about that, then sure, a quit handler for JavaFX could be wired in to the same mechanism automatically.  Maybe Linux has an equivalent as well, I don?t know.

While we are at it, custom handling for the ?About? menu item in the application menu is also needed, is it not?  

For now I?m currently using Jan Gassen?s port of NSMenuFX to hook into this stuff. https://github.com/0x4a616e/NSMenuFX


Scott

> On Sep 20, 2022, at 5:55 AM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> ?
> What about Alt + F4 and Ctrl + F4 on Windows?  Alt + F4 closes the application (which works with JavaFX already) and Ctrl + F4 is supposed to close a single window, but that doesn't work for JavaFX.
> 
> Also very much in favor of Keeping the API platform neutral, that's just how Java has worked since its inception.
> 
> --John
> 
> On 20/09/2022 06:25, Scott Palmer wrote:
>> Windows applications often have an ?Exit? menu item, but since it isn?t standardized like it is on macOS, calling a quit handler for it would need to be a manual step - but the exact same method for the quit handler could be called, leaving it up to the programmer to continue or not with the application exit depending on the return value. This manual coding isn?t a big deal since you would also need to have some app-specific handling to avoid making an Exit menu item on macOS, where it would look out of place.  
>> 
>> You could add a standard ?requestExit()? method to Platform that you could manually bind to an Exit menu item on Windows or Linux, but it would be automatically called via an internal macOS Quit handler implementation.  The implementation of Platform.requestExit() on *all* platforms would call a boolean method if one was registered and then conditionally call Platform.exit() depending on the return value, the default being to always exit if nothing was registered. On macOS it would pass on the value to veto the native Quit handler as needed.  I haven?t checked, does Application.stop() get called on macOS if you exit via the Quit menu or Command-Q? If it doesn?t, that?s another benefit.  This idea should probably be opt-in via some API or system property, I suppose it would have to be if it changes behaviour of having Application.stop() called in some circumstances. Or you can just make the setting of the handler function the ?opt-in?.
>> 
>> Btw, this reminds me of the long-standing request for system tray support, along with with various other features that have equivalents across multiple OS?, like showing progress on the dock icon, or a numbered badge (for notifications, or unread msgs, etc).  I think there are already issues in Jira for these, maybe just as a general request to support some features that AWT/Swing has that JFX is still missing. Most of these features are available on both Mac and Windows, possibly Linux.  It would be irritating to code to different APIs for each if it can be avoided, so I agree with going for a platform-neutral way.
>> 
>> Cheers, 
>> 
>> Scott
>> 
>>> On Sep 19, 2022, at 8:11 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>> 
>>> ? I don't see us adding 100s of OS-specific API calls, but even if we did, going down the path of exposing them as Mac APIs or Windows APIs, doesn't really seem like the direction we want to go. Whatever we do needs to balance the desire to integrate with, e.g., the macOS or Windows platform with a desire to leave the door open for it to later be implemented on the other platform(s). And the most cross-platform way to do that from an API point of view is by defining API that delivers the desired functionality in as platform-neutral a way as possible. It also needs to fit cleanly into the existing API.
>>> 
>>> So in the specific case of a quit handler, we could define a platform API that an app could call to register a handler that gets called if the platform quit menu is selected and is able to cancel the Quit action(basically, that's what is being proposed). We could decide to provide some way for an app to query whether it is supported, but maybe we just don't need to worry about it in this specific case. We could just document that it will get called when the platform quit action is called, if there is such an action on that platform. Other than maybe mentioning in the docs that the macOS system menu "quit" action is an example of an action that would invoke this, it doesn't need to be platform-specific. One question to answer is whether we should just put this in the Platform class (where we have other similar "global" application state), the Application class (which has the life-cycle APIs), or somewhere else (which might make sense if we wanted to define an analog to the AWT Desktop class, although the existing Platform class already has some APIs like this).
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>>>> Thank you, Kevin.  Your insightful feedback always pulls the discussion in the right direction.
>>>>  
>>>> The initial problem we are facing is access to Mac menu in general and additional API specifically.  I can see a possibility of extending the list of APIs that app devs would want on Mac growing, so there should be a better way to add them.  Using hacks like com.apple.eawt, or system properties is probably not the best solution.  Ideally, there should be away that does not require creative linking of stub classes on non-Mac platforms, i.e. we should be able to use a single code base for all the platforms.
>>>>  
>>>> ConditionalFeature might work well internally for openjfx, but I don't think it is a good solution for actually exposing the platform APIs to the user.
>>>>  
>>>> So, in order to provide platform-specific API in such a way that still allows for a single code base for multiple platform, and one that potentially scales to tens or hundreds of API calls, I see two solutions:
>>>>  
>>>> 1. one start starts with a single entry point, like PlatformAPI, described earlier.
>>>>  
>>>> 2. a lookup-based approach, where the client code requests a (possibly fine-grained and narrowly defined) implementation from the system.  For example:
>>>>  
>>>> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>>>>  
>>>> (where IMacMenu is an interface that, in this example, provides access to Mac menu, adding shutdown listeners, and so forth).
>>>>  
>>>> if we are on windows, this method either returns null or throws an exception, if we are on Mac, we get a working instance (a singleton or a new instance each time, depending on the circumstances).
>>>>  
>>>> This way we are free to extend or version the APIs without modifying the core classes.
>>>>  
>>>> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see whether the capability is present.
>>>>  
>>>> The platform-specific interfaces like IMacMenu might in turn extend some base interface that provides introspection into common properties, such as version, description, possibly a list of other similar capabilities that the platform supports (may be a number of earlier versions?) and so forth.
>>>>  
>>>> What do you think?
>>>>  
>>>> -andy
>>>>  
>>>>  
>>>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth <kevin.rushforth at oracle.com>
>>>> Date: Monday, 2022/09/19 at 09:33
>>>> To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>>> Subject: Re: Provide Quit handler for system menu bar
>>>> 
>>>> I like the idea of looking at this holistically, even if we do end up adding such features one at a time.
>>>> 
>>>> As for how to expose such an API, I don't much like the idea of exposing the underlying platform explicitly unless there is no viable alternative. A better approach is one where a feature is optional based on whether the platform you are running on supports that feature. Especially given, as you pointed out, that features that are only available in one platform today might make their way into other platforms tomorrow. As for how to let an application know whether they can use a particular API, we already have ConditionalFeature, so adding to that would be a reasonable thing to consider.
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>>>> Greetings!
>>>>  
>>>> Thank you for proposing a solution, Florian.  I wonder if we should extrapolate the problem further.  Given the fact that app developers always need access to platform specific APIs, be it integration with Mac menu, perhaps we should consider a way to do so in such a way that does not require various tricks.
>>>>  
>>>> For example, we might invent a way to query whether we are running on a certain platform and get the corresponding APIs.  Let's say the class is PlatformAPI:
>>>>  
>>>> These methods allow for querying whether the specific platform APIs are available
>>>>  
>>>> PlatformAPI.isWindows();
>>>> PlatformAPI.isMacOS();
>>>> PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>>>>  
>>>>  
>>>> and these will actually return a service object that provides access to the APIs, or throws some kind of exception:
>>>>  
>>>> IWindowsAPI PlatformAPI.getWindowsAPI();
>>>> IMacOSAPI PlatformAPI.getMacOSAPI();
>>>>  
>>>> the service object returned by one of these methods might provide further information about the platform version, as well as access to platform-specific APIs.
>>>>  
>>>>  
>>>> Another thought is perhaps we ought to think about expanding functionality that became available on every platform in the XXI century (example: going to sleep/hibernate).  Possibly external shutdown via Mac menu or a signal discussed by the OP would be considered as platform-independent.
>>>>  
>>>> What do you think?
>>>>  
>>>> -andy
>>>>  
>>>>  
>>>>  
>>>>  
>>>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Florian Kirmaier <florian.kirmaier at gmail.com>
>>>> Date: Tuesday, 2022/09/13 at 08:11
>>>> To: openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
>>>> Subject: Provide Quit handler for system menu bar
>>>> 
>>>> Hi Everyone,
>>>> 
>>>> In one project, we have to handle the quit-logic for MacOS ourselves,
>>>> when the <quit app> menu entry is used.
>>>> As background information - this menu entry is set in the class com.sun.glass.ui.mac.MacApplication.
>>>> It's basically hard coded. Currently, in this project, the menu entry doesn't work in some cases.
>>>> 
>>>> My Solution would be:
>>>> 
>>>> Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
>>>> This handler is called when quit <appname> from the menu is called.
>>>> If the handler returns true, all windows are closed. Otherwise, nothing happens.
>>>> 
>>>> It would look like the following:
>>>> ```
>>>> /**
>>>>  * Sets the handler to be called when the application is about to quit.
>>>>  * Currently, this can only happen on MacOS.
>>>>  *
>>>>  * This handler is called, when the user selects
>>>>  * the "Quit <appname>" from the application menu.
>>>>  * When the provided handler returns true,
>>>>  * the application will close all windows.
>>>>  * If the handler returns false, the application will not quit.
>>>>  *
>>>>  * @param The new quit handler.
>>>>  */
>>>> public static void setQuitHandler(Supplier x) {
>>>>     ...
>>>> }
>>>> ```
>>>> I've created a ticket for this topic. https://bugs.openjdk.org/browse/JDK-8293700
>>>> 
>>>> I've got a working version for this change. 
>>>> According to Kevin Rushforth this need a prior dicussion on the mailing list.
>>>> Any opinion regarding this?
>>>> 
>>>> I could provide a pullrequest, if someone is interested.
>>>> 
>>>> Florian Kirmaier
>>>>  
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220920/2f93ec7a/attachment-0001.htm>

From philip.race at oracle.com  Tue Sep 20 17:57:29 2022
From: philip.race at oracle.com (Philip Race)
Date: Tue, 20 Sep 2022 10:57:29 -0700
Subject: Provide Quit handler for system menu bar
In-Reply-To: <0D317235-1194-44F0-B989-AC81A5D40C64@gmail.com>
References: <38b8838b-a63f-ead2-e498-076e04419cdc@gmail.com>
 <0D317235-1194-44F0-B989-AC81A5D40C64@gmail.com>
Message-ID: <8d6bc2ef-e918-ffbf-ceb0-a29ad290d694@oracle.com>

All of these requests seem to map to what we added to AWT in JDK 9.
We did this because there'd been Apple specific APIs that came in via the
Apple port but were very iffy in terms of what was supported and it was
not a good idea to formally export them from the new desktop module.

The java.awt.Desktop class was enhanced by the java.awt.desktop package
and all of these things are provided in a platform neutral way.
You just query whether the support is available.

These can even be used in a mixed AWT/FX application if you want a 
solution now,
but FX could have its own version of these.

Nothing that mentions a platform (please!).

-phil

On 9/20/22 6:38 AM, Scott Palmer wrote:
> I always understood Alt+F4 as simply being a keyboard shortcut on 
> Windows for closing the window of the active application. ?The same as 
> clicking the close widget. ?I don?t think there is anything special 
> about it. ?As far as being an equivalent to the macOS Quit action, I 
> don?t think it is quite the same. Does an application even know the 
> difference between a window closed with the widget vs. Alt+F4? CTRL+F4 
> closes the current document window or tab - similar to Command-W on 
> macOS.
>
> I?m not aware of any special handlers being called on Windows for 
> these shortcuts other than what is called when the equivalent close 
> widget is pressed. If I?m wrong about that, then sure, a quit handler 
> for JavaFX could be wired in to the same mechanism automatically. 
> ?Maybe Linux has an equivalent as well, I don?t know.
>
> While we are at it, custom handling for the ?About? menu item in the 
> application menu is also needed, is it not?
>
> For now I?m currently using Jan Gassen?s port of NSMenuFX to hook into 
> this stuff. https://github.com/0x4a616e/NSMenuFX
>
>
> Scott
>
>> On Sep 20, 2022, at 5:55 AM, John Hendrikx <john.hendrikx at gmail.com> 
>> wrote:
>>
>> ?
>>
>> What about Alt + F4 and Ctrl + F4 on Windows?? Alt + F4 closes the 
>> application (which works with JavaFX already) and Ctrl + F4 is 
>> supposed to close a single window, but that doesn't work for JavaFX.
>>
>> Also very much in favor of Keeping the API platform neutral, that's 
>> just how Java has worked since its inception.
>>
>> --John
>>
>> On 20/09/2022 06:25, Scott Palmer wrote:
>>> Windows applications often have an ?Exit? menu item, but since it 
>>> isn?t standardized like it is on macOS, calling a quit handler for 
>>> it would need to be a manual step - but the exact same method for 
>>> the quit handler could be called, leaving it up to the programmer to 
>>> continue or not with the application exit depending on the return 
>>> value. This manual coding isn?t a big deal since you would also need 
>>> to have some app-specific handling to avoid making an Exit menu item 
>>> on macOS, where it would look out of place.
>>>
>>> You could add a standard ?requestExit()? method to Platform that you 
>>> could manually bind to an Exit menu item on Windows or Linux, but it 
>>> would be automatically called via an internal macOS Quit handler 
>>> implementation. ?The implementation of Platform.requestExit() on 
>>> *all* platforms would call a boolean method if one was registered 
>>> and then conditionally call Platform.exit() depending on the return 
>>> value, the default being to always exit if nothing was registered. 
>>> On macOS it would pass on the value to veto the native Quit handler 
>>> as needed. I haven?t checked, does Application.stop() get called on 
>>> macOS if you exit via the Quit menu or Command-Q? If it doesn?t, 
>>> that?s another benefit. ?This idea should probably be opt-in via 
>>> some API or system property, I suppose it would have to be if it 
>>> changes behaviour of having Application.stop() called in some 
>>> circumstances. Or you can just make the setting of the handler 
>>> function the ?opt-in?.
>>>
>>> Btw, this reminds me of the long-standing request for system tray 
>>> support, along with with various other features that have 
>>> equivalents across multiple OS?, like showing progress on the dock 
>>> icon, or a numbered badge (for notifications, or unread msgs, etc). 
>>> ?I think there are already issues in Jira for these, maybe just as a 
>>> general request to support some features that AWT/Swing has that JFX 
>>> is still missing. Most of these features are available on both Mac 
>>> and Windows, possibly Linux. ?It would be irritating to code to 
>>> different APIs for each if it can be avoided, so I agree with going 
>>> for a platform-neutral way.
>>>
>>> Cheers,
>>>
>>> Scott
>>>
>>>> On Sep 19, 2022, at 8:11 PM, Kevin Rushforth 
>>>> <kevin.rushforth at oracle.com> wrote:
>>>>
>>>> ? I don't see us adding 100s of OS-specific API calls, but even if 
>>>> we did, going down the path of exposing them as Mac APIs or Windows 
>>>> APIs, doesn't really seem like the direction we want to go. 
>>>> Whatever we do needs to balance the desire to integrate with, e.g., 
>>>> the macOS or Windows platform with a desire to leave the door open 
>>>> for it to later be implemented on the other platform(s). And the 
>>>> most cross-platform way to do that from an API point of view is by 
>>>> defining API that delivers the desired functionality in as 
>>>> platform-neutral a way as possible. It also needs to fit cleanly 
>>>> into the existing API.
>>>>
>>>> So in the specific case of a quit handler, we could define a 
>>>> platform API that an app could call to register a handler that gets 
>>>> called if the platform quit menu is selected and is able to cancel 
>>>> the Quit action(basically, that's what is being proposed). We could 
>>>> decide to provide some way for an app to query whether it is 
>>>> supported, but maybe we just don't need to worry about it in this 
>>>> specific case. We could just document that it will get called when 
>>>> the platform quit action is called, if there is such an action on 
>>>> that platform. Other than maybe mentioning in the docs that the 
>>>> macOS system menu "quit" action is an example of an action that 
>>>> would invoke this, it doesn't need to be platform-specific. One 
>>>> question to answer is whether we should just put this in the 
>>>> Platform class (where we have other similar "global" application 
>>>> state), the Application class (which has the life-cycle APIs), or 
>>>> somewhere else (which might make sense if we wanted to define an 
>>>> analog to the AWT Desktop class, although the existing Platform 
>>>> class already has some APIs like this).
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>>>>>
>>>>> Thank you, Kevin.? Your insightful feedback always pulls the 
>>>>> discussion in the right direction.
>>>>>
>>>>> The initial problem we are facing is access to Mac menu in general 
>>>>> and additional API specifically.? I can see a possibility of 
>>>>> extending the list of APIs that app devs would want on Mac 
>>>>> growing, so there should be a better way to add them. Using hacks 
>>>>> like com.apple.eawt, or system properties is probably not the best 
>>>>> solution. ?Ideally, there should be away that does not require 
>>>>> creative linking of stub classes on non-Mac platforms, i.e. we 
>>>>> should be able to use a single code base for all the platforms.
>>>>>
>>>>> ConditionalFeature might work well internally for openjfx, but I 
>>>>> don't think it is a good solution for actually exposing the 
>>>>> platform APIs to the user.
>>>>>
>>>>> So, in order to provide platform-specific API in such a way that 
>>>>> still allows for a single code base for multiple platform, and one 
>>>>> that potentially scales to tens or hundreds of API calls, I see 
>>>>> two solutions:
>>>>>
>>>>> 1. one start starts with a single entry point, like PlatformAPI, 
>>>>> described earlier.
>>>>>
>>>>> 2. a lookup-based approach, where the client code requests a 
>>>>> (possibly fine-grained and narrowly defined) implementation from 
>>>>> the system.? For example:
>>>>>
>>>>> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>>>>>
>>>>> (where IMacMenu is an interface that, in this example, provides 
>>>>> access to Mac menu, adding shutdown listeners, and so forth).
>>>>>
>>>>> if we are on windows, this method either returns null or throws an 
>>>>> exception, if we are on Mac, we get a working instance (a 
>>>>> singleton or a new instance each time, depending on the 
>>>>> circumstances).
>>>>>
>>>>> This way we are free to extend or version the APIs without 
>>>>> modifying the core classes.
>>>>>
>>>>> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see 
>>>>> whether the capability is present.
>>>>>
>>>>> The platform-specific interfaces like IMacMenu might in turn 
>>>>> extend some base interface that provides introspection into common 
>>>>> properties, such as version, description, possibly a list of other 
>>>>> similar capabilities that the platform supports (may be a number 
>>>>> of earlier versions?) and so forth.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> -andy
>>>>>
>>>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of 
>>>>> Kevin Rushforth <kevin.rushforth at oracle.com>
>>>>> *Date: *Monday, 2022/09/19 at 09:33
>>>>> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
>>>>> *Subject: *Re: Provide Quit handler for system menu bar
>>>>>
>>>>> I like the idea of looking at this holistically, even if we do end 
>>>>> up adding such features one at a time.
>>>>>
>>>>> As for how to expose such an API, I don't much like the idea of 
>>>>> exposing the underlying platform explicitly unless there is no 
>>>>> viable alternative. A better approach is one where a feature is 
>>>>> optional based on whether the platform you are running on supports 
>>>>> that feature. Especially given, as you pointed out, that features 
>>>>> that are only available in one platform today might make their way 
>>>>> into other platforms tomorrow. As for how to let an application 
>>>>> know whether they can use a particular API, we already have 
>>>>> ConditionalFeature, so adding to that would be a reasonable thing 
>>>>> to consider.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>>>>>
>>>>>     Greetings!
>>>>>
>>>>>     Thank you for proposing a solution, Florian.? I wonder if we
>>>>>     should extrapolate the problem further.? Given the fact that
>>>>>     app developers always need access to platform specific APIs,
>>>>>     be it integration with Mac menu, perhaps we should consider a
>>>>>     way to do so in such a way that does not require various tricks.
>>>>>
>>>>>     For example, we might invent a way to query whether we are
>>>>>     running on a certain platform and get the corresponding APIs.?
>>>>>     Let's say the class is PlatformAPI:
>>>>>
>>>>>     These methods allow for querying whether the specific platform
>>>>>     APIs are available
>>>>>
>>>>>     PlatformAPI.isWindows();
>>>>>
>>>>>     PlatformAPI.isMacOS();
>>>>>
>>>>>     PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>>>>>
>>>>>     and these will actually return a service object that provides
>>>>>     access to the APIs, or throws some kind of exception:
>>>>>
>>>>>     IWindowsAPI PlatformAPI.getWindowsAPI();
>>>>>
>>>>>     IMacOSAPI PlatformAPI.getMacOSAPI();
>>>>>
>>>>>     the service object returned by one of these methods might
>>>>>     provide further information about the platform version, as
>>>>>     well as access to platform-specific APIs.
>>>>>
>>>>>     Another thought is perhaps we ought to think about expanding
>>>>>     functionality that became available on every platform in the
>>>>>     XXI century (example: going to sleep/hibernate). Possibly
>>>>>     external shutdown via Mac menu or a signal discussed by the OP
>>>>>     would be considered as platform-independent.
>>>>>
>>>>>     What do you think?
>>>>>
>>>>>     -andy
>>>>>
>>>>>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>>>>>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Florian
>>>>>     Kirmaier <florian.kirmaier at gmail.com>
>>>>>     <mailto:florian.kirmaier at gmail.com>
>>>>>     *Date: *Tuesday, 2022/09/13 at 08:11
>>>>>     *To: *openjfx-dev at openjdk.java.net
>>>>>     <openjfx-dev at openjdk.java.net>
>>>>>     <mailto:openjfx-dev at openjdk.java.net>
>>>>>     *Subject: *Provide Quit handler for system menu bar
>>>>>
>>>>>     Hi Everyone,
>>>>>
>>>>>
>>>>>     In one project, we have to handle the quit-logic for MacOS
>>>>>     ourselves,
>>>>>     when the <quit app> menu entry is used.
>>>>>     As background information - this menu entry is set in the
>>>>>     class?com.sun.glass.ui.mac.MacApplication.
>>>>>     It's basically hard coded. Currently, in this project, the
>>>>>     menu entry doesn't work in some cases.
>>>>>
>>>>>     My Solution would be:
>>>>>
>>>>>     Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
>>>>>     This handler is called when quit <appname> from the menu is
>>>>>     called.
>>>>>     If the handler returns true, all windows are closed.
>>>>>     Otherwise, nothing happens.
>>>>>
>>>>>     It would look like the following:
>>>>>     ```
>>>>>     /**
>>>>>     ?* Sets the handler to be called when the application is about
>>>>>     to quit.
>>>>>     ?* Currently, this can only happen on MacOS.
>>>>>     ?*
>>>>>     ?* This handler is called, when the user selects
>>>>>     ?* the "Quit <appname>" from the application menu.
>>>>>     ?* When the provided handler returns true,
>>>>>     ?* the application will close all windows.
>>>>>     ?* If the handler returns false, the application will not quit.
>>>>>     ?*
>>>>>     ?* @param The new quit handler.
>>>>>     ?*/
>>>>>     public static void setQuitHandler(Supplier x) {
>>>>>     ? ? ...
>>>>>     }
>>>>>     ```
>>>>>     I've created a ticket for this topic.
>>>>>     https://bugs.openjdk.org/browse/JDK-8293700
>>>>>
>>>>>
>>>>>     I've got a working version for this change.
>>>>>
>>>>>     According to Kevin Rushforth this need a prior dicussion?on
>>>>>     the mailing list.
>>>>>
>>>>>     Any opinion regarding this?
>>>>>
>>>>>     I could provide a pullrequest, if someone is interested.
>>>>>
>>>>>     Florian Kirmaier
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220920/0e29de96/attachment-0001.htm>

From kcr at openjdk.org  Tue Sep 20 18:14:59 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 20 Sep 2022 18:14:59 GMT
Subject: RFR: 8293839: Documentation memory consistency effects of runLater
In-Reply-To: <1tbfqMpro3JJFTlWr_NruPYMphdqIkrU0mZhD-W49hc=.d87bc9ca-117a-47bb-834b-41b0c1b978fe@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
 <4pJhZUn_kT_ntTqdlxJQTLsDukkMNyjtxP4Smo-Q6gA=.028ebf34-43f2-4a34-8094-33073da21cb1@github.com>
 <_Hm2RRHRQWAKm_NKMRvOfevV4S1H_ArUI_LrLLYA1zs=.ba60a65f-7aeb-4b69-8cc3-8f82c40cbc15@github.com>
 <LdP_F8nJXmCDSXcFAmvrIuW0s25UhvArnYFV4A4I1CM=.51cb193a-1be9-4cb2-b5c7-e53e761f2a41@github.com>
 <1tbfqMpro3JJFTlWr_NruPYMphdqIkrU0mZhD-W49hc=.d87bc9ca-117a-47bb-834b-41b0c1b978fe@github.com>
Message-ID: <yAi4v_--6nmCgJ7zM7r40qgamhxtCaORXgKeawOCOqo=.73fd5ece-5921-464a-b6f4-bae3766a71fa@github.com>

On Thu, 15 Sep 2022 12:10:25 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

>>> Do I remove the summary by issuing and empty `/summary`?
>>> 
>>> Will the commit message of the squshed commit be taken from the PR description?
>> 
>> Yes to both questions.
>
> @kevinrushforth I think this is now finished.
> 
> Thanks for teaching me about the OpenJDK contribution process! :)

@jensli This is now ready for you to `/integrate`.

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

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

From angorya at openjdk.org  Tue Sep 20 19:06:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 Sep 2022 19:06:19 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
Message-ID: <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8292353: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/13ee82f4..324828ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=10-11

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

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

From angorya at openjdk.org  Tue Sep 20 19:06:20 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 20 Sep 2022 19:06:20 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v11]
In-Reply-To: <qwlX4-0tLGKtM59stCHWzQHt1DeU_fZXkpPTkNeSICE=.81a21c56-4d33-4350-adae-9310ac10fadf@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <8G4s2cMFGjWygaMqZmT7UANZb_YxGZUcjFOVdf-At98=.15560f48-acde-4ee0-b546-a7737d93450f@github.com>
 <qwlX4-0tLGKtM59stCHWzQHt1DeU_fZXkpPTkNeSICE=.81a21c56-4d33-4350-adae-9310ac10fadf@github.com>
Message-ID: <S2GbE4_9We56xe4-Gcg36wet9MJAJ_f3u5bmEYrpOjU=.604916f7-8621-4f91-a93f-b079d216ae3b@github.com>

On Tue, 20 Sep 2022 12:49:01 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292353: review comments
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlUtils.java line 201:
> 
>> 199:     /**
>> 200:      * Finds a Node given the selector and predicate filter, then insures there is
>> 201:      * one one such node
> 
> Comment has a typo : "one one"?

only one.  fixed.  thank you.

> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeAndTableViewTest.java line 61:
> 
>> 59:     }
>> 60: 
>> 61:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
> 
> Comment needs correction. `TreeTableView` should be `TableView` & `TreeTableRows` should be `TableRows`

fixed, thank you.

> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 840:
> 
>> 838:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
>> 839:     @Test
>> 840:     public void test_TreeTableView_jdk_8292353_select_all() {
> 
> This test passes with or without the code changes.
> If test intention is to increase coverage, then the comment `// JDK-8292353 failure` needs to be removed. If not, the test needs some correction.

similarly, this test also fails without code changes:


TreeTableRowTest > test_TreeTableView_jdk_8292353_select_all FAILED
    org.opentest4j.AssertionFailedError: expected: <false> but was: <true>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)
        at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35)
        at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227)
        at app//test.javafx.scene.control.TreeTableRowTest.test_TreeTableView_jdk_8292353_select_all(TreeTableRowTest.java:870)

> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 875:
> 
>> 873:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
>> 874:     @Test
>> 875:     public void test_TreeTableView_jdk_8292353_select_all_but_one() {
> 
> This test passes with or without the code changes.
> If test intention is to increase coverage, then the comment `// JDK-8292353 failure` needs to be removed. If not, the test needs some correction.

I don't understand.  It fails for me


TreeTableRowTest > test_TreeTableView_jdk_8292353_select_all_but_one FAILED
    org.opentest4j.AssertionFailedError: expected: <false> but was: <true>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)
        at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35)
        at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227)
        at app//test.javafx.scene.control.TreeTableRowTest.test_TreeTableView_jdk_8292353_select_all_but_one(TreeTableRowTest.java:902)


command line:

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

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

From duke at openjdk.org  Tue Sep 20 20:59:30 2022
From: duke at openjdk.org (Jens Lidestrom)
Date: Tue, 20 Sep 2022 20:59:30 GMT
Subject: Integrated: 8293839: Documentation memory consistency effects of
 runLater
In-Reply-To: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
References: <Wj6sfbSzaDsMJvHN4AdpcPEu7ysQBjmY7bFk3bOELLM=.052af171-28df-40b8-a366-1c8cdd576f6b@github.com>
Message-ID: <W7ZlPKVhLmL0v7n7OH1SWEL-Crma671jWPqL2mJ_RiQ=.f1604ed3-4473-4891-ad0c-492dfcebc784@github.com>

On Wed, 17 Aug 2022 07:21:43 GMT, Jens Lidestrom <duke at openjdk.org> wrote:

> Prior to this change it was not clear from the documentation if callers of Platform#runLater must perform
> any synchronisation to have writes of the calling thread be visible in the JavaFX Application
> Thread. It is important to document either if callers can rely on runLater to do such synchronisation
> internally, or to document is users CAN NOT rely on runLater for this.
> 
> This change documents that actions in a thread prior to submitting a runnable to
> Platform#runLater happen-before actions performed by the runnable in the JavaFX
> Application Thread.
> 
> runLater inherits the memory consistency effects of InvokeLaterDispatcher in most cases. 
> InvokeLaterDispatcher uses BlockingDeque internally. This change documents this
> in the same way as it is documented by BlockingDeque.
> 
> Other implementations of runLater should have similar memory consistency effects.

This pull request has now been integrated.

Changeset: 7c6a54d4
Author:    Jens Lidestrom <jens at lidestrom.se>
Committer: Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7c6a54d41945a21d2a4f0eceae56b5ba3df9f39f
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8293839: Documentation memory consistency effects of runLater

Reviewed-by: kcr

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

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

From aghaisas at openjdk.org  Wed Sep 21 06:18:59 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 21 Sep 2022 06:18:59 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v11]
In-Reply-To: <S2GbE4_9We56xe4-Gcg36wet9MJAJ_f3u5bmEYrpOjU=.604916f7-8621-4f91-a93f-b079d216ae3b@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <8G4s2cMFGjWygaMqZmT7UANZb_YxGZUcjFOVdf-At98=.15560f48-acde-4ee0-b546-a7737d93450f@github.com>
 <qwlX4-0tLGKtM59stCHWzQHt1DeU_fZXkpPTkNeSICE=.81a21c56-4d33-4350-adae-9310ac10fadf@github.com>
 <S2GbE4_9We56xe4-Gcg36wet9MJAJ_f3u5bmEYrpOjU=.604916f7-8621-4f91-a93f-b079d216ae3b@github.com>
Message-ID: <5-7NOxO2iiRbPNE4FeFqEQhTCkMNcA5x2BLuGBg4OHg=.953f5e83-3568-43d1-8958-2f6e1fa652f9@github.com>

On Tue, 20 Sep 2022 18:59:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 840:
>> 
>>> 838:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
>>> 839:     @Test
>>> 840:     public void test_TreeTableView_jdk_8292353_select_all() {
>> 
>> This test passes with or without the code changes.
>> If test intention is to increase coverage, then the comment `// JDK-8292353 failure` needs to be removed. If not, the test needs some correction.
>
> similarly, this test also fails without code changes:
> 
> 
> TreeTableRowTest > test_TreeTableView_jdk_8292353_select_all FAILED
>     org.opentest4j.AssertionFailedError: expected: <false> but was: <true>
>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>         at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)
>         at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35)
>         at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227)
>         at app//test.javafx.scene.control.TreeTableRowTest.test_TreeTableView_jdk_8292353_select_all(TreeTableRowTest.java:870)

A clean build and run behaves correctly. This test fails without code changes and passes with them.
Sorry for the confusion!

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 875:
>> 
>>> 873:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
>>> 874:     @Test
>>> 875:     public void test_TreeTableView_jdk_8292353_select_all_but_one() {
>> 
>> This test passes with or without the code changes.
>> If test intention is to increase coverage, then the comment `// JDK-8292353 failure` needs to be removed. If not, the test needs some correction.
>
> I don't understand.  It fails for me
> 
> 
> TreeTableRowTest > test_TreeTableView_jdk_8292353_select_all_but_one FAILED
>     org.opentest4j.AssertionFailedError: expected: <false> but was: <true>
>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>         at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)
>         at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35)
>         at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227)
>         at app//test.javafx.scene.control.TreeTableRowTest.test_TreeTableView_jdk_8292353_select_all_but_one(TreeTableRowTest.java:902)
> 
> 
> command line:

A clean build and run behaves correctly. This test fails without code changes and passes with them.
Sorry for the confusion!

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

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

From aghaisas at openjdk.org  Wed Sep 21 07:24:55 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Wed, 21 Sep 2022 07:24:55 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
Message-ID: <nTNfR8S-l8n6vDtylzUw8MOAsRZI_TXCcrU7UPyuUKI=.f17ddd67-fe99-41dc-abe5-bd6608830186@github.com>

On Tue, 20 Sep 2022 19:06:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: review comments

Marked as reviewed by aghaisas (Reviewer).

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

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

From hmeda at openjdk.org  Wed Sep 21 07:53:42 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 21 Sep 2022 07:53:42 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v5]
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <MoObPNO9vRnJzpgicP8_rCq2Y79PG6W91m99FR1ho_4=.26f6facb-5259-413f-8492-258dde76230b@github.com>

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Update icu_web.md

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/893/files
  - new: https://git.openjdk.org/jfx/pull/893/files/c9678a25..22c8e530

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

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

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

From jvos at openjdk.org  Wed Sep 21 10:06:59 2022
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 21 Sep 2022 10:06:59 GMT
Subject: RFR: 8254676: Alert disables Tab selection when TabDragPolicy
 REORDER is used
In-Reply-To: <zmKf2JzkT5VNQGNUo7waznl9JctUXrLdV8HF6l9-IQg=.e41ca2b3-94cc-4bc5-8a6a-bd704d5091f2@github.com>
References: <M_UldTEZfn072rPUS8OvvUfEOv_PbDZi4K7xrbEHJ0Q=.944ed2b9-fd84-4d0f-ae10-5d680ef605c9@github.com>
 <zmKf2JzkT5VNQGNUo7waznl9JctUXrLdV8HF6l9-IQg=.e41ca2b3-94cc-4bc5-8a6a-bd704d5091f2@github.com>
Message-ID: <2g79fg1YhnczAxuRC5QNTNiyV0IMNPfQ1Fh4yQnlgXs=.16eb1c14-aa84-4cb7-8aad-22edff9ba8e8@github.com>

On Mon, 19 Sep 2022 11:43:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> The fix looks good to me. Testing looks good. But I am not sure why I had included this call at the time of implementation. Requesting @kevinrushforth to take a look.

I was wondering about the original reason to include these calls. I think it may be because of the javadoc for MouseDragEvent (https://openjfx.io/javadoc/19/javafx.graphics/javafx/scene/input/MouseDragEvent.html):

You can achieve this by calling setMouseTransparent(true) on the dragged node in a MOUSE_PRESSED handler and returning it back to false in a MOUSE_RELEASED handler.

This scenario doesn't take into account the case where for some reason a MOUSE_RELEASED event is never received on the specific node -- which is the case when an Alert is being shown.

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

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

From florian.kirmaier at gmail.com  Wed Sep 21 11:59:40 2022
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Wed, 21 Sep 2022 13:59:40 +0200
Subject: Provide Quit handler for system menu bar
In-Reply-To: <8d6bc2ef-e918-ffbf-ceb0-a29ad290d694@oracle.com>
References: <38b8838b-a63f-ead2-e498-076e04419cdc@gmail.com>
 <0D317235-1194-44F0-B989-AC81A5D40C64@gmail.com>
 <8d6bc2ef-e918-ffbf-ceb0-a29ad290d694@oracle.com>
Message-ID: <CA+4mSqZ6e2whAOSgVsuZ6UJtFDqtRSkOjYn8okSaSAgDYjOnLA@mail.gmail.com>

Yes, a custom "about menu" handling would be very similar and could be
implemented at the same time.

It's worth mentioning, that we cannot use the methods java.awt.Desktop
setAboutHandler and setQuitHandler methods,
because they only work, if the menu is from Swing. They don't work when the
menu bar is from JavaFX.

For that reason, it might be the case, that more of the methods, provided
in awt.Desktop are required in some cases.

So how could this look?

I think it would make sense, to make the API very similar to the existing
API in Swing.
This would make it easier for Developers to get used to the API, or to
switch form the Swing call to the new JavaFX call, if someone is migrating
from Swing to JavaFX.
```
javafx.application.Desktop {
boolean isSupported(Feature)
void setQuitHandler(Supplier<Boolean>)
}
```
Would this meet the expectation, of how this could look?
Alternatively, these methods could be added to the Platform class, but I
think it would make sense to create a new class for this.

On Tue, 20 Sept 2022 at 19:57, Philip Race <philip.race at oracle.com> wrote:

> All of these requests seem to map to what we added to AWT in JDK 9.
> We did this because there'd been Apple specific APIs that came in via the
> Apple port but were very iffy in terms of what was supported and it was
> not a good idea to formally export them from the new desktop module.
>
> The java.awt.Desktop class was enhanced by the java.awt.desktop package
> and all of these things are provided in a platform neutral way.
> You just query whether the support is available.
>
> These can even be used in a mixed AWT/FX application if you want a
> solution now,
> but FX could have its own version of these.
>
> Nothing that mentions a platform (please!).
>
> -phil
>
> On 9/20/22 6:38 AM, Scott Palmer wrote:
>
> I always understood Alt+F4 as simply being a keyboard shortcut on Windows
> for closing the window of the active application.  The same as clicking the
> close widget.  I don?t think there is anything special about it.  As far as
> being an equivalent to the macOS Quit action, I don?t think it is quite the
> same. Does an application even know the difference between a window closed
> with the widget vs. Alt+F4? CTRL+F4 closes the current document window or
> tab - similar to Command-W on macOS.
>
> I?m not aware of any special handlers being called on Windows for these
> shortcuts other than what is called when the equivalent close widget is
> pressed. If I?m wrong about that, then sure, a quit handler for JavaFX
> could be wired in to the same mechanism automatically.  Maybe Linux has an
> equivalent as well, I don?t know.
>
> While we are at it, custom handling for the ?About? menu item in the
> application menu is also needed, is it not?
>
> For now I?m currently using Jan Gassen?s port of NSMenuFX to hook into
> this stuff. https://github.com/0x4a616e/NSMenuFX
>
>
> Scott
>
> On Sep 20, 2022, at 5:55 AM, John Hendrikx <john.hendrikx at gmail.com>
> <john.hendrikx at gmail.com> wrote:
>
> ?
>
> What about Alt + F4 and Ctrl + F4 on Windows?  Alt + F4 closes the
> application (which works with JavaFX already) and Ctrl + F4 is supposed to
> close a single window, but that doesn't work for JavaFX.
>
> Also very much in favor of Keeping the API platform neutral, that's just
> how Java has worked since its inception.
>
> --John
> On 20/09/2022 06:25, Scott Palmer wrote:
>
> Windows applications often have an ?Exit? menu item, but since it isn?t
> standardized like it is on macOS, calling a quit handler for it would need
> to be a manual step - but the exact same method for the quit handler could
> be called, leaving it up to the programmer to continue or not with the
> application exit depending on the return value. This manual coding isn?t a
> big deal since you would also need to have some app-specific handling to
> avoid making an Exit menu item on macOS, where it would look out of place.
>
>
> You could add a standard ?requestExit()? method to Platform that you could
> manually bind to an Exit menu item on Windows or Linux, but it would be
> automatically called via an internal macOS Quit handler implementation.
> The implementation of Platform.requestExit() on *all* platforms would call
> a boolean method if one was registered and then conditionally call
> Platform.exit() depending on the return value, the default being to always
> exit if nothing was registered. On macOS it would pass on the value to veto
> the native Quit handler as needed.  I haven?t checked, does
> Application.stop() get called on macOS if you exit via the Quit menu or
> Command-Q? If it doesn?t, that?s another benefit.  This idea should
> probably be opt-in via some API or system property, I suppose it would have
> to be if it changes behaviour of having Application.stop() called in some
> circumstances. Or you can just make the setting of the handler function the
> ?opt-in?.
>
> Btw, this reminds me of the long-standing request for system tray
> support, along with with various other features that have equivalents
> across multiple OS?, like showing progress on the dock icon, or a numbered
> badge (for notifications, or unread msgs, etc).  I think there are already
> issues in Jira for these, maybe just as a general request to support some
> features that AWT/Swing has that JFX is still missing. Most of these
> features are available on both Mac and Windows, possibly Linux.  It would
> be irritating to code to different APIs for each if it can be avoided, so I
> agree with going for a platform-neutral way.
>
> Cheers,
>
> Scott
>
> On Sep 19, 2022, at 8:11 PM, Kevin Rushforth <kevin.rushforth at oracle.com>
> <kevin.rushforth at oracle.com> wrote:
>
> ? I don't see us adding 100s of OS-specific API calls, but even if we did,
> going down the path of exposing them as Mac APIs or Windows APIs, doesn't
> really seem like the direction we want to go. Whatever we do needs to
> balance the desire to integrate with, e.g., the macOS or Windows platform
> with a desire to leave the door open for it to later be implemented on the
> other platform(s). And the most cross-platform way to do that from an API
> point of view is by defining API that delivers the desired functionality in
> as platform-neutral a way as possible. It also needs to fit cleanly into
> the existing API.
>
> So in the specific case of a quit handler, we could define a platform API
> that an app could call to register a handler that gets called if the
> platform quit menu is selected and is able to cancel the Quit
> action(basically, that's what is being proposed). We could decide to
> provide some way for an app to query whether it is supported, but maybe we
> just don't need to worry about it in this specific case. We could just
> document that it will get called when the platform quit action is called,
> if there is such an action on that platform. Other than maybe mentioning in
> the docs that the macOS system menu "quit" action is an example of an
> action that would invoke this, it doesn't need to be platform-specific. One
> question to answer is whether we should just put this in the Platform class
> (where we have other similar "global" application state), the Application
> class (which has the life-cycle APIs), or somewhere else (which might make
> sense if we wanted to define an analog to the AWT Desktop class, although
> the existing Platform class already has some APIs like this).
>
> -- Kevin
>
>
> On 9/19/2022 1:46 PM, Andy Goryachev wrote:
>
> Thank you, Kevin.  Your insightful feedback always pulls the discussion in
> the right direction.
>
>
>
> The initial problem we are facing is access to Mac menu in general and
> additional API specifically.  I can see a possibility of extending the list
> of APIs that app devs would want on Mac growing, so there should be a
> better way to add them.  Using hacks like com.apple.eawt, or system
> properties is probably not the best solution.  Ideally, there should be
> away that does not require creative linking of stub classes on non-Mac
> platforms, i.e. we should be able to use a single code base for all the
> platforms.
>
>
>
> ConditionalFeature might work well internally for openjfx, but I don't
> think it is a good solution for actually exposing the platform APIs to the
> user.
>
>
>
> So, in order to provide platform-specific API in such a way that still
> allows for a single code base for multiple platform, and one that
> potentially scales to tens or hundreds of API calls, I see two solutions:
>
>
>
> 1. one start starts with a single entry point, like PlatformAPI, described
> earlier.
>
>
>
> 2. a lookup-based approach, where the client code requests a (possibly
> fine-grained and narrowly defined) implementation from the system.  For
> example:
>
>
>
> IMacMenu impl = PlatformAPI.lookup(IMacMenu.class);
>
>
>
> (where IMacMenu is an interface that, in this example, provides access to
> Mac menu, adding shutdown listeners, and so forth).
>
>
>
> if we are on windows, this method either returns null or throws an
> exception, if we are on Mac, we get a working instance (a singleton or a
> new instance each time, depending on the circumstances).
>
>
>
> This way we are free to extend or version the APIs without modifying the
> core classes.
>
>
>
> PlatformAPI.isSupported(IMacMenu.class) might provide a way to see whether
> the capability is present.
>
>
>
> The platform-specific interfaces like IMacMenu might in turn extend some
> base interface that provides introspection into common properties, such as
> version, description, possibly a list of other similar capabilities that
> the platform supports (may be a number of earlier versions?) and so forth.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
> <openjfx-dev-retn at openjdk.org> on behalf of Kevin Rushforth
> <kevin.rushforth at oracle.com> <kevin.rushforth at oracle.com>
> *Date: *Monday, 2022/09/19 at 09:33
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> <openjfx-dev at openjdk.org>
> *Subject: *Re: Provide Quit handler for system menu bar
>
> I like the idea of looking at this holistically, even if we do end up
> adding such features one at a time.
>
> As for how to expose such an API, I don't much like the idea of exposing
> the underlying platform explicitly unless there is no viable alternative. A
> better approach is one where a feature is optional based on whether the
> platform you are running on supports that feature. Especially given, as you
> pointed out, that features that are only available in one platform today
> might make their way into other platforms tomorrow. As for how to let an
> application know whether they can use a particular API, we already have
> ConditionalFeature, so adding to that would be a reasonable thing to
> consider.
>
> -- Kevin
>
> On 9/19/2022 9:06 AM, Andy Goryachev wrote:
>
> Greetings!
>
>
>
> Thank you for proposing a solution, Florian.  I wonder if we should
> extrapolate the problem further.  Given the fact that app developers always
> need access to platform specific APIs, be it integration with Mac menu,
> perhaps we should consider a way to do so in such a way that does not
> require various tricks.
>
>
>
> For example, we might invent a way to query whether we are running on a
> certain platform and get the corresponding APIs.  Let's say the class is
> PlatformAPI:
>
>
>
> These methods allow for querying whether the specific platform APIs are
> available
>
>
>
> PlatformAPI.isWindows();
>
> PlatformAPI.isMacOS();
>
> PlatformAPI.isLinux(); // isUnix()? isPosix() ?
>
>
>
>
>
> and these will actually return a service object that provides access to
> the APIs, or throws some kind of exception:
>
>
>
> IWindowsAPI PlatformAPI.getWindowsAPI();
>
> IMacOSAPI PlatformAPI.getMacOSAPI();
>
>
>
> the service object returned by one of these methods might provide further
> information about the platform version, as well as access to
> platform-specific APIs.
>
>
>
>
>
> Another thought is perhaps we ought to think about expanding functionality
> that became available on every platform in the XXI century (example: going
> to sleep/hibernate).  Possibly external shutdown via Mac menu or a signal
> discussed by the OP would be considered as platform-independent.
>
>
>
> What do you think?
>
>
>
> -andy
>
>
>
>
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
> <openjfx-dev-retn at openjdk.org> on behalf of Florian Kirmaier
> <florian.kirmaier at gmail.com> <florian.kirmaier at gmail.com>
> *Date: *Tuesday, 2022/09/13 at 08:11
> *To: *openjfx-dev at openjdk.java.net <openjfx-dev at openjdk.java.net>
> <openjfx-dev at openjdk.java.net>
> *Subject: *Provide Quit handler for system menu bar
>
> Hi Everyone,
>
>
> In one project, we have to handle the quit-logic for MacOS ourselves,
> when the <quit app> menu entry is used.
> As background information - this menu entry is set in the
> class com.sun.glass.ui.mac.MacApplication.
> It's basically hard coded. Currently, in this project, the menu entry
> doesn't work in some cases.
>
> My Solution would be:
>
> Provide a method "Platform.setQuiteHandler(Supplier<Boolean>)"
> This handler is called when quit <appname> from the menu is called.
> If the handler returns true, all windows are closed. Otherwise, nothing
> happens.
>
> It would look like the following:
> ```
> /**
>  * Sets the handler to be called when the application is about to quit.
>  * Currently, this can only happen on MacOS.
>  *
>  * This handler is called, when the user selects
>  * the "Quit <appname>" from the application menu.
>  * When the provided handler returns true,
>  * the application will close all windows.
>  * If the handler returns false, the application will not quit.
>  *
>  * @param The new quit handler.
>  */
> public static void setQuitHandler(Supplier x) {
>     ...
> }
> ```
> I've created a ticket for this topic.
> https://bugs.openjdk.org/browse/JDK-8293700
>
>
> I've got a working version for this change.
>
> According to Kevin Rushforth this need a prior dicussion on the mailing
> list.
>
> Any opinion regarding this?
>
> I could provide a pullrequest, if someone is interested.
>
> Florian Kirmaier
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220921/f1e7058c/attachment-0001.htm>

From fkirmaier at openjdk.org  Wed Sep 21 12:08:55 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 21 Sep 2022 12:08:55 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v4]
In-Reply-To: <g-Ggzq9Ov8UbontgYfSY-uoKaCA2raJkdl4rpckNiDQ=.337c4778-d6c4-4ed4-804f-6f6d1fcda181@github.com>
References: <ZZ4qI4_kz81SYfN64REeXjIt3lsnJT2FHwkUEuOS3gk=.6922b475-acdd-43b5-ace7-72fe1ec94d76@github.com>
 <g-Ggzq9Ov8UbontgYfSY-uoKaCA2raJkdl4rpckNiDQ=.337c4778-d6c4-4ed4-804f-6f6d1fcda181@github.com>
Message-ID: <G5QL5gPwpJLq5oejHxDWEDCSuEoY6DQryl0uh_Fu_oE=.20e11957-dc71-437a-a938-67ed333d8e7b@github.com>

On Mon, 22 Aug 2022 09:46:24 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> It's "a bit" complicated.
>> In some situations, getRuns get's called because listeners on bounds are set.
>> This causes TextFlow to layout to compute the runs.
>> Afterward, the bounds of the parents get updated. 
>> This triggers a call to compute bounds - which cascades up to the children.
>> When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
>> The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
>> 
>> In the case it happened - it didn't repair and the application kinda crashed.
>> This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
>> It also can cause unpredictable performance issues.
>> 
>> Unit test and example stacktrace are in the ticket.
>> 
>> The suggested fix makes sure that recomputing the geometry of the Text, doesn't trigger the layout of the TextFlow. 
>> The Textflow should be layouting by the Parent.
>> This might change the behavior in some cases, but as far as I've tested it works without issues in TextFlow Heavy applications.
>> 
>> Benefits:
>>  * Better Tooling Support For ScenicView etc.
>>  * Fixes complicated but reproducible crashes
>>  * Might fix some rare crashes, which are hard to reproduce
>>  * Likely improves performance - might fix some edge cases with unpredictable bad performance
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269921
>   Reverted the change to the layout, so we can fix the main-bug without further discussions.

The simple null check helps in this case.
But sometimes I see the exception, posted by @Maran23 .
So the root cause is probably not fixed - but the symptoms are.
I guess, this PR is then a good progress.

Imo the main issue is, that having listeners on the bounds causes a change in the behavior of TextFlow and Group - causing unpredictable behavior.

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

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

From kcr at openjdk.org  Wed Sep 21 13:39:07 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Sep 2022 13:39:07 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v5]
In-Reply-To: <MoObPNO9vRnJzpgicP8_rCq2Y79PG6W91m99FR1ho_4=.26f6facb-5259-413f-8492-258dde76230b@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <MoObPNO9vRnJzpgicP8_rCq2Y79PG6W91m99FR1ho_4=.26f6facb-5259-413f-8492-258dde76230b@github.com>
Message-ID: <qe9XGqaSTcgDfWFkhKu1M3pL1QgEjpndMn2fwLKk3ME=.bb1806f2-3190-43bb-ac0e-7a0c277c908d@github.com>

On Wed, 21 Sep 2022 07:53:42 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated icu to v71.1.
>> Verified build and sanity testing on windows,Mac and Linux.
>> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update icu_web.md

It looks like there are 4 missing blank lines in the newly added attribution. Otherwise looks good.

modules/javafx.web/src/main/legal/icu_web.md line 446:

> 444: suitability of this software for any purpose.  It is provided "as is"
> 445: without express or implied warranty.
> 446: ----------------------------------------------------------------------

Add blank line above and below this line.

modules/javafx.web/src/main/legal/icu_web.md line 450:

> 448: File: selfmt.h
> 449: File: selfmtimpl.h
> 450: File: umsg.h

Add blank line here.

modules/javafx.web/src/main/legal/icu_web.md line 453:

> 451: Copyright (c) 1995-2016 International Business Machines Corporation and others
> 452: All rights reserved.
> 453: Copyright (C) 2010 , Yahoo! Inc.

Add blank line here.

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

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

From mstrauss at openjdk.org  Wed Sep 21 13:40:13 2022
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 21 Sep 2022 13:40:13 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v3]
In-Reply-To: <8KHPZhz6IrC74E9dFYFfMzsxdhn_RkF_lg8zuOcMejQ=.9b0652d9-1168-4dd0-ac9a-358ce9257eff@github.com>
References: <ZZ4qI4_kz81SYfN64REeXjIt3lsnJT2FHwkUEuOS3gk=.6922b475-acdd-43b5-ace7-72fe1ec94d76@github.com>
 <uZsDdwFcHBZqf5YHWXyUuEldjSYkenKUhyDItpg3oHg=.c102ccb4-54cd-4238-b283-7e7d5ef5dba3@github.com>
 <8KHPZhz6IrC74E9dFYFfMzsxdhn_RkF_lg8zuOcMejQ=.9b0652d9-1168-4dd0-ac9a-358ce9257eff@github.com>
Message-ID: <YKQLYoKfXQ0j6cdqt6Zg7sbBrdoBFr15xkArR6IGRfE=.407d5e6c-a4ab-48f4-8404-b24c4aed6abd@github.com>

On Fri, 5 Aug 2022 07:34:43 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Florian Kirmaier has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origjfx/master' into JDK-8269921-textflow-bug
>>  - JDK-8269921
>>    Added a copyright header
>>  - JDK-8269921
>>    Fixing a crash related to Text and TextFlow with bounds listeners
>
> I got this problem as well today. NPE as `runs` is null in line `359`. Does it make sense to first 'resolve' this by adding a simple null check and later we may try your other change which removes the call to `getParent().layout()`?
> 
> Edit: I also got another interesting NPE in `PrismTextLayout`:
> 
> java.lang.NullPointerException: Cannot read the array length because "this.runs" is null
> ?? ?at com.sun.javafx.text.PrismTextLayout.addTextRun(PrismTextLayout.java:770)
> ?? ?at com.sun.javafx.text.GlyphLayout.addTextRun(GlyphLayout.java:140)
> ?? ?at com.sun.javafx.text.GlyphLayout.breakRuns(GlyphLayout.java:210)
> ?? ?at com.sun.javafx.text.PrismTextLayout.buildRuns(PrismTextLayout.java:785)
> ?? ?at com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1036)
> ?? ?at com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:223)
> ?? ?at com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:246)
> ?? ?at javafx.scene.text.Text.getLogicalBounds(Text.java:432)
> ?? ?at javafx.scene.text.Text.doComputeGeomBounds(Text.java:1187)
> ?? ?at javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149)
> ?? ?at com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90)
> ?? ?at com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:116)
> ?? ?at javafx.scene.Node.updateGeomBounds(Node.java:3818)
> ?? ?at javafx.scene.Node.getGeomBounds(Node.java:3780)
> ?? ?at javafx.scene.Node.updateBounds(Node.java:776)
> ?? ?at javafx.scene.Parent.updateBounds(Parent.java:1833)
>     ...
>    <<pulse>>

> The simple null check helps in this case. But sometimes I see the exception, posted by @Maran23 . So the root cause is probably not fixed - but the symptoms are. I guess, this PR is then a good progress.

Maybe it's not good progress. You've investigated the issue, and have identified a likely root cause. Not fixing the root cause just means that it most likely won't be fixed for years to come, and the insights you've accumulated will fade.

I think we should just fix the root cause. If some application breaks as a result of this, not much harm is done: we'd gain valuable insight into a real-world situation that depends on the current behavior, and can then decide whether to revert the fix, or provide a viable alternative solution (for users) that accomplishes the same goal.

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

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

From angorya at openjdk.org  Wed Sep 21 14:56:36 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 21 Sep 2022 14:56:36 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v11]
In-Reply-To: <5-7NOxO2iiRbPNE4FeFqEQhTCkMNcA5x2BLuGBg4OHg=.953f5e83-3568-43d1-8958-2f6e1fa652f9@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <8G4s2cMFGjWygaMqZmT7UANZb_YxGZUcjFOVdf-At98=.15560f48-acde-4ee0-b546-a7737d93450f@github.com>
 <qwlX4-0tLGKtM59stCHWzQHt1DeU_fZXkpPTkNeSICE=.81a21c56-4d33-4350-adae-9310ac10fadf@github.com>
 <S2GbE4_9We56xe4-Gcg36wet9MJAJ_f3u5bmEYrpOjU=.604916f7-8621-4f91-a93f-b079d216ae3b@github.com>
 <5-7NOxO2iiRbPNE4FeFqEQhTCkMNcA5x2BLuGBg4OHg=.953f5e83-3568-43d1-8958-2f6e1fa652f9@github.com>
Message-ID: <5UJwFqdHQKhwu120HRbLqeyltXIINQd7kOSyboi3woY=.03fdbca7-594a-4e9c-934f-6b55604a896a@github.com>

On Wed, 21 Sep 2022 06:15:06 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> I don't understand.  It fails for me
>> 
>> 
>> TreeTableRowTest > test_TreeTableView_jdk_8292353_select_all_but_one FAILED
>>     org.opentest4j.AssertionFailedError: expected: <false> but was: <true>
>>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>>         at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:40)
>>         at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:35)
>>         at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:227)
>>         at app//test.javafx.scene.control.TreeTableRowTest.test_TreeTableView_jdk_8292353_select_all_but_one(TreeTableRowTest.java:902)
>> 
>> 
>> command line:
>
> A clean build and run behaves correctly. This test fails without code changes and passes with them.
> Sorry for the confusion!

Thank you, Ajit!

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

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

From hmeda at openjdk.org  Wed Sep 21 16:32:09 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 21 Sep 2022 16:32:09 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v6]
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <Nh2kX3UHJHRu2M3jJmM81wBRWKzGxP_ug0_P_RU9qsY=.02f3df7c-db96-41df-b31b-174290beddcf@github.com>

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:

  Space corrections

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/893/files
  - new: https://git.openjdk.org/jfx/pull/893/files/22c8e530..88301d54

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

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

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

From kcr at openjdk.org  Wed Sep 21 16:42:08 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 21 Sep 2022 16:42:08 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v6]
In-Reply-To: <Nh2kX3UHJHRu2M3jJmM81wBRWKzGxP_ug0_P_RU9qsY=.02f3df7c-db96-41df-b31b-174290beddcf@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <Nh2kX3UHJHRu2M3jJmM81wBRWKzGxP_ug0_P_RU9qsY=.02f3df7c-db96-41df-b31b-174290beddcf@github.com>
Message-ID: <Oi7TQHYTKOa_CJvYFjXRXyGWc_o_xMyxFhMU8E8b8Lw=.8d3b7eda-bc85-4dc7-be86-750319507a68@github.com>

On Wed, 21 Sep 2022 16:32:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated icu to v71.1.
>> Verified build and sanity testing on windows,Mac and Linux.
>> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Space corrections

Approved.

The `icu_web.md` file looks good now. All other testing and review was previously done.

@johanvos or @tiainen can you do a test build?

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

Marked as reviewed by kcr (Lead).

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

From hmeda at openjdk.org  Wed Sep 21 16:42:13 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 21 Sep 2022 16:42:13 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v5]
In-Reply-To: <qe9XGqaSTcgDfWFkhKu1M3pL1QgEjpndMn2fwLKk3ME=.bb1806f2-3190-43bb-ac0e-7a0c277c908d@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <MoObPNO9vRnJzpgicP8_rCq2Y79PG6W91m99FR1ho_4=.26f6facb-5259-413f-8492-258dde76230b@github.com>
 <qe9XGqaSTcgDfWFkhKu1M3pL1QgEjpndMn2fwLKk3ME=.bb1806f2-3190-43bb-ac0e-7a0c277c908d@github.com>
Message-ID: <HXIYGOc7LB5i2216JTp9QvymL3EoSLp3tI_J3-1fAOA=.126f5e64-9f29-42cd-8509-338c45408ba3@github.com>

On Wed, 21 Sep 2022 13:17:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update icu_web.md
>
> modules/javafx.web/src/main/legal/icu_web.md line 446:
> 
>> 444: suitability of this software for any purpose.  It is provided "as is"
>> 445: without express or implied warranty.
>> 446: ----------------------------------------------------------------------
> 
> Add blank line above and below this line.

Done

> modules/javafx.web/src/main/legal/icu_web.md line 450:
> 
>> 448: File: selfmt.h
>> 449: File: selfmtimpl.h
>> 450: File: umsg.h
> 
> Add blank line here.

Done

> modules/javafx.web/src/main/legal/icu_web.md line 453:
> 
>> 451: Copyright (c) 1995-2016 International Business Machines Corporation and others
>> 452: All rights reserved.
>> 453: Copyright (C) 2010 , Yahoo! Inc.
> 
> Add blank line here.

Done

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

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

From jvos at openjdk.org  Wed Sep 21 19:37:22 2022
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 21 Sep 2022 19:37:22 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v6]
In-Reply-To: <Oi7TQHYTKOa_CJvYFjXRXyGWc_o_xMyxFhMU8E8b8Lw=.8d3b7eda-bc85-4dc7-be86-750319507a68@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <Nh2kX3UHJHRu2M3jJmM81wBRWKzGxP_ug0_P_RU9qsY=.02f3df7c-db96-41df-b31b-174290beddcf@github.com>
 <Oi7TQHYTKOa_CJvYFjXRXyGWc_o_xMyxFhMU8E8b8Lw=.8d3b7eda-bc85-4dc7-be86-750319507a68@github.com>
Message-ID: <fjrQoHxyVC4dWlp5YxxVfaqyt_HEYaYiW1Conz4OnSY=.a818c5b3-8036-49db-b7f6-9f2ba560181d@github.com>

On Wed, 21 Sep 2022 16:36:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> @johanvos or @tiainen can you do a test build?

building + testing

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

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

From nlisker at openjdk.org  Wed Sep 21 21:46:23 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 21 Sep 2022 21:46:23 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v4]
In-Reply-To: <eN3dZMOxmHn4gp17E-kamzPntKK7Kvi1PXjxJDgcSp8=.71e5b9d2-f835-44d7-8943-af87ec1c57d5@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <eN3dZMOxmHn4gp17E-kamzPntKK7Kvi1PXjxJDgcSp8=.71e5b9d2-f835-44d7-8943-af87ec1c57d5@github.com>
Message-ID: <PHfuFJRN747UqpJazKion00LsckE--VECRQ-gL4eEbs=.29763f72-147e-47a4-bc1a-aa83c3eaae11@github.com>

On Sun, 4 Sep 2022 19:49:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
>> 
>> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
>> 
>> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
>> 
>>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
>> 
>> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
>> 
>> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
>> 
>> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
>> 
>> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small wording fixes

The docs of `when` look good now (I left one minor comment). I actually didn't think about the name of the method, compared to ReactFX's `conditionOn` for example, but this is good enough until others review.

I haven't looked at the addition to `Node` closely yet. I will look at the implementation and tests of the method itself first because `Node` is a use case.

modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 296:

> 294:      * label.textProperty().bind(longLivedProperty.when(label::isShownProperty));
> 295:      * }</pre>
> 296:      * @param condition a boolean {@code ObservableValue}, cannot be {@code null}

New line before `@param`.

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

Changes requested by nlisker (Reviewer).

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

From duke at openjdk.org  Thu Sep 22 06:31:29 2022
From: duke at openjdk.org (danielpeintner)
Date: Thu, 22 Sep 2022 06:31:29 GMT
Subject: RFR: JDK-8269921 Text in Textflow and listeners on bounds can
 cause endless loop/crash and other performance issues [v3]
In-Reply-To: <YKQLYoKfXQ0j6cdqt6Zg7sbBrdoBFr15xkArR6IGRfE=.407d5e6c-a4ab-48f4-8404-b24c4aed6abd@github.com>
References: <ZZ4qI4_kz81SYfN64REeXjIt3lsnJT2FHwkUEuOS3gk=.6922b475-acdd-43b5-ace7-72fe1ec94d76@github.com>
 <uZsDdwFcHBZqf5YHWXyUuEldjSYkenKUhyDItpg3oHg=.c102ccb4-54cd-4238-b283-7e7d5ef5dba3@github.com>
 <8KHPZhz6IrC74E9dFYFfMzsxdhn_RkF_lg8zuOcMejQ=.9b0652d9-1168-4dd0-ac9a-358ce9257eff@github.com>
 <YKQLYoKfXQ0j6cdqt6Zg7sbBrdoBFr15xkArR6IGRfE=.407d5e6c-a4ab-48f4-8404-b24c4aed6abd@github.com>
Message-ID: <bhZQB0Wa0EQ7vsvCWRvHcnjm9lKhALUm3P0M-OE5aIY=.5f8b925f-158e-479a-adf4-5603d5748646@github.com>

On Wed, 21 Sep 2022 13:27:46 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I got this problem as well today. NPE as `runs` is null in line `359`. Does it make sense to first 'resolve' this by adding a simple null check and later we may try your other change which removes the call to `getParent().layout()`?
>> 
>> Edit: I also got another interesting NPE in `PrismTextLayout`:
>> 
>> java.lang.NullPointerException: Cannot read the array length because "this.runs" is null
>> ?? ?at com.sun.javafx.text.PrismTextLayout.addTextRun(PrismTextLayout.java:770)
>> ?? ?at com.sun.javafx.text.GlyphLayout.addTextRun(GlyphLayout.java:140)
>> ?? ?at com.sun.javafx.text.GlyphLayout.breakRuns(GlyphLayout.java:210)
>> ?? ?at com.sun.javafx.text.PrismTextLayout.buildRuns(PrismTextLayout.java:785)
>> ?? ?at com.sun.javafx.text.PrismTextLayout.layout(PrismTextLayout.java:1036)
>> ?? ?at com.sun.javafx.text.PrismTextLayout.ensureLayout(PrismTextLayout.java:223)
>> ?? ?at com.sun.javafx.text.PrismTextLayout.getBounds(PrismTextLayout.java:246)
>> ?? ?at javafx.scene.text.Text.getLogicalBounds(Text.java:432)
>> ?? ?at javafx.scene.text.Text.doComputeGeomBounds(Text.java:1187)
>> ?? ?at javafx.scene.text.Text$1.doComputeGeomBounds(Text.java:149)
>> ?? ?at com.sun.javafx.scene.shape.TextHelper.computeGeomBoundsImpl(TextHelper.java:90)
>> ?? ?at com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:116)
>> ?? ?at javafx.scene.Node.updateGeomBounds(Node.java:3818)
>> ?? ?at javafx.scene.Node.getGeomBounds(Node.java:3780)
>> ?? ?at javafx.scene.Node.updateBounds(Node.java:776)
>> ?? ?at javafx.scene.Parent.updateBounds(Parent.java:1833)
>>     ...
>>    <<pulse>>
>
>> The simple null check helps in this case. But sometimes I see the exception, posted by @Maran23 . So the root cause is probably not fixed - but the symptoms are. I guess, this PR is then a good progress.
> 
> Maybe it's not good progress. You've investigated the issue, and have identified a likely root cause. Not fixing the root cause just means that it most likely won't be fixed for years to come, and the insights you've accumulated will fade.
> 
> I think we should just fix the root cause. If some application breaks as a result of this, not much harm is done: we'd gain valuable insight into a real-world situation that depends on the current behavior, and can then decide whether to revert the fix, or provide a viable alternative solution (for users) that accomplishes the same goal.

@mstr2 I see you arguments and your concerns. On the other hand, as a developer affected by this problem, it is different. Costumers are complaining and now it seems to occur even more frequently.

Note: I do not have any voting rights and I do not want to make any claims. Anyhow, I think we all agree that the simple null check *solves* the issue by hiding it and definitely does not create any regression. Hence, affected applications may get a quick fix and are running stable. The *actual* fix can come later, taking more time, with more sophisticated testing et cetera. I am happy to help there with our application as well. Thanks!

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

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

From jvos at openjdk.org  Thu Sep 22 07:55:35 2022
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 22 Sep 2022 07:55:35 GMT
Subject: RFR: JDK-8289541 : Update ICU4C to 71.1 [v6]
In-Reply-To: <Nh2kX3UHJHRu2M3jJmM81wBRWKzGxP_ug0_P_RU9qsY=.02f3df7c-db96-41df-b31b-174290beddcf@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
 <Nh2kX3UHJHRu2M3jJmM81wBRWKzGxP_ug0_P_RU9qsY=.02f3df7c-db96-41df-b31b-174290beddcf@github.com>
Message-ID: <ecFsDJ4ZQm7WUIyWaC6BBm-0fqLOs1MpMGs1xrn-0nY=.45e679c1-0b5c-41dd-9f62-9949d58ee0c1@github.com>

On Wed, 21 Sep 2022 16:32:09 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Updated icu to v71.1.
>> Verified build and sanity testing on windows,Mac and Linux.
>> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu
>
> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Space corrections

Looking good on win/linux/mac

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

Marked as reviewed by jvos (Reviewer).

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

From jhendrikx at openjdk.org  Thu Sep 22 11:04:46 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 22 Sep 2022 11:04:46 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v5]
In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
Message-ID: <he1V2bgR_n60-g0ZKbw6fZ9WJbmH9gQtnZofaTrwMdg=.f8006a46-8082-406f-85e2-a0b912eb1e9b@github.com>

> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
> 
> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
> 
> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
> 
>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
> 
> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
> 
> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
> 
> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
> 
> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Add missing new line

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/830/files
  - new: https://git.openjdk.org/jfx/pull/830/files/13c6e39a..23538520

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

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

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

From hmeda at openjdk.org  Thu Sep 22 11:25:28 2022
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Thu, 22 Sep 2022 11:25:28 GMT
Subject: Integrated: JDK-8289541 : Update ICU4C to 71.1
In-Reply-To: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
References: <aWUOd9uGmRACjTJ2rzwA7I-1mvpO6if6eqBSQHs9tgc=.2db11379-3b8c-48fa-b947-f313e26da0dd@github.com>
Message-ID: <Hf100_HddlPU0fJp3SIyofHmyX_mMA599T3JoQw4R-s=.3c35e11d-df24-4772-8b59-3b3c08613a68@github.com>

On Wed, 7 Sep 2022 18:13:43 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

> Updated icu to v71.1.
> Verified build and sanity testing on windows,Mac and Linux.
> Removed icu directory from Source/WTF, as the functionality is already provided by Source/ThirdParty/icu

This pull request has now been integrated.

Changeset: 82db6cc3
Author:    Hima Bindu Meda <hmeda at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/82db6cc342e7de4391f14c70877e77b0e52fbfff
Stats:     144949 lines in 751 files changed: 10988 ins; 123549 del; 10412 mod

8289541: Update ICU4C to 71.1

Reviewed-by: kcr, jvos

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

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

From angorya at openjdk.org  Thu Sep 22 19:42:30 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Sep 2022 19:42:30 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <1kUrRtvqu1CBeV6QAFVgbcJ7vjMQ14VqopJm3gtEqqY=.8478cd04-458d-4db0-8a27-234535ed52a6@github.com>

On Thu, 15 Sep 2022 21:55:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
> 
> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
> edit: won't be done as a part of this PR.

@nlisker :
could you please review this small change, I wanted to publish a demo/manual test for the constrained resize policy in [JDK-8293119](https://bugs.openjdk.org/browse/JDK-8293119) to the mailing list?
thank you in advance!
-andy

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

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

From nlisker at openjdk.org  Thu Sep 22 19:56:49 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 22 Sep 2022 19:56:49 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <khfj6hubmVoRMrr5PyTerRd39sElwVEalDZS6ECkvOs=.cfc61b62-9e56-4304-99b2-24f162bc6f0d@github.com>

On Thu, 15 Sep 2022 21:55:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
> 
> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
> edit: won't be done as a part of this PR.

There are sources under `tests/performance` and `tests/manual` that should also be included in the classpath.

I was actually reviewing it just now.

Same as with apps, this is not the way the tests should be ordered. While it allows to run them from Eclipse, the way the tests are currently divided means that they should be (sub-) projects. We will need a follow-up on this.

@kevinrushforth Are you planning on continuing the cleanup of apps and tests soon? If so, we should wait for it with the Eclipse changes.

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

Changes requested by nlisker (Reviewer).

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

From angorya at openjdk.org  Thu Sep 22 20:11:36 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Sep 2022 20:11:36 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
In-Reply-To: <khfj6hubmVoRMrr5PyTerRd39sElwVEalDZS6ECkvOs=.cfc61b62-9e56-4304-99b2-24f162bc6f0d@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
 <khfj6hubmVoRMrr5PyTerRd39sElwVEalDZS6ECkvOs=.cfc61b62-9e56-4304-99b2-24f162bc6f0d@github.com>
Message-ID: <kmBYpL5vUOJFX8EXaPEBUaEMpW9CL_TFLzGtt4IXYjI=.03bb1d46-67ed-4e02-837b-58e9efa34ad9@github.com>

On Thu, 22 Sep 2022 19:54:41 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> There are sources under `tests/performance` and `tests/manual` that should also be included in the classpath.

I would like to limit the scope of this PR.  

The problem is that one thing leads to another - and the fact that all these manual tests are using the default package instead of their own individual packages might lead to issues and/or require more time and attention.

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

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

From nlisker at openjdk.org  Thu Sep 22 20:22:21 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 22 Sep 2022 20:22:21 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <cbLXWiKrt5st4v_Pl7akabOU0-ikJcp8L7EL3OVSRx8=.39b48182-4658-46bd-ac11-591bd9ffbd45@github.com>

On Thu, 15 Sep 2022 21:55:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
> 
> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
> edit: won't be done as a part of this PR.

The default package is pre-existing bad practice, but doesn't pose an issue, I tried it myself. It makes little sense to add just one source folder while neglecting all the others. If we are editing this classpath to make the tests runnable (even if with the incorrect configuration), then we should make the tests runnable.

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

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

From angorya at openjdk.org  Thu Sep 22 20:33:44 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Sep 2022 20:33:44 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse) [v2]
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <hV4qdfp3T4w_UpKhdmUCeu3EOpdif_Dih4yxo4OOArk=.2de03227-261c-47d0-a08e-4b966c215166@github.com>

> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
> 
> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
> edit: won't be done as a part of this PR.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8293883: more dirs under manual/ and performance/

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/901/files
  - new: https://git.openjdk.org/jfx/pull/901/files/06877a4b..9949c68b

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

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

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

From angorya at openjdk.org  Thu Sep 22 20:33:44 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 22 Sep 2022 20:33:44 GMT
Subject: RFR: 8293883: Add test/.classpath (Eclipse)
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <kI_sA_IveJVCv5tn3HDzhs2SP0mdeUHch0j2oSoL_I8=.d6dffc5f-e73b-4e64-9cd7-49f3a97f8973@github.com>

On Thu, 15 Sep 2022 21:55:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
> 
> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
> edit: won't be done as a part of this PR.

Added more dirs under manual/ and performance/ - had to skip certain directories that looked like projects in their own right, or that required additional dependencies.

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

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

From fastegal at openjdk.org  Fri Sep 23 12:04:32 2022
From: fastegal at openjdk.org (Jeanette Winzenburg)
Date: Fri, 23 Sep 2022 12:04:32 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
Message-ID: <6dIhITzxd5jFyWJ9_VT-M4pKCVNtU9nUk9gJh3BWLts=.d389aff3-ba86-490e-b029-75134d122865@github.com>

On Tue, 20 Sep 2022 19:06:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: review comments

> /reviewer remove kleopatra

just noticed that this self removal request didn't work (a bit unexpected ;) - @kevinrushforth please remove me as reviewer for this PR

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

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

From kcr at openjdk.org  Fri Sep 23 12:28:35 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 23 Sep 2022 12:28:35 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <6dIhITzxd5jFyWJ9_VT-M4pKCVNtU9nUk9gJh3BWLts=.d389aff3-ba86-490e-b029-75134d122865@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
 <6dIhITzxd5jFyWJ9_VT-M4pKCVNtU9nUk9gJh3BWLts=.d389aff3-ba86-490e-b029-75134d122865@github.com>
Message-ID: <dvPmeFOMUoZBU5nHUfFH8co3v-cmMFbtfPpPxLjEMew=.a298e153-0ab7-4cb3-9708-93ffcf8fd1cb@github.com>

On Fri, 23 Sep 2022 11:59:01 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> > /reviewer remove kleopatra
> 
> just noticed that this self removal request didn't work (a bit unexpected ;) - @kevinrushforth please remove me as reviewer for this PR

There's nothing to remove, at least from a Skara point of view. You aren't listed as a `Reviewer` of this PR.

If you mean that you are tagged as a _potential_ reviewer from GitHub's point of view, yes, since you left review comments. It doesn't translate into your having reviewed it, though. I can try to remove you as a potential reviewer, but that's under control of GitHub not Skara.

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

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

From nlisker at openjdk.org  Fri Sep 23 21:13:25 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 23 Sep 2022 21:13:25 GMT
Subject: RFR: 8293883: Add tests/.classpath (Eclipse) [v2]
In-Reply-To: <hV4qdfp3T4w_UpKhdmUCeu3EOpdif_Dih4yxo4OOArk=.2de03227-261c-47d0-a08e-4b966c215166@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
 <hV4qdfp3T4w_UpKhdmUCeu3EOpdif_Dih4yxo4OOArk=.2de03227-261c-47d0-a08e-4b966c215166@github.com>
Message-ID: <KknE7zN8sFu2A4n_KLzzlVPg2HFX0mrBciXOAUnHjig=.51965142-e52a-40f9-bd0c-692ac13a9791@github.com>

On Thu, 22 Sep 2022 20:33:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
>> 
>> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
>> edit: won't be done as a part of this PR.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293883: more dirs under manual/ and performance/

Marked as reviewed by nlisker (Reviewer).

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

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

From angorya at openjdk.org  Fri Sep 23 21:27:55 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 23 Sep 2022 21:27:55 GMT
Subject: Integrated: 8293883: Add tests/.classpath (Eclipse)
In-Reply-To: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
References: <fH_JylP9XfyMRMT1LKD0fQ3FYSHOGLd-wR5aLsP5RRc=.5e088099-bed9-40e5-ab3f-3bedd3458f27@github.com>
Message-ID: <tX4UroUU1Zsca0RJL69h38-QDSql_JgKtdgZqcelZCU=.72dda590-7efa-41d1-bc9b-a1ba18c5d2cd@github.com>

On Thu, 15 Sep 2022 21:55:20 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Adding a tests/.classpath file to include tests/manual/controls source folder so Eclipse could see/execute manual tests there.
> 
> Also, I would rather move the sources there to a specific package (test.manual ?) instead of a default package. Any objections?
> edit: won't be done as a part of this PR.

This pull request has now been integrated.

Changeset: 03569b71
Author:    Andy Goryachev <angorya at openjdk.org>
Committer: Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/03569b719b9d838d643dc4514971b06617275e86
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8293883: Add tests/.classpath (Eclipse)

Reviewed-by: nlisker

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

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

From almatvee at openjdk.org  Sat Sep 24 03:12:04 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 24 Sep 2022 03:12:04 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail when
 loading from FXML
Message-ID: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>

There was two problems:
 - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
 - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
 
Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.

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

Commit messages:
 - 8293971: Loading new Media from resources can sometimes fail when loading from FXML

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

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

From angorya at openjdk.org  Mon Sep 26 15:26:16 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 26 Sep 2022 15:26:16 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML
In-Reply-To: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
Message-ID: <nywDinnulZEDiOJqtbdrIsnzRBUMtI6te8UAGweG66E=.21e75723-6b9e-40cc-9090-237731a3fcec@github.com>

On Sat, 24 Sep 2022 03:07:00 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> There was two problems:
>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>  
> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.

modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java line 425:

> 423:                             stream.close();
> 424:                             isConnected = true;
> 425:                             contentType = MediaUtils.filenameToContentType(uri); // We need to provide at least something

would it be possible to explain what ie being done instead?  i.e. "try to determine the content type based on extension" or something like that?

modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 154:

> 152:         } else if ((buf[0] & 0xff) == 0xff && (buf[1] & 0xe0) == 0xe0 && // sync
> 153:                 (buf[1] & 0x18) != 0x08 && // not reserved version
> 154:                 (buf[1] & 0x06) != 0x00) { // not reserved layer

thank you for providing a descriptive comment!

I wonder if, in the future, when the list of supported formats grows, we ought to invent some kind of Bit(input)Stream class that would make operating on bit fields easier?

modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 187:

> 185:      * Returns the content type given the file name.
> 186:      *
> 187:      * @param uri

should the comment be changed since the argument is uri and not a file name?

modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 241:

> 239: 
> 240:         String scheme = uri.getScheme().toLowerCase();
> 241:         if (scheme.equals("jar")) {

is it possible for the 'scheme' to be null?

(may be "jar".equals(scheme) would work better here?)

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

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

From almatvee at openjdk.org  Mon Sep 26 23:01:38 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 26 Sep 2022 23:01:38 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML
In-Reply-To: <nywDinnulZEDiOJqtbdrIsnzRBUMtI6te8UAGweG66E=.21e75723-6b9e-40cc-9090-237731a3fcec@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
 <nywDinnulZEDiOJqtbdrIsnzRBUMtI6te8UAGweG66E=.21e75723-6b9e-40cc-9090-237731a3fcec@github.com>
Message-ID: <PoODTBLMrENfxCJ_qJnZHe7vyNYn5bfcvYrV3fyN3JE=.49f35be0-3134-423a-ab68-9f3fc4802f6b@github.com>

On Mon, 26 Sep 2022 15:14:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There was two problems:
>>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>>  
>> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.
>
> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 154:
> 
>> 152:         } else if ((buf[0] & 0xff) == 0xff && (buf[1] & 0xe0) == 0xe0 && // sync
>> 153:                 (buf[1] & 0x18) != 0x08 && // not reserved version
>> 154:                 (buf[1] & 0x06) != 0x00) { // not reserved layer
> 
> thank you for providing a descriptive comment!
> 
> I wonder if, in the future, when the list of supported formats grows, we ought to invent some kind of Bit(input)Stream class that would make operating on bit fields easier?

I think we can use java.util.BitSet. We can define BitSet for headers and then use intersects to see if bits are set, but it will be out of scope for this issue.

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

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

From angorya at openjdk.org  Mon Sep 26 23:12:17 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 26 Sep 2022 23:12:17 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML
In-Reply-To: <PoODTBLMrENfxCJ_qJnZHe7vyNYn5bfcvYrV3fyN3JE=.49f35be0-3134-423a-ab68-9f3fc4802f6b@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
 <nywDinnulZEDiOJqtbdrIsnzRBUMtI6te8UAGweG66E=.21e75723-6b9e-40cc-9090-237731a3fcec@github.com>
 <PoODTBLMrENfxCJ_qJnZHe7vyNYn5bfcvYrV3fyN3JE=.49f35be0-3134-423a-ab68-9f3fc4802f6b@github.com>
Message-ID: <U_vRvNtOIzTXccYJnHJgHe_CJ6eRiv1dbvvDhpz1Sr4=.b5c782c6-480d-43a5-b892-140b40159972@github.com>

On Mon, 26 Sep 2022 22:57:37 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 154:
>> 
>>> 152:         } else if ((buf[0] & 0xff) == 0xff && (buf[1] & 0xe0) == 0xe0 && // sync
>>> 153:                 (buf[1] & 0x18) != 0x08 && // not reserved version
>>> 154:                 (buf[1] & 0x06) != 0x00) { // not reserved layer
>> 
>> thank you for providing a descriptive comment!
>> 
>> I wonder if, in the future, when the list of supported formats grows, we ought to invent some kind of Bit(input)Stream class that would make operating on bit fields easier?
>
> I think we can use java.util.BitSet. We can define BitSet for headers and then use intersects to see if bits are set, but it will be out of scope for this issue.

No, not a BitSet.  
Something along the lines of
https://github.com/andy-goryachev/PasswordSafe/blob/master/src/goryachev/common/io/BitStreamReader.java

just a suggestion, no change in this PR is requested.

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

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

From nlisker at openjdk.org  Mon Sep 26 23:33:25 2022
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 26 Sep 2022 23:33:25 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v5]
In-Reply-To: <he1V2bgR_n60-g0ZKbw6fZ9WJbmH9gQtnZofaTrwMdg=.f8006a46-8082-406f-85e2-a0b912eb1e9b@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <he1V2bgR_n60-g0ZKbw6fZ9WJbmH9gQtnZofaTrwMdg=.f8006a46-8082-406f-85e2-a0b912eb1e9b@github.com>
Message-ID: <3npWBIZ0nvS9Fa4wBhOVRbApPJ7J-emrQInMQU6vOP8=.ac54b5bd-798b-4cc4-9cbd-e642d367a691@github.com>

On Thu, 22 Sep 2022 11:04:46 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
>> 
>> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
>> 
>> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
>> 
>>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
>> 
>> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
>> 
>> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
>> 
>> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
>> 
>> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing new line

Implementation and tests look good. Left a few minor comments.

in `ObjectBinding.java`, the change in a previous PR was integrated. I think that you need to merge master to not show this as a change in this PR.

I will have a look at the changes to `Node` soon. I'm not sure if they need to be in this PR, but I personally don't mind. Will also do some sanity checks manually to see that the binding functions the way I think it should (as I have done in the previous fluent binding PR), but I don't foresee any issues.

modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 12:

> 10:     private final ObservableValue<Boolean> nonNullCondition;
> 11: 
> 12:     private Subscription subscription;

Isn't it better to use an `EMPTY` subscription, like `FlatMap` does?

modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 16:

> 14:     public ConditionalBinding(ObservableValue<T> source, ObservableValue<Boolean> condition) {
> 15:         this.source = Objects.requireNonNull(source, "source");
> 16:         this.nonNullCondition = Objects.requireNonNull(condition, "condition").orElse(false);

The message should probably match the other classes: "source cannot be null".

modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 41:

> 39:     protected T computeValue() {
> 40:         if (isObserved() && isActive()) {
> 41:             if(subscription == null) {

Space after `if`.

modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java line 65:

> 63: 
> 64:         binding.addListener(obs -> {
> 65:             assertEquals("A", binding.get());

Can be converted to an expression.

modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 52:

> 50: 
> 51: public class ObservableValueFluentBindingsTest {
> 52:     private int invalidations;

Empty line after class declaration.

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

Changes requested by nlisker (Reviewer).

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

From almatvee at openjdk.org  Tue Sep 27 01:22:41 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 27 Sep 2022 01:22:41 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML [v2]
In-Reply-To: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
Message-ID: <tpysVNGkXofTBsQsIshb6h4M-VbyICkj95XGvdKCTB0=.a8b68ab6-0f87-4806-8446-fcae64cce65a@github.com>

> There was two problems:
>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>  
> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8293971: Loading new Media from resources can sometimes fail when loading from FXML [v2]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/902/files
  - new: https://git.openjdk.org/jfx/pull/902/files/6ec8b2e7..9830b77e

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

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

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

From almatvee at openjdk.org  Tue Sep 27 01:22:41 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 27 Sep 2022 01:22:41 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML
In-Reply-To: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
Message-ID: <vAyqkjVN34R1nUfPbYWVCZTluLPQyiapA8iNwKMpWAk=.54de2c23-6e7a-46ed-b105-e0f429698218@github.com>

On Sat, 24 Sep 2022 03:07:00 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> There was two problems:
>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>  
> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.

8293971: Loading new Media from resources can sometimes fail when loading from FXML [v2]
 - Fixed comments from Andy.

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

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

From almatvee at openjdk.org  Tue Sep 27 01:22:42 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 27 Sep 2022 01:22:42 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML [v2]
In-Reply-To: <nywDinnulZEDiOJqtbdrIsnzRBUMtI6te8UAGweG66E=.21e75723-6b9e-40cc-9090-237731a3fcec@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
 <nywDinnulZEDiOJqtbdrIsnzRBUMtI6te8UAGweG66E=.21e75723-6b9e-40cc-9090-237731a3fcec@github.com>
Message-ID: <2KyAxZT94pN_75IIoaX3s9O9mnun7XNdr6XRSEjUEt0=.1aeb5fa8-b220-4920-88d5-f75b9f9b6f03@github.com>

On Mon, 26 Sep 2022 15:16:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293971: Loading new Media from resources can sometimes fail when loading from FXML [v2]
>
> modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/Locator.java line 425:
> 
>> 423:                             stream.close();
>> 424:                             isConnected = true;
>> 425:                             contentType = MediaUtils.filenameToContentType(uri); // We need to provide at least something
> 
> would it be possible to explain what ie being done instead?  i.e. "try to determine the content type based on extension" or something like that?

Fixed.

> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 187:
> 
>> 185:      * Returns the content type given the file name.
>> 186:      *
>> 187:      * @param uri
> 
> should the comment be changed since the argument is uri and not a file name?

Fixed.

> modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/MediaUtils.java line 241:
> 
>> 239: 
>> 240:         String scheme = uri.getScheme().toLowerCase();
>> 241:         if (scheme.equals("jar")) {
> 
> is it possible for the 'scheme' to be null?
> 
> (may be "jar".equals(scheme) would work better here?)

No, it should not be null, since we have check for null before it. I did change it, so it is same as rest of our code.

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

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

From angorya at openjdk.org  Tue Sep 27 15:09:41 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 27 Sep 2022 15:09:41 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML [v2]
In-Reply-To: <tpysVNGkXofTBsQsIshb6h4M-VbyICkj95XGvdKCTB0=.a8b68ab6-0f87-4806-8446-fcae64cce65a@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
 <tpysVNGkXofTBsQsIshb6h4M-VbyICkj95XGvdKCTB0=.a8b68ab6-0f87-4806-8446-fcae64cce65a@github.com>
Message-ID: <EN3QHNwRqdVdJUXs0xj-Msl45KWSrFJL7MtCoaktrsc=.bc7b2ba5-fea5-4128-8259-f29fa67fba24@github.com>

On Tue, 27 Sep 2022 01:22:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> There was two problems:
>>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>>  
>> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293971: Loading new Media from resources can sometimes fail when loading from FXML [v2]

changes look good to me

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

Marked as reviewed by angorya (Author).

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

From arapte at openjdk.org  Wed Sep 28 08:48:55 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 28 Sep 2022 08:48:55 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
Message-ID: <j0UuPgiBL9QvbgPnsvMPR1YMP7CtpVU5Y8mI-7n9IAQ=.b830663d-3f0c-4c20-928b-4475626e342c@github.com>

On Fri, 16 Sep 2022 18:04:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Weak*Listeners eliminates the memory leak.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293444: memory buddy

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 36:

> 34: import org.junit.Before;
> 35: import org.junit.Ignore;
> 36: import org.junit.Test;

These got moved from line 51(without this PR), can restore this change.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 875:

> 873: 
> 874:     /**
> 875:      * checks that there are no memory leaks when replacing scroll pane content

Minor rephrasing:

     * Test that ScrollPane object is not leaked when 'same' node
     * is used as content for different ScrollPane objects.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 878:

> 876:      */
> 877:     @Test
> 878:     public void checkMemoryLeaks_JDK_8293444() {

may be rename to something similar as : `testScrollPaneObjLeakWhenUsedSameContent`

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 887:

> 885:         stage.setScene(new Scene(bp));
> 886:         stage.setWidth(600);
> 887:         stage.setHeight(600);

Minor: These are not required for the test. so can remove.

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 912:

> 910: 
> 911:         // one instance is still held by the 'content' label
> 912:         assertTrue("uncollected objects=" + ct, ct <= 1);

May be the assert can be updated to:


        assertEquals("One instance should be held by the 'content' label", 1, ct);

        content = null;
        ct = 0;
        for (WeakReference<ScrollPane> ref : refs) {
            JMemoryBuddy.checkCollectable(ref);
            if (ref.get() != null) {
                ct++;
            }
        }
        assertEquals(ct + " References of ScrollPane are not freed.", 0, ct);

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

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

From arapte at openjdk.org  Wed Sep 28 08:54:38 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 28 Sep 2022 08:54:38 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
Message-ID: <ggEpGneywhxSFXeN81a7u52mv8d4qyjwTvLdGaq1US4=.91598a5b-af01-436f-9e65-a0ac7b960ded@github.com>

On Fri, 16 Sep 2022 18:04:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Weak*Listeners eliminates the memory leak.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293444: memory buddy

Fix looks good,
Providing some minor comments for test.

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

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

From fkirmaier at openjdk.org  Wed Sep 28 10:20:33 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 28 Sep 2022 10:20:33 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
Message-ID: <qUWJdW4O9KES9CWgIYs4nCeXtjX7ELUDPYZFvItj_HI=.51392291-6b7d-4069-ac2e-7f6afde54041@github.com>

On Fri, 16 Sep 2022 18:04:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Weak*Listeners eliminates the memory leak.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293444: memory buddy

A small comment about the memory test with [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy).
Instead of this:

<code>
List<WeakReference> refs = ...
WeakReference a = b;
refs.add(a);
<code>
for (WeakReference<ScrollPane> ref : refs) {
       JMemoryBuddy.checkCollectable(ref);
}

It is more readable this way:

JMemoryBuddy.memoryTest(checker -> {
  <code>
  checker.setAsReferenced(objects);
  checker.assertCollectable(b);
});

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

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

From kcr at openjdk.org  Wed Sep 28 11:38:27 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 Sep 2022 11:38:27 GMT
Subject: RFR: 8293971: Loading new Media from resources can sometimes fail
 when loading from FXML [v2]
In-Reply-To: <tpysVNGkXofTBsQsIshb6h4M-VbyICkj95XGvdKCTB0=.a8b68ab6-0f87-4806-8446-fcae64cce65a@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
 <tpysVNGkXofTBsQsIshb6h4M-VbyICkj95XGvdKCTB0=.a8b68ab6-0f87-4806-8446-fcae64cce65a@github.com>
Message-ID: <-otDan8uQHJxkC6m1qNA7Z9PNr9--ZGVX1n5w2_bMTA=.888c3311-2f7b-406f-b0d5-fe1a5bf01434@github.com>

On Tue, 27 Sep 2022 01:22:41 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> There was two problems:
>>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>>  
>> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293971: Loading new Media from resources can sometimes fail when loading from FXML [v2]

Marked as reviewed by kcr (Lead).

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

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

From kcr at openjdk.org  Wed Sep 28 17:07:42 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 Sep 2022 17:07:42 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
Message-ID: <jSG7mTjrz5cKFXwgk4KEdxKjOF1KVbmUtHCf__pL15Q=.f6b6f640-f9f1-4380-a99f-4f0d355c3e34@github.com>

On Tue, 20 Sep 2022 19:06:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: review comments

The fix looks good.

As for the tests, I somewhat agree with the comments left by @kleopatra, especially the comment about the suitability of the tests in `TreeAndTableViewTest`. Having said that, they aren't harmful, so I will leave it up to you as to whether to remove that test class or leave it in.

I left a few specific comments on the tests inline. You can either update this PR (probably best) or file a follow-up test bug, which can be done during an upcoming test sprint.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ControlUtils.java line 55:

> 53:  * Miscellaneous convenience methods to support javafx.controls tests.
> 54:  */
> 55: public class ControlUtils {

Minor: You might consider adding a private no-arg constructor to highlight the fact that it is a collection of static utility methods.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 28:

> 26: 
> 27: import static org.junit.jupiter.api.Assertions.assertFalse;
> 28: import static org.junit.jupiter.api.Assertions.assertTrue;

Best not to mix JUnit4 and JUnit5 methods in the same test class. So I recommend changing all of the `org.junit.jupiter.api.Assertions` imports their JUnit4 equivalents in the modified and added tests.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 54:

> 52:     }
> 53: 
> 54:     /** TableView with cell selection enabled should not select TreeTableRows */

Typo: should be `TableRows`

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 56:

> 54:     /** TableView with cell selection enabled should not select TreeTableRows */
> 55:     @Test
> 56:     public void test_TableView_jdk_8292353_select_all() {

Minor: I recommend removing `jdk_8292353` from the name of the tests, as we no longer follow that pattern. Instead, you can add the bug ID in the method comment, if you like.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 81:

> 79:         sm.select(0, col0);
> 80:         sm.select(0, col1);
> 81:         sm.select(0, col2);

In addition to this test method, which verifies that selecting all columns individually doesn't select the row when in cell selection mode, I recommend adding another test method that selects all of them as a group using `sm.select(0, null)`.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 89:

> 87:     }
> 88: 
> 89:     /** TableView with cell selection enabled should not select TreeTableRows */

Typo: should be "TableRows"

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 120:

> 118:         assertFalse(row.isSelected());
> 119:     }
> 120: }

Unless you are certain that they are covered elsewhere (not counting anything in `TreeAndTableViewTest`), having similar test methods to the above with cell selection disabled would be useful.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeAndTableViewTest.java line 29:

> 27: import static org.junit.jupiter.api.Assertions.assertEquals;
> 28: import static org.junit.jupiter.api.Assertions.assertFalse;
> 29: import static org.junit.jupiter.api.Assertions.assertTrue;

Replace with JUnit4 equivalents.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 32:

> 30: import static org.junit.Assert.assertSame;
> 31: import static org.junit.jupiter.api.Assertions.assertFalse;
> 32: import static org.junit.jupiter.api.Assertions.assertTrue;

Replace with JUnit4 equivalents.

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableRowTest.java line 840:

> 838:     /** TreeTableView with cell selection enabled should not select TreeTableRows */
> 839:     @Test
> 840:     public void test_TreeTableView_jdk_8292353_select_all() {

Ditto the comments I made in `TableViewRowTest` about the test method names and the need for additional test methods.

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

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

From angorya at openjdk.org  Wed Sep 28 17:54:35 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 17:54:35 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <j0UuPgiBL9QvbgPnsvMPR1YMP7CtpVU5Y8mI-7n9IAQ=.b830663d-3f0c-4c20-928b-4475626e342c@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
 <j0UuPgiBL9QvbgPnsvMPR1YMP7CtpVU5Y8mI-7n9IAQ=.b830663d-3f0c-4c20-928b-4475626e342c@github.com>
Message-ID: <nLI3yKM7Xrx-0ltWNGk4t0WJTnHvd9GNl3zlf2S_A94=.9f63f335-3049-442a-8b20-16d5a4f3bcf7@github.com>

On Wed, 28 Sep 2022 08:46:41 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293444: memory buddy
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 36:
> 
>> 34: import org.junit.Before;
>> 35: import org.junit.Ignore;
>> 36: import org.junit.Test;
> 
> These got moved from line 51(without this PR), can move them back to original lines as.
> 
> 
> import javafx.stage.Stage;
> 
> import org.junit.Before;
> import org.junit.Ignore;
> import org.junit.Test;
> import test.util.memory.JMemoryBuddy;

changed formatter rules for import ordering: java,javax,javafx,org

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

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

From angorya at openjdk.org  Wed Sep 28 18:02:53 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 18:02:53 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v3]
In-Reply-To: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
Message-ID: <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>

> Using Weak*Listeners eliminates the memory leak.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8293444: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/900/files
  - new: https://git.openjdk.org/jfx/pull/900/files/02330d09..0b22c2c9

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

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

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

From angorya at openjdk.org  Wed Sep 28 18:02:53 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 18:02:53 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <qUWJdW4O9KES9CWgIYs4nCeXtjX7ELUDPYZFvItj_HI=.51392291-6b7d-4069-ac2e-7f6afde54041@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
 <qUWJdW4O9KES9CWgIYs4nCeXtjX7ELUDPYZFvItj_HI=.51392291-6b7d-4069-ac2e-7f6afde54041@github.com>
Message-ID: <2fXufX6gGSm2aDn8Fhnfbv0fgEWybDhLLVg1gupv3TI=.667faa22-1795-477d-8e26-4c87bdb922cf@github.com>

On Wed, 28 Sep 2022 10:16:47 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> A small comment about the memory test with [JMemoryBuddy](https://github.com/Sandec/JMemoryBuddy).

Thank you for suggestion.  I will definitely use it in other tests!
Here it won't work because in the part of the test one instance is expected to remain uncollected.

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

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

From angorya at openjdk.org  Wed Sep 28 18:02:54 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 18:02:54 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v2]
In-Reply-To: <j0UuPgiBL9QvbgPnsvMPR1YMP7CtpVU5Y8mI-7n9IAQ=.b830663d-3f0c-4c20-928b-4475626e342c@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <TpvPaFQvCMe-DgbCFxChcYAKglSUR2dPRrlZQqoWc4A=.1cc68f1b-6ce5-41d7-ab69-5d9012aad21b@github.com>
 <j0UuPgiBL9QvbgPnsvMPR1YMP7CtpVU5Y8mI-7n9IAQ=.b830663d-3f0c-4c20-928b-4475626e342c@github.com>
Message-ID: <AFMMkWHL4OJNt6B7ZUNIIhB8QONfdXzAQ5IeFUUnKGQ=.98dc0fa6-a9fa-46d0-bda6-91c9a0344f42@github.com>

On Wed, 28 Sep 2022 08:41:42 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293444: memory buddy
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/ScrollPaneSkinTest.java line 912:
> 
>> 910: 
>> 911:         // one instance is still held by the 'content' label
>> 912:         assertTrue("uncollected objects=" + ct, ct <= 1);
> 
> May be the assert can be updated to:
> 
> 
>         assertEquals("One instance should be held by the 'content' label", 1, ct);
> 
>         content = null;
>         ct = 0;
>         for (WeakReference<ScrollPane> ref : refs) {
>             JMemoryBuddy.checkCollectable(ref);
>             if (ref.get() != null) {
>                 ct++;
>             }
>         }
>         assertEquals(ct + " References of ScrollPane are not freed.", 0, ct);

thank you

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

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

From kcr at openjdk.org  Wed Sep 28 18:14:47 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 28 Sep 2022 18:14:47 GMT
Subject: RFR: 8290844: Add Skin.install() method [v5]
In-Reply-To: <94JWlhRZbd8ERyHGxsu_W0pkZVHYbCooIsRtAyvBrmk=.d5ffe60f-bf8d-4cc1-a980-e77eaa907150@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <94JWlhRZbd8ERyHGxsu_W0pkZVHYbCooIsRtAyvBrmk=.d5ffe60f-bf8d-4cc1-a980-e77eaa907150@github.com>
Message-ID: <qO1avtVzWwDKqt146NGVX3RTq3Q7oKyUk9djlWh_D5M=.f31d4389-ba61-4ee0-a1be-e7419be46889@github.com>

On Fri, 9 Sep 2022 20:47:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - added Skin.install()
>> - javadoc changes for Skinnable.setSkin(Skin)
>> 
>> no code changes for Skinnable.setSkin(Skin) yet.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - 8290844: review comments
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: review comments
>  - 8290844: review comments
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: javadoc
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8289397: added space
>  - 8290844: skin.install
>  - 8290844: whitespace
>  - ... and 6 more: https://git.openjdk.org/jfx/compare/6f6de14f...7d5db78b

The API looks good. I left a few more minor comments on the docs, and then I think it's ready.

The implementation looks good, too. So I think the only thing missing are unit tests.

modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 226:

> 224:      * <p>
> 225:      * To ensure a one-to-one relationship between a {@code Control} and its {@code Skin},
> 226:      * {@link Control#setSkin(Skin)} method will check the return value of {@link Skin#getSkinnable()}

Suggestion: either "the setSkin method" or "setSkin" (without "method").

modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 231:

> 229:      * A skin may be null.
> 230:      *
> 231:      * @return the skin property for this control

I recommend adding an `@throws` clause here. Something like:


     * @throws IllegalArgumentException if {@code skin != null && skin != getSkinnable()}


although the javadoc tool currently doesn't do anything with an `@throws` tag in a property (I'll file a follow-up bug for this).

modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 252:

> 250:                     unbind();
> 251:                     set(oldValue);
> 252:                     throw new IllegalArgumentException("Skin does not correspond to this Skinnable");

Minor: it might be clearer to say "this Control" here (but `Skinnable` is not wrong)

modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 83:

> 81:      *
> 82:      * @implNote
> 83:      * Most implementations of Skin in the <code>javafx.controls</code> module

Minor: `{@code some text}` is preferred over `<code>some text</code>` in API docs.

modules/javafx.controls/src/main/java/javafx/scene/control/Skin.java line 84:

> 82:      * @implNote
> 83:      * Most implementations of Skin in the <code>javafx.controls</code> module
> 84:      * do not need to implement {@link Skin#install()} unless they must set one or more

Since this doc is already in the `install` method, there is no need for a link. It can be replaced with: `{@code install}`

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

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

From angorya at openjdk.org  Wed Sep 28 18:23:45 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 18:23:45 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <jSG7mTjrz5cKFXwgk4KEdxKjOF1KVbmUtHCf__pL15Q=.f6b6f640-f9f1-4380-a99f-4f0d355c3e34@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
 <jSG7mTjrz5cKFXwgk4KEdxKjOF1KVbmUtHCf__pL15Q=.f6b6f640-f9f1-4380-a99f-4f0d355c3e34@github.com>
Message-ID: <tkRcdRQgSvZBhYY4KegAc9YCheQ3f-cnGg04IGGi8mg=.561769a8-6c1f-4a7f-bec6-f87607a620f8@github.com>

On Wed, 28 Sep 2022 16:20:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292353: review comments
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewRowTest.java line 120:
> 
>> 118:         assertFalse(row.isSelected());
>> 119:     }
>> 120: }
> 
> Unless you are certain that they are covered elsewhere (not counting anything in `TreeAndTableViewTest`), having similar test methods to the above with cell selection disabled would be useful.

yes, these cases are covered in TableViewSelectionModelImplTest

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

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

From angorya at openjdk.org  Wed Sep 28 18:33:31 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 18:33:31 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v12]
In-Reply-To: <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <_Fo4g6GJ2MzkFxI9_-A-SQESUdJ9R4BZpLHWlrcGwjI=.f6919947-8c26-4c75-9596-5faeb593180b@github.com>
Message-ID: <-ugu0CKrheIS0KiaREKJa4wqGDVmn7IMU-EfRfSPp-Y=.90bb7b78-8a5c-4425-9979-633ed3aff5fd@github.com>

On Tue, 20 Sep 2022 19:06:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: review comments

I give up - removing TreeAndTableViewTest.

Thank you @kevinrushforth for insights and suggestions!

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

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

From nlisker at gmail.com  Wed Sep 28 18:44:22 2022
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 28 Sep 2022 21:44:22 +0300
Subject: ObservableValue::map called twice
Message-ID: <CA+0ynh_DOMpKx4qfE-Jv8NR=t26cb2FApXE0TduNysbNZsaYHw@mail.gmail.com>

Hi,

Running this code:

var label = new Label();
var tf = new TextField();
label.textProperty().bind(tf.textProperty().map(t -> {
    System.out.println("in");
    return t;
}));

produces the output::
in
in

>From what I see, the lambda should be called once, but it's called twice.
Looks like improper behavior to me.

- Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20220928/acdb9de4/attachment.htm>

From angorya at openjdk.org  Wed Sep 28 19:07:26 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 19:07:26 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v13]
In-Reply-To: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
Message-ID: <mrs1ibMzuByd24DO8gFvHpLaZQIDVwQVtKwLBGtqTSU=.64e03928-a00d-4f9d-bdc2-5228d327098f@github.com>

> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
> 
> Changes:
> - modified TreeTableRow.updateSelection()

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8292353: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/875/files
  - new: https://git.openjdk.org/jfx/pull/875/files/324828ec..2a9b9417

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=875&range=11-12

  Stats: 367 lines in 4 files changed: 85 ins; 271 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/875.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/875/head:pull/875

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

From angorya at openjdk.org  Wed Sep 28 19:33:38 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 19:33:38 GMT
Subject: RFR: 8290844: Add Skin.install() method [v6]
In-Reply-To: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
Message-ID: <j7CnVAQKjAgURSL3JsAqEFDOKfgrH8SS3CyKgHa2Fh0=.75a1fd14-836a-458c-8ed2-13a1aa14cbcd@github.com>

> - added Skin.install()
> - javadoc changes for Skinnable.setSkin(Skin)
> 
> no code changes for Skinnable.setSkin(Skin) yet.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8290844: review comments

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/845/files
  - new: https://git.openjdk.org/jfx/pull/845/files/7d5db78b..e4310ce0

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

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

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

From fkirmaier at openjdk.org  Wed Sep 28 20:28:31 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Wed, 28 Sep 2022 20:28:31 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v3]
In-Reply-To: <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
Message-ID: <9EaCEx2I2raj9JYPwnvMTC7x4Zp0YX1C0AoqyLAqPMM=.8f406025-6a90-46b5-b4a5-2779eb594ac5@github.com>

On Wed, 28 Sep 2022 18:02:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Weak*Listeners eliminates the memory leak.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293444: review comments

if you use `checker.setAsReferenced(object)` then the specified object won't be collected for the current test.

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

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

From almatvee at openjdk.org  Wed Sep 28 20:36:21 2022
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 28 Sep 2022 20:36:21 GMT
Subject: Integrated: 8293971: Loading new Media from resources can sometimes
 fail when loading from FXML
In-Reply-To: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
References: <YuCBsOYf4i2Tsl-DRTiYZpN_RO6-u__QfZ9YfEHlTl8=.fbc8d920-f2b3-4ec9-ae4c-d6feda6c4de8@github.com>
Message-ID: <euyuOLxlUP2mORydWHAEvOUUfhKGdhcs11VyKJ5Nfok=.0842b08a-3adf-41e6-988b-826914a2588b@github.com>

On Sat, 24 Sep 2022 03:07:00 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> There was two problems:
>  - uri.getPath() was returning null for jar URI, since it is not a standard URI and thus we did not detect file type based on extension.
>  - Our signature detection for MP3 had a bug and did not detect MP3 correctly. See comments in code.
>  
> Fixed by adding function to extract file name from jar URI and also signature detection was fixed for MP3.

This pull request has now been integrated.

Changeset: 35675c8d
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/35675c8d27d54a26059b182614e18152794dbcec
Stats:     53 lines in 2 files changed: 42 ins; 0 del; 11 mod

8293971: Loading new Media from resources can sometimes fail when loading from FXML

Reviewed-by: angorya, kcr

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

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

From angorya at openjdk.org  Wed Sep 28 20:54:56 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 20:54:56 GMT
Subject: RFR: 8290844: Add Skin.install() method [v7]
In-Reply-To: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
Message-ID: <i0AqY9vW4wneX2noRJjKx-vnBnS3IfSUE8gJmzeUjlM=.102b7aec-b5a2-47a4-bf71-8f6be7cc9387@github.com>

> - added Skin.install()
> - javadoc changes for Skinnable.setSkin(Skin)

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: review comments
 - 8290844: review comments
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: review comments
 - 8290844: review comments
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: javadoc
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8289397: added space
 - ... and 8 more: https://git.openjdk.org/jfx/compare/22a02189...4b70199f

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/845/files
  - new: https://git.openjdk.org/jfx/pull/845/files/e4310ce0..4b70199f

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

  Stats: 145500 lines in 770 files changed: 11435 ins; 123611 del; 10454 mod
  Patch: https://git.openjdk.org/jfx/pull/845.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/845/head:pull/845

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

From angorya at openjdk.org  Wed Sep 28 21:40:29 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 21:40:29 GMT
Subject: RFR: 8290844: Add Skin.install() method [v8]
In-Reply-To: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
Message-ID: <B-ksXBbiGGMUiaw-FNNLDSPAqZBfPuswKmglSFhpPdM=.20c3d050-8904-4810-bd8e-3abdc50d7d62@github.com>

> - added Skin.install()
> - javadoc changes for Skinnable.setSkin(Skin)

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  8290844: unit tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/845/files
  - new: https://git.openjdk.org/jfx/pull/845/files/4b70199f..a08bdf60

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

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

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

From angorya at openjdk.org  Wed Sep 28 21:57:27 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 28 Sep 2022 21:57:27 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v3]
In-Reply-To: <9EaCEx2I2raj9JYPwnvMTC7x4Zp0YX1C0AoqyLAqPMM=.8f406025-6a90-46b5-b4a5-2779eb594ac5@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
 <9EaCEx2I2raj9JYPwnvMTC7x4Zp0YX1C0AoqyLAqPMM=.8f406025-6a90-46b5-b4a5-2779eb594ac5@github.com>
Message-ID: <z7G1uLckwJTAcJRlyE0q-a17EFvlByAWUKWev-ona-k=.3313c59a-de02-429c-9586-71019f37bbcd@github.com>

On Wed, 28 Sep 2022 20:24:47 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293444: review comments
>
> if you use `checker.setAsReferenced(object)` then the specified object won't be collected for the current test.
> And there is also the statement assertNotCollectable() to check the reverse.
> 
> 
> The method "checkCollectable/assertCollectable" is very slow in the negative case (but reliable in the positive case)
> The method "checkNotCollectable/<assertNotCollectable" should be used, if it's expected that the object is not collectable - otherwise the test will be quite slow.

@FlorianKirmaier :
I am not sure if using JMemoryBuddy.memoryTest results in a clearer or more concise code, given the nature of testScrollPaneObjLeakWhenUsedSameContent().

BTW, MemoryTestAPI names are a bit confusing: "assert*Collectable" suggests assertion is done at the point when these calls are made, though it looks like they just add a reference the an internal list.  Also, assertCollectable might want to skip creation of a WeakReference if the object passed to it is already a WeakReference.

With your permission, I would like to keep this test as is.

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

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

From arapte at openjdk.org  Thu Sep 29 05:35:30 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Thu, 29 Sep 2022 05:35:30 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v3]
In-Reply-To: <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
Message-ID: <UBk2bpGNzcVQOg_eroCrJLte0PBOrGCN_0AMbNovMjk=.3f571e50-54d7-40ba-bf72-ad923bcc4b88@github.com>

On Wed, 28 Sep 2022 18:02:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Weak*Listeners eliminates the memory leak.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293444: review comments

Looks good to me.

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

Marked as reviewed by arapte (Reviewer).

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

From fkirmaier at openjdk.org  Thu Sep 29 08:05:29 2022
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Thu, 29 Sep 2022 08:05:29 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v3]
In-Reply-To: <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
Message-ID: <aCZA5umvfpZ8LfJ4X0I-fqxoD-r4-_CpuhAV-vDbqzM=.85339a24-1e2f-4058-8ad0-cb18b5755510@github.com>

On Wed, 28 Sep 2022 18:02:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Weak*Listeners eliminates the memory leak.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293444: review comments

Of course, you can keep it this way.

The point of JMemoryBuddy.memoryTest is, that the user doesn't have to fiddle around with WeakReferences.
For the record, your test might look like this (not tested):

    @Test
    public void testScrollPaneObjLeakWhenUsedSameContent() {
        JMemoryBuddy.memoryTest(() -> {
            BorderPane bp = new BorderPane();

            Stage stage = new Stage();
            stage.setScene(new Scene(bp));
            stage.show();

            Label content = new Label("content");

            ScrollPane sp1 = new ScrollPane(content);
            bp.setCenter(sp1);
            Toolkit.getToolkit().firePulse();

            ScrollPane sp2 = new ScrollPane(content);
            bp.setCenter(sp2);
            Toolkit.getToolkit().firePulse();

            bp.setCenter(null);
            Toolkit.getToolkit().firePulse();

            // When the label is still referenced, then only one ScrollPane should stay which is its parent
            checker.setAsReferenced(label)
            checker.assertCollectable(sp1)
            checker.assertNotCollectable(sp2)
        });
    }

    @Test
    public void testScrollPaneObjLeakWhenUsedSameContent() {
        JMemoryBuddy.memoryTest(() -> {
            BorderPane bp = new BorderPane();

            Stage stage = new Stage();
            stage.setScene(new Scene(bp));
            stage.show();

            Label content = new Label("content");

            ScrollPane sp1 = new ScrollPane(content);
            bp.setCenter(sp1);
            Toolkit.getToolkit().firePulse();

            ScrollPane sp2 = new ScrollPane(content);
            bp.setCenter(sp2);
            Toolkit.getToolkit().firePulse();

            bp.setCenter(null);
            Toolkit.getToolkit().firePulse();

            // IF our label is gone, both scrollpanes shold be collectable
            checker.assertCollectable(sp1)
            checker.assertCollectable(sp2)
        });
    }

I think only the first test is the important one.

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

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

From kcr at openjdk.org  Thu Sep 29 14:01:36 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Sep 2022 14:01:36 GMT
Subject: RFR: 8292353: TableRow vs. TreeTableRow: inconsistent visuals in
 cell selection mode [v13]
In-Reply-To: <mrs1ibMzuByd24DO8gFvHpLaZQIDVwQVtKwLBGtqTSU=.64e03928-a00d-4f9d-bdc2-5228d327098f@github.com>
References: <rVSABXHWrh6MhazWUtrWo0vWgvEOsgkeRe4v0fCgT_A=.f2e88eab-7796-409f-a0ac-577a68ad4c78@github.com>
 <mrs1ibMzuByd24DO8gFvHpLaZQIDVwQVtKwLBGtqTSU=.64e03928-a00d-4f9d-bdc2-5228d327098f@github.com>
Message-ID: <ZaGupkkj8rSCjAxHAnrPX2mDrbVntXlusEb0dn9gPSM=.1c427325-ced7-45a5-b948-49e82fc75fbf@github.com>

On Wed, 28 Sep 2022 19:07:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The issue is caused by TreeTableRow incorrectly selected when cell selection mode is enabled.
>> 
>> Changes:
>> - modified TreeTableRow.updateSelection()
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292353: review comments

Looks good.

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

Marked as reviewed by kcr (Lead).

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

From john.hendrikx at gmail.com  Thu Sep 29 14:33:38 2022
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Thu, 29 Sep 2022 16:33:38 +0200
Subject: ObservableValue::map called twice
In-Reply-To: <CA+0ynh_DOMpKx4qfE-Jv8NR=t26cb2FApXE0TduNysbNZsaYHw@mail.gmail.com>
References: <CA+0ynh_DOMpKx4qfE-Jv8NR=t26cb2FApXE0TduNysbNZsaYHw@mail.gmail.com>
Message-ID: <b3fa1bdb-1f2e-2bc0-6578-a8b12d45e5c1@gmail.com>

Hi Nir,

This is sort of normal behavior, and is a consequence of how listeners 
are only registered when themselves observed.? This interacts with the 
concept of being valid/invalid.? There is a long comment about it in 
LazyObjectBinding, but this is the code that is causing this:

 ??? private void updateSubscriptionAfterAdd() {
 ??????? if (!wasObserved) { // was first observer registered?
 ??????????? subscription = observeSources(); // start observing source

 ??????????? /*
 ???????????? * Although the act of registering a listener already 
attempts to make
 ???????????? * this binding valid, allowValidation won't allow it as 
the binding is
 ???????????? * not observed yet. This is because isObserved will not 
yet return true
 ???????????? * when the process of registering the listener hasn't 
completed yet.
 ???????????? *
 ???????????? * As the binding must be valid after it becomes observed 
the first time
 ???????????? * 'get' is called again.
 ???????????? *
 ???????????? * See com.sun.javafx.binding.ExpressionHelper (which is used
 ???????????? * by ObjectBinding) where it will do a call to 
ObservableValue#getValue
 ???????????? * BEFORE adding the actual listener. This results in 
ObjectBinding#get
 ???????????? * to be called in which the #allowValidation call will 
block it from
 ???????????? * becoming valid as the condition is "isObserved()"; this 
is technically
 ???????????? * correct as the listener wasn't added yet, but means we 
must call
 ???????????? * #get again to make this binding valid.
 ???????????? */

 ??????????? get(); // make binding valid as source wasn't tracked until now

 ??????????? wasObserved = true;
 ??????? }
 ??? }

Basically the first "map" call in your sample is triggered by 
`observeSources` in the snippet above (triggered in turn by 
`ExpressionHelper` call to getValue just before it adds the listener).? 
The 2nd one is triggered by the `get()` call.

It may be possible to change this but will likely require a change in 
the parent class (ObjectBinding) to explicitely set it to valid (which 
breaks the encapsulation it does there to guard this).

Alternatively, it may be possible to change the order of calls in 
`ExpressionListener`, first add the listener, then make it valid with 
`getValue` instead of the other way around. At the time I didn't want to 
risk changing that order as I'm unsure if that could have any 
consequences, given that it is such an important part of JavaFX properties.

It may also be possible to somehow override what `allowValidation` 
returns during the call to `observeSources`.

--John

On 28/09/2022 20:44, Nir Lisker wrote:
> Hi,
>
> Running this code:
>
> var label = new Label();
> var tf = new TextField();
> label.textProperty().bind(tf.textProperty().map(t -> {
> ? ? System.out.println("in");
> ? ? return t;
> }));
>
> produces the output::
> in
> in
>
> From what I see, the lambda should be called once, but it's called 
> twice. Looks like improper behavior to me.
>
> - Nir

From jhendrikx at openjdk.org  Thu Sep 29 14:55:38 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 29 Sep 2022 14:55:38 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v5]
In-Reply-To: <3npWBIZ0nvS9Fa4wBhOVRbApPJ7J-emrQInMQU6vOP8=.ac54b5bd-798b-4cc4-9cbd-e642d367a691@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <he1V2bgR_n60-g0ZKbw6fZ9WJbmH9gQtnZofaTrwMdg=.f8006a46-8082-406f-85e2-a0b912eb1e9b@github.com>
 <3npWBIZ0nvS9Fa4wBhOVRbApPJ7J-emrQInMQU6vOP8=.ac54b5bd-798b-4cc4-9cbd-e642d367a691@github.com>
Message-ID: <k9WIzRH3jOuhHSkk5CQFDUxiwI-WZxwxa895RutXHY8=.7ebd159c-4a0f-441a-a1c5-7e20e167a375@github.com>

On Mon, 26 Sep 2022 19:37:54 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing new line
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 12:
> 
>> 10:     private final ObservableValue<Boolean> nonNullCondition;
>> 11: 
>> 12:     private Subscription subscription;
> 
> Isn't it better to use an `EMPTY` subscription, like `FlatMap` does?

I think it would be less good here, since I also need to know whether there currently is a subscription.  Comparing with the empty subscription feels not very nice, specifically this code:

    @Override
    protected T computeValue() {
        if (isObserved() && isActive()) {
            if (subscription.equals(Subscription.EMPTY)) {  // was: if(subscription == null) {
                subscription = Subscription.subscribeInvalidations(source, this::invalidate);
            }
        }
        else {
            unsubscribe();
        }

        return source.getValue();
    }

In flatMap this doesn't occur, and we don't care so much whether that specific subscription is present or not.  In flatMap the empty subscription is used because there always should be a subscription, but in case of a mapping to `null` there obviously can't be one.

> modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 16:
> 
>> 14:     public ConditionalBinding(ObservableValue<T> source, ObservableValue<Boolean> condition) {
>> 15:         this.source = Objects.requireNonNull(source, "source");
>> 16:         this.nonNullCondition = Objects.requireNonNull(condition, "condition").orElse(false);
> 
> The message should probably match the other classes: "source cannot be null".

Fixed

> modules/javafx.base/src/main/java/com/sun/javafx/binding/ConditionalBinding.java line 41:
> 
>> 39:     protected T computeValue() {
>> 40:         if (isObserved() && isActive()) {
>> 41:             if(subscription == null) {
> 
> Space after `if`.

Fixed (everywhere)

> modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java line 65:
> 
>> 63: 
>> 64:         binding.addListener(obs -> {
>> 65:             assertEquals("A", binding.get());
> 
> Can be converted to an expression.

Fixed

> modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 52:
> 
>> 50: 
>> 51: public class ObservableValueFluentBindingsTest {
>> 52:     private int invalidations;
> 
> Empty line after class declaration.

Fixed

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

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

From jhendrikx at openjdk.org  Thu Sep 29 15:02:13 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 29 Sep 2022 15:02:13 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v6]
In-Reply-To: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
Message-ID: <_fhh3rovPXyJLj8c_uYrf15QjIMbes-UhDscAzWWzb4=.9b2602b9-12d8-4545-841c-d72feb53de84@github.com>

> This PR adds a new (lazy*) property on `Node` which provides a boolean which indicates whether or not the `Node` is currently part of a `Scene`, which in turn is part of a currently showing `Window`.
> 
> It also adds a new fluent binding method on `ObservableValue` dubbed `when` (open for discussion, originally I had `conditionOn` here).
> 
> Both of these together means it becomes much easier to break strong references that prevent garbage collection between a long lived property and one that should be shorter lived. A good example is when a `Label` is bound to a long lived property:
> 
>      label.textProperty().bind(longLivedProperty.when(label::isShowingProperty));
> 
> The above basically ties the life cycle of the label to the long lived property **only** when the label is currently showing.  When it is not showing, the label can be eligible for GC as the listener on `longLivedProperty` is removed when the condition provided by `label::isShowingProperty` is `false`.  A big advantage is that these listeners stop observing the long lived property **immediately** when the label is no longer showing, in contrast to weak bindings which may keep observing the long lived property (and updating the label, and triggering its listeners in turn) until the next GC comes along.
> 
> The issue in JBS also describes making the `Subscription` API public, but I think that might best be a separate PR.
> 
> Note that this PR contains a bugfix in `ObjectBinding` for which there is another open PR: https://github.com/openjdk/jfx/pull/829 -- this is because the tests for the newly added method would fail otherwise; once it has been integrated to jfx19 and then to master, I can take the fix out.
> 
> (*) Lazy means here that the property won't be creating any listeners unless observed itself, to avoid problems creating too many listeners on Scene/Window.

John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge remote-tracking branch 'origin/master' into
   feature/conditional-bindings
   
   # Conflicts:
   #	modules/javafx.base/src/test/java/test/javafx/beans/value/LazyObjectBindingTest.java
 - Fix review comments
 - Add missing new line
 - Small wording fixes
 - Update javadoc of "when" with better phrasing
 - Rename showing property to shown as it is already used in subclasses
 - Add conditional bindings to ObservableValue
 - Change explanatory comment to block comment
 - Fix bug where ObjectBinding returns null when revalidated immediately
   
   Introduced with the fluent bindings PR

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

Changes: https://git.openjdk.org/jfx/pull/830/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=830&range=05
  Stats: 553 lines in 5 files changed: 543 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/830.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/830/head:pull/830

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

From jhendrikx at openjdk.org  Thu Sep 29 15:02:14 2022
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 29 Sep 2022 15:02:14 GMT
Subject: RFR: 8290040: Provide simplified deterministic way to manage
 listeners [v5]
In-Reply-To: <3npWBIZ0nvS9Fa4wBhOVRbApPJ7J-emrQInMQU6vOP8=.ac54b5bd-798b-4cc4-9cbd-e642d367a691@github.com>
References: <5lmsGvmQFxdLJDJulBdBj3bfCG6-_6cCkh44OzHaaac=.fdcdfc8c-5fc7-466d-aa11-7fd6ba327c8b@github.com>
 <he1V2bgR_n60-g0ZKbw6fZ9WJbmH9gQtnZofaTrwMdg=.f8006a46-8082-406f-85e2-a0b912eb1e9b@github.com>
 <3npWBIZ0nvS9Fa4wBhOVRbApPJ7J-emrQInMQU6vOP8=.ac54b5bd-798b-4cc4-9cbd-e642d367a691@github.com>
Message-ID: <W04MllHtsQH1gQsMffSDMdsEicBrt0zym7fyju9435U=.e9f0551c-a835-4227-b548-73b3551ae7d2@github.com>

On Mon, 26 Sep 2022 23:30:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Implementation and tests look good. Left a few minor comments.
> 
> in `ObjectBinding.java`, the change in a previous PR was integrated. I think that you need to merge master to not show this as a change in this PR.

I've merged in master.
 
> I will have a look at the changes to `Node` soon. I'm not sure if they need to be in this PR, but I personally don't mind. Will also do some sanity checks manually to see that the binding functions the way I think it should (as I have done in the previous fluent binding PR), but I don't foresee any issues.

It would be good to have changes in `Node` as well as they help with the goal of this issue (deterministic ways to manage listeners), but not required.  If we take them out, I'll have to update one of the examples that assumes it is part of this PR.

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

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

From angorya at openjdk.org  Thu Sep 29 15:58:01 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 Sep 2022 15:58:01 GMT
Subject: RFR: 8290844: Add Skin.install() method [v9]
In-Reply-To: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
Message-ID: <oZ4ZBrKrILEV8Q4xbXCUh8uMda_C5lgCUjKagCK0Uzc=.90d2dc1b-e4b9-44b1-92d6-dc425a47ec38@github.com>

> - added Skin.install()
> - javadoc changes for Skinnable.setSkin(Skin)

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8290844.skin.install
 - 8290844: unit tests
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: review comments
 - 8290844: review comments
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: review comments
 - 8290844: review comments
 - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
 - 8290844: javadoc
 - ... and 10 more: https://git.openjdk.org/jfx/compare/bd52ff03...d954aafc

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/845/files
  - new: https://git.openjdk.org/jfx/pull/845/files/a08bdf60..d954aafc

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

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

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

From angorya at openjdk.org  Thu Sep 29 16:15:34 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 Sep 2022 16:15:34 GMT
Subject: RFR: 8293444: Creating ScrollPane with same content component
 causes memory leak [v3]
In-Reply-To: <aCZA5umvfpZ8LfJ4X0I-fqxoD-r4-_CpuhAV-vDbqzM=.85339a24-1e2f-4058-8ad0-cb18b5755510@github.com>
References: <9M9b9E3VLFKRQYGZ7aYwNdgHXAC9vsJLmCLpnGSkNAs=.d9cdabe7-5b55-43d5-9fe6-d6558b998b5d@github.com>
 <24VyehK8S7W8vjroiKNSkCDCASGMkhy3jLkQ05dMnUo=.e4d2e29b-50f3-4642-8e7f-2379d34fdd17@github.com>
 <aCZA5umvfpZ8LfJ4X0I-fqxoD-r4-_CpuhAV-vDbqzM=.85339a24-1e2f-4058-8ad0-cb18b5755510@github.com>
Message-ID: <Z0UcsUqVjA4t37iymg8Xtn3BtlFCnMHWtcfHCgfuKpU=.de9e0252-4ada-492c-9fe1-7a0cb3b42f8c@github.com>

On Thu, 29 Sep 2022 08:01:55 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293444: review comments
>
> Of course, you can keep it this way.
> 
> The point of JMemoryBuddy.memoryTest is, that the user doesn't have to fiddle around with WeakReferences.
> For the record, your test might look like this (not tested):
> 
>     @Test
>     public void testScrollPaneObjLeakWhenUsedSameContent() {
>         JMemoryBuddy.memoryTest(() -> {
>             BorderPane bp = new BorderPane();
> 
>             Stage stage = new Stage();
>             stage.setScene(new Scene(bp));
>             stage.show();
> 
>             Label content = new Label("content");
> 
>             ScrollPane sp1 = new ScrollPane(content);
>             bp.setCenter(sp1);
>             Toolkit.getToolkit().firePulse();
> 
>             ScrollPane sp2 = new ScrollPane(content);
>             bp.setCenter(sp2);
>             Toolkit.getToolkit().firePulse();
> 
>             bp.setCenter(null);
>             Toolkit.getToolkit().firePulse();
> 
>             // When the label is still referenced, then only one ScrollPane should stay which is its parent
>             checker.setAsReferenced(label)
>             checker.assertCollectable(sp1)
>             checker.assertNotCollectable(sp2)
>         });
>     }
> 
>     @Test
>     public void testScrollPaneObjLeakWhenUsedSameContent() {
>         JMemoryBuddy.memoryTest(() -> {
>             BorderPane bp = new BorderPane();
> 
>             Stage stage = new Stage();
>             stage.setScene(new Scene(bp));
>             stage.show();
> 
>             Label content = new Label("content");
> 
>             ScrollPane sp1 = new ScrollPane(content);
>             bp.setCenter(sp1);
>             Toolkit.getToolkit().firePulse();
> 
>             ScrollPane sp2 = new ScrollPane(content);
>             bp.setCenter(sp2);
>             Toolkit.getToolkit().firePulse();
> 
>             bp.setCenter(null);
>             Toolkit.getToolkit().firePulse();
> 
>             // IF our label is gone, both scrollpanes shold be collectable
>             checker.assertCollectable(sp1)
>             checker.assertCollectable(sp2)
>         });
>     }
> 
> I think only the first test is the important one.

Thank you for clarifications, @FlorianKirmaier

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

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

From kcr at openjdk.org  Thu Sep 29 18:59:37 2022
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 29 Sep 2022 18:59:37 GMT
Subject: RFR: 8290844: Add Skin.install() method [v9]
In-Reply-To: <oZ4ZBrKrILEV8Q4xbXCUh8uMda_C5lgCUjKagCK0Uzc=.90d2dc1b-e4b9-44b1-92d6-dc425a47ec38@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <oZ4ZBrKrILEV8Q4xbXCUh8uMda_C5lgCUjKagCK0Uzc=.90d2dc1b-e4b9-44b1-92d6-dc425a47ec38@github.com>
Message-ID: <oLBI9-xvsX9idYAg1nVY1HCCnUif-_P_BKWM1MzKuAw=.418f7b52-9e56-49c4-822b-7b936c5592a2@github.com>

On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - added Skin.install()
>> - javadoc changes for Skinnable.setSkin(Skin)
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8290844.skin.install
>  - 8290844: unit tests
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: review comments
>  - 8290844: review comments
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: review comments
>  - 8290844: review comments
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: javadoc
>  - ... and 10 more: https://git.openjdk.org/jfx/compare/d3accb42...d954aafc

This looks good now, although I want to do a little more testing before approving it.

The next step is to update the CSR with the latest doc changes. For the existing methods and class docs that have been modified, please show the diffs to make it easier to see what is changed.

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

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

From angorya at openjdk.org  Thu Sep 29 19:24:43 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 29 Sep 2022 19:24:43 GMT
Subject: RFR: 8290844: Add Skin.install() method [v9]
In-Reply-To: <oZ4ZBrKrILEV8Q4xbXCUh8uMda_C5lgCUjKagCK0Uzc=.90d2dc1b-e4b9-44b1-92d6-dc425a47ec38@github.com>
References: <x8ttaSpC8qVGUvpcoXWQt47vKhrQCts7jeTM6YB5atE=.a2c42dbb-26dd-4d1e-9260-766c365f5287@github.com>
 <oZ4ZBrKrILEV8Q4xbXCUh8uMda_C5lgCUjKagCK0Uzc=.90d2dc1b-e4b9-44b1-92d6-dc425a47ec38@github.com>
Message-ID: <ANuSfPMII4XpAffVbDM6KeTkosuU0iLDS2TZK37nUkU=.b9fa1f02-6a19-4cd0-aec0-36933136f440@github.com>

On Thu, 29 Sep 2022 15:58:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - added Skin.install()
>> - javadoc changes for Skinnable.setSkin(Skin)
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8290844.skin.install
>  - 8290844: unit tests
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: review comments
>  - 8290844: review comments
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: review comments
>  - 8290844: review comments
>  - Merge remote-tracking branch 'origin/master' into 8290844.skin.install
>  - 8290844: javadoc
>  - ... and 10 more: https://git.openjdk.org/jfx/compare/db325a55...d954aafc

updated CSR.

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

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

From jvos at openjdk.org  Fri Sep 30 06:53:31 2022
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 30 Sep 2022 06:53:31 GMT
Subject: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25]
In-Reply-To: <K9M6HXH-Kny5Kjm2gvbUQ40XrHuQu4sjpH1ziq3QShw=.b03a8566-7378-48ac-8da0-27b8fb05d17e@github.com>
References: <jmhA3uSYJ86NkYfIRRArrOUs95l91y8dXnhpKOXXWCY=.36c6ac98-fa69-400e-8fd4-690903a3d07e@github.com>
 <6gBNdAxOqgSHOKfj86nzOUc6_1UWY0kmUnKhf9TwiK8=.7d722669-0d59-42b1-931d-36022d274bc3@github.com>
 <9GXnzwJwsUwutske-Y64hdOx2d28Bcm_COZfJbNEyaI=.9afc48fa-85df-471d-b363-0b7c88ad1055@github.com>
 <Gz-u0ePIekeV77DN03X8_ivSCFxum9aDdR8_fMdMFlc=.2e52bff5-f8e3-448f-a444-1d9f1ab1f01a@github.com>
 <41DeoC5Ij7KsuyYv0YZVGlGPs6UK10zwlzC2HJ0wM5Y=.cacffc47-9de1-4b3b-8d3a-cace992499f5@github.com>
 <l6taNSXPp64fVWSG8n1SKLzXxhdLI3XGlnfCveR7pDE=.04c1f266-c0d7-48de-b6b2-451085f4a220@github.com>
 <mplx8a0OFgatK-pQVnxN1aO5XD217Tobaq2OkYCHwOA=.4616ac94-859a-4e0d-9848-785631fac474@github.com>
 <DchHL8jVuzj14BxwNEtSRj4rC43lhq9a3Y5VuEod1gM=.35faf3ee-f4f9-4e31-b778-d04f24cd6633@github.com>
 <K9M6HXH-Kny5Kjm2gvbUQ40XrHuQu4sjpH1ziq3QShw=.b03a8566-7378-48ac-8da0-27b8fb05d17e@github.com>
Message-ID: <thwYYnHPea-2faOPUrSRg8nle_XTb54d1MkyOr6S0T0=.f7f716ef-62e0-4447-91d5-548292664852@github.com>

On Sun, 21 Mar 2021 00:31:35 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bug in content oriented child windows
>
> Testing:
> 
> **master**
> ![master](https://user-images.githubusercontent.com/30704286/111889893-6e793f80-89c3-11eb-8f38-640e8123794c.png)
> 
> **tsayao:glass_gtk_new_position_and_size**
> ![branch](https://user-images.githubusercontent.com/30704286/111889897-733df380-89c3-11eb-9929-2ed55471638e.png)
> 
> `--tests test.robot.javafx.scene.RobotTest` causes some intermittent error but eventually all passes.

@tsayao The work in this PR looks really good. If you want to continue with this, I will review it. There are some conflicts but those can easily be solved.

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

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

From arapte at openjdk.org  Fri Sep 30 15:20:02 2022
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 30 Sep 2022 15:20:02 GMT
Subject: RFR: 8293795: [Accessibility] [Win] [Narrator] Exceptions when
 deleting text with continous key press in TextArea and TextField
Message-ID: <GfyfhZzepT1E_fKwu8xtO__Pinrf4Am0SIM5djycjkw=.f3de5152-d0ff-4eb6-b7e8-541e76f13664@github.com>

This is a follow up bug-fix to [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281)

Issue:
When Narrator is running,
Following scenarios with TextField or TextArea cause IllegalArgumentException  or NPE

1. Move cursor to beginning of line, Press and hold DELETE key
2. Move cursor to beginning of line, Press and hold CTRL + DELETE key
3. Move cursor to end of line, Press and hold BACKSPACE key
4. Move cursor to end of line, Press and hold CTRL + BACKSPACE key

Fix:
Two variable `start` and `end` in  `WinTextRangeProvider` should be validated against text length
1. Added a method `validateRange()`, and is called several from methods which access text based on `start` and `end` variables
2. Partially reverted fix of [JDK-8284281](https://bugs.openjdk.org/browse/JDK-8284281) : 
    - removed https://github.com/openjdk/jfx/blob/35675c8d27d54a26059b182614e18152794dbcec/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java#L180
    - and used `validateRange()` instead to be symmetrical.

Verification:
To observe the issue.

1. Run any program with TextField and/or TextArea
2. Launch Windows Narrator
3. Run the exception causing scenarios several times:

- Move cursor to beginning of line, Press and hold DELETE key
- Move cursor to beginning of line, Press and hold CTRL + DELETE key
- Move cursor to end of line, Press and hold BACKSPACE key
- Move cursor to end of line, Press and hold CTRL + BACKSPACE key

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

Commit messages:
 - validateRange before accessing text string

Changes: https://git.openjdk.org/jfx/pull/907/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293795
  Stats: 24 lines in 1 file changed: 16 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/907.diff
  Fetch: git fetch https://git.openjdk.org/jfx pull/907/head:pull/907

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