[jfx21u] RFR: 8318387: Update GStreamer to 1.22.6

[Alexander Matveev]

Clean backport of JDK-8318387.

-

Commit messages:
 - Backport 606878af275dbad551a10653c92a2deef61c10cd

Changes: https://git.openjdk.org/jfx21u/pull/33/files
 Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=33&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318387
  Stats: 45668 lines in 438 files changed: 19431 ins; 18936 del; 7301 mod
  Patch: https://git.openjdk.org/jfx21u/pull/33.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/33/head:pull/33

PR: https://git.openjdk.org/jfx21u/pull/33

Re: RFR: 8316518 javafx.print.Paper getWidth / getHeight rounds values, causing errors. [v2]

[Phil Race]

On Tue, 31 Oct 2023 11:46:57 GMT, Florian Kirmaier  
wrote:

>> The Method javafx.print.getWidth and getHeight returns a double of points.
>> But the values are always rounded to full integers. This causes especially 
>> problems,
>> with mm based Papers.
>> 
>> I asked in the mailing list, with the conclusion (me and John Hendrix) that 
>> is best to just fix this behavior by removing the rounding.
>
> Florian Kirmaier has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   JDK-8316518
>   small change based on codereview

Sorry about the very lengthy delay here. I've gone back over what little I have 
left from 11 years ago and I can't find a specific reason for the rounding.
My best guess is that it was about "UI", meaning ideally a user would not see 
values like 611.9985349
If that becomes a problem we can revert this i fwe can't handle it elsewhere.

-

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1244#pullrequestreview-1745523007

Re: RFR: 8313648: JavaFX application continues to show a black screen after graphic card driver crash

[Marius Hanl]

On Sat, 5 Aug 2023 12:28:16 GMT, Thorsten Fischer  wrote:

> Hi,
> 
> I did open the bug report. Some notes to this PR:
> 
> My colleagues and I are able to reproduce this bug regularly, even though it 
> takes sometimes up to 3 or 4 weeks until the D3DERR_DEVICEHUNG error shows 
> up. We are currently evaluating two versions of fixes, but until now we do 
> not have any results. I will post them as soon as I got them.
> 
> Version 1 (this version): Based on the observation, that the 
> TestCooperativeLevel/CheckDeviceState method returns D3D_OK again after about 
> 20 - 60 seconds, the reinitialize is called after the first time the state is 
> returning D3D_OK. The 'isHung' flag stores the information until then.
> 
> Version 2: calls reinitialize directly after D3DERR_DEVICEHUNG has been 
> returned. Basically
> if (hr == D3DERR_DEVICEREMOVED || hr == D3DERR_DEVICEHUNG  ) { .. }
> 
> I did not modify the validatePresent method, as for our workaround (see 
> ticket) it was not necessary. At least the native call swapchain->present 
> dows not return that error code 
> (https://learn.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-idirect3dswapchain9-present).
>  I did not look decisively into all the native calls behind 
> D3DRTTexture#readPixels.
> 
> As I said I will post the results (prism.verbose output) for the 2 versions 
> later as a base for discussions.

Looks good to me as well.

modules/javafx.graphics/src/main/native-prism-d3d/D3DContext.cc line 761:

> 759: TraceLn1(NWT_TRACE_INFO, "  device %d has been removed", 
> adapterOrdinal);
> 760: break;
> 761: case D3DERR_DEVICEHUNG:

you probably need to adjust the copyright here as well

-

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1199#pullrequestreview-1745352628
PR Review Comment: https://git.openjdk.org/jfx/pull/1199#discussion_r1402696340

Re: RFR: 8313648: JavaFX application continues to show a black screen after graphic card driver crash

[mintykat]

On Sat, 5 Aug 2023 12:28:16 GMT, Thorsten Fischer  wrote:

> Hi,
> 
> I did open the bug report. Some notes to this PR:
> 
> My colleagues and I are able to reproduce this bug regularly, even though it 
> takes sometimes up to 3 or 4 weeks until the D3DERR_DEVICEHUNG error shows 
> up. We are currently evaluating two versions of fixes, but until now we do 
> not have any results. I will post them as soon as I got them.
> 
> Version 1 (this version): Based on the observation, that the 
> TestCooperativeLevel/CheckDeviceState method returns D3D_OK again after about 
> 20 - 60 seconds, the reinitialize is called after the first time the state is 
> returning D3D_OK. The 'isHung' flag stores the information until then.
> 
> Version 2: calls reinitialize directly after D3DERR_DEVICEHUNG has been 
> returned. Basically
> if (hr == D3DERR_DEVICEREMOVED || hr == D3DERR_DEVICEHUNG  ) { .. }
> 
> I did not modify the validatePresent method, as for our workaround (see 
> ticket) it was not necessary. At least the native call swapchain->present 
> dows not return that error code 
> (https://learn.microsoft.com/en-us/windows/win32/api/d3d9/nf-d3d9-idirect3dswapchain9-present).
>  I did not look decisively into all the native calls behind 
> D3DRTTexture#readPixels.
> 
> As I said I will post the results (prism.verbose output) for the 2 versions 
> later as a base for discussions.

We have a mission critical application for Navy air traffic control that is 
losing javaFX display continuity after the graphics driver crashes on an HP 
Pavlion G6, which happens randomly every few hours. Of course, while the error 
says the system recovers, the javaFX doesn't, so we have to reboot the 
workstation. I see that a similar issue was fixed for remote desktop. I hope we 
can get an Oracle bug fix ASAP.

-

PR Comment: https://git.openjdk.org/jfx/pull/1199#issuecomment-1823415669

Integrated: JDK-8320444: Column drag header is positioned wrong for nested columns

[Marius Hanl]

On Mon, 20 Nov 2023 22:24:58 GMT, Marius Hanl  wrote:

> When a nested column is dragged, the column drag header (blue) is positioned 
> wrong.
> It appears at the very left of the table and not where the column is.
> 
> ![image](https://github.com/openjdk/jfx/assets/66004280/6c2a0f61-f32d-4c38-9549-e2e20f5bd4f8)
> 
> The fix is to calculate the bound based off the `TableHeaderRow` (and not the 
> parent `NestedTableColumnHeader`.

This pull request has now been integrated.

Changeset: 3548cdde
Author:Marius Hanl 
URL:   
https://git.openjdk.org/jfx/commit/3548cddedcf3e99af9263efc8004a092a55af8fb
Stats: 92 lines in 3 files changed: 87 ins; 0 del; 5 mod

8320444: Column drag header is positioned wrong for nested columns

Reviewed-by: kpk, angorya, mstrauss

-

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

Re: RFR: 8284544: [Win] Name-Property of Spinner cannot be changed [v3]

[Ambarish Rapte]

On Wed, 22 Nov 2023 17:05:36 GMT, Ambarish Rapte  wrote:

>> Currently we use the value of spinner as it's `UIA_NamePropertyId` when a11y 
>> client application requests for it.
>> Ideally we should use the text set by `Node.setAccessibleText()` as the 
>> `UIA_NamePropertyId`.
>> For other controls such as Slider, ListView we use the text set by 
>> setAccessibleText() API.
>> 
>> Fix:
>> Use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`.
>> This means, when a11y client requests `UIA_NamePropertyId`, which is mapped 
>> to AccessibleAttribute.TEXT attribute,  we shall return the accessible text.
>> So we need another way to read out the VALUE of the Spinner.
>> - For this we need to implement `IValueProvider` pattern for Spinner control
>> - IValueProvider requests the value of the control using it's API 
>> `get_ValueString()`
>> - It required to introduce a new AccessibleAttribute `VALUE_STRING`
>> - IValueProvider  also reads out if the control is editable or not, hence 
>> added `EDITABLE `case in `Spinner.queryAccessibleAttribute()`
>> 
>> Verification:
>> - Run any spinner app, with setAccessibleText set on spinner 
>> - Run Windows narrator and observe
>> - Without this fix:
>> - 1. Narrator does not read the text set by setAccessibleText
>> - 2. In application "Accessibility Insights for Windows", you can see the 
>> value of Spinner as the Name property
>> - After this fix:
>> - 1. Narrator reads the accessible text then value of Spinner and then if 
>> editable or not
>> - 2. In application "Accessibility Insights for Windows", you can see the 
>> text set by `setAccessibleText()` for Spinner as the Name property and the 
>> Spinner's value as value property
>
> Ambarish Rapte has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Mac a11y change for VALUE_STRING attribute for Spinner

Updated the PR with changes required for macOS, such that the Spinner is read 
same as before.

-

PR Comment: https://git.openjdk.org/jfx/pull/1291#issuecomment-1823181516

Re: RFR: 8313556: Create implementation of NSAccessibilitySlider protocol [v6]

[Ambarish Rapte]

On Wed, 15 Nov 2023 22:00:13 GMT, Alexander Zuev  wrote:

>> Create implementation for Slider and Stepper accessibility protocols.
>> Fix mapping.
>> Fix performAction parameter type in declaration.
>
> Alexander Zuev has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Adding accessibilityMinValue and accessibilityMaxValue

>But with, [8284544: [Win] Name-Property of Spinner cannot be changed 
> #1291](https://github.com/openjdk/jfx/pull/1291) , the value of spinner is 
> not read

This is corrected in #1291, Please ignore above comment.
Above is not a side effect of this PR, but it was an issue with #1291
I have corrected the same and Spinner gets read same as before, with #1291  and 
with both #1291 & this #1226

-

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-1823180199

Re: RFR: 8284544: [Win] Name-Property of Spinner cannot be changed [v3]

[Ambarish Rapte]

> Currently we use the value of spinner as it's `UIA_NamePropertyId` when a11y 
> client application requests for it.
> Ideally we should use the text set by `Node.setAccessibleText()` as the 
> `UIA_NamePropertyId`.
> For other controls such as Slider, ListView we use the text set by 
> setAccessibleText() API.
> 
> Fix:
> Use the text set by `Node.setAccessibleText()` as the `UIA_NamePropertyId`.
> This means, when a11y client requests `UIA_NamePropertyId`, which is mapped 
> to AccessibleAttribute.TEXT attribute,  we shall return the accessible text.
> So we need another way to read out the VALUE of the Spinner.
> - For this we need to implement `IValueProvider` pattern for Spinner control
> - IValueProvider requests the value of the control using it's API 
> `get_ValueString()`
> - It required to introduce a new AccessibleAttribute `VALUE_STRING`
> - IValueProvider  also reads out if the control is editable or not, hence 
> added `EDITABLE `case in `Spinner.queryAccessibleAttribute()`
> 
> Verification:
> - Run any spinner app, with setAccessibleText set on spinner 
> - Run Windows narrator and observe
> - Without this fix:
> - 1. Narrator does not read the text set by setAccessibleText
> - 2. In application "Accessibility Insights for Windows", you can see the 
> value of Spinner as the Name property
> - After this fix:
> - 1. Narrator reads the accessible text then value of Spinner and then if 
> editable or not
> - 2. In application "Accessibility Insights for Windows", you can see the 
> text set by `setAccessibleText()` for Spinner as the Name property and the 
> Spinner's value as value property

Ambarish Rapte has updated the pull request incrementally with one additional 
commit since the last revision:

  Mac a11y change for VALUE_STRING attribute for Spinner

-

Changes:
  - all: https://git.openjdk.org/jfx/pull/1291/files
  - new: https://git.openjdk.org/jfx/pull/1291/files/58bf6dd3..31f8d14a

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

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

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

Re: [jfx21u] RFR: 8317370: JavaFX runtime version is wrong at runtime

[John Neffenger]

On Tue, 21 Nov 2023 20:19:04 GMT, John Neffenger  wrote:

> Backport 16169240667876633895b27464eb90033abb6166
> 
> Please review this backport of openjdk/jfx#1253 to JavaFX 21. Please give me 
> a day or two to test it again before starting your review.

I ran the builds and unit tests on Linux, macOS, and Windows. All builds and 
tests were successful. The run-time and build-time versions are as expected:


$ grep 'static final String' \
  
linux/modules/javafx.base/build/gensrc/java/com/sun/javafx/runtime/VersionInfo.java
private static final String BUILD_TIMESTAMP = "2023-11-21-201527";
private static final String HUDSON_JOB_NAME = "not_hudson";
private static final String HUDSON_BUILD_NUMBER = "";
private static final String RELEASE_SUFFIX = "-internal";
private static final String VERSION = "21.0.2-internal";
private static final String RUNTIME_VERSION = 
"21.0.2-internal+0-2023-11-21-201527";
$ cat linux/build/sdk/lib/javafx.properties
javafx.version=21.0.2-internal
javafx.runtime.version=21.0.2-internal+0-2023-11-21-201527
javafx.runtime.build=0


The only thing that didn't get copied over with the original commit is the 
updated copyright statement in the `VersionInfo.java` class:


$ for f in $(git diff master --name-only); do echo "$f"; grep Copyright "$f"; 
done 
UPDATING-VERSION.md
build.gradle
 * Copyright (c) 2013, 2023, Oracle and/or its affiliates. All rights reserved.
modules/javafx.base/src/main/version-info/VersionInfo.java
 * Copyright (c) 2011, 2022, Oracle and/or its affiliates. All rights reserved.
modules/javafx.base/src/test/java/test/com/sun/javafx/runtime/VersionInfoTest.java
 * Copyright (c) 2011, 2023, Oracle and/or its affiliates. All rights reserved.


In general, do we try to keep that copyright statement updated when backporting 
a fix?

By the way, could a lawyer at Oracle take a look into whether we could stop 
updating the copyright years or even drop the years altogether? Apparently, it 
all [started with *curl*][1], but now [everyone's doing it][2] (Amazon, 
Microsoft, Facebook, Google, Netflix) — or rather, **not** doing it. 😄 The most 
authoritative post about the subject might be [this one from the Linux 
Foundation][3].

[1]: https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
[2]: https://hynek.me/til/copyright-years/
[3]: 
https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects

-

PR Comment: https://git.openjdk.org/jfx21u/pull/32#issuecomment-1823070821

Re: [External] : Re: JavaFX 21.0.2 will be closed for fixes on December 4th

[Johan Vos]

No concerns, good idea.

On Tue, Nov 21, 2023 at 5:23 PM Kevin Rushforth 
wrote:

> This one looks OK to me as long as there are no dependencies on other
> fixes. It's been in jfx22 for a couple months, and don't recall any
> regressions.
>
> Johan and Jose: you reviewed it, any concerns?
>
> -- Kevin
>
>
> On 11/21/2023 8:13 AM, Thiago Milczarek Sayão wrote:
>
> Hi Kevin,
>
> Some folks from the JabRef project asked to backport this:
> https://github.com/openjdk/jfx/pull/1173
> 
>
> JabRef project issue:
> https://github.com/JabRef/jabref/issues/5867
> 
>
> I don't know if it fits the backport rationale.
>
> -- Thiago.
>
>
>
>
>
> Em seg., 20 de nov. de 2023 às 21:59, Kevin Rushforth <
> kevin.rushfo...@oracle.com> escreveu:
>
>> All,
>>
>> If you have backports that you want to get into jfx21u for JavaFX
>> 21.0.2, please do so by Monday, December 4th. Note that approval from
>> one of the project leads is needed as outlined in this message [1].
>>
>> Thanks.
>>
>> -- Kevin
>>
>> [1]
>> https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/042200.html
>>
>>
>