From aghaisas at openjdk.org  Mon Apr  1 09:17:38 2024
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 1 Apr 2024 09:17:38 GMT
Subject: RFR: 8328745: Remove unused imports in system tests
In-Reply-To: <WotT8FmPfdsbWBlSpY4M6Gr4PgAV26jMNldinBKhrBo=.61f15161-c864-44b7-be5a-ca2debd2d070@github.com>
References: <WotT8FmPfdsbWBlSpY4M6Gr4PgAV26jMNldinBKhrBo=.61f15161-c864-44b7-be5a-ca2debd2d070@github.com>
Message-ID: <BqX6Ohvsur-bKY5_PHai2J3iraomgc0y0JSaya7MJUk=.2fd86a0e-0161-4942-b2f7-37a5fbe9fe05@github.com>

On Thu, 21 Mar 2024 21:31:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **system tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> --
> 
> This is a trivial change (though fairly large), 1 reviewer is probably enough.

This cleanup Looks good.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1419#pullrequestreview-1970960265

From aghaisas at openjdk.org  Mon Apr  1 09:34:37 2024
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 1 Apr 2024 09:34:37 GMT
Subject: RFR: 8328718: Remove unused imports in javafx.controls
In-Reply-To: <sp6VnlZj2Pdyqa7TpN9HGMFx3cRLSGgwbqfN9mF2Qv0=.4180c14a-6f89-4c19-b017-7d6358167cc8@github.com>
References: <sp6VnlZj2Pdyqa7TpN9HGMFx3cRLSGgwbqfN9mF2Qv0=.4180c14a-6f89-4c19-b017-7d6358167cc8@github.com>
Message-ID: <LWrmczwcNFQwI641NZtkLfgt10SdnWLMM6uMoJvxmYY=.e207e7a3-398d-419e-87f1-306be041555d@github.com>

On Thu, 21 Mar 2024 18:47:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in javafx.controls and update the copyright year to 2024.  Using wildcard for more than 10 static imports.
> 
> This is a trivial change, 1 reviewer is probably enough.

This cleanup Looks good.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1416#pullrequestreview-1970980892

From aghaisas at openjdk.org  Mon Apr  1 09:35:37 2024
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 1 Apr 2024 09:35:37 GMT
Subject: RFR: 8328820: Remove unused imports in javafx.swing
In-Reply-To: <wjlBwvzgaDZI-aNL1qGR8m0Ze5m73TOgIXrTy_6JAeE=.ee1f6227-7b45-47b8-8787-4fe9ea47910a@github.com>
References: <wjlBwvzgaDZI-aNL1qGR8m0Ze5m73TOgIXrTy_6JAeE=.ee1f6227-7b45-47b8-8787-4fe9ea47910a@github.com>
Message-ID: <UrDSUAh4nQUWD0DLM5NQqgUQSpCkvDswXKBakJLKlTI=.213814f5-7e1e-47c4-99d2-f9f500a4d5a1@github.com>

On Fri, 22 Mar 2024 16:04:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removed unused imports in javafx.swing (1 change) module.
> 
> See the discussion in [JDK-8289379](https://bugs.openjdk.org/browse/JDK-8289379)

This cleanup Looks good.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1428#pullrequestreview-1970981426

From kcr at openjdk.org  Mon Apr  1 14:01:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Apr 2024 14:01:37 GMT
Subject: RFR: 8328746: Remove unused imports in demo apps
In-Reply-To: <CbIUc-_ZCTuQCoMiU47B0WQqjx2Jb9snoYDsJy6_H3w=.c8d2fed0-7be7-4d49-99a2-3411e9c7f432@github.com>
References: <bCGV-dKuowPkMfOqAoXqV-GXMbeaQUSD85NRzyN6Ucc=.84086de7-78ef-4fe3-bafb-a16ffe0090b2@github.com>
 <CbIUc-_ZCTuQCoMiU47B0WQqjx2Jb9snoYDsJy6_H3w=.c8d2fed0-7be7-4d49-99a2-3411e9c7f432@github.com>
Message-ID: <fnOE7jHdNsvKUl6zLNkFJVGbDvIm4_fvTphYxwlSR1A=.9cc748d4-9caa-4de0-bdaf-7bd37b9c6a2b@github.com>

On Wed, 27 Mar 2024 14:51:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I would highly suggest to use the current guidelines in CONTRIBUTING.md
> 
> ```
> * Don't worry too much about import order. Try not to change it but don't worry about fighting your IDE to stop it from doing so.
> ```

Since this is the existing guideline, and there isn't clear agreement on a new guideline, this seems like the best approach. We can revisit this after the current set of PRs are integrated if there is a desire to do so.

> as not doing so generates unnecessary (in my opinion) discussion.

And I think that it is the _absence_ of at least a soft guideline that generates the discussion, but we can table the discussion for now.

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

PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2029799109

From kcr at openjdk.org  Mon Apr  1 14:01:37 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Apr 2024 14:01:37 GMT
Subject: RFR: 8328746: Remove unused imports in demo apps
In-Reply-To: <bCGV-dKuowPkMfOqAoXqV-GXMbeaQUSD85NRzyN6Ucc=.84086de7-78ef-4fe3-bafb-a16ffe0090b2@github.com>
References: <bCGV-dKuowPkMfOqAoXqV-GXMbeaQUSD85NRzyN6Ucc=.84086de7-78ef-4fe3-bafb-a16ffe0090b2@github.com>
Message-ID: <_hKb9EYD_gy_xmZ6dKFx_jrQ_mt8LDzzul5xVO0Odow=.e1bc38a6-b491-4ce3-b0a1-25edd66765c4@github.com>

On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> --
> 
> This is a trivial change (though fairly large), 1 reviewer is probably enough.

This PR looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1420#pullrequestreview-1971320748

From kcr at openjdk.org  Mon Apr  1 14:01:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Apr 2024 14:01:38 GMT
Subject: RFR: 8328746: Remove unused imports in demo apps
In-Reply-To: <2i6hyUMSMJeg4vvARKhFe0eJalFOv36Kq7axbSUIitY=.8340f08f-6269-4984-84bb-2e810e054f88@github.com>
References: <bCGV-dKuowPkMfOqAoXqV-GXMbeaQUSD85NRzyN6Ucc=.84086de7-78ef-4fe3-bafb-a16ffe0090b2@github.com>
 <2i6hyUMSMJeg4vvARKhFe0eJalFOv36Kq7axbSUIitY=.8340f08f-6269-4984-84bb-2e810e054f88@github.com>
Message-ID: <tEjqCm20wB3BqNfRzRSQQ7tKthtVbNTN9LKdHhLNuNs=.532fd879-962d-4631-b43b-d241c5ed2d9b@github.com>

On Thu, 28 Mar 2024 09:05:00 GMT, Karthik P K <kpk at openjdk.org> wrote:

> Leaving it unspecified would be ok but some kind of soft recommendation could also help in my opinion. So there will be a direction for someone who is looking for a recommended way to add imports and have consistency class files.

This might be the best approach. A soft recommendation in addition to the current advice to try not to reorder the imports in connection with bug fixes. We can discuss on the list (decoupled from this PR).

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

PR Comment: https://git.openjdk.org/jfx/pull/1420#issuecomment-2029801487

From kcr at openjdk.org  Mon Apr  1 14:02:40 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Apr 2024 14:02:40 GMT
Subject: RFR: 8328749: Remove unused imports in javafx.web [v2]
In-Reply-To: <s1dys6jLlWv1LaoZc2GVxXrbEe0PvLztyruTKb0_Vpk=.78cfdd51-e3ca-4d4d-ba96-add71e9085f3@github.com>
References: <YLPEw-aZbBVGOs69kHRMIog9qEz1V8vvaflsKDi7H94=.d8a324ba-f7b2-4976-9a38-4b3779fc3f8b@github.com>
 <s1dys6jLlWv1LaoZc2GVxXrbEe0PvLztyruTKb0_Vpk=.78cfdd51-e3ca-4d4d-ba96-add71e9085f3@github.com>
Message-ID: <AguKUcjwSZPHudtw3KgBNVdPLo5_ZkH0emlpgfXR4X0=.1674c2d2-5425-420a-9bc5-17236e1fd18a@github.com>

On Fri, 22 Mar 2024 16:11:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Using Eclipse IDE to remove unused imports **javafx.web** module, and update the copyright year to 2024. Using wildcard for more than 10 static imports.
>> 
>> 
>> --
>> 
>> This is a trivial change, 1 reviewer is probably enough.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed swing file

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1421#pullrequestreview-1971321945

From kcr at openjdk.org  Mon Apr  1 14:07:34 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 1 Apr 2024 14:07:34 GMT
Subject: RFR: 8328739: Remove unused imports in javafx.graphics
In-Reply-To: <cROpQbH1Z1QsU4MjEsm6kgDat4bv5D_YCLFXQYBqPT4=.e7cd9e47-e7f6-458c-8368-1c843a0f6157@github.com>
References: <cROpQbH1Z1QsU4MjEsm6kgDat4bv5D_YCLFXQYBqPT4=.e7cd9e47-e7f6-458c-8368-1c843a0f6157@github.com>
Message-ID: <fmJhUIRa_QSlJARzuFnB38ntdS2C8VYLoKFj0BN2uv8=.ef7655ca-0089-412d-bdae-b4091295fbb0@github.com>

On Thu, 21 Mar 2024 19:05:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **javafx.graphics** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> **PROBLEM**
> The code in `graphics/build/gensrc/jsl-decora/` is generated and cannot be fixed.
> This means this warning **must be suppressed** in IDEs until the generator script is changed not to emit unused imports.
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

+1

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1417#pullrequestreview-1971330350

From angorya at openjdk.org  Mon Apr  1 15:03:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 15:03:35 GMT
Subject: Integrated: 8328739: Remove unused imports in javafx.graphics
In-Reply-To: <cROpQbH1Z1QsU4MjEsm6kgDat4bv5D_YCLFXQYBqPT4=.e7cd9e47-e7f6-458c-8368-1c843a0f6157@github.com>
References: <cROpQbH1Z1QsU4MjEsm6kgDat4bv5D_YCLFXQYBqPT4=.e7cd9e47-e7f6-458c-8368-1c843a0f6157@github.com>
Message-ID: <6-3xHIknBvd3j9wqhOQOGi-A3k3zizNNMZoZLL58wUM=.f7387ec3-7d06-4f21-97f5-cbb7de33ddf6@github.com>

On Thu, 21 Mar 2024 19:05:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **javafx.graphics** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> **PROBLEM**
> The code in `graphics/build/gensrc/jsl-decora/` is generated and cannot be fixed.
> This means this warning **must be suppressed** in IDEs until the generator script is changed not to emit unused imports.
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

This pull request has now been integrated.

Changeset: 3761d371
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3761d3715f2475150241b91ba25b44abdfeee3f0
Stats:     33 lines in 6 files changed: 7 ins; 20 del; 6 mod

8328739: Remove unused imports in javafx.graphics

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Mon Apr  1 15:03:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 15:03:40 GMT
Subject: Integrated: 8328749: Remove unused imports in javafx.web
In-Reply-To: <YLPEw-aZbBVGOs69kHRMIog9qEz1V8vvaflsKDi7H94=.d8a324ba-f7b2-4976-9a38-4b3779fc3f8b@github.com>
References: <YLPEw-aZbBVGOs69kHRMIog9qEz1V8vvaflsKDi7H94=.d8a324ba-f7b2-4976-9a38-4b3779fc3f8b@github.com>
Message-ID: <CathnhOPCgRQlHGI5gGF6zV0B3tBw-VKz1LILtHhZew=.645c00bc-55c4-45a8-922d-01d0102608e9@github.com>

On Thu, 21 Mar 2024 21:57:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports **javafx.web** module, and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

This pull request has now been integrated.

Changeset: a85af134
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a85af134f9255f140ea8f9f8e63a19e74f2d1731
Stats:     21 lines in 3 files changed: 4 ins; 13 del; 4 mod

8328749: Remove unused imports in javafx.web

Reviewed-by: hmeda, kcr

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

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

From angorya at openjdk.org  Mon Apr  1 15:04:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 15:04:36 GMT
Subject: Integrated: 8328820: Remove unused imports in javafx.swing
In-Reply-To: <wjlBwvzgaDZI-aNL1qGR8m0Ze5m73TOgIXrTy_6JAeE=.ee1f6227-7b45-47b8-8787-4fe9ea47910a@github.com>
References: <wjlBwvzgaDZI-aNL1qGR8m0Ze5m73TOgIXrTy_6JAeE=.ee1f6227-7b45-47b8-8787-4fe9ea47910a@github.com>
Message-ID: <vl4iHWk0oHZJFGOCEyf27hnIvHufmFyFyug7XKz10Mc=.d68f7f42-dda2-42a0-a851-0dce41d5f32a@github.com>

On Fri, 22 Mar 2024 16:04:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Removed unused imports in javafx.swing (1 change) module.
> 
> See the discussion in [JDK-8289379](https://bugs.openjdk.org/browse/JDK-8289379)

This pull request has now been integrated.

Changeset: edbb88fd
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/edbb88fd578cd5a59d1f8ac47ce961228951b6a2
Stats:     17 lines in 1 file changed: 7 ins; 9 del; 1 mod

8328820: Remove unused imports in javafx.swing

Reviewed-by: aghaisas

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

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

From angorya at openjdk.org  Mon Apr  1 15:05:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 15:05:34 GMT
Subject: Integrated: 8328746: Remove unused imports in demo apps
In-Reply-To: <bCGV-dKuowPkMfOqAoXqV-GXMbeaQUSD85NRzyN6Ucc=.84086de7-78ef-4fe3-bafb-a16ffe0090b2@github.com>
References: <bCGV-dKuowPkMfOqAoXqV-GXMbeaQUSD85NRzyN6Ucc=.84086de7-78ef-4fe3-bafb-a16ffe0090b2@github.com>
Message-ID: <oAPzC7fmRyM9lhCMtv3iSiz_J7pMKCUNC9VJPWvI46s=.01b231cf-826f-4ea4-8352-66510589a359@github.com>

On Thu, 21 Mar 2024 21:50:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **demo apps** (3D, Ensemble, etc.) and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> --
> 
> This is a trivial change (though fairly large), 1 reviewer is probably enough.

This pull request has now been integrated.

Changeset: 01a1d90c
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/01a1d90c317f4dc8e04a01c4b28e7fd63f74f162
Stats:     391 lines in 75 files changed: 98 ins; 189 del; 104 mod

8328746: Remove unused imports in demo apps

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Mon Apr  1 15:05:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 15:05:37 GMT
Subject: Integrated: 8328718: Remove unused imports in javafx.controls
In-Reply-To: <sp6VnlZj2Pdyqa7TpN9HGMFx3cRLSGgwbqfN9mF2Qv0=.4180c14a-6f89-4c19-b017-7d6358167cc8@github.com>
References: <sp6VnlZj2Pdyqa7TpN9HGMFx3cRLSGgwbqfN9mF2Qv0=.4180c14a-6f89-4c19-b017-7d6358167cc8@github.com>
Message-ID: <EkfW-Gkf-wIdXayXOo8vx8DgQM9m90VXi9SjWJ2PlKs=.8bceb42f-4f41-423e-83f5-4403211ce4e7@github.com>

On Thu, 21 Mar 2024 18:47:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in javafx.controls and update the copyright year to 2024.  Using wildcard for more than 10 static imports.
> 
> This is a trivial change, 1 reviewer is probably enough.

This pull request has now been integrated.

Changeset: 4e0a2293
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/4e0a2293e2cfecf6c11ad15cda214ddd179cdc93
Stats:     159 lines in 14 files changed: 47 ins; 81 del; 31 mod

8328718: Remove unused imports in javafx.controls

Reviewed-by: aghaisas

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

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

From angorya at openjdk.org  Mon Apr  1 15:06:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 15:06:34 GMT
Subject: Integrated: 8328745: Remove unused imports in system tests
In-Reply-To: <WotT8FmPfdsbWBlSpY4M6Gr4PgAV26jMNldinBKhrBo=.61f15161-c864-44b7-be5a-ca2debd2d070@github.com>
References: <WotT8FmPfdsbWBlSpY4M6Gr4PgAV26jMNldinBKhrBo=.61f15161-c864-44b7-be5a-ca2debd2d070@github.com>
Message-ID: <NU5OuolEm13Muthy5rL4ouiFa0J5RyL3HGrOMQEnHRc=.abb7d7a7-fdb6-44be-8b37-c4bc755016e4@github.com>

On Thu, 21 Mar 2024 21:31:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **system tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> --
> 
> This is a trivial change (though fairly large), 1 reviewer is probably enough.

This pull request has now been integrated.

Changeset: c08a6b74
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c08a6b7458d4320d91ae7dfad5c0e6278fa9c4c7
Stats:     847 lines in 89 files changed: 206 ins; 480 del; 161 mod

8328745: Remove unused imports in system tests

Reviewed-by: aghaisas

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

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

From angorya at openjdk.org  Mon Apr  1 19:27:17 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 19:27:17 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
Message-ID: <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>

> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
> 
> - ListView
> - TreeView
> - TableView
> - TreeTableView
> 
> to support keyboard-only horizontal scrolling.  The main reason for the change is to improve accessibility.
> 
> **NOTE: For controls in right-to-left orientation, the direction is reversed.**
> 
> As far as I can tell, these key combinations do not interfere with editing.
> 
> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like
> 
> 
> public void horizontalUnitScroll(boolean right);
> 
> 
> Q: Does this change require a CSR to explain the change in the controls' behavior?  We don't yet have the key bindings documented in /doc-files/behavior
> 
> Note:
> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available.

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

 - tests
 - cleanup
 - node orientation
 - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
 - table view behavior
 - tree view behavior
 - list view behavior
 - orientation
 - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
 - Merge branch 'master' into 8313138.horizontal
 - ... and 4 more: https://git.openjdk.org/jfx/compare/90e2a378...5bae5e7a

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1393/files
  - new: https://git.openjdk.org/jfx/pull/1393/files/05809ca3..5bae5e7a

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

  Stats: 2238 lines in 205 files changed: 1093 ins; 826 del; 319 mod
  Patch: https://git.openjdk.org/jfx/pull/1393.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1393/head:pull/1393

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

From angorya at openjdk.org  Mon Apr  1 19:34:03 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 19:34:03 GMT
Subject: RFR: 8328752: Fix missing @Overrides in javafx.web
In-Reply-To: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
References: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
Message-ID: <026Qws0-pOxsX2DM1hYqUYVTxLyGbguWZ1yRDVGV8tQ=.6666ec2b-3c15-4aec-b8c1-d6334c72db8f@github.com>

On Thu, 21 Mar 2024 23:48:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fix missing @Overrides in **javafx.web**.
> 
> This is still a trivial change since all the spots are identified by the IDE.

@HimaBinduMeda could you please take a look at this?  Once reviewed, I'll start the back port chain.  Thank you!

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

PR Comment: https://git.openjdk.org/jfx/pull/1424#issuecomment-2030415866

From thiago.sayao at gmail.com  Mon Apr  1 20:47:56 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 1 Apr 2024 17:47:56 -0300
Subject: Prefer EGL over GLX on Linux
In-Reply-To: <CAAP_wu=TQyxsKZwzpAAOj9Qgp1xVKHXAy2cf0ynkO4Eo=cNYEA@mail.gmail.com>
References: <CAAP_wu=TQyxsKZwzpAAOj9Qgp1xVKHXAy2cf0ynkO4Eo=cNYEA@mail.gmail.com>
Message-ID: <CAAP_wukOPOCPUcEjNt2ToOKaS9W_tphEDpO9xrM=yoHCOCN+vw@mail.gmail.com>

I was looking for comments :)



Em dom., 31 de mar. de 2024 ?s 18:34, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> Hi,
>
> I am doing some efforts here:
> https://github.com/openjdk/jfx/pull/1381
>
> Why?
>
> This is initial Wayland support work, since it will require EGL to draw to
> a Wayland surface. EGL is also supported on Xorg.
> The idea is to prefer EGL and fallback to GLX as it's done in Gtk, for
> example. I don't know of an exact scenario where EGL will fail - maybe very
> old graphics cards.
>
> The second step will be to implement a libwayland-client glass backend.
>
> Some caveats I've found:
> - PrismES2Defs.h -> too much #ifdefs
> - Monocle also uses EGL so it feels somewhat duplicated
> - The Library loading only supports one lib and then falls back to
> software - in this case it's a three-phase loading: EGL, GLX, then SW. I
> will probably have to touch other platform code to isolate this.
>
>
> -- Thiago.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240401/f6f92d79/attachment.htm>

From angorya at openjdk.org  Mon Apr  1 21:59:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 21:59:11 GMT
Subject: [jfx22u] RFR: 8328749: Remove unused imports in javafx.web
Message-ID: <3ZyUwMudRizhoQZ0NX0wRj2DA0LvWCgO8mWoyPv0Rgo=.7cf9af04-cd71-49c0-a116-519a251713cd@github.com>

8328749: Remove unused imports in javafx.web

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

Commit messages:
 - Backport a85af134f9255f140ea8f9f8e63a19e74f2d1731

Changes: https://git.openjdk.org/jfx22u/pull/22/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328749
  Stats: 21 lines in 3 files changed: 4 ins; 13 del; 4 mod
  Patch: https://git.openjdk.org/jfx22u/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/22/head:pull/22

PR: https://git.openjdk.org/jfx22u/pull/22

From angorya at openjdk.org  Mon Apr  1 22:25:07 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Apr 2024 22:25:07 GMT
Subject: [jfx22u] Integrated: 8328749: Remove unused imports in javafx.web
In-Reply-To: <3ZyUwMudRizhoQZ0NX0wRj2DA0LvWCgO8mWoyPv0Rgo=.7cf9af04-cd71-49c0-a116-519a251713cd@github.com>
References: <3ZyUwMudRizhoQZ0NX0wRj2DA0LvWCgO8mWoyPv0Rgo=.7cf9af04-cd71-49c0-a116-519a251713cd@github.com>
Message-ID: <oe7g-Mzf3MRqRaTluCgNRgAdgggFtLvdHOI2Amb5jQ0=.bf6fec31-45fb-4c95-8b06-bf0b93e870dc@github.com>

On Mon, 1 Apr 2024 21:51:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a85af134](https://urldefense.com/v3/__https://github.com/openjdk/jfx/commit/a85af134f9255f140ea8f9f8e63a19e74f2d1731__;!!ACWV5N9M2RV99hQ!OtQmI24diE6uzrrVGadETfh3W-uWRrc5i2-yKL1pWL3y_6JeJ0IpXtnRLh6RQL8axenA6uT-fVigocRTOrnQkzSIIdt2OA$) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Andy Goryachev on 1 Apr 2024 and was reviewed by Hima Bindu Meda and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b3c73197
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx22u/commit/b3c73197aa06f40918710ef87b27295585e39ddb
Stats:     21 lines in 3 files changed: 4 ins; 13 del; 4 mod

8328749: Remove unused imports in javafx.web

Backport-of: a85af134f9255f140ea8f9f8e63a19e74f2d1731

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

PR: https://git.openjdk.org/jfx22u/pull/22

From almatvee at openjdk.org  Tue Apr  2 00:21:59 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 2 Apr 2024 00:21:59 GMT
Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live Streaming
Message-ID: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>

- Added support for #EXT-X-MEDIA tag to HTTP Live Streaming.
- Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details):
  - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
  - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
  - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag.
- Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits.
- HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams.
- Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend.
- JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes.
- Fixed and improved debug output in Linux AV plugins.
- Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time.
- Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams.
- Removed dead code from MediaManager.
- Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases.

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

Commit messages:
 - 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming

Changes: https://git.openjdk.org/jfx/pull/1435/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1435&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282999
  Stats: 2344 lines in 30 files changed: 1265 ins; 408 del; 671 mod
  Patch: https://git.openjdk.org/jfx/pull/1435.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1435/head:pull/1435

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

From rlichten at openjdk.org  Tue Apr  2 07:40:02 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Tue, 2 Apr 2024 07:40:02 GMT
Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if
 has graphic [v4]
In-Reply-To: <_-kHLuzDlB_Vs7MtGRqMx8km6OhxEiYMRoypMmOXDlE=.3986ed1f-71e1-4cc9-b1a0-f46b8add5852@github.com>
References: <GOCc3REwnXmSpsN96WBzCq3dQJPzzvL2dFjOKlpE15c=.fab298e9-f241-4f7c-ab53-2891d5f7fcfa@github.com>
 <WCBZ7zwSnqw7Vw9GdiU8Nznl9CJEIhj_swotTwnzYoM=.5c14df59-52fb-48b7-8d7e-9bd80227fac3@github.com>
 <_-kHLuzDlB_Vs7MtGRqMx8km6OhxEiYMRoypMmOXDlE=.3986ed1f-71e1-4cc9-b1a0-f46b8add5852@github.com>
Message-ID: <VTBsv1M0XLJHRk33bnfyXYzrQtysIFvTsKj0eDmo5o4=.66776aaf-6f2a-4bde-997e-6026119ee163@github.com>

On Wed, 27 Mar 2024 22:29:02 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> @effad Since you benchmarked this method in #1358, could you do that again with this changes?

Sorry for the late reply, I just returned from easter holidays :-). I'll try to benchmark this change within the next days...

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

PR Comment: https://git.openjdk.org/jfx/pull/1405#issuecomment-2031284221

From duke at openjdk.org  Tue Apr  2 12:58:27 2024
From: duke at openjdk.org (eduardsdv)
Date: Tue, 2 Apr 2024 12:58:27 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v3]
In-Reply-To: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
Message-ID: <UZTXB9HcmwVkmceERI4uQq1bS66rz01X2UUJJKVUFJQ=.e42a872c-aa47-444f-b50f-3289e4f37a68@github.com>

> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
> It is now determined before the nodes are removed from the scene graph.
> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
> 
> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.

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

  JDK-8328577: Add unit test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1434/files
  - new: https://git.openjdk.org/jfx/pull/1434/files/82994291..09dcc48d

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

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

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

From rlichten at openjdk.org  Tue Apr  2 13:24:08 2024
From: rlichten at openjdk.org (Robert Lichtenberger)
Date: Tue, 2 Apr 2024 13:24:08 GMT
Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if
 has graphic [v7]
In-Reply-To: <rf1ywzjmJ7EDxuRmF-pOaDZ6XfEgHl6qJm2ZHxSu3Sc=.1959a49d-1413-4af7-b8c2-78e2b7044da0@github.com>
References: <GOCc3REwnXmSpsN96WBzCq3dQJPzzvL2dFjOKlpE15c=.fab298e9-f241-4f7c-ab53-2891d5f7fcfa@github.com>
 <rf1ywzjmJ7EDxuRmF-pOaDZ6XfEgHl6qJm2ZHxSu3Sc=.1959a49d-1413-4af7-b8c2-78e2b7044da0@github.com>
Message-ID: <TDjZBBWIK-aJ7b0ygezGYS4KJzMFDv8hZBUnAk7ykOw=.565788d1-5c0c-4fc1-8c99-b43d7c07354d@github.com>

On Wed, 27 Mar 2024 23:20:49 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes the issue that the initial column autosizing is wrong under some circumstances.
>> The following things will break the initial autosizing:
>> - Bold Column text (that is where I initially found this problem)
>> - Another font / font size
>> - Graphic
>> - Graphic Content Display (which can be styled via CSS)
>> 
>> The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well.
>> 
>> ~It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me.~
>> **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)**
>> 
>> The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text.
>> 
>> I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy).
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use snapped insets

As per request I tested the changes of this PR with the Benchmark found at https://gist.github.com/effad/9eebee0c1e86a8e605cb55ced9485dd4

Baseline: JFX 23-internal+0-2024-04-02-130613 average run time: 975
After `gh pr checkout 1405`: JFX 23-internal+0-2024-04-02-130613 average run time: 1026

So we have a measurable (~5%) but (IMO) neglectable slowdown. Compared to JFX 21.0.2+5 (2460) we are still more than twice as fast.

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

Marked as reviewed by rlichten (Author).

PR Review: https://git.openjdk.org/jfx/pull/1405#pullrequestreview-1973799359

From thiago.sayao at gmail.com  Tue Apr  2 13:24:28 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 2 Apr 2024 10:24:28 -0300
Subject: [openjdk/jfx] Draft: Prefer EGL over GLX to allow further
 development towards Wayland (PR #1381)
In-Reply-To: <openjdk/jfx/pull/1381/review/1973486376@github.com>
References: <openjdk/jfx/pull/1381@github.com>
 <openjdk/jfx/pull/1381/review/1973486376@github.com>
Message-ID: <CAAP_wu=xXC_m-ahKCRqfPgC_w1tJqh2z9LqLJnjaKojZBi8xWA@mail.gmail.com>

Thanks Lukasz. ll look into the points brought up.

I'm unsure on scenarios where GLX will work and EGL will not, but Gtk has
GLX fallback. I will look into it (maybe ask on a Mesa development
channel). The force flag is a nice idea.

It's not a formal JBS issue yet because I don't know if it fits the JavaFX
roadmap, or if there are any other efforts on doing it. It's a "step 1" for
wayland support.
This is the initial feedback I was looking for. I'm willing to invest time
on this, but not if it will never be accepted.

-- Thiago.




Em ter., 2 de abr. de 2024 ?s 09:45, Lukasz Kostyra <
notifications at github.com> escreveu:

> *@lukostyra* commented on this pull request.
>
> I took a brief look at your changes and I shared some comments.
>
> Overall the changes look good. The EGL/GLX loading in GLFactory feels a
> bit hacky, but other than making EGL a completely separate Prism backend
> (which would duplicate/reorganize a lot of common EGL/GLX code - definitely
> a no-go IMO) I don't have a better idea how to solve this. Maybe with an
> ES2-specific property like prism.es2.forceglx=true?
>
> This brings me to a question - other than some form of debugging/fallback
> for when EGL is still new to JFX, do we even need GLX implementation when
> we have a working EGL implementation? I'm fairly sure that current distros
> (especially ones officially supported by JFX) have EGL support available at
> this point in time, and since it's an intermediary layer between
> application and runtime it shouldn't depend on used GPU.
> ------------------------------
>
> In
> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c
> <https://github.com/openjdk/jfx/pull/1381#discussion_r1547684895>:
>
> > +
> +    eglExtensions = (const char *) eglQueryString(eglDisplay, EGL_EXTENSIONS);
> +    if (eglExtensions == NULL) {
> +        eglDestroyContext(eglDisplay, eglContext);
> +        fprintf(stderr, "eglExtensions == null\n");
> +        return 0;
> +    }
> +
> +    /*
> +        fprintf(stderr, "glExtensions: %s\n", glExtensions);
> +        fprintf(stderr, "glxExtensions: %s\n", glxExtensions);
> +    */
> +
> +    /* allocate the structure */
> +    ctxInfo = (ContextInfo *) malloc(sizeof (ContextInfo));
> +    if (ctxInfo == NULL) {
>
> Shouldn't this also eglDestroyContext?
> ------------------------------
>
> In
> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c
> <https://github.com/openjdk/jfx/pull/1381#discussion_r1547688868>:
>
> > +    }
> +
> +    /* initialize the structure */
> +    initializeCtxInfo(ctxInfo);
> +    ctxInfo->versionStr = strdup(glVersion);
> +    ctxInfo->vendorStr = strdup(glVendor);
> +    ctxInfo->rendererStr = strdup(glRenderer);
> +    ctxInfo->glExtensionStr = strdup(glExtensions);
> +    ctxInfo->eglExtensionStr = strdup(eglExtensions);
> +    ctxInfo->versionNumbers[0] = versionNumbers[0];
> +    ctxInfo->versionNumbers[1] = versionNumbers[1];
> +    ctxInfo->context = eglContext;
> +
> +    /* set function pointers */
> +    ctxInfo->glActiveTexture = (PFNGLACTIVETEXTUREPROC)
> +            dlsym(RTLD_DEFAULT, "glActiveTexture");
>
> Since you're using EGL, it would be better to use EGL's own
> eglGetProcAddress here and below.
> ------------------------------
>
> In
> modules/javafx.graphics/src/main/java/com/sun/prism/es2/LinuxEGLContext.java
> <https://github.com/openjdk/jfx/pull/1381#discussion_r1547718158>:
>
> > @@ -0,0 +1,36 @@
> +/*
> + * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
>
> Copyright dates should be updated (here and in other files)
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jfx/pull/1381#pullrequestreview-1973486376>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHKIFHRJWJBPAPXKZHIHLO3Y3KR6HAVCNFSM6AAAAABDYFPNMCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNZTGQ4DMMZXGY>
> .
> You are receiving this because you were mentioned.Message ID:
> <openjdk/jfx/pull/1381/review/1973486376 at github.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240402/05e7e93f/attachment.htm>

From kcr at openjdk.org  Tue Apr  2 14:19:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Apr 2024 14:19:09 GMT
Subject: RFR: 8328752: Fix missing @Overrides in javafx.web
In-Reply-To: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
References: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
Message-ID: <HCGTN072l3bU5YvFj6Xxn2llnjBE2wtFKcvYNvQYwu0=.e2d72592-4e96-4ca1-896f-206202b8ac9e@github.com>

On Thu, 21 Mar 2024 23:48:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fix missing @Overrides in **javafx.web**.
> 
> This is still a trivial change since all the spots are identified by the IDE.

These changes look good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1424#pullrequestreview-1973976089

From lkostyra at openjdk.org  Tue Apr  2 14:23:09 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 2 Apr 2024 14:23:09 GMT
Subject: RFR: JDK-8326619: Stage.sizeToScene() on maximized/fullscreen
 Stage breaks the Window [v3]
In-Reply-To: <oRYnvnSzu5Ro9dW7b8TCRcXLasx_DBmUfaavhs_9OS0=.f8db5b04-1948-4892-a4a4-483852ef1863@github.com>
References: <iLZXWKXwQINtUmCNkY_mS9H_Wd9CT78CUQlCHe0Rx4Q=.743085fb-ea97-4a15-b6a3-fddd2926dff5@github.com>
 <oRYnvnSzu5Ro9dW7b8TCRcXLasx_DBmUfaavhs_9OS0=.f8db5b04-1948-4892-a4a4-483852ef1863@github.com>
Message-ID: <mQw4jVZbXq6pO62VJK8Pdnyh_w3NxofGpCsn1hYnRpE=.d6c75d94-7c79-46e1-8bac-76918ba441f9@github.com>

On Sat, 9 Mar 2024 18:41:10 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after.
>> 
>> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. 
>> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized).
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve tests

LGTM, tests also seem to be fine on my end (checked on Windows and Ubuntu 22.04 LTS)

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-1973986480

From angorya at openjdk.org  Tue Apr  2 15:37:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Apr 2024 15:37:09 GMT
Subject: RFR: 8328742: Remove unused imports in manual tests
In-Reply-To: <vqEKKCNwgLdYdDf-ERUYHA6hY6vhKEL97y8JDEootJQ=.f2533f20-b246-4e4a-a3a1-16a5acdaf833@github.com>
References: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
 <vqEKKCNwgLdYdDf-ERUYHA6hY6vhKEL97y8JDEootJQ=.f2533f20-b246-4e4a-a3a1-16a5acdaf833@github.com>
Message-ID: <uHGMvzNS3ucT6LdTamn6sabiXS6WyJXVEIHQyNWbb_E=.25707d5f-a233-4dfc-9fd5-9e6721ec5a97@github.com>

On Thu, 21 Mar 2024 19:51:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
>> 
>> 
>> 
>> --
>> 
>> This is a trivial change, 1 reviewer is probably enough.
>
> I recommend to revert the change to the swing class. Also, you have a copy/paste error in the description regarding generated source files.

@kevinrushforth could you please review this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1418#issuecomment-2032396028

From angorya at openjdk.org  Tue Apr  2 18:46:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Apr 2024 18:46:10 GMT
Subject: RFR: 8328742: Remove unused imports in manual tests
In-Reply-To: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
References: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
Message-ID: <T3MAiqUVvEtP49E96Pf-1uR7oRwJUVkcg4qs_A9PesU=.b21e914e-3e9b-4ce9-8b0b-d55f7bd2245c@github.com>

On Thu, 21 Mar 2024 19:38:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

@aghaisas would you mind taking a look at this PR?  thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/1418#issuecomment-2032796271

From kcr at openjdk.org  Tue Apr  2 22:27:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Apr 2024 22:27:11 GMT
Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live
 Streaming
In-Reply-To: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
References: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
Message-ID: <23Q_5Nnh64iV3xKce0DSP5oEdPSMljmBiyL9maBKSJ8=.55cf6b77-43e0-4cb2-b678-a25c2e99e3b5@github.com>

On Tue, 2 Apr 2024 00:18:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming.
> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details):
>   - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag.
> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits.
> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams.
> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend.
> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes.
> - Fixed and improved debug output in Linux AV plugins.
> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time.
> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams.
> - Removed dead code from MediaManager.
> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases.

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1435#issuecomment-2033203914

From kcr at openjdk.org  Tue Apr  2 22:28:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Apr 2024 22:28:10 GMT
Subject: RFR: 8328742: Remove unused imports in manual tests
In-Reply-To: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
References: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
Message-ID: <cp9jXHDXkbA4Pyyy7t4ymHCVzyMPVGsOMUBQuPPffEs=.53f3e878-173d-4809-94b8-e9d123959df3@github.com>

On Thu, 21 Mar 2024 19:38:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

I'm already planning to review it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1418#issuecomment-2033205292

From kcr at openjdk.org  Tue Apr  2 22:42:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 2 Apr 2024 22:42:09 GMT
Subject: RFR: 8328742: Remove unused imports in manual tests
In-Reply-To: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
References: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
Message-ID: <kHbggLRhnbMusuOpJh3esWmkG1E0qfzLxdRh0cvEvDc=.463fdc71-72fc-47ea-bcb5-39c1c64e615f@github.com>

On Thu, 21 Mar 2024 19:38:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1418#pullrequestreview-1975192482

From angorya at openjdk.org  Tue Apr  2 22:49:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Apr 2024 22:49:10 GMT
Subject: Integrated: 8328742: Remove unused imports in manual tests
In-Reply-To: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
References: <DXdaP2CjUlOvKT0mIgQc5g50kZOFm63_PQS3RSdkJi4=.91c44ef4-5bf7-4265-995d-eb3e35ead73b@github.com>
Message-ID: <bwjgI2ryd4YeNIOv7j6QuK_d01u0ByPYK34CxZZ4txg=.e4a7bb77-67b3-4e97-932a-144b52ff13e8@github.com>

On Thu, 21 Mar 2024 19:38:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Using Eclipse IDE to remove unused imports in **manual tests** and update the copyright year to 2024. Using wildcard for more than 10 static imports.
> 
> 
> 
> --
> 
> This is a trivial change, 1 reviewer is probably enough.

This pull request has now been integrated.

Changeset: c41b000e
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c41b000e10924c082e38af401659cee19c2401b4
Stats:     125 lines in 14 files changed: 35 ins; 68 del; 22 mod

8328742: Remove unused imports in manual tests

Reviewed-by: kcr

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

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

From angorya at openjdk.org  Tue Apr  2 23:30:16 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 2 Apr 2024 23:30:16 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v12]
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com>
Message-ID: <Vw61RqGEoUXOPzSZwsbCHi08lkLFoeQZhQzpG_-wEdI=.f69d7ec2-a5b3-4482-977f-29f6928df0b6@github.com>

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - tolerance
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - undo merge
 - no new api
 - ... and 21 more: https://git.openjdk.org/jfx/compare/c41b000e...25533552

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

Changes: https://git.openjdk.org/jfx/pull/1156/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=11
  Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod
  Patch: https://git.openjdk.org/jfx/pull/1156.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156

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

From duke at openjdk.org  Wed Apr  3 09:49:15 2024
From: duke at openjdk.org (eduardsdv)
Date: Wed, 3 Apr 2024 09:49:15 GMT
Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels
 [v2]
In-Reply-To: <IU6CMRDYmIpEQbhxow-TW1jSpS7GBI_YJ46MQmHIS-8=.5ce9de35-13c6-4d78-8d9b-ac34df4c9f0e@github.com>
References: <RAHBz8_U__Pk8FxX1nILErmbXHQwrquWgtjVBh5q_fA=.bc2db6b1-3324-4de2-9bdd-4b13693821e9@github.com>
 <IU6CMRDYmIpEQbhxow-TW1jSpS7GBI_YJ46MQmHIS-8=.5ce9de35-13c6-4d78-8d9b-ac34df4c9f0e@github.com>
Message-ID: <4k9zNAPnl7hhjiLNCtMxv_ln2J_XJvpJg7ZzGW5oiaw=.85fbac86-cd8e-472b-bd4f-ff86cdd13397@github.com>

On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used.
>> 
>> With this PR, always the default cell height is used, to determine how much is scrolled.
>> This makes the behavior more consistent.
>> 
>> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent.
>> 
>> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8323511
>   reverted accidental indentation chang

I understand your objections. I will create a new pull request. We can then discuss which solution we use.

But I already have a few questions about it.

In the new pull request, the ``VirtualScrollBar.adjustValue(double pos)`` method will then use the ``VirtualFlow.scrollPixels(double delta)`` method as follows.


public class VirtualScrollBar extends ScrollBar {

    @Override
    public void adjustValue(double pos) {
        if (isVirtual()) {
            IndexedCell<?> cell = flow.getCell(-1);
            double pixels = flow.getFixedCellSize() > 0
                            ? flow.getFixedCellSize()
                            : flow.isVertical()
                              ? cell.getLayoutBounds().getHeight()
                              : cell.getLayoutBounds().getWidth();
            if (pos > getValue()) {
                flow.scrollPixels(pixels);
            } else {
                flow.scrollPixels(-pixels);
            }
        } else {
            super.adjustValue(pos);
        }
    }
}


The main question is how far should we scroll when the user clicks on the thumb?

For backwards compatibility reasons, I have used the same logic to calculate the delta pixels as is currently used.
Therefore, to calculate the delta pixels, we probably need to change the visibility of the method ``VirtualFlow.getCellLength(T cell)`` to ``public``. Currently I copied the content of it.
Furthermore, the method ``VirtualFlow.getCell(int index)`` is always called with the index ``-1`` that always returns the ``accumCell``. 
Can we somehow shortcut this or should we use a different logic here?

Should we move the entire delta pixel calculation logic into a new method ``VirtualFlow.getBlockIncrement()``?

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

PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2034084290

From hmeda at openjdk.org  Wed Apr  3 17:50:12 2024
From: hmeda at openjdk.org (Hima Bindu Meda)
Date: Wed, 3 Apr 2024 17:50:12 GMT
Subject: RFR: 8328752: Fix missing @Overrides in javafx.web
In-Reply-To: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
References: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
Message-ID: <WaigvNgkkXCUziTXcFY3hKEPyTT4z8S16dZATRYAeEU=.df6ccebb-1e7e-414a-9622-dec49f224f6c@github.com>

On Thu, 21 Mar 2024 23:48:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fix missing @Overrides in **javafx.web**.
> 
> This is still a trivial change since all the spots are identified by the IDE.

Changes look good

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

Marked as reviewed by hmeda (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1424#pullrequestreview-1977554056

From angorya at openjdk.org  Wed Apr  3 17:50:13 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 17:50:13 GMT
Subject: RFR: 8328752: Fix missing @Overrides in javafx.web
In-Reply-To: <WaigvNgkkXCUziTXcFY3hKEPyTT4z8S16dZATRYAeEU=.df6ccebb-1e7e-414a-9622-dec49f224f6c@github.com>
References: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
 <WaigvNgkkXCUziTXcFY3hKEPyTT4z8S16dZATRYAeEU=.df6ccebb-1e7e-414a-9622-dec49f224f6c@github.com>
Message-ID: <Tt3cnz6mfnZR_Ak3EDQ6cES8ex9O1w9RWmyDUXqheYA=.7527b39f-67ce-4df4-9fde-17a4a3676362@github.com>

On Wed, 3 Apr 2024 17:45:46 GMT, Hima Bindu Meda <hmeda at openjdk.org> wrote:

>> Fix missing @Overrides in **javafx.web**.
>> 
>> This is still a trivial change since all the spots are identified by the IDE.
>
> Changes look good

thank you @HimaBinduMeda !

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

PR Comment: https://git.openjdk.org/jfx/pull/1424#issuecomment-2035217487

From angorya at openjdk.org  Wed Apr  3 17:50:13 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 17:50:13 GMT
Subject: Integrated: 8328752: Fix missing @Overrides in javafx.web
In-Reply-To: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
References: <oawMcWYt7jjZYZs7KRABBGX0f9pydfETt0u2L1WzEqA=.78abc39b-918e-4747-8c3e-cc00906facfe@github.com>
Message-ID: <GgRzAnxVkrn5969Wt0zc5yheN9YSZKOhEoAfxmqeFfE=.97d250bc-2063-4dc5-9dc0-d158de87024a@github.com>

On Thu, 21 Mar 2024 23:48:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fix missing @Overrides in **javafx.web**.
> 
> This is still a trivial change since all the spots are identified by the IDE.

This pull request has now been integrated.

Changeset: 483c6408
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/483c64082f7752e239c5630eb1d7895e599e5dda
Stats:     1058 lines in 103 files changed: 956 ins; 0 del; 102 mod

8328752: Fix missing @Overrides in javafx.web

Reviewed-by: kcr, hmeda

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

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

From angorya at openjdk.org  Wed Apr  3 18:40:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 18:40:09 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit
In-Reply-To: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
Message-ID: <7Um1sF8lm1AKdchzZbtS-rew5DB-UTLjgbx8lttmYyI=.1c3574ce-f709-4b3c-a694-11509704da38@github.com>

On Wed, 20 Mar 2024 10:55:56 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly.
> 
> For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before).
> 
> By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before).
> 
> Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix).

The problem listed in the ticket is fixed, tested on macOS 14.4.1 M1 with the monkey tester.

Thank you for adding tests and fixing the comments!

(there was a comment from @Maran23 , if you would like to address it I'll re-approve).

modules/javafx.controls/src/main/java/javafx/scene/control/TreeCell.java line 429:

> 427: 
> 428:         if (tree != null) {
> 429:             // reset the editing item in the TreeView

+1

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1411#pullrequestreview-1977641091
PR Review Comment: https://git.openjdk.org/jfx/pull/1411#discussion_r1550251709

From angorya at openjdk.org  Wed Apr  3 18:40:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 18:40:10 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit
In-Reply-To: <rmi9W2sbSIrGn4FynYfElVi7IfzsM7ZZgupJQfTJ95A=.230e0ffd-4888-4190-afe7-75089aff5f81@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
 <rmi9W2sbSIrGn4FynYfElVi7IfzsM7ZZgupJQfTJ95A=.230e0ffd-4888-4190-afe7-75089aff5f81@github.com>
Message-ID: <IajIZ5mnmCNrVHo3Z5PE_MjWF26ViXY2ds1AOavrdgc=.d881f697-7084-4088-b304-9cdb73e9dab1@github.com>

On Thu, 28 Mar 2024 11:20:23 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly.
>> 
>> For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before).
>> 
>> By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before).
>> 
>> Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix).
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 2362:
> 
>> 2360:         assertTrue(treeView.isFocused());
>> 2361: 
>> 2362:         VirtualFlowTestUtils.BLOCK_STAGE_LOADER_DISPOSE = true;
> 
> This should not be needed since you are creating a `stageLoader` above. This seems to be only used when no `stageLoader` was created before

I wish there was a more reliable way of implementing getCell() without resorting to undocumented flags like BLOCK_STAGE_LOADER_DISPOSE.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1411#discussion_r1550266702

From angorya at openjdk.org  Wed Apr  3 18:57:20 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 18:57:20 GMT
Subject: [jfx22u] RFR: 8328752: Fix missing @Overrides in javafx.web
Message-ID: <WkyUZA-rYpzaq6q9uv4gFHT5d1wDCK2P-ESHbbhFUT0=.afff8309-1d63-4489-87fc-0e09a1bc6846@github.com>

Hi all,

This pull request contains a backport of commit [483c6408](https://urldefense.com/v3/__https://github.com/openjdk/jfx/commit/483c64082f7752e239c5630eb1d7895e599e5dda__;!!ACWV5N9M2RV99hQ!M-G018UM97QRsj9teiPLnY-Cdm4FuyCwtrHfyQodu1pJVqB6O1X9nx8G-xSgI9garjnyTYhFbukpa-9-Sfb6b7kZJpzddg$) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Andy Goryachev on 3 Apr 2024 and was reviewed by Kevin Rushforth and Hima Bindu Meda.

Thanks!

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

Commit messages:
 - Backport 483c64082f7752e239c5630eb1d7895e599e5dda

Changes: https://git.openjdk.org/jfx22u/pull/23/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=23&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328752
  Stats: 1058 lines in 103 files changed: 956 ins; 0 del; 102 mod
  Patch: https://git.openjdk.org/jfx22u/pull/23.diff
  Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/23/head:pull/23

PR: https://git.openjdk.org/jfx22u/pull/23

From angorya at openjdk.org  Wed Apr  3 19:37:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 19:37:09 GMT
Subject: [jfx22u] Integrated: 8328752: Fix missing @Overrides in javafx.web
In-Reply-To: <WkyUZA-rYpzaq6q9uv4gFHT5d1wDCK2P-ESHbbhFUT0=.afff8309-1d63-4489-87fc-0e09a1bc6846@github.com>
References: <WkyUZA-rYpzaq6q9uv4gFHT5d1wDCK2P-ESHbbhFUT0=.afff8309-1d63-4489-87fc-0e09a1bc6846@github.com>
Message-ID: <EfjC8dity-J2iP3Z2g3gk-oLh-IawVILxyRwVKuzP8c=.37b03879-263e-4952-b4ef-b8535f714fbe@github.com>

On Wed, 3 Apr 2024 18:53:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [483c6408](https://urldefense.com/v3/__https://github.com/openjdk/jfx/commit/483c64082f7752e239c5630eb1d7895e599e5dda__;!!ACWV5N9M2RV99hQ!M-G018UM97QRsj9teiPLnY-Cdm4FuyCwtrHfyQodu1pJVqB6O1X9nx8G-xSgI9garjnyTYhFbukpa-9-Sfb6b7kZJpzddg$) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Andy Goryachev on 3 Apr 2024 and was reviewed by Kevin Rushforth and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: e6572643
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx22u/commit/e65726439eb6d3b82dfbf70141c5efb6cccea566
Stats:     1058 lines in 103 files changed: 956 ins; 0 del; 102 mod

8328752: Fix missing @Overrides in javafx.web

Backport-of: 483c64082f7752e239c5630eb1d7895e599e5dda

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

PR: https://git.openjdk.org/jfx22u/pull/23

From jpereda at openjdk.org  Wed Apr  3 19:54:20 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 3 Apr 2024 19:54:20 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit [v2]
In-Reply-To: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
Message-ID: <Z1ONBggztiRi_KlIt4j2eRPg52Zr0IzlgorMahsY-tk=.81469be8-499f-4869-b469-38731ef21fe7@github.com>

> This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly.
> 
> For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before).
> 
> By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before).
> 
> Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix).

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

  Address feedback from reviewer

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1411/files
  - new: https://git.openjdk.org/jfx/pull/1411/files/8f312781..744562f0

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

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

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

From jpereda at openjdk.org  Wed Apr  3 19:54:20 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 3 Apr 2024 19:54:20 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit [v2]
In-Reply-To: <rmi9W2sbSIrGn4FynYfElVi7IfzsM7ZZgupJQfTJ95A=.230e0ffd-4888-4190-afe7-75089aff5f81@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
 <rmi9W2sbSIrGn4FynYfElVi7IfzsM7ZZgupJQfTJ95A=.230e0ffd-4888-4190-afe7-75089aff5f81@github.com>
Message-ID: <BvVqvzAyNG8Na6QkXb6WYnq4BrphTu1-J4AiPLJN8zk=.6d9579cd-2176-4066-859a-1fd7fbd882ff@github.com>

On Thu, 28 Mar 2024 11:20:23 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback from reviewer
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 2362:
> 
>> 2360:         assertTrue(treeView.isFocused());
>> 2361: 
>> 2362:         VirtualFlowTestUtils.BLOCK_STAGE_LOADER_DISPOSE = true;
> 
> This should not be needed since you are creating a `stageLoader` above. This seems to be only used when no `stageLoader` was created before

Thanks @Maran23, I've removed it now from the added tests.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1411#discussion_r1550359262

From angorya at openjdk.org  Wed Apr  3 21:39:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 3 Apr 2024 21:39:10 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit [v2]
In-Reply-To: <Z1ONBggztiRi_KlIt4j2eRPg52Zr0IzlgorMahsY-tk=.81469be8-499f-4869-b469-38731ef21fe7@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
 <Z1ONBggztiRi_KlIt4j2eRPg52Zr0IzlgorMahsY-tk=.81469be8-499f-4869-b469-38731ef21fe7@github.com>
Message-ID: <TB4aoiBmBi88v9INQch3-Ibro8bqXXTzNhoLFeLVrAQ=.e1461579-00ca-48e2-ab71-c4ae701d48de@github.com>

On Wed, 3 Apr 2024 19:54:20 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly.
>> 
>> For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before).
>> 
>> By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before).
>> 
>> Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix).
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback from reviewer

Marked as reviewed by angorya (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1411#pullrequestreview-1978103130

From mhanl at openjdk.org  Thu Apr  4 07:16:11 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 4 Apr 2024 07:16:11 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit [v2]
In-Reply-To: <BvVqvzAyNG8Na6QkXb6WYnq4BrphTu1-J4AiPLJN8zk=.6d9579cd-2176-4066-859a-1fd7fbd882ff@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
 <rmi9W2sbSIrGn4FynYfElVi7IfzsM7ZZgupJQfTJ95A=.230e0ffd-4888-4190-afe7-75089aff5f81@github.com>
 <BvVqvzAyNG8Na6QkXb6WYnq4BrphTu1-J4AiPLJN8zk=.6d9579cd-2176-4066-859a-1fd7fbd882ff@github.com>
Message-ID: <TAuGNsR3cfkv9eeQ4gdyS7-e113--dtfVG574DhLGv0=.8bef1cd7-e60a-4844-990e-b845ffa21109@github.com>

On Wed, 3 Apr 2024 19:51:08 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java line 2362:
>> 
>>> 2360:         assertTrue(treeView.isFocused());
>>> 2361: 
>>> 2362:         VirtualFlowTestUtils.BLOCK_STAGE_LOADER_DISPOSE = true;
>> 
>> This should not be needed since you are creating a `stageLoader` above. This seems to be only used when no `stageLoader` was created before
>
> Thanks @Maran23, I've removed it now from the added tests.

> I wish there was a more reliable way of implementing getCell() without resorting to undocumented flags like BLOCK_STAGE_LOADER_DISPOSE.

There is, just add the virtual container to a Stage. Since the cells are only created inside the skin, which is only created when the component is inside the scene tree.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1411#discussion_r1551054299

From mhanl at openjdk.org  Thu Apr  4 07:19:10 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 4 Apr 2024 07:19:10 GMT
Subject: RFR: 8324939: Editable TableView loses focus after commit [v2]
In-Reply-To: <Z1ONBggztiRi_KlIt4j2eRPg52Zr0IzlgorMahsY-tk=.81469be8-499f-4869-b469-38731ef21fe7@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
 <Z1ONBggztiRi_KlIt4j2eRPg52Zr0IzlgorMahsY-tk=.81469be8-499f-4869-b469-38731ef21fe7@github.com>
Message-ID: <qvSx81lwerVbcSZOhzoenrf5BhKqQRdQkj6SLsdpdRk=.d1427bb0-7051-46f2-af1e-ff2b87f8363f@github.com>

On Wed, 3 Apr 2024 19:54:20 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly.
>> 
>> For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before).
>> 
>> By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before).
>> 
>> Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix).
>
> Jose Pereda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback from reviewer

Looks good to me too. 
Fix and the rationale behind makes sense. 
Something I also noticed on virtual containers (cells).

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

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1411#pullrequestreview-1978930892

From jpereda at openjdk.org  Thu Apr  4 08:18:13 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Thu, 4 Apr 2024 08:18:13 GMT
Subject: Integrated: 8324939: Editable TableView loses focus after commit
In-Reply-To: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
References: <Ss4jnN9U6NekGJK-D7Rg5sUPM6dW-PGnu1zbXE3JpBs=.c69dacdf-2870-495b-bedc-104c0ef48c67@github.com>
Message-ID: <M4rL-bR3wIdq183UHkhoxg3RrHcbdV1VCEWjyhWB1dI=.bc5df706-c151-4ea6-8fa4-22442b95ef20@github.com>

On Wed, 20 Mar 2024 10:55:56 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR fixes the issue that after committing an edit on a ListView/TreeView/TableView/TreeTableView control, the control might lose the focus unexpectedly.
> 
> For that, it refactors the `ControlUtils::requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild` method, in order to check if the control (`ListView`, `TreeView`, `TableView`, `TreeTableView`) should request the focus _before_ the actual focus owner (which could be the control added to the cell to edit its content, like a `TextField`) is removed from the cell, so the `Control::requestFocus` call, if needed, can be still invoked after the edit commit is done (as it was done before).
> 
> By adding `ControlUtils::controlShouldRequestFocusIfCurrentFocusOwnerIsChild` the `Cell::commitEdit` implementations can now query if the control should have the focus, after `super.commitEdit(newValue);` but before firing the `CellEditEvent` and calling `updateItem()`, and if the result is true, then request focus after the edit commit ends (like it was done before).
> 
> Two new tests per control have been included, to verify that the focus remains at the control, one for edit cancel (this passes before and after the proposed changes), one for edit commit (this fails before and passes after including the proposed fix).

This pull request has now been integrated.

Changeset: 0d336063
Author:    Jose Pereda <jpereda at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0d336063346879671e1c9fbdeed4926d69c6cf44
Stats:     443 lines in 9 files changed: 422 ins; 5 del; 16 mod

8324939: Editable TableView loses focus after commit

Reviewed-by: angorya, mhanl

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

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

From kizune at openjdk.org  Thu Apr  4 21:59:34 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 4 Apr 2024 21:59:34 GMT
Subject: RFR: 8329705: Add missing Application thread checks to platform
 specific a11y methods
Message-ID: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>

Added missing checks;
Added a manual regression test;

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

Commit messages:
 - 8329705: Add missing Application thread checks to platform specific a11y methods
 - Merge pull request #8 from openjdk/master
 - Merge pull request #7 from openjdk/master

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

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

From kcr at openjdk.org  Thu Apr  4 22:28:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 4 Apr 2024 22:28:09 GMT
Subject: RFR: 8329705: Add missing Application thread checks to platform
 specific a11y methods
In-Reply-To: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
References: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
Message-ID: <vHf-I3s96rCfc0EwHcZc4DiahEogKlyeKT1LblL7C50=.38ce841a-5370-4ea6-8b5e-77d0cd3d7859@github.com>

On Thu, 4 Apr 2024 21:55:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added missing checks;
> Added a manual regression test;

Reviewers: @kevinrushforth @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1436#issuecomment-2038349547

From arapte at openjdk.org  Fri Apr  5 13:02:11 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 5 Apr 2024 13:02:11 GMT
Subject: RFR: 8329705: Add missing Application thread checks to platform
 specific a11y methods
In-Reply-To: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
References: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
Message-ID: <FUi8wQBw7MDndPZwaT1deDjdylnvQkpAe7NhzmChgfM=.1ff758d3-b0d4-45de-9419-b003b60efb4a@github.com>

On Thu, 4 Apr 2024 21:55:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added missing checks;
> Added a manual regression test;

Marked as reviewed by arapte (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1436#pullrequestreview-1983111622

From kcr at openjdk.org  Fri Apr  5 17:56:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 5 Apr 2024 17:56:10 GMT
Subject: RFR: 8329705: Add missing Application thread checks to platform
 specific a11y methods
In-Reply-To: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
References: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
Message-ID: <0hHzjweWqsaiQR4WlL7p5JGR8b6x8jyUwZwyPPMroeU=.5b2fa1c4-3b1b-4ce6-bda0-be9539cff0fc@github.com>

On Thu, 4 Apr 2024 21:55:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added missing checks;
> Added a manual regression test;

Both the fix and the test look good. Testing complete on Mac and Windows.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1436#pullrequestreview-1983807637

From kizune at openjdk.org  Fri Apr  5 19:36:12 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 5 Apr 2024 19:36:12 GMT
Subject: Integrated: 8329705: Add missing Application thread checks to platform
 specific a11y methods
In-Reply-To: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
References: <UGhltGl-GDj-MpJ1OUgDfmj7mkdcGrUaETO-qcJFNXU=.bdc99cd1-407a-42d2-b4cd-c82672a27f32@github.com>
Message-ID: <M9Q981_sugLxIJByxFeK00kSILj8cckBz59Fn0TcEgo=.af570cb6-9df4-4313-b7e5-9a4bc82086a5@github.com>

On Thu, 4 Apr 2024 21:55:11 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Added missing checks;
> Added a manual regression test;

This pull request has now been integrated.

Changeset: 0eb4d719
Author:    Alexander Zuev <kizune at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0eb4d7196099d817cc6467985b882242845bdd2e
Stats:     299 lines in 4 files changed: 299 ins; 0 del; 0 mod

8329705: Add missing Application thread checks to platform specific a11y methods

Reviewed-by: arapte, kcr

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

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

From kizune at openjdk.org  Fri Apr  5 21:14:35 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 5 Apr 2024 21:14:35 GMT
Subject: [jfx22u] RFR: 8329705: Add missing Application thread checks to
 platform specific a11y methods
Message-ID: <lnmBbdG_moYMmePdwBwqFoF9DO2zlNF_WK7yZ7DVc1c=.ae859d6b-13c9-4764-a4c2-91549c632dc6@github.com>

Backport from mainline. Changes can be applied cleanly.

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

Commit messages:
 - Backport 0eb4d7196099d817cc6467985b882242845bdd2e

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

PR: https://git.openjdk.org/jfx22u/pull/25

From kizune at openjdk.org  Fri Apr  5 21:42:13 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 5 Apr 2024 21:42:13 GMT
Subject: [jfx22u] Integrated: 8329705: Add missing Application thread checks to
 platform specific a11y methods
In-Reply-To: <lnmBbdG_moYMmePdwBwqFoF9DO2zlNF_WK7yZ7DVc1c=.ae859d6b-13c9-4764-a4c2-91549c632dc6@github.com>
References: <lnmBbdG_moYMmePdwBwqFoF9DO2zlNF_WK7yZ7DVc1c=.ae859d6b-13c9-4764-a4c2-91549c632dc6@github.com>
Message-ID: <2pIlS3aCUjJucZ-5S9AbHJQaNJwFDGDomx4qMgcZZ1Y=.310b0d5f-70d4-4c85-a567-db082de5aef2@github.com>

On Fri, 5 Apr 2024 21:09:34 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Backport from mainline. Changes can be applied cleanly.

This pull request has now been integrated.

Changeset: 1e21a6f3
Author:    Alexander Zuev <kizune at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx22u/commit/1e21a6f3a58105434a14b66147fbdaf5e387b835
Stats:     299 lines in 4 files changed: 299 ins; 0 del; 0 mod

8329705: Add missing Application thread checks to platform specific a11y methods

Backport-of: 0eb4d7196099d817cc6467985b882242845bdd2e

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

PR: https://git.openjdk.org/jfx22u/pull/25

From tsayao at openjdk.org  Sat Apr  6 16:31:26 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 6 Apr 2024 16:31:26 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX
Message-ID: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>

GLX is X only while EGL is need for Wayland and also works with X.org.

I know there are limitations on Xorg and I still need to investigate it.

GLX replacement for Xorg is not mandatory - this can be further discussed. 

This is a work in progress and it's on the first step (making it work).

See:
[Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
[Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

Commit messages:
 - - Review points
 - Rework native library loading because it can now vary
 - Refactor common functionality
 - Try EGL and fallback to GLX
 - Allow both EGL and GLX
 - Allow both EGL and GLX
 - Allow both EGL and GLX
 - Allow both EGL and GLX
 - Merge branch 'master' into egl
 - Merge branch 'master' into egl
 - ... and 1 more: https://git.openjdk.org/jfx/compare/eca32354...e8330501

Changes: https://git.openjdk.org/jfx/pull/1381/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329820
  Stats: 2352 lines in 35 files changed: 1771 ins; 486 del; 95 mod
  Patch: https://git.openjdk.org/jfx/pull/1381.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381

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

From lkostyra at openjdk.org  Sat Apr  6 16:31:26 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Sat, 6 Apr 2024 16:31:26 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <raHvIKAsD77fOiBMx8YCHxvkvhoUVsflr6-SOv22vsI=.c94f3452-c319-488d-8281-a0942e68ad6e@github.com>

On Sat, 24 Feb 2024 17:54:47 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> GLX is X only while EGL is need for Wayland and also works with X.org.
> 
> I know there are limitations on Xorg and I still need to investigate it.
> 
> GLX replacement for Xorg is not mandatory - this can be further discussed. 
> 
> This is a work in progress and it's on the first step (making it work).
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

I took a brief look at your changes and I shared some comments.

Overall the changes look good. The EGL/GLX loading in GLFactory feels a bit hacky, but other than making EGL a completely separate Prism backend (which would duplicate/reorganize a lot of common EGL/GLX code - definitely a no-go IMO) I don't have a better idea how to solve this. Maybe with an ES2-specific property like `prism.es2.forceglx=true`?

This brings me to a question - other than some form of debugging/fallback for when EGL is still new to JFX, do we even need GLX implementation when we have a working EGL implementation? I'm fairly sure that current distros (especially ones officially supported by JFX) have EGL support available at this point in time, and since it's an intermediary layer between application and runtime it shouldn't depend on used GPU.

Also a side note - the PR title does not match the JBS issue.

modules/javafx.graphics/src/main/java/com/sun/prism/es2/LinuxEGLContext.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.

Copyright dates should be updated (here and in other files)

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 140:

> 138:     /* allocate the structure */
> 139:     ctxInfo = (ContextInfo *) malloc(sizeof (ContextInfo));
> 140:     if (ctxInfo == NULL) {

Shouldn't this also `eglDestroyContext`?

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 158:

> 156:     /* set function pointers */
> 157:     ctxInfo->glActiveTexture = (PFNGLACTIVETEXTUREPROC)
> 158:             dlsym(RTLD_DEFAULT, "glActiveTexture");

Since you're using EGL, it would be better to use EGL's own `eglGetProcAddress` here and below.

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

PR Review: https://git.openjdk.org/jfx/pull/1381#pullrequestreview-1973486376
PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2031952274
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1547718158
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1547684895
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1547688868

From tsayao at openjdk.org  Sat Apr  6 16:31:26 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 6 Apr 2024 16:31:26 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX
In-Reply-To: <raHvIKAsD77fOiBMx8YCHxvkvhoUVsflr6-SOv22vsI=.c94f3452-c319-488d-8281-a0942e68ad6e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <raHvIKAsD77fOiBMx8YCHxvkvhoUVsflr6-SOv22vsI=.c94f3452-c319-488d-8281-a0942e68ad6e@github.com>
Message-ID: <Vfhis8zdCrtGygDjXYIdDY_t7PgE6gKuilEk8QVJhsY=.ab4a3773-1d00-4a74-b412-68133136a0e0@github.com>

On Tue, 2 Apr 2024 11:50:39 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> GLX is X only while EGL is need for Wayland and also works with X.org.
>> 
>> I know there are limitations on Xorg and I still need to investigate it.
>> 
>> GLX replacement for Xorg is not mandatory - this can be further discussed. 
>> 
>> This is a work in progress and it's on the first step (making it work).
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> modules/javafx.graphics/src/main/java/com/sun/prism/es2/LinuxEGLContext.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright dates should be updated (here and in other files)

Fixed

> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 140:
> 
>> 138:     /* allocate the structure */
>> 139:     ctxInfo = (ContextInfo *) malloc(sizeof (ContextInfo));
>> 140:     if (ctxInfo == NULL) {
> 
> Shouldn't this also `eglDestroyContext`?

Added

> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 158:
> 
>> 156:     /* set function pointers */
>> 157:     ctxInfo->glActiveTexture = (PFNGLACTIVETEXTUREPROC)
>> 158:             dlsym(RTLD_DEFAULT, "glActiveTexture");
> 
> Since you're using EGL, it would be better to use EGL's own `eglGetProcAddress` here and below.

Yes - changed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1554636413
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1554635523
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1554635568

From tsayao at openjdk.org  Sat Apr  6 16:35:36 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 6 Apr 2024 16:35:36 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v2]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <0uBPYyW1eubuDse3dHIEIeh7rybwM0uUxI5ZXWuPCMI=.deada152-4f47-416f-a5e8-d03bb667ec6f@github.com>

> GLX is X only while EGL is need for Wayland and also works with X.org.
> 
> I know there are limitations on Xorg and I still need to investigate it.
> 
> GLX replacement for Xorg is not mandatory - this can be further discussed. 
> 
> This is a work in progress and it's on the first step (making it work).
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

  - Remove fprintf call

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/e8330501..7ae1f275

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

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

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

From tsayao at openjdk.org  Sat Apr  6 17:39:28 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 6 Apr 2024 17:39:28 GMT
Subject: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized
Message-ID: <xGwSdybKPE7SRiRDvZlUv4GQP_77auQe-rx4hghWW2I=.14295dd8-f336-42e1-881b-40ba10abd6fd@github.com>

Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration.

It seems i3 replies with decorated sizes, even if window is not decorated.

Won't hurt other WMs.

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

Commit messages:
 - - Fix for i3 menus size

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

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

From duke at openjdk.org  Sat Apr  6 17:47:08 2024
From: duke at openjdk.org (Christopher Schnick)
Date: Sat, 6 Apr 2024 17:47:08 GMT
Subject: RFR: 8329821: [Linux] When using i3 WM,
 menus are incorrectly sized
In-Reply-To: <xGwSdybKPE7SRiRDvZlUv4GQP_77auQe-rx4hghWW2I=.14295dd8-f336-42e1-881b-40ba10abd6fd@github.com>
References: <xGwSdybKPE7SRiRDvZlUv4GQP_77auQe-rx4hghWW2I=.14295dd8-f336-42e1-881b-40ba10abd6fd@github.com>
Message-ID: <U3niBTUNnmt9MD6_z_-fqHOFmQxZAwCTtv_k5Badl1I=.8954b6f0-9f63-4cce-a571-f10a2f42308b@github.com>

On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration.
> 
> It seems i3 replies with decorated sizes, even if window is not decorated.
> 
> Won't hurt other WMs.

I recently got a report from a user running the latest xfce version that had the same problem where context menus and tooltips were cut off. But this fix is specific to i3?

![image](https://github.com/openjdk/jfx/assets/72509152/93e4171c-0e0d-45b6-bc0c-da725ceabd26)

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

PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2041148672

From tsayao at openjdk.org  Sun Apr  7 12:52:09 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 7 Apr 2024 12:52:09 GMT
Subject: RFR: 8329821: [Linux] When using i3 WM,
 menus are incorrectly sized
In-Reply-To: <xGwSdybKPE7SRiRDvZlUv4GQP_77auQe-rx4hghWW2I=.14295dd8-f336-42e1-881b-40ba10abd6fd@github.com>
References: <xGwSdybKPE7SRiRDvZlUv4GQP_77auQe-rx4hghWW2I=.14295dd8-f336-42e1-881b-40ba10abd6fd@github.com>
Message-ID: <YRwrbLxwuEK9UP4U6JSNSUol3DGZZFTj2tzPRd1H_uQ=.4c827684-0b46-4892-ba29-b981a88d7e2a@github.com>

On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration.
> 
> It seems i3 replies with decorated sizes, even if window is not decorated.
> 
> Won't hurt other WMs.

High chance it's the same problem.

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

PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2041460226

From mhanl at openjdk.org  Sun Apr  7 13:20:10 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Sun, 7 Apr 2024 13:20:10 GMT
Subject: RFR: JDK-8186188: TableColumHeader: initial auto-size broken if
 has graphic [v4]
In-Reply-To: <VTBsv1M0XLJHRk33bnfyXYzrQtysIFvTsKj0eDmo5o4=.66776aaf-6f2a-4bde-997e-6026119ee163@github.com>
References: <GOCc3REwnXmSpsN96WBzCq3dQJPzzvL2dFjOKlpE15c=.fab298e9-f241-4f7c-ab53-2891d5f7fcfa@github.com>
 <WCBZ7zwSnqw7Vw9GdiU8Nznl9CJEIhj_swotTwnzYoM=.5c14df59-52fb-48b7-8d7e-9bd80227fac3@github.com>
 <_-kHLuzDlB_Vs7MtGRqMx8km6OhxEiYMRoypMmOXDlE=.3986ed1f-71e1-4cc9-b1a0-f46b8add5852@github.com>
 <VTBsv1M0XLJHRk33bnfyXYzrQtysIFvTsKj0eDmo5o4=.66776aaf-6f2a-4bde-997e-6026119ee163@github.com>
Message-ID: <Swx7JRgyfXRQL6Y_Hm6k6xk9BoLdGmwu42BsngvIiDQ=.9877687c-9cc3-42ad-84be-0e29a9980e87@github.com>

On Tue, 2 Apr 2024 07:37:15 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> @effad Since you benchmarked this method in #1358, could you do that again with this changes?
>
>> @effad Since you benchmarked this method in #1358, could you do that again with this changes?
> 
> Sorry for the late reply, I just returned from easter holidays :-). I'll try to benchmark this change within the next days...

@effad Thank you, much appreciated! Good to see that this does not cause any major performance problems.

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

PR Comment: https://git.openjdk.org/jfx/pull/1405#issuecomment-2041469051

From kcr at openjdk.org  Mon Apr  8 13:35:15 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Apr 2024 13:35:15 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v2]
In-Reply-To: <0uBPYyW1eubuDse3dHIEIeh7rybwM0uUxI5ZXWuPCMI=.deada152-4f47-416f-a5e8-d03bb667ec6f@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <0uBPYyW1eubuDse3dHIEIeh7rybwM0uUxI5ZXWuPCMI=.deada152-4f47-416f-a5e8-d03bb667ec6f@github.com>
Message-ID: <r91kPJQTqbgufUr2hWgA7FdAmb-_Dv6S1y_JGYUjgvI=.112b3d84-2575-4083-80c3-3eeddf12d9eb@github.com>

On Sat, 6 Apr 2024 16:35:36 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> GLX is X only while EGL is need for Wayland and also works with X.org.
>> 
>> I know there are limitations on Xorg and I still need to investigate it.
>> 
>> GLX replacement for Xorg is not mandatory - this can be further discussed. 
>> 
>> This is a work in progress and it's on the first step (making it work).
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Remove fprintf call

This will need a fair bit of testing and review. I would like a chance to review it, but won't be able to get to it for a couple weeks.

Reviewers: @kevinrushforth @lukostyra @johanvos @arapte

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2042771591

From angorya at openjdk.org  Mon Apr  8 14:34:23 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 14:34:23 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v2]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <YA8OhQa6P-P4NG8xE3ZaQS_aQl3wf66SrhLydhcVayE=.1b78a4a0-243d-4ba4-8303-a6fa86dd57df@github.com>

> ## ManualTestWindow
> 
> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
> 
> A simple test would look like this:
> 
> 
> public class SampleManualTest {
>      public static void main(String[] args) throws Exception {
>          ManualTestWindow.builder().
>              title("Sample Manual Test").
>              instructions(
>                  """
>                  Provide
>                  multi-line instructions here.
>                  """
>              ).
>              ui(() -> createTestUI()).
>              buildAndRun();
>      }
> 
>      private static Node createTestUI() {
>          return new Label("Test UI");
>      }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
> 
> Readme:
> 
> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project and moved sources to src/, still using the default package).
> 
> Q: Do we want to avoid using the default package?
> 
> Q: What other features can be added to the test window?

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

 - Merge branch 'master' into 8319555.manual
 - whitespace
 - Merge branch 'master' into 8319555.manual
 - manual test window
 - fixed text manual test setup

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/1cc09504..22da890b

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

  Stats: 15159 lines in 565 files changed: 9088 ins; 4321 del; 1750 mod
  Patch: https://git.openjdk.org/jfx/pull/1413.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1413/head:pull/1413

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

From angorya at openjdk.org  Mon Apr  8 14:48:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 14:48:35 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v3]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <WuxZs6L8Gr0m6eq84fs2zLHPnKyRvtKlfMLtwgPXgEc=.94588946-6c1a-4af2-b87b-4cdb6f331a85@github.com>

> ## ManualTestWindow
> 
> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
> 
> A simple test would look like this:
> 
> 
> public class SampleManualTest {
>      public static void main(String[] args) throws Exception {
>          ManualTestWindow.builder().
>              title("Sample Manual Test").
>              instructions(
>                  """
>                  Provide
>                  multi-line instructions here.
>                  """
>              ).
>              ui(() -> createTestUI()).
>              buildAndRun();
>      }
> 
>      private static Node createTestUI() {
>          return new Label("Test UI");
>      }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
> 
> Readme:
> 
> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project and moved sources to src/, still using the default package).
> 
> Q: Do we want to avoid using the default package?
> 
> Q: What other features can be added to the test window?

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  sources moved back

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/22da890b..66d7d0d0

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

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

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

From angorya at openjdk.org  Mon Apr  8 15:04:24 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 15:04:24 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>

> ## ManualTestWindow
> 
> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
> 
> A simple test would look like this:
> 
> 
> public class SampleManualTest {
>      public static void main(String[] args) throws Exception {
>          ManualTestWindow.builder().
>              title("Sample Manual Test").
>              instructions(
>                  """
>                  Provide
>                  multi-line instructions here.
>                  """
>              ).
>              ui(() -> createTestUI()).
>              buildAndRun();
>      }
> 
>      private static Node createTestUI() {
>          return new Label("Test UI");
>      }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
> 
> Readme:
> 
> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project and moved sources to src/, still using the default package).
> 
> Q: Do we want to avoid using the default package?
> 
> Q: What other features can be added to the test window?

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - works
 - .

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/66d7d0d0..a106587a

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

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

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

From angorya at openjdk.org  Mon Apr  8 15:07:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 15:07:10 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v3]
In-Reply-To: <WuxZs6L8Gr0m6eq84fs2zLHPnKyRvtKlfMLtwgPXgEc=.94588946-6c1a-4af2-b87b-4cdb6f331a85@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <WuxZs6L8Gr0m6eq84fs2zLHPnKyRvtKlfMLtwgPXgEc=.94588946-6c1a-4af2-b87b-4cdb6f331a85@github.com>
Message-ID: <shByuMudXkxUpjcT-drw7M1XsQuD-UnFIL8UOLd6cj4=.150c08ab-1d38-4217-b0fe-c28b3c68a63c@github.com>

On Mon, 8 Apr 2024 14:48:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
>> 
>> A simple test would look like this:
>> 
>> 
>> public class SampleManualTest {
>>      public static void main(String[] args) throws Exception {
>>          ManualTestWindow.builder().
>>              title("Sample Manual Test").
>>              instructions(
>>                  """
>>                  Provide
>>                  multi-line instructions here.
>>                  """
>>              ).
>>              ui(() -> createTestUI()).
>>              buildAndRun();
>>      }
>> 
>>      private static Node createTestUI() {
>>          return new Label("Test UI");
>>      }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
>> 
>> Readme:
>> 
>> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sources moved back

Moved the sources back to the root.

Eclipse has a weird behavior when it comes to modular projects or mixing modular and classpath sources: the project which has been modified (or converted to modular or back) needs to be closed and re-opened, otherwise Eclipse loses its marbles.  Both 2023-06 and 2024-03 versions seem to exhibit this behavior.

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

PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2043003366

From angorya at openjdk.org  Mon Apr  8 17:41:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 17:41:10 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
Message-ID: <9k4bW_BLhUcA06WmnpLSDbncu7xCQ2zAHF8EIYqr9iA=.ad145524-aedc-4931-95ac-6ebc9a341b8b@github.com>

On Mon, 8 Apr 2024 15:04:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
>> 
>> A simple test would look like this:
>> 
>> 
>> public class SampleManualTest {
>>      public static void main(String[] args) throws Exception {
>>          ManualTestWindow.builder().
>>              title("Sample Manual Test").
>>              instructions(
>>                  """
>>                  Provide
>>                  multi-line instructions here.
>>                  """
>>              ).
>>              ui(() -> createTestUI()).
>>              buildAndRun();
>>      }
>> 
>>      private static Node createTestUI() {
>>          return new Label("Test UI");
>>      }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
>> 
>> Readme:
>> 
>> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - works
>  - .

@mstr2 @jperedadnr @sashamatveev @aghaisas 
would you gentlemen be interested in reviewing this?

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

PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2043309375

From angorya at openjdk.org  Mon Apr  8 17:50:11 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 17:50:11 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
Message-ID: <wmJRIU2iRnqubhBHrF5fGKvUyCgt-Nr7DnPDccVKioY=.79e054df-0661-4e21-bfb6-dc5afd371854@github.com>

On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>> 
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>> 
>> to support keyboard-only horizontal scrolling.  The main reason for the change is to improve accessibility.
>> 
>> **NOTE: For controls in right-to-left orientation, the direction is reversed.**
>> 
>> As far as I can tell, these key combinations do not interfere with editing.
>> 
>> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like
>> 
>> 
>> public void horizontalUnitScroll(boolean right);
>> 
>> 
>> Q: Does this change require a CSR to explain the change in the controls' behavior?  We don't yet have the key bindings documented in /doc-files/behavior
>> 
>> Note:
>> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available.
>
> 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 14 additional commits since the last revision:
> 
>  - tests
>  - cleanup
>  - node orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - table view behavior
>  - tree view behavior
>  - list view behavior
>  - orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - Merge branch 'master' into 8313138.horizontal
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/03d3aef8...5bae5e7a

@azuev-java could you please take a look at this from accessibility perspective?

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2043322776

From kizune at openjdk.org  Mon Apr  8 18:23:15 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 8 Apr 2024 18:23:15 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
Message-ID: <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>

On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>> 
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>> 
>> to support keyboard-only horizontal scrolling.  The main reason for the change is to improve accessibility.
>> 
>> **NOTE: For controls in right-to-left orientation, the direction is reversed.**
>> 
>> As far as I can tell, these key combinations do not interfere with editing.
>> 
>> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like
>> 
>> 
>> public void horizontalUnitScroll(boolean right);
>> 
>> 
>> Q: Does this change require a CSR to explain the change in the controls' behavior?  We don't yet have the key bindings documented in /doc-files/behavior
>> 
>> Note:
>> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available.
>
> 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 14 additional commits since the last revision:
> 
>  - tests
>  - cleanup
>  - node orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - table view behavior
>  - tree view behavior
>  - list view behavior
>  - orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - Merge branch 'master' into 8313138.horizontal
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/bdf215b7...5bae5e7a

Looks good.

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

Marked as reviewed by kizune (Author).

PR Review: https://git.openjdk.org/jfx/pull/1393#pullrequestreview-1987123433

From angorya at openjdk.org  Mon Apr  8 18:23:15 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 18:23:15 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
 <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>
Message-ID: <MCIVaG5YqRssINzvR4WdHUGPWSoxCjEEOV5YOS2mO7Q=.e4ed2680-1a39-43b3-bc99-3f249e689287@github.com>

On Mon, 8 Apr 2024 18:19:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 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 14 additional commits since the last revision:
>> 
>>  - tests
>>  - cleanup
>>  - node orientation
>>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>>  - table view behavior
>>  - tree view behavior
>>  - list view behavior
>>  - orientation
>>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>>  - Merge branch 'master' into 8313138.horizontal
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/bdf215b7...5bae5e7a
>
> Looks good.

@azuev-java does the choice of key combination make sense?

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2043398115

From kcr at openjdk.org  Mon Apr  8 22:10:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Apr 2024 22:10:11 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
Message-ID: <wgxkGzsIblG_VLurYTwmLT4MhjU6-Iq9JbleFrvoX1E=.c38024a0-5abf-405e-8bbf-6567daa5b56d@github.com>

On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>> 
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>> 
>> to support keyboard-only horizontal scrolling.  The main reason for the change is to improve accessibility.
>> 
>> **NOTE: For controls in right-to-left orientation, the direction is reversed.**
>> 
>> As far as I can tell, these key combinations do not interfere with editing.
>> 
>> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like
>> 
>> 
>> public void horizontalUnitScroll(boolean right);
>> 
>> 
>> Q: Does this change require a CSR to explain the change in the controls' behavior?  We don't yet have the key bindings documented in /doc-files/behavior
>> 
>> Note:
>> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available.
>
> 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 14 additional commits since the last revision:
> 
>  - tests
>  - cleanup
>  - node orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - table view behavior
>  - tree view behavior
>  - list view behavior
>  - orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - Merge branch 'master' into 8313138.horizontal
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/eeaf2405...5bae5e7a

A couple questions about this:

1. What are the keyboard shortcuts for vertical scrolling? I would expect them to be something like alt-ctrl-UP/DOWN but that doesn't seem to be the case. In fact I don't see a way to even do vertical scrolling (PAGE UP/PAGE DOWN is not the same as vertical scrolling), but maybe I'm missing something.
2. What do other apps or toolkits provide for horizontal / vertical scrolling?

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2043722302

From kcr at openjdk.org  Mon Apr  8 22:14:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Apr 2024 22:14:11 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
Message-ID: <R-XazkBA8sNAHMFkuZS1ckvYw4f4LWyOdo_phsy7TDw=.d64d5fbd-a890-48a3-bd57-162cc396473b@github.com>

On Mon, 8 Apr 2024 15:04:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
>> 
>> A simple test would look like this:
>> 
>> 
>> public class SampleManualTest {
>>      public static void main(String[] args) throws Exception {
>>          ManualTestWindow.builder().
>>              title("Sample Manual Test").
>>              instructions(
>>                  """
>>                  Provide
>>                  multi-line instructions here.
>>                  """
>>              ).
>>              ui(() -> createTestUI()).
>>              buildAndRun();
>>      }
>> 
>>      private static Node createTestUI() {
>>          return new Label("Test UI");
>>      }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
>> 
>> Readme:
>> 
>> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - works
>  - .

This could use a second pair of eyes. I don't have time right now, but I'll add a couple comments.

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

PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2043728148

From angorya at openjdk.org  Mon Apr  8 22:19:13 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 22:19:13 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
Message-ID: <COE1ity6fsYQSMiO-WH2tg9Qfs6Y_orSfwePAle3uys=.4675d67a-4262-432d-a490-9dfb846c3232@github.com>

On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>> 
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>> 
>> to support keyboard-only horizontal scrolling.  The main reason for the change is to improve accessibility.
>> 
>> **NOTE: For controls in right-to-left orientation, the direction is reversed.**
>> 
>> As far as I can tell, these key combinations do not interfere with editing.
>> 
>> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like
>> 
>> 
>> public void horizontalUnitScroll(boolean right);
>> 
>> 
>> Q: Does this change require a CSR to explain the change in the controls' behavior?  We don't yet have the key bindings documented in /doc-files/behavior
>> 
>> Note:
>> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available.
>
> 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 14 additional commits since the last revision:
> 
>  - tests
>  - cleanup
>  - node orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - table view behavior
>  - tree view behavior
>  - list view behavior
>  - orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - Merge branch 'master' into 8313138.horizontal
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/46deacaf...5bae5e7a

1. Vertical scrolling is not addressed in this PR (the ticket *is* about horizontal scrolling).  I suppose the existing selection/navigation key bindings are sufficient.

2. In most cases, LEFT/RIGHT arrows; I haven't encountered any special keys for horizontal navigation.  We could have used that for ListView case, but it is clearly insufficient for any table-like control.  A multi-key chord was therefore selected that a) works for all 4 cases and b) does not interfere with editing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2043732830

From kcr at openjdk.org  Mon Apr  8 22:23:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 8 Apr 2024 22:23:09 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
Message-ID: <WSNRXQwb7hxbN17efHNjZ5-g867P7jrZQScj1QlQyq8=.66e2e28c-2aac-4477-b816-2624fc408006@github.com>

On Mon, 8 Apr 2024 15:04:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
>> 
>> A simple test would look like this:
>> 
>> 
>> public class SampleManualTest {
>>      public static void main(String[] args) throws Exception {
>>          ManualTestWindow.builder().
>>              title("Sample Manual Test").
>>              instructions(
>>                  """
>>                  Provide
>>                  multi-line instructions here.
>>                  """
>>              ).
>>              ui(() -> createTestUI()).
>>              buildAndRun();
>>      }
>> 
>>      private static Node createTestUI() {
>>          return new Label("Test UI");
>>      }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
>> 
>> Readme:
>> 
>> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - works
>  - .

I left one general comment inline. I also have a question about how to build this without a build script given that the utility is in a separate directory tree from the test application (EmojiText) that you updated to use this?

At a minimum, you need instructions for compiling and running it on the command line, but it might be better to defer this until we can wire up the manual tests to the build (which would be a good test sprint task).

tests/manual/text/EmojiTest.java line 34:

> 32: import com.oracle.util.testing.ManualTestWindow;
> 33: 
> 34: public class EmojiTest {

Our existing manual tests all extend `Application`. Is there a reason this has to change? Absent a compelling reason, I'd prefer to not require test apps to stop extending Application in order to use this utility.

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

PR Review: https://git.openjdk.org/jfx/pull/1413#pullrequestreview-1987493781
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556482838

From angorya at openjdk.org  Mon Apr  8 22:28:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 22:28:09 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <WSNRXQwb7hxbN17efHNjZ5-g867P7jrZQScj1QlQyq8=.66e2e28c-2aac-4477-b816-2624fc408006@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
 <WSNRXQwb7hxbN17efHNjZ5-g867P7jrZQScj1QlQyq8=.66e2e28c-2aac-4477-b816-2624fc408006@github.com>
Message-ID: <0tPcWYDNWuq-rxGU2VG5yBi3HlCs1-WpnoPnxAMtdfw=.6d3c446c-b640-4333-9f2a-32e32adbcb10@github.com>

On Mon, 8 Apr 2024 22:15:04 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - works
>>  - .
>
> tests/manual/text/EmojiTest.java line 34:
> 
>> 32: import com.oracle.util.testing.ManualTestWindow;
>> 33: 
>> 34: public class EmojiTest {
> 
> Our existing manual tests all extend `Application`. Is there a reason this has to change? Absent a compelling reason, I'd prefer to not require test apps to stop extending Application in order to use this utility.

Everything, including creating an instance of Application, is taken care of by the `ManualTestWindow`.  This simplifies the test code greatly.

What is the reason that the test must extend `Application`?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556489482

From almatvee at openjdk.org  Mon Apr  8 22:50:09 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 8 Apr 2024 22:50:09 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
Message-ID: <q_YeOjkmdgapIx88B4-HQBDvbEtI6rXviqXauqeCBgA=.c2360ae1-8f9e-4b6f-8a51-b88e38df0c26@github.com>

On Mon, 8 Apr 2024 15:04:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides a framework for manual tests to display test instructions, test pane, and Pass/Fail buttons.
>> 
>> A simple test would look like this:
>> 
>> 
>> public class SampleManualTest {
>>      public static void main(String[] args) throws Exception {
>>          ManualTestWindow.builder().
>>              title("Sample Manual Test").
>>              instructions(
>>                  """
>>                  Provide
>>                  multi-line instructions here.
>>                  """
>>              ).
>>              ui(() -> createTestUI()).
>>              buildAndRun();
>>      }
>> 
>>      private static Node createTestUI() {
>>          return new Label("Test UI");
>>      }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/15b34a8f-cb0d-4469-85bc-ec5962e448c7)
>> 
>> Readme:
>> 
>> https://github.com/openjdk/jfx/blob/1cc095049be3773e1211ad570eb2285f08f25cec/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - works
>  - .

tests/manual/util/README.md line 19:

> 17:                  multi-line instructions here.
> 18:                  """
> 19:              ).

Add `size(1200, 800).` to example. I think adjusting size will be common enough and no need to look at `ManualTestWindow` to figure it out.

tests/manual/util/README.md line 30:

> 28: ```
> 29: 
> 30: Resulting application window:

Resulting application window does not look like it is from example above. Not sure if it is important.

tests/manual/util/src/com/oracle/util/testing/ManualTestWindow.java line 89:

> 87: // TODO log area
> 88: // TODO screenshots on failure?
> 89: // TODO initial position?

In general I do not like TODO in comments. You can file follow up issue to improve/extend `ManualTestWindow` if needed.

tests/manual/util/src/com/oracle/util/testing/ManualTestWindow.java line 250:

> 248:             Scene scene = new Scene(vb);
> 249:             stage.setWidth(width == 0 ? 800 : width);
> 250:             stage.setHeight(height == 0 ? 600 : height);

I think `width` and `height` is `double` and not `int`. Also, lets not change it. If test wants 0, then pass 0.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556487869
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556488908
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556491820
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556500553

From almatvee at openjdk.org  Mon Apr  8 22:56:08 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 8 Apr 2024 22:56:08 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <0tPcWYDNWuq-rxGU2VG5yBi3HlCs1-WpnoPnxAMtdfw=.6d3c446c-b640-4333-9f2a-32e32adbcb10@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
 <WSNRXQwb7hxbN17efHNjZ5-g867P7jrZQScj1QlQyq8=.66e2e28c-2aac-4477-b816-2624fc408006@github.com>
 <0tPcWYDNWuq-rxGU2VG5yBi3HlCs1-WpnoPnxAMtdfw=.6d3c446c-b640-4333-9f2a-32e32adbcb10@github.com>
Message-ID: <mItAsKdNE1Z_oGvDL-iS8TT2TM73vAaklRHRZl2wCSs=.66dcfe9e-872f-4799-80b9-10ba7e478dd7@github.com>

On Mon, 8 Apr 2024 22:25:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/manual/text/EmojiTest.java line 34:
>> 
>>> 32: import com.oracle.util.testing.ManualTestWindow;
>>> 33: 
>>> 34: public class EmojiTest {
>> 
>> Our existing manual tests all extend `Application`. Is there a reason this has to change? Absent a compelling reason, I'd prefer to not require test apps to stop extending Application in order to use this utility.
>
> Everything, including creating an instance of Application, is taken care of by the `ManualTestWindow`.  This simplifies the test code greatly.
> 
> What is the reason that the test must extend `Application`?

For example if test needs to access `getParameters()` or `getHostServices ()` from `Application` how it can be done? I think it might be better to extend `ManualTestWindow` from `Application` and require test itself to extend `ManualTestWindow`. In this case tests will extend `Application`.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556506989

From angorya at openjdk.org  Mon Apr  8 22:56:08 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 22:56:08 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <q_YeOjkmdgapIx88B4-HQBDvbEtI6rXviqXauqeCBgA=.c2360ae1-8f9e-4b6f-8a51-b88e38df0c26@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
 <q_YeOjkmdgapIx88B4-HQBDvbEtI6rXviqXauqeCBgA=.c2360ae1-8f9e-4b6f-8a51-b88e38df0c26@github.com>
Message-ID: <5X_vOqNlkKPISiqjgxspYMKI0xkgetvDDparj6ETAnU=.ff19df8e-a2a8-476b-bfde-75cdcea10d73@github.com>

On Mon, 8 Apr 2024 22:23:07 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - works
>>  - .
>
> tests/manual/util/README.md line 19:
> 
>> 17:                  multi-line instructions here.
>> 18:                  """
>> 19:              ).
> 
> Add `size(1200, 800).` to example. I think adjusting size will be common enough and no need to look at `ManualTestWindow` to figure it out.

good point!

> tests/manual/util/README.md line 30:
> 
>> 28: ```
>> 29: 
>> 30: Resulting application window:
> 
> Resulting application window does not look like it is from example above. Not sure if it is important.

Not really important.

Apart from being resized to decrease the size of the PNG image, it looks exactly the same.  Are you running it on a different platform?  How does it look, anything appears missing (can you post a screenshot)?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556506834
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556507844

From almatvee at openjdk.org  Mon Apr  8 23:17:11 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 8 Apr 2024 23:17:11 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <5X_vOqNlkKPISiqjgxspYMKI0xkgetvDDparj6ETAnU=.ff19df8e-a2a8-476b-bfde-75cdcea10d73@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
 <q_YeOjkmdgapIx88B4-HQBDvbEtI6rXviqXauqeCBgA=.c2360ae1-8f9e-4b6f-8a51-b88e38df0c26@github.com>
 <5X_vOqNlkKPISiqjgxspYMKI0xkgetvDDparj6ETAnU=.ff19df8e-a2a8-476b-bfde-75cdcea10d73@github.com>
Message-ID: <l1HYtDLl3MN75_djO0HQzI_E5sWqKD1CuaNsGFDWyw4=.1ec2a4c9-5d69-4ed6-b744-5e019fb1bf95@github.com>

On Mon, 8 Apr 2024 22:53:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/manual/util/README.md line 30:
>> 
>>> 28: ```
>>> 29: 
>>> 30: Resulting application window:
>> 
>> Resulting application window does not look like it is from example above. Not sure if it is important.
>
> Not really important.
> 
> Apart from being resized to decrease the size of the PNG image, it looks exactly the same.  Are you running it on a different platform?  How does it look, anything appears missing (can you post a screenshot)?

If you run `EmojiTest`, then yes it will look correct, but if you run `SampleManualTest` it will not. Since you added this image to `SampleManualTest` as resulting image of `SampleManualTest`. Look at [ReadMe.md](https://github.com/openjdk/jfx/blob/a106587a69859966e668233a9d89539c3438fed7/tests/manual/util/README.md).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556551412

From angorya at openjdk.org  Mon Apr  8 23:27:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 8 Apr 2024 23:27:10 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <l1HYtDLl3MN75_djO0HQzI_E5sWqKD1CuaNsGFDWyw4=.1ec2a4c9-5d69-4ed6-b744-5e019fb1bf95@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
 <q_YeOjkmdgapIx88B4-HQBDvbEtI6rXviqXauqeCBgA=.c2360ae1-8f9e-4b6f-8a51-b88e38df0c26@github.com>
 <5X_vOqNlkKPISiqjgxspYMKI0xkgetvDDparj6ETAnU=.ff19df8e-a2a8-476b-bfde-75cdcea10d73@github.com>
 <l1HYtDLl3MN75_djO0HQzI_E5sWqKD1CuaNsGFDWyw4=.1ec2a4c9-5d69-4ed6-b744-5e019fb1bf95@github.com>
Message-ID: <4u1ZjpTR-VqyJoZy60gNKatVu2iD5gCbsKazJJ0wm2U=.60cd953c-f590-4b75-8852-b9c0753a5e90@github.com>

On Mon, 8 Apr 2024 23:14:30 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Not really important.
>> 
>> Apart from being resized to decrease the size of the PNG image, it looks exactly the same.  Are you running it on a different platform?  How does it look, anything appears missing (can you post a screenshot)?
>
> If you run `EmojiTest`, then yes it will look correct, but if you run `SampleManualTest` it will not. Since you added this image to `SampleManualTest` as resulting image of `SampleManualTest`. Look at [ReadMe.md](https://github.com/openjdk/jfx/blob/a106587a69859966e668233a9d89539c3438fed7/tests/manual/util/README.md).

indeed!  thanks!

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1556572150

From craigraw at gmail.com  Tue Apr  9 09:37:17 2024
From: craigraw at gmail.com (Craig Raw)
Date: Tue, 9 Apr 2024 11:37:17 +0200
Subject: Headless glass platform
In-Reply-To: <trinity-bc9a4197-3fa5-4f29-a76b-0b18d02d8d49-1706863827891@3c-app-webde-bs26>
References: <CABxFH2EAqvM36TfOLTC6ss2s7ShErwrWkM+OVpGuASdrNzcrPQ@mail.gmail.com>
 <trinity-bc9a4197-3fa5-4f29-a76b-0b18d02d8d49-1706863827891@3c-app-webde-bs26>
Message-ID: <CAPR5oBN9J+8cN1TcNh4qJvBDHt5bvhTaVXxpDw1ZncREqM6Tpw@mail.gmail.com>

Hi Johan,

As you advised in another thread, I've tested the headless glass platform
and find it to be an excellent solution. My particular use case is to
provide an alternative terminal interface (using Lanterna) for a JavaFX
application without needing to rewrite a great deal of the logic. For this
purpose, the headless glass platform works very well as a replacement to
Monocle.

I encountered only one problem - calling Platform.exit() did not terminate
the application after it had been packaged with jpackage. This did not
occur with the same code using the JavaFX18 Monocle libraries on Linux
amd64. The JavaFX application thread was the only non-daemon thread at this
point. I solved this fairly simply by calling System.exit(0) after
Platform.exit().

As an aside, I was impressed by how simple it was to build JavaFX. I was
surprised though that javafx.graphics.jar did not contain the native
libraries, and I had to repackage the jar to include them manually. There
are probably good reasons for this, but it wasn't obvious.

It would be really good to see the headless glass platform merged into
JavaFX proper, and would allow me to move beyond JavaFX 18, the last
version to have Monocle support for Linux amd64.

Craig

On Fri, Feb 2, 2024 at 10:50?AM Marius Hanl <mariushanl at web.de> wrote:

> I agree that this a nice feature, especially for headless tests as you
> also mentioned.
> Really looking forward to this feature.
>
> - Marius
>
> *Gesendet:* Dienstag, 30. Januar 2024 um 12:46 Uhr
> *Von:* "Johan Vos" <johan.vos at gluonhq.com>
> *An:* "openjfx-dev" <openjfx-dev at openjdk.org>
> *Betreff:* Headless glass platform
> Hi,
>
> I created a branch in the jfx-sandbox repository for experimenting with a
> headless glass platform:
> https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>
> This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I
> suggest a POC for a Headless platform.
>
> There are a number of usecases for this, including:
> 1. applications that require JavaFX rendering without presenting this to a
> window (and instead send it to a printer for example)
> 2. running tests without requiring a window manager.
>
> Regarding the second usecase, we already did some basic experiments using
> a modified version of TestFX where instead of the Monocle Headless
> subplatform, the POC Headless platform is used.
>
> By using a first-class Headless glass platform instead of a Monocle
> subplatform, it should be easier to use by developers.
> The monocle code contains very platform/os specific parts, which often
> don't make sense outside the target platform. This is very valuable, but it
> is also a very different usecase than a headless platform and it requires a
> much more complex build procedure.
>
> I added an initial, limited HeadlessRobot to do some basic tests. That
> code is mainly taken from the existing Monocle implementation, but I want
> to be careful to avoid anything that is not applicable to the headless
> scenarios.
>
> - Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240409/edeb09d3/attachment-0001.htm>

From johan.vos at gluonhq.com  Wed Apr 10 11:45:08 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 10 Apr 2024 13:45:08 +0200
Subject: Headless glass platform
In-Reply-To: <CAPR5oBN9J+8cN1TcNh4qJvBDHt5bvhTaVXxpDw1ZncREqM6Tpw@mail.gmail.com>
References: <CABxFH2EAqvM36TfOLTC6ss2s7ShErwrWkM+OVpGuASdrNzcrPQ@mail.gmail.com>
 <trinity-bc9a4197-3fa5-4f29-a76b-0b18d02d8d49-1706863827891@3c-app-webde-bs26>
 <CAPR5oBN9J+8cN1TcNh4qJvBDHt5bvhTaVXxpDw1ZncREqM6Tpw@mail.gmail.com>
Message-ID: <CABxFH2HwRZW4OrmrPYSKyfssvx=z_emfCvB4O63CT3By0nYj1Q@mail.gmail.com>

Hi Craig,

Thanks for testing and for the feedback. Based on that feedback, I pushed a
change so that the HeadlessApplication now responds properly to a
`Platform.exit()` call (see
https://github.com/openjdk/jfx-sandbox/commit/5c8bcb2ca1f7a72f34c3e53e209b818abf8f8504
).
My implementation does a gentle stop of the processing thread, and already
submitted runnables will be handled before the processing halts. I think
this is how it should be, and it works with a simple application, but I
didn't test it with a jpackaged application yet. It would be great if you
can confirm that this is now fixed?

Thanks again for the feedback!

- Johan

On Tue, Apr 9, 2024 at 11:37?AM Craig Raw <craigraw at gmail.com> wrote:

> Hi Johan,
>
> As you advised in another thread, I've tested the headless glass platform
> and find it to be an excellent solution. My particular use case is to
> provide an alternative terminal interface (using Lanterna) for a JavaFX
> application without needing to rewrite a great deal of the logic. For this
> purpose, the headless glass platform works very well as a replacement to
> Monocle.
>
> I encountered only one problem - calling Platform.exit() did not terminate
> the application after it had been packaged with jpackage. This did not
> occur with the same code using the JavaFX18 Monocle libraries on Linux
> amd64. The JavaFX application thread was the only non-daemon thread at this
> point. I solved this fairly simply by calling System.exit(0) after
> Platform.exit().
>
> As an aside, I was impressed by how simple it was to build JavaFX. I was
> surprised though that javafx.graphics.jar did not contain the native
> libraries, and I had to repackage the jar to include them manually. There
> are probably good reasons for this, but it wasn't obvious.
>
> It would be really good to see the headless glass platform merged into
> JavaFX proper, and would allow me to move beyond JavaFX 18, the last
> version to have Monocle support for Linux amd64.
>
> Craig
>
> On Fri, Feb 2, 2024 at 10:50?AM Marius Hanl <mariushanl at web.de> wrote:
>
>> I agree that this a nice feature, especially for headless tests as you
>> also mentioned.
>> Really looking forward to this feature.
>>
>> - Marius
>>
>> *Gesendet:* Dienstag, 30. Januar 2024 um 12:46 Uhr
>> *Von:* "Johan Vos" <johan.vos at gluonhq.com>
>> *An:* "openjfx-dev" <openjfx-dev at openjdk.org>
>> *Betreff:* Headless glass platform
>> Hi,
>>
>> I created a branch in the jfx-sandbox repository for experimenting with a
>> headless glass platform:
>> https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>>
>> This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I
>> suggest a POC for a Headless platform.
>>
>> There are a number of usecases for this, including:
>> 1. applications that require JavaFX rendering without presenting this to
>> a window (and instead send it to a printer for example)
>> 2. running tests without requiring a window manager.
>>
>> Regarding the second usecase, we already did some basic experiments using
>> a modified version of TestFX where instead of the Monocle Headless
>> subplatform, the POC Headless platform is used.
>>
>> By using a first-class Headless glass platform instead of a Monocle
>> subplatform, it should be easier to use by developers.
>> The monocle code contains very platform/os specific parts, which often
>> don't make sense outside the target platform. This is very valuable, but it
>> is also a very different usecase than a headless platform and it requires a
>> much more complex build procedure.
>>
>> I added an initial, limited HeadlessRobot to do some basic tests. That
>> code is mainly taken from the existing Monocle implementation, but I want
>> to be careful to avoid anything that is not applicable to the headless
>> scenarios.
>>
>> - Johan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240410/477c6f1d/attachment.htm>

From duke at openjdk.org  Wed Apr 10 11:47:28 2024
From: duke at openjdk.org (drmarmac)
Date: Wed, 10 Apr 2024 11:47:28 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
Message-ID: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>

> This PR should fix the issue and cover all relevant cases with new tests.
> 
> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.

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

  Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1431/files
  - new: https://git.openjdk.org/jfx/pull/1431/files/103ac473..6b38b9ce

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

  Stats: 50 lines in 3 files changed: 9 ins; 10 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1431.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1431/head:pull/1431

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

From duke at openjdk.org  Wed Apr 10 11:47:28 2024
From: duke at openjdk.org (drmarmac)
Date: Wed, 10 Apr 2024 11:47:28 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases
In-Reply-To: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
Message-ID: <c-SI5ATfRtXyEGjJGHkyOwyRo0ojgzZD5MNPqNoLGsE=.91bd725b-0158-47db-9fbe-2c6cfc69dbe4@github.com>

On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac <duke at openjdk.org> wrote:

> This PR should fix the issue and cover all relevant cases with new tests.
> 
> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.

I've updated the behavior for the double spinner according to option 4.

Consequences of this approach are:
 - The wrapping behavior of the double spinner is not the same as for the integer spinner, even for all-integer values.
 - Going over the limit with one Spinner arrow, and going back with the other arrow, will generally not result in the previous value.

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

PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2047310739

From jvos at openjdk.org  Wed Apr 10 12:20:11 2024
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 10 Apr 2024 12:20:11 GMT
Subject: RFR: 8323511 Scrollbar Click jumps inconsistent amount of pixels
 [v2]
In-Reply-To: <IU6CMRDYmIpEQbhxow-TW1jSpS7GBI_YJ46MQmHIS-8=.5ce9de35-13c6-4d78-8d9b-ac34df4c9f0e@github.com>
References: <RAHBz8_U__Pk8FxX1nILErmbXHQwrquWgtjVBh5q_fA=.bc2db6b1-3324-4de2-9bdd-4b13693821e9@github.com>
 <IU6CMRDYmIpEQbhxow-TW1jSpS7GBI_YJ46MQmHIS-8=.5ce9de35-13c6-4d78-8d9b-ac34df4c9f0e@github.com>
Message-ID: <vzZCwKGYjlfN2T8vNv2mZnBUBOv_vo8W6KGd-1iD_hM=.15ecc4ab-6f88-4b44-9097-95ee85494a7f@github.com>

On Mon, 15 Jan 2024 08:31:59 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> As seen in the unit test of the PR, when we click on the area above/below the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI always jumps to the top. In the other cases, the assumed default cell height is used.
>> 
>> With this PR, always the default cell height is used, to determine how much is scrolled.
>> This makes the behavior more consistent.
>> 
>> Especially from the unit-test, it's clear that with this PR the behavior is much more consistent.
>> 
>> This is also related to the following PR: https://github.com/openjdk/jfx/pull/1194
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8323511
>   reverted accidental indentation chang

That's a good question. Since there are a number of scenario's that change the current position (offset) of the VirtualFlow, we have to be careful that those scenario's are not conflicting, and are using the same code when appropriate. Hence, duplicating code between VirtualFlow and VirtualScrollBar sounds dangerous (what if code is changed on one place but not on the other?)

Rather than shifting some logic to VirtualScrollBar, I believe it would be safer to have VirtualScrollBar calling into VirtualFlow. For mouse-scrollwheel events, this is already the case so it might be a good idea to do something similar here?

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

PR Comment: https://git.openjdk.org/jfx/pull/1326#issuecomment-2047392270

From kpk at openjdk.org  Wed Apr 10 12:54:15 2024
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 10 Apr 2024 12:54:15 GMT
Subject: RFR: 8092102: Labeled: truncated property [v8]
In-Reply-To: <sIX1EzEt0oM4gBG_y4u_upJUxl1Kg-pmYr4zDXScnCM=.2edca975-af0b-4643-adc0-62faad041c7d@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <sIX1EzEt0oM4gBG_y4u_upJUxl1Kg-pmYr4zDXScnCM=.2edca975-af0b-4643-adc0-62faad041c7d@github.com>
Message-ID: <8VCkcxrg8ZwH-FMW7VjXcJ0lkFg0zGLCmlNPq6ysZC8=.758c22dd-7a7e-46e3-ad50-578a396bd6f0@github.com>

On Thu, 28 Mar 2024 21:44:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width.
>> 
>> The new property reacts to changes in the following properties:
>> - ellipsisString
>> - font
>> - height
>> - text
>> - width
>> - wrapText
>> 
>> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code.
>> 
>> **Alternative**
>> 
>> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass.  What is the benefit of adding this functionality to the core?
>> 
>> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126).  The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone.
>> 
>> **See Also**
>> 
>> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated
>> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...)
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add exports

Overall this looks good to me. Left couple of inline comments.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 38:

> 36:         /**
> 37:          * Returns true when the Labeled must compute the actual content width in computePrefWidth().
> 38:          * @return whether computePrefWidth() must compute the actual content width

Do you think re-wording the sentence to explain when this function returns true/false would be better here?

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 58:

> 56:     /**
> 57:      * Returns true when the Labeled must compute the actual content width in computePrefWidth().
> 58:      * @return whether computePrefWidth() must compute the actual content width

Same comment as above

modules/javafx.controls/src/test/java/test/javafx/scene/control/LabeledTruncatedTest.java line 42:

> 40: /**
> 41:  * Tests textTruncated property of Labeled, using Label, TableCell, and TreeTableCell controls
> 42:  * (the last two contain conditional code that redirects the execution of computePrefWidth()

Missing `)`?

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

PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-1991164711
PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1559103685
PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1559108375
PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1559148976

From prr at openjdk.org  Wed Apr 10 19:05:32 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Apr 2024 19:05:32 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10 and
 later
Message-ID: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>

The Linux font lookup code is rejecting CFF OpenType fonts.
Since these are becoming common because of the Noto family this could soon be quite a problem.
I expect this fix is a candidate for backporting.

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

Commit messages:
 - 8322251

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

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

From angorya at openjdk.org  Wed Apr 10 19:13:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 19:13:09 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <rzi5ygNYKDGyuCSPwXNemucqSMWMDxKmaCflRpcM_Q8=.ccff82b2-0c35-40f6-bd1f-abde73342481@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

modules/javafx.graphics/src/main/native-font/fontpath_linux.c line 417:

> 415:              */
> 416:             if ((fontformat != NULL) &&
> 417:                 ((strcmp((char*)fontformat, "TrueType") != 0) &&

Code in `javax.web` uses `equalLettersIgnoringASCIICase` in a similar situation, should we use case-insensitive comparison here?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1439#discussion_r1559940651

From prr at openjdk.org  Wed Apr 10 19:42:09 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Apr 2024 19:42:09 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <rzi5ygNYKDGyuCSPwXNemucqSMWMDxKmaCflRpcM_Q8=.ccff82b2-0c35-40f6-bd1f-abde73342481@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
 <rzi5ygNYKDGyuCSPwXNemucqSMWMDxKmaCflRpcM_Q8=.ccff82b2-0c35-40f6-bd1f-abde73342481@github.com>
Message-ID: <_2Pi8M0qZYizYWITf1oI4woPL2wtFSahUEQi8FIpL4E=.32f1cfc0-479f-47fa-a9d4-d508dd9ecdb6@github.com>

On Wed, 10 Apr 2024 19:09:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The Linux font lookup code is rejecting CFF OpenType fonts.
>> Since these are becoming common because of the Noto family this could soon be quite a problem.
>> I expect this fix is a candidate for backporting.
>
> modules/javafx.graphics/src/main/native-font/fontpath_linux.c line 417:
> 
>> 415:              */
>> 416:             if ((fontformat != NULL) &&
>> 417:                 ((strcmp((char*)fontformat, "TrueType") != 0) &&
> 
> Code in `javax.web` uses `equalLettersIgnoringASCIICase` in a similar situation, should we use case-insensitive comparison here?

I thought about that but we have been using specific-case here for ever for TrueType and also in the Java 2D code - which BTW does allow CFF already and it looks for 'CFF' and more to the point the fontconfig API we are using itself explicitly looks for 'CFF' which it in turn gets by using freetype to examine font files and the API in freetype it uses says

<pre>
   *  FT_Get_Font_Format
   *
   * @description:
   *  Return a string describing the format of a given face.  Possible values
   *  are 'TrueType', 'Type~1', 'BDF', 'PCF', 'Type~42', 'CID~Type~1', 'CFF',
   *  'PFR', and 'Windows~FNT'.
</pre>

So it is baked in from the start what case is used.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1439#discussion_r1559969032

From mhanl at openjdk.org  Wed Apr 10 21:13:31 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 10 Apr 2024 21:13:31 GMT
Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the
 first tooltip that is shown before it is displayed [v3]
In-Reply-To: <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
References: <BPB1m-WI2YguyLzi9WgQlyx405H4ZlZa-YWz6D5RL1E=.43b499ce-3ed8-442d-acce-22fd80d30baf@github.com>
 <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
Message-ID: <fDsPrGoFzaaAWjA7iE1fhvycJNIVU5b4CpzSqw24__E=.277a6b6a-ccbc-456c-8eb9-cffb8b457f42@github.com>

On Sat, 9 Mar 2024 10:27:21 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the 
>> `-fx-show-delay` was set to another value.
>> 
>> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately.
>> 
>> Added a bunch of headful tests for the behaviour since there were none before.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay

keep it open.

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

PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2048442535

From mhanl at openjdk.org  Wed Apr 10 21:21:59 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 10 Apr 2024 21:21:59 GMT
Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal
 scrolling
In-Reply-To: <SyyulfXZS_Z3bnCmUq770iE29PPg9f_3sqcaVJurBgU=.0978831c-30c3-4684-b5f5-9170ab1df9db@github.com>
References: <SyyulfXZS_Z3bnCmUq770iE29PPg9f_3sqcaVJurBgU=.0978831c-30c3-4684-b5f5-9170ab1df9db@github.com>
Message-ID: <u0pi8d48-hAs7GQCi8GXFsthGtlA1o3izlkirPHGv0s=.0a914996-fc7a-46ed-9f61-276bb74ef762@github.com>

On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes the border glitch/gap as explained in both linked tickets.
> 
> I noted that the `ScrollPane` control does not suffer from this problem, although the code is mostly the same as in `VirtualFlow`. The `ScrollPane` snaps the content correctly, no matter which scale. I carefully checked the code and it seems that the container structure in `ScrollPane` was explicitly written to handle this perfectly. There was definitely some thought on that.
> 
> So to finally fix this issue, I rewrote the `VirtualFlow` container/scrolling code to be **exactly** the same as in `ScrollPane`(Skin).
> And this also fixes the issue, while behaving the same as before.
> 
> In the future it may makes sense to try to somewhat unify the code from `ScrollPane` and `VirtualFlow`. I already have some ideas.
> 
> Unfortunately though, one more container is introduced to `VirtualFlow`, so the css needs to be changed since it is very strictly written in the first place:
> Before: `.list-view:focused > .virtual-flow > .clipped-container > .sheet > .list-cell`
> After: `.list-view:focused > .virtual-flow > .viewport > .clipped-container > .sheet > .list-cell`
> 
> To better understand this, the container structure (tree) is shown below:
> 
> - ScrollPane
>   - viewRect ->  `setClip` -> clipRect (viewContent size)
>     - viewContent -> `setLayoutX`
>       - Content
>   - vsb
>   - hsb
>   - corner
> 
> ---
> - VirtualFlow
>   - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect (clippedContainer size)
>     - clippedContainer/clipView -> `setLayoutX` (when scrolling)
>       - sheet
>         - Cell
>   - vsb
>   - hsb
>   - corner

open for discussion still, but there will be a counter PR from me at one point.

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

PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-2048453333

From angorya at openjdk.org  Wed Apr 10 21:25:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 21:25:10 GMT
Subject: RFR: 8092102: Labeled: truncated property [v9]
In-Reply-To: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
Message-ID: <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>

> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width.
> 
> The new property reacts to changes in the following properties:
> - ellipsisString
> - font
> - height
> - text
> - width
> - wrapText
> 
> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code.
> 
> **Alternative**
> 
> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass.  What is the benefit of adding this functionality to the core?
> 
> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126).  The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone.
> 
> **See Also**
> 
> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated
> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...)

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - missing )
 - review comments
 - Merge branch 'master' into 8092102.truncated
 - add exports
 - added unit tests
 - Merge remote-tracking branch 'origin/master' into 8092102.truncated
 - test
 - Merge remote-tracking branch 'origin/master' into 8092102.truncated
 - Merge branch 'master' into 8092102.truncated
 - labeled helper
 - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e

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

Changes: https://git.openjdk.org/jfx/pull/1389/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1389&range=08
  Stats: 309 lines in 8 files changed: 279 ins; 19 del; 11 mod
  Patch: https://git.openjdk.org/jfx/pull/1389.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1389/head:pull/1389

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

From angorya at openjdk.org  Wed Apr 10 21:29:49 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 21:29:49 GMT
Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal
 scrolling
In-Reply-To: <_kDXEiA5mxJ3YW5ecxBovaSsjDOZ_Mgu_LOay56T7wM=.77dacdf9-392d-4d93-8529-05b3429c5b17@github.com>
References: <SyyulfXZS_Z3bnCmUq770iE29PPg9f_3sqcaVJurBgU=.0978831c-30c3-4684-b5f5-9170ab1df9db@github.com>
 <_kDXEiA5mxJ3YW5ecxBovaSsjDOZ_Mgu_LOay56T7wM=.77dacdf9-392d-4d93-8529-05b3429c5b17@github.com>
Message-ID: <g1F4epxfRZ0sCzjEetWuldQbBgU1j3aj0ywD7QG-gR4=.22747721-7aa6-4de7-84c3-73049e5129af@github.com>

On Sun, 10 Mar 2024 13:29:58 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> But there is obviously a bug on the low level NGNode side as well. Not sure where to go from here.

does it mean this PR is not ready, or do we have other issue(s)?

Also, a CSR is needed for this PR to go forward.

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

PR Comment: https://git.openjdk.org/jfx/pull/1330#issuecomment-2048461451

From angorya at openjdk.org  Wed Apr 10 21:30:52 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 21:30:52 GMT
Subject: RFR: 8092102: Labeled: truncated property [v8]
In-Reply-To: <8VCkcxrg8ZwH-FMW7VjXcJ0lkFg0zGLCmlNPq6ysZC8=.758c22dd-7a7e-46e3-ad50-578a396bd6f0@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <sIX1EzEt0oM4gBG_y4u_upJUxl1Kg-pmYr4zDXScnCM=.2edca975-af0b-4643-adc0-62faad041c7d@github.com>
 <8VCkcxrg8ZwH-FMW7VjXcJ0lkFg0zGLCmlNPq6ysZC8=.758c22dd-7a7e-46e3-ad50-578a396bd6f0@github.com>
Message-ID: <8mpifOecQbU9ZK2ind7xIt_Ldpnv3ug0yykXEykAOc8=.441c417f-95a0-4791-a737-139aaa7a2b69@github.com>

On Wed, 10 Apr 2024 09:03:33 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add exports
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 38:
> 
>> 36:         /**
>> 37:          * Returns true when the Labeled must compute the actual content width in computePrefWidth().
>> 38:          * @return whether computePrefWidth() must compute the actual content width
> 
> Do you think re-wording the sentence to explain when this function returns true/false would be better here?

is the new version clearer?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1560075257

From angorya at openjdk.org  Wed Apr 10 23:04:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 23:04:56 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v5]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <RKH3xLojQLP90_tP_Cz6-AXtZ1dvMDiPugbogkwdtac=.6e33a8f0-02af-40e0-8b56-33e1bbf5ab8d@github.com>

> ## ManualTestWindow
> 
> This facility provides the base class for manual tests which displays the test instructions,
> the UI under test, and the Pass/Fail buttons.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>     }
> 
>     public static void main(String[] args) throws Exception {
>         launch(args);
>     }
> 
>     @Override
>     protected Node createContent() {
>         return new Button("Test");
>     }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
> 
> Readme:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
> 
> Q: What other features can be added to the test window?
> 
> Edit: the sources are left in their original place at the root of the project.

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - extends application

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/a106587a..dbcdb542

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

  Stats: 385 lines in 5 files changed: 135 ins; 177 del; 73 mod
  Patch: https://git.openjdk.org/jfx/pull/1413.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1413/head:pull/1413

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

From angorya at openjdk.org  Wed Apr 10 23:04:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 23:04:56 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v4]
In-Reply-To: <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <3BRJ3ptO6bRuhHmrBYYaaeynZne3MStqVCn17wRJ1as=.c31ba53e-7ba9-43f6-9200-faad14859d98@github.com>
Message-ID: <PosZ9jnGYw8_3REVgrJzdTmqWjjddsZEiLxuA7W8Xrs=.5ba53116-aaef-481a-9f21-28da77e578bc@github.com>

On Mon, 8 Apr 2024 15:04:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides the base class for manual tests which displays the test instructions,
>> the UI under test, and the Pass/Fail buttons.
>> 
>> Example:
>> 
>> 
>> public class ManualTestExample extends ManualTestWindow {
>>     public ManualTestExample() {
>>         super(
>>             "Manual Test Example",
>>             """
>>             Instructions:
>>             1. you will see a button named "Test"
>>             2. press the button
>>             3. verify that the button can be pressed""",
>>             400, 250
>>         );
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         launch(args);
>>     }
>> 
>>     @Override
>>     protected Node createContent() {
>>         return new Button("Test");
>>     }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
>> 
>> Readme:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - works
>  - .

Thank you all for comments and suggestions!
Changed to extend Application.  See if you like this better.

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

PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2048571900

From angorya at openjdk.org  Wed Apr 10 23:16:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 23:16:02 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v6]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <zkPKbBGHPAl8zqXfwuKv4tvhKf3LZVZp0Ciyq1yhoUY=.eceab3fb-5e2c-474f-a019-4df9d18ef99d@github.com>

> ## ManualTestWindow
> 
> This facility provides the base class for manual tests which displays the test instructions,
> the UI under test, and the Pass/Fail buttons.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>     }
> 
>     public static void main(String[] args) throws Exception {
>         launch(args);
>     }
> 
>     @Override
>     protected Node createContent() {
>         return new Button("Test");
>     }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
> 
> Readme:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
> 
> Q: What other features can be added to the test window?
> 
> Edit: the sources are left in their original place at the root of the project.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  removed example

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/dbcdb542..76a4dc8c

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

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

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

From almatvee at openjdk.org  Wed Apr 10 23:31:48 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 10 Apr 2024 23:31:48 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v6]
In-Reply-To: <zkPKbBGHPAl8zqXfwuKv4tvhKf3LZVZp0Ciyq1yhoUY=.eceab3fb-5e2c-474f-a019-4df9d18ef99d@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <zkPKbBGHPAl8zqXfwuKv4tvhKf3LZVZp0Ciyq1yhoUY=.eceab3fb-5e2c-474f-a019-4df9d18ef99d@github.com>
Message-ID: <kMx7lSafO6NzMm6n7oXO-kQYbULYIH3_WEop1bocMu4=.a7d184ee-1c7b-42b4-9549-6ba3b33a6b8d@github.com>

On Wed, 10 Apr 2024 23:16:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides the base class for manual tests which displays the test instructions,
>> the UI under test, and the Pass/Fail buttons.
>> 
>> Example:
>> 
>> 
>> public class ManualTestExample extends ManualTestWindow {
>>     public ManualTestExample() {
>>         super(
>>             "Manual Test Example",
>>             """
>>             Instructions:
>>             1. you will see a button named "Test"
>>             2. press the button
>>             3. verify that the button can be pressed""",
>>             400, 250
>>         );
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         launch(args);
>>     }
>> 
>>     @Override
>>     protected Node createContent() {
>>         return new Button("Test");
>>     }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
>> 
>> Readme:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed example

Only minor comment about unused code. Otherwise looks fine to me.

tests/manual/util/src/com/oracle/util/testing/ManualTestWindow.java line 130:

> 128:         });
> 129:         screenshotButton.setDisable(true);
> 130:         */

I will suggest to delete unused code.

tests/manual/util/src/com/oracle/util/testing/ManualTestWindow.java line 148:

> 146:         HBox buttons = new HBox(
> 147:             10,
> 148:             //screenshotButton,

Same here.

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

PR Review: https://git.openjdk.org/jfx/pull/1413#pullrequestreview-1992844835
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1560162005
PR Review Comment: https://git.openjdk.org/jfx/pull/1413#discussion_r1560162155

From angorya at openjdk.org  Wed Apr 10 23:39:44 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 23:39:44 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v3]
In-Reply-To: <UZTXB9HcmwVkmceERI4uQq1bS66rz01X2UUJJKVUFJQ=.e42a872c-aa47-444f-b50f-3289e4f37a68@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <UZTXB9HcmwVkmceERI4uQq1bS66rz01X2UUJJKVUFJQ=.e42a872c-aa47-444f-b50f-3289e4f37a68@github.com>
Message-ID: <q7Trx2NktmuRuqetHQId9kiMCUxcFFVPyy7rJ0c0Bsk=.2903bf6e-3a1d-4405-8942-00de99cc11ca@github.com>

On Tue, 2 Apr 2024 12:58:27 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Add unit test

Thank you for adding a unit test!

I think you might have introduced an issue.  I am using the Monkey Tester
https://github.com/andy-goryachev-oracle/MonkeyTest
 to dynamically change the application style sheet by adding the following line:

.button { -fx-padding: 100 100 100 100; }

it's a bit extreme, yes, but once that update is made, I can get it to generate continuous flicker (see the recording).

https://github.com/openjdk/jfx/assets/107069028/b1a2d8ac-3d14-45b3-adff-b3893cd0ff90

steps to reproduce (with the MT):
- select ToolBar page from the list on the left
- set HORIZONTAL orientation
- open Tools -> CSS Playground tool, enter the CSS string above, press Update button
- try resizing the split pane containing the tool bar.  at some point the flicker starts.
- I also see the small buttons in the area that flickers, suggesting that CSS might not be applied correctly

For reference, I am running this on a secondary monitor with 100% scale with macOS 14.4.1

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2048603429

From angorya at openjdk.org  Wed Apr 10 23:45:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 23:45:56 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v7]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <1RjouGQLZp9yUv4cbYmNYOduAfGmbfh5bcKhCkmgtIs=.7a60a586-b91d-4465-b37b-7f54e0e98cf7@github.com>

> ## ManualTestWindow
> 
> This facility provides the base class for manual tests which displays the test instructions,
> the UI under test, and the Pass/Fail buttons.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>     }
> 
>     public static void main(String[] args) throws Exception {
>         launch(args);
>     }
> 
>     @Override
>     protected Node createContent() {
>         return new Button("Test");
>     }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
> 
> Readme:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
> 
> Q: What other features can be added to the test window?
> 
> Edit: the sources are left in their original place at the root of the project.

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual
 - cleanup

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/76a4dc8c..a8fc661b

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

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

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

From angorya at openjdk.org  Wed Apr 10 23:45:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 10 Apr 2024 23:45:56 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v6]
In-Reply-To: <zkPKbBGHPAl8zqXfwuKv4tvhKf3LZVZp0Ciyq1yhoUY=.eceab3fb-5e2c-474f-a019-4df9d18ef99d@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <zkPKbBGHPAl8zqXfwuKv4tvhKf3LZVZp0Ciyq1yhoUY=.eceab3fb-5e2c-474f-a019-4df9d18ef99d@github.com>
Message-ID: <vXNxFveKo4IjMhSNjKFj0AOWUGEQEZDyAO7xm7SRRjw=.cff0ffe2-0122-4666-83ea-a23197ea00fd@github.com>

On Wed, 10 Apr 2024 23:16:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides the base class for manual tests which displays the test instructions,
>> the UI under test, and the Pass/Fail buttons.
>> 
>> Example:
>> 
>> 
>> public class ManualTestExample extends ManualTestWindow {
>>     public ManualTestExample() {
>>         super(
>>             "Manual Test Example",
>>             """
>>             Instructions:
>>             1. you will see a button named "Test"
>>             2. press the button
>>             3. verify that the button can be pressed""",
>>             400, 250
>>         );
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         launch(args);
>>     }
>> 
>>     @Override
>>     protected Node createContent() {
>>         return new Button("Test");
>>     }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
>> 
>> Readme:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed example

it's in the test code, but ok - removed commented out code.  thanks!

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

PR Comment: https://git.openjdk.org/jfx/pull/1413#issuecomment-2048607700

From almatvee at openjdk.org  Wed Apr 10 23:47:48 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 10 Apr 2024 23:47:48 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v7]
In-Reply-To: <1RjouGQLZp9yUv4cbYmNYOduAfGmbfh5bcKhCkmgtIs=.7a60a586-b91d-4465-b37b-7f54e0e98cf7@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
 <1RjouGQLZp9yUv4cbYmNYOduAfGmbfh5bcKhCkmgtIs=.7a60a586-b91d-4465-b37b-7f54e0e98cf7@github.com>
Message-ID: <D1j4BHwKb9fGwipSR9seMBxylLc8SfTeu4q5JYK05Vw=.e85a5dab-9394-47fd-ae5b-909bcd20158e@github.com>

On Wed, 10 Apr 2024 23:45:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ## ManualTestWindow
>> 
>> This facility provides the base class for manual tests which displays the test instructions,
>> the UI under test, and the Pass/Fail buttons.
>> 
>> Example:
>> 
>> 
>> public class ManualTestExample extends ManualTestWindow {
>>     public ManualTestExample() {
>>         super(
>>             "Manual Test Example",
>>             """
>>             Instructions:
>>             1. you will see a button named "Test"
>>             2. press the button
>>             3. verify that the button can be pressed""",
>>             400, 250
>>         );
>>     }
>> 
>>     public static void main(String[] args) throws Exception {
>>         launch(args);
>>     }
>> 
>>     @Override
>>     protected Node createContent() {
>>         return new Button("Test");
>>     }
>> }
>> 
>> 
>> Resulting application window:
>> 
>> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
>> 
>> Readme:
>> 
>> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
>> 
>> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
>> 
>> Q: What other features can be added to the test window?
>> 
>> Edit: the sources are left in their original place at the root of the project.
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual
>  - cleanup

Marked as reviewed by almatvee (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1413#pullrequestreview-1992862962

From mfox at openjdk.org  Wed Apr 10 23:48:44 2024
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 10 Apr 2024 23:48:44 GMT
Subject: RFR: 8273743: KeyCharacterCombination for "+" does not work on US
 QWERTY keyboard layout
In-Reply-To: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com>
References: <5LU6hctZe8tCkhnp5SYzk8tVYVDVjgQaAYATBISCtCU=.184f8e75-1aec-4cb2-8628-2ffca93784c5@github.com>
Message-ID: <BJfcSA1fq_U0H5EwYDTjSNYPZhRseztnkal-KOdEiRw=.220e3228-1d1b-4298-acbd-149e44ce0616@github.com>

On Tue, 20 Feb 2024 18:07:43 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On Linux getKeyCodeForChar does not consult the current keyboard layout. For example, it assumes the ?+? character is on KeyCode.PLUS even on layouts which don?t generate KeyCode.PLUS. The result is that most KeyCharacterCombinations don?t work.
> 
> This PR fixes this using the same approach that Mac glass uses. When the user types a key we lookup all the characters that key might generate and put them in a map. getKeyCodeForChar then consults the map to find the Java key code. This ensures that we only pay attention to keys that are on the user?s physical keyboard.
> 
> (Some Linux layout maps are expansive and include entries for keys that may be on the user?s keyboard but probably aren?t, like ?(? and ?)? on the numeric keypad. If we simply ask for all entries that generate a given character we can get multiple hits with no good way to determine which ones are physically present.)
> 
> This PR also contains fixes to the Robot to enable testing. When Glass consults the GdkKeymap to determine which keys might generate a keyval GDK returns a list covering every installed layout and shift level. The old Glass code simply picked the first entry in the list. This PR iterates through the list looking for one that works for the current layout and correct shift level.

Comment added to keep the bots at bay.

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

PR Comment: https://git.openjdk.org/jfx/pull/1373#issuecomment-2048610696

From craigraw at gmail.com  Thu Apr 11 07:43:25 2024
From: craigraw at gmail.com (Craig Raw)
Date: Thu, 11 Apr 2024 09:43:25 +0200
Subject: Headless glass platform
In-Reply-To: <CABxFH2HwRZW4OrmrPYSKyfssvx=z_emfCvB4O63CT3By0nYj1Q@mail.gmail.com>
References: <CABxFH2EAqvM36TfOLTC6ss2s7ShErwrWkM+OVpGuASdrNzcrPQ@mail.gmail.com>
 <trinity-bc9a4197-3fa5-4f29-a76b-0b18d02d8d49-1706863827891@3c-app-webde-bs26>
 <CAPR5oBN9J+8cN1TcNh4qJvBDHt5bvhTaVXxpDw1ZncREqM6Tpw@mail.gmail.com>
 <CABxFH2HwRZW4OrmrPYSKyfssvx=z_emfCvB4O63CT3By0nYj1Q@mail.gmail.com>
Message-ID: <CAPR5oBOWvKewpLQkUGwfEsg1FmVxBNJjwk7-T+MfQKi2mZv+Jg@mail.gmail.com>

Thanks Johan.

I have tested this change with a jpackaged application, and the issue no
longer appears. Platform.exit() now exits the application properly.

Craig

On Wed, Apr 10, 2024 at 1:45?PM Johan Vos <johan.vos at gluonhq.com> wrote:

> Hi Craig,
>
> Thanks for testing and for the feedback. Based on that feedback, I pushed
> a change so that the HeadlessApplication now responds properly to a
> `Platform.exit()` call (see
> https://github.com/openjdk/jfx-sandbox/commit/5c8bcb2ca1f7a72f34c3e53e209b818abf8f8504
> ).
> My implementation does a gentle stop of the processing thread, and already
> submitted runnables will be handled before the processing halts. I think
> this is how it should be, and it works with a simple application, but I
> didn't test it with a jpackaged application yet. It would be great if you
> can confirm that this is now fixed?
>
> Thanks again for the feedback!
>
> - Johan
>
> On Tue, Apr 9, 2024 at 11:37?AM Craig Raw <craigraw at gmail.com> wrote:
>
>> Hi Johan,
>>
>> As you advised in another thread, I've tested the headless glass platform
>> and find it to be an excellent solution. My particular use case is to
>> provide an alternative terminal interface (using Lanterna) for a JavaFX
>> application without needing to rewrite a great deal of the logic. For this
>> purpose, the headless glass platform works very well as a replacement to
>> Monocle.
>>
>> I encountered only one problem - calling Platform.exit() did not
>> terminate the application after it had been packaged with jpackage. This
>> did not occur with the same code using the JavaFX18 Monocle libraries on
>> Linux amd64. The JavaFX application thread was the only non-daemon thread
>> at this point. I solved this fairly simply by calling System.exit(0) after
>> Platform.exit().
>>
>> As an aside, I was impressed by how simple it was to build JavaFX. I was
>> surprised though that javafx.graphics.jar did not contain the native
>> libraries, and I had to repackage the jar to include them manually. There
>> are probably good reasons for this, but it wasn't obvious.
>>
>> It would be really good to see the headless glass platform merged into
>> JavaFX proper, and would allow me to move beyond JavaFX 18, the last
>> version to have Monocle support for Linux amd64.
>>
>> Craig
>>
>> On Fri, Feb 2, 2024 at 10:50?AM Marius Hanl <mariushanl at web.de> wrote:
>>
>>> I agree that this a nice feature, especially for headless tests as you
>>> also mentioned.
>>> Really looking forward to this feature.
>>>
>>> - Marius
>>>
>>> *Gesendet:* Dienstag, 30. Januar 2024 um 12:46 Uhr
>>> *Von:* "Johan Vos" <johan.vos at gluonhq.com>
>>> *An:* "openjfx-dev" <openjfx-dev at openjdk.org>
>>> *Betreff:* Headless glass platform
>>> Hi,
>>>
>>> I created a branch in the jfx-sandbox repository for experimenting with
>>> a headless glass platform:
>>> https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>>>
>>> This addresses https://bugs.openjdk.org/browse/JDK-8324941 where I
>>> suggest a POC for a Headless platform.
>>>
>>> There are a number of usecases for this, including:
>>> 1. applications that require JavaFX rendering without presenting this to
>>> a window (and instead send it to a printer for example)
>>> 2. running tests without requiring a window manager.
>>>
>>> Regarding the second usecase, we already did some basic experiments
>>> using a modified version of TestFX where instead of the Monocle Headless
>>> subplatform, the POC Headless platform is used.
>>>
>>> By using a first-class Headless glass platform instead of a Monocle
>>> subplatform, it should be easier to use by developers.
>>> The monocle code contains very platform/os specific parts, which often
>>> don't make sense outside the target platform. This is very valuable, but it
>>> is also a very different usecase than a headless platform and it requires a
>>> much more complex build procedure.
>>>
>>> I added an initial, limited HeadlessRobot to do some basic tests. That
>>> code is mainly taken from the existing Monocle implementation, but I want
>>> to be careful to avoid anything that is not applicable to the headless
>>> scenarios.
>>>
>>> - Johan
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240411/abba6d0c/attachment-0001.htm>

From angorya at openjdk.org  Thu Apr 11 19:47:50 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Apr 2024 19:47:50 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
 <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
Message-ID: <u0ygRVwCEOENxxRlS-6kdDNcV4uUXqG9T4kidPFrPH0=.2f52bc65-da1e-4f8f-9814-7276fdc23312@github.com>

On Wed, 10 Apr 2024 11:47:28 GMT, drmarmac <duke at openjdk.org> wrote:

>> This PR should fix the issue and cover all relevant cases with new tests.
>> 
>> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.
>
> drmarmac has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic

Marked as reviewed by angorya (Reviewer).

It looks like the issue [JDK-8193286](https://bugs.openjdk.org/browse/JDK-8193286) is also fixed by this change, so it probably should be added to this PR.

Also, this PR changes the way {List|Integer|Double}ValueFactory behaves when wrapping is enabled, so even though we determined that no CSR is required, I feel we need to document the new behavior in the ticket.

So here my suggestions:
1. add JDK-8193286 to this PR
2. describe the new behavior in JDK-8242553 description

otherwise, lgtm.

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

PR Review: https://git.openjdk.org/jfx/pull/1431#pullrequestreview-1995142070
PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2050402556

From angorya at openjdk.org  Thu Apr 11 20:06:45 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Apr 2024 20:06:45 GMT
Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the
 first tooltip that is shown before it is displayed [v3]
In-Reply-To: <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
References: <BPB1m-WI2YguyLzi9WgQlyx405H4ZlZa-YWz6D5RL1E=.43b499ce-3ed8-442d-acce-22fd80d30baf@github.com>
 <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
Message-ID: <HJ2nz_BKnBLjMnFw0AjDobQDSwlTgGOgtrRhEJbtfiI=.7d01383c-9e5c-4ff7-9502-1f1555d012ea@github.com>

On Sat, 9 Mar 2024 10:27:21 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the 
>> `-fx-show-delay` was set to another value.
>> 
>> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately.
>> 
>> Added a bunch of headful tests for the behaviour since there were none before.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay

Please sync up with the latest master (should be a SOP for any long outstanding PRs - sorry for long delay!)


Description	Resource	Type	Path	Location
The method shutdown() in the type Util is not applicable for the arguments (Stage)	TooltipTest.java	Java Problem	/systemTests-test/java/test/robot/javafx/scene	line 238


^ please remove the 'stage' argument, see JDK-8325566

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

PR Comment: https://git.openjdk.org/jfx/pull/1394#issuecomment-2050428426

From angorya at openjdk.org  Thu Apr 11 20:26:47 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Apr 2024 20:26:47 GMT
Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the
 first tooltip that is shown before it is displayed [v3]
In-Reply-To: <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
References: <BPB1m-WI2YguyLzi9WgQlyx405H4ZlZa-YWz6D5RL1E=.43b499ce-3ed8-442d-acce-22fd80d30baf@github.com>
 <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
Message-ID: <gFEK84n6SXjPXKQ9ioCwPi6VeU-NdJfAAYqk6I0PYcc=.82a1b135-0d2e-491f-89c0-2cb12c1fae50@github.com>

On Sat, 9 Mar 2024 10:27:21 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a long standing issue where the `Tooltip` will always wait one second until it appears the very first time, even if the 
>> `-fx-show-delay` was set to another value.
>> 
>> The culprit is, that the `cssForced` flag is not inside `Tooltip`, but inside the `TooltipBehaviour`. So the very first `Tooltip` gets processed correctly, but after no `Tooltip` will be processed by CSS before showing, resulting in the set `-fx-show-delay` to not be applied immediately.
>> 
>> Added a bunch of headful tests for the behaviour since there were none before.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay

modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 177:

> 175:     protected void show() {
> 176:         // The very first show call is just for us to do the correct CSS processing, so we ignore the request here.
> 177:         if (!cssForced) {

I am *very* suspicious of this change.  Yes, it sort of works, but I wonder if it might backfire as it breaks the contract of show() and also depends on some assumptions ("The very first show call is just for us to do the correct CSS processing").

Would it be possible to try the applySceneStylesFromOwner() approach, maybe by moving the method to Utils to avoid changing the API?  This issue does not seem to be limited to Tooltip - there is a similar code in CustomColorDialog:88 for example.

What do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1561619791

From angorya at openjdk.org  Thu Apr 11 21:38:47 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Apr 2024 21:38:47 GMT
Subject: RFR: 8186188: TableColumHeader: initial auto-size broken if has
 graphic [v7]
In-Reply-To: <rf1ywzjmJ7EDxuRmF-pOaDZ6XfEgHl6qJm2ZHxSu3Sc=.1959a49d-1413-4af7-b8c2-78e2b7044da0@github.com>
References: <GOCc3REwnXmSpsN96WBzCq3dQJPzzvL2dFjOKlpE15c=.fab298e9-f241-4f7c-ab53-2891d5f7fcfa@github.com>
 <rf1ywzjmJ7EDxuRmF-pOaDZ6XfEgHl6qJm2ZHxSu3Sc=.1959a49d-1413-4af7-b8c2-78e2b7044da0@github.com>
Message-ID: <KM2QTNcVJ-PM6vdkso_2CjTEVw4A4GIuCWg1HOXEthA=.0c08fd1d-de1a-4711-8527-780552cdd4ec@github.com>

On Wed, 27 Mar 2024 23:20:49 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes the issue that the initial column autosizing is wrong under some circumstances.
>> The following things will break the initial autosizing:
>> - Bold Column text (that is where I initially found this problem)
>> - Another font / font size
>> - Graphic
>> - Graphic Content Display (which can be styled via CSS)
>> 
>> The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well.
>> 
>> ~It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me.~
>> **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)**
>> 
>> The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text.
>> 
>> I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy).
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use snapped insets

Works as expected with the code in the ticket, no issues found with the monkey tester.
Thanks!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1405#pullrequestreview-1995527604

From angorya at openjdk.org  Thu Apr 11 21:49:46 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 11 Apr 2024 21:49:46 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <-Xm_WMXG6Us8UQVG6TKG_rhJGOUDOFEx7CI9fFT0pPI=.a2bf44b4-bb4b-4ce9-a254-23f2d56ae0b3@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

The windows build failure is unrelated:


curl: (28) Failed to connect to www.cygwin.com port 443 after 21041 ms: Couldn't connect to server
Start-Process: D:\a_temp\46314114-c9de-404b-9d61-702019e10c7b.ps1:4
Line |
   4 |  Start-Process -FilePath "$HOME\cygwin\setup-x86_64.exe" -ArgumentList ?
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | This command cannot be run due to the error: The system cannot find the file specified.
Error: Process completed with exit code 1.

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

PR Comment: https://git.openjdk.org/jfx/pull/1439#issuecomment-2050608323

From mhanl at openjdk.org  Fri Apr 12 08:01:55 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 12 Apr 2024 08:01:55 GMT
Subject: Integrated: 8186188: TableColumHeader: initial auto-size broken if has
 graphic
In-Reply-To: <GOCc3REwnXmSpsN96WBzCq3dQJPzzvL2dFjOKlpE15c=.fab298e9-f241-4f7c-ab53-2891d5f7fcfa@github.com>
References: <GOCc3REwnXmSpsN96WBzCq3dQJPzzvL2dFjOKlpE15c=.fab298e9-f241-4f7c-ab53-2891d5f7fcfa@github.com>
Message-ID: <1lyOdWKAq5s_Me6-m4CFc3gZrS95PHCcav7Vmbz78NY=.ff1f9660-fc5a-4b12-a5f8-5a758e398da3@github.com>

On Sat, 16 Mar 2024 15:47:18 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes the issue that the initial column autosizing is wrong under some circumstances.
> The following things will break the initial autosizing:
> - Bold Column text (that is where I initially found this problem)
> - Another font / font size
> - Graphic
> - Graphic Content Display (which can be styled via CSS)
> 
> The reason is actually quite simple: The CSS is not (yet) applied initially, we therefore ALWAYS take the default font into account + the graphic is not yet layouted as well.
> 
> ~It was not so easy to write tests for this, also for me the `test_resizeColumnToFitContentHeader` is always failing locally. I don't know what happens here, but he seems to not find a (Stub?) `Font` for me.~
> **EDIT: Found out the cause and fixed it. I will check if I can write more tests since it works now. :)**
> 
> The test I wrote now is checking if the css is applied after we triggered the autosize, which is what we would expect here since we measure text.
> 
> I also copied the `TableColumnHeaderTest` and rewrote the tests for `TreeTableView` as well, so we can catch any errors here as well since they both use different code (although it is technically the same - C&P errors can happen very easy).

This pull request has now been integrated.

Changeset: 44d53baf
Author:    Marius Hanl <mhanl at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/44d53baf2f9fda395e6a37671794482d7f0a28ca
Stats:     515 lines in 4 files changed: 505 ins; 4 del; 6 mod

8186188: TableColumHeader: initial auto-size broken if has graphic

Reviewed-by: angorya, rlichten

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

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

From mhanl at openjdk.org  Fri Apr 12 09:29:47 2024
From: mhanl at openjdk.org (Marius Hanl)
Date: Fri, 12 Apr 2024 09:29:47 GMT
Subject: RFR: 8296387: [Tooltip, CSS] -fx-show-delay is only applied to the
 first tooltip that is shown before it is displayed [v3]
In-Reply-To: <gFEK84n6SXjPXKQ9ioCwPi6VeU-NdJfAAYqk6I0PYcc=.82a1b135-0d2e-491f-89c0-2cb12c1fae50@github.com>
References: <BPB1m-WI2YguyLzi9WgQlyx405H4ZlZa-YWz6D5RL1E=.43b499ce-3ed8-442d-acce-22fd80d30baf@github.com>
 <Jhh1SMmWlEu2eYnnTqdvnYqzVkShszMQRp56ScPAMcw=.09decf8c-13d5-4f52-8d76-06f99e56f4e9@github.com>
 <gFEK84n6SXjPXKQ9ioCwPi6VeU-NdJfAAYqk6I0PYcc=.82a1b135-0d2e-491f-89c0-2cb12c1fae50@github.com>
Message-ID: <_rTyx0aTU-cH7WWhWp0yPcr9CvBVoaGosl7VJJB3Cfg=.7a3b9108-1767-47bc-9c6f-d9e1f2782aab@github.com>

On Thu, 11 Apr 2024 20:23:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allow Tooltip to process the owner styles first so that also global stylesheets are considered for the e.g. tooltip show-delay
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Tooltip.java line 177:
> 
>> 175:     protected void show() {
>> 176:         // The very first show call is just for us to do the correct CSS processing, so we ignore the request here.
>> 177:         if (!cssForced) {
> 
> I am *very* suspicious of this change.  Yes, it sort of works, but I wonder if it might backfire as it breaks the contract of show() and also depends on some assumptions ("The very first show call is just for us to do the correct CSS processing").
> 
> Would it be possible to try the applySceneStylesFromOwner() approach, maybe by moving the method to Utils to avoid changing the API?  This issue does not seem to be limited to Tooltip - there is a similar code in CustomColorDialog:88 for example.
> 
> What do you think?

As written above, that would also be a possibility I explorer and that worked as well. Would be fine for me and I agree that this is rather unexpected. I will explore the other solution soon, when time permits.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1394#discussion_r1562296242

From duke at openjdk.org  Fri Apr 12 15:21:14 2024
From: duke at openjdk.org (eduardsdv)
Date: Fri, 12 Apr 2024 15:21:14 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v4]
In-Reply-To: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
Message-ID: <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>

> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
> It is now determined before the nodes are removed from the scene graph.
> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
> 
> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.

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

  JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1434/files
  - new: https://git.openjdk.org/jfx/pull/1434/files/09dcc48d..6478f38b

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

  Stats: 143 lines in 1 file changed: 81 ins; 54 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1434.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1434/head:pull/1434

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

From duke at openjdk.org  Fri Apr 12 15:26:48 2024
From: duke at openjdk.org (eduardsdv)
Date: Fri, 12 Apr 2024 15:26:48 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v4]
In-Reply-To: <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
Message-ID: <QAIBmZ4C-gmnKlNiXx-8IOGWjxmVCcjU89K9OccEIJI=.f9172fcd-a1d8-4733-b1e6-6a53d66921f2@github.com>

On Fri, 12 Apr 2024 15:21:14 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane

I solved the issue with applying of CSS by introducing a 'shadow' pane (``overflowBox``).
This pane contains the overflowed items all the time unless overflow menu is open.
After the overflow menu is closed the items are moved back the to the pane.

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2051974734

From angorya at openjdk.org  Fri Apr 12 18:26:52 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Apr 2024 18:26:52 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v4]
In-Reply-To: <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
Message-ID: <LD42T4V-52bxWl3gumMEfS2ervD-qGrtqdnM_gKZzmI=.87b54db1-9496-4436-bf88-e120dc272af1@github.com>

On Fri, 12 Apr 2024 15:21:14 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane

It looks like the flicker issue has been resolved.

There might be an issue with runtime style update which the proposed solution may not handle (I can't readily test it right now, but I think it is a valid concern).

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 570:

> 568:         // The overflowBox must have the same style classes, otherwise the overflow items may get wrong values.
> 569:         overflowBox.setId(box.getId());
> 570:         overflowBox.getStyleClass().addAll(box.getStyleClass());

I think this solution might not be the best one.  One reason is that both the `id` property and the style class list can change at runtime, and this code does not handle that (using `bind()` and `bindContent()` for property and the observable list correspondingly).

On a higher level, do you think it is possible to simply lay out hidden buttons using width/height of 0 instead?  This way there will be no need for the `overflowBox` and its maintenance.

What do you think?

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 783:

> 781:                     CustomMenuItem customMenuItem = new CustomMenuItem(node);
> 782: 
> 783:                     // RT-36455:

since we moved this code, could we change this line to
`     // RT-36455 (JDK-8096292):`

and also make sure that this change introduced no regression w.r.t. JDK-8096292 ?
(My limited testing indicates that it still works as expected, but please double check)

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

PR Review: https://git.openjdk.org/jfx/pull/1434#pullrequestreview-1998162402
PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1562978834
PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1562984112

From angorya at openjdk.org  Fri Apr 12 22:47:21 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 12 Apr 2024 22:47:21 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v13]
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.bcf68b38-b200-4178-94d7-c57890f9c84d@github.com>
Message-ID: <2GY47oVE9mCl0FLEyRr8FvMsZVR1z7Jp5K45vCTx668=.463f1350-f524-4e14-87f9-618c2c1b6463@github.com>

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge branch 'master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - tolerance
 - Merge remote-tracking branch 'origin/master' into 8299753.resize
 - undo merge
 - ... and 22 more: https://git.openjdk.org/jfx/compare/44d53baf...197cfaf0

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

Changes: https://git.openjdk.org/jfx/pull/1156/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1156&range=12
  Stats: 479 lines in 9 files changed: 165 ins; 222 del; 92 mod
  Patch: https://git.openjdk.org/jfx/pull/1156.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1156/head:pull/1156

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

From almatvee at openjdk.org  Sat Apr 13 01:41:10 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 13 Apr 2024 01:41:10 GMT
Subject: RFR: 8328603: HLS video stream fails to render consistently
Message-ID: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com>

- When video fails to render AVFoundation outputs frame in `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` format which is not supported. We do force format change after that to `kCVPixelFormatType_422YpCbCr8`, but AVFoundation does not provides any video frames after format change. Not sure why it happens.
- When video worked for stream in this issue, then AVFoundation was using `kCVPixelFormatType_422YpCbCr8` for some reason instead of `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange`.
- I tested format fallback from `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` to `kCVPixelFormatType_422YpCbCr8` manually and many streams I tried works fine, except one reported in this bug.
- If AVFoundation is initialized with list of formats JavaFX Media rendering supports, then this issue is no longer reproducible.
- Fixed by providing list of supported formats to AVFoundation.
- Removed unused variable `response`.
- Tested with all streams I have and no issues found.

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

Commit messages:
 - 8328603: HLS video stream fails to render consistently

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

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

From duke at openjdk.org  Sat Apr 13 08:09:52 2024
From: duke at openjdk.org (Lihang Xu)
Date: Sat, 13 Apr 2024 08:09:52 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v15]
In-Reply-To: <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
Message-ID: <15keyVaTOkCEQ_HJXyYK9Xyv20WBoJNsr218PwVxQdw=.242ac88b-bf07-475c-894a-56f184584230@github.com>

On Sat, 10 Feb 2024 17:24:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change test to use the more common Arial font and add assumptions

Hi there, could this fix be merged? As I am creating a typesetting tool, this is very important for it. https://github.com/xulihang/ImageTrans-docs/issues/482

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2053566232

From kpk at openjdk.org  Mon Apr 15 09:59:49 2024
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 15 Apr 2024 09:59:49 GMT
Subject: RFR: 8092102: Labeled: truncated property [v9]
In-Reply-To: <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
Message-ID: <QE_xNeYfexIq3hEa6L3DWa4nUUtaSm7d1FYRrg42YQA=.7c3462db-8b56-4585-81ca-2d68eae5e8b4@github.com>

On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width.
>> 
>> The new property reacts to changes in the following properties:
>> - ellipsisString
>> - font
>> - height
>> - text
>> - width
>> - wrapText
>> 
>> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code.
>> 
>> **Alternative**
>> 
>> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass.  What is the benefit of adding this functionality to the core?
>> 
>> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126).  The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone.
>> 
>> **See Also**
>> 
>> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated
>> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...)
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - missing )
>  - review comments
>  - Merge branch 'master' into 8092102.truncated
>  - add exports
>  - added unit tests
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - Merge branch 'master' into 8092102.truncated
>  - labeled helper
>  - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e

LGTM

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

Marked as reviewed by kpk (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1389#pullrequestreview-2000588287

From kpk at openjdk.org  Mon Apr 15 09:59:50 2024
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 15 Apr 2024 09:59:50 GMT
Subject: RFR: 8092102: Labeled: truncated property [v8]
In-Reply-To: <8mpifOecQbU9ZK2ind7xIt_Ldpnv3ug0yykXEykAOc8=.441c417f-95a0-4791-a737-139aaa7a2b69@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <sIX1EzEt0oM4gBG_y4u_upJUxl1Kg-pmYr4zDXScnCM=.2edca975-af0b-4643-adc0-62faad041c7d@github.com>
 <8VCkcxrg8ZwH-FMW7VjXcJ0lkFg0zGLCmlNPq6ysZC8=.758c22dd-7a7e-46e3-ad50-578a396bd6f0@github.com>
 <8mpifOecQbU9ZK2ind7xIt_Ldpnv3ug0yykXEykAOc8=.441c417f-95a0-4791-a737-139aaa7a2b69@github.com>
Message-ID: <IRXNwCoKz1B32VD44wJL5ufwB952NmEo-2_XAefRN2s=.a6454679-0848-41fe-9f78-f59656b61c79@github.com>

On Wed, 10 Apr 2024 21:28:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/LabeledHelper.java line 38:
>> 
>>> 36:         /**
>>> 37:          * Returns true when the Labeled must compute the actual content width in computePrefWidth().
>>> 38:          * @return whether computePrefWidth() must compute the actual content width
>> 
>> Do you think re-wording the sentence to explain when this function returns true/false would be better here?
>
> is the new version clearer?

Yes. Thanks for updating.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1389#discussion_r1565508320

From duke at openjdk.org  Mon Apr 15 12:31:50 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 12:31:50 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v4]
In-Reply-To: <LD42T4V-52bxWl3gumMEfS2ervD-qGrtqdnM_gKZzmI=.87b54db1-9496-4436-bf88-e120dc272af1@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
 <LD42T4V-52bxWl3gumMEfS2ervD-qGrtqdnM_gKZzmI=.87b54db1-9496-4436-bf88-e120dc272af1@github.com>
Message-ID: <S0GqZsXOgOHfZUfUQZTygzM4uBW1ouPuT7TtjwADAyo=.8f67d77c-60eb-418e-abe7-7a6cf8831b56@github.com>

On Fri, 12 Apr 2024 18:15:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 783:
> 
>> 781:                     CustomMenuItem customMenuItem = new CustomMenuItem(node);
>> 782: 
>> 783:                     // RT-36455:
> 
> since we moved this code, could we change this line to
> `     // RT-36455 (JDK-8096292):`
> 
> and also make sure that this change introduced no regression w.r.t. JDK-8096292 ?
> (My limited testing indicates that it still works as expected, but please double check)

I tested it with the Modena application. The bug is not reproducible.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1565712081

From duke at openjdk.org  Mon Apr 15 12:38:15 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 12:38:15 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v5]
In-Reply-To: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
Message-ID: <X6hES2M-LYeSbE01sGyOdcgvbU1SWKcaKwLOn-_d9LI=.45a617d2-9739-44c2-ad9b-4494f45271ca@github.com>

> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
> It is now determined before the nodes are removed from the scene graph.
> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
> 
> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.

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

 - JDK-8328577: Update comment
 - JDK-8328577: Bind style related properties

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1434/files
  - new: https://git.openjdk.org/jfx/pull/1434/files/6478f38b..e63b0b9b

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

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

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

From duke at openjdk.org  Mon Apr 15 14:07:03 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 14:07:03 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v4]
In-Reply-To: <LD42T4V-52bxWl3gumMEfS2ervD-qGrtqdnM_gKZzmI=.87b54db1-9496-4436-bf88-e120dc272af1@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
 <LD42T4V-52bxWl3gumMEfS2ervD-qGrtqdnM_gKZzmI=.87b54db1-9496-4436-bf88-e120dc272af1@github.com>
Message-ID: <N1ondVaAbWc1RmLHJj7lQLrhsXHA51T8fU-u3hUJoC4=.30d8c876-faaf-48d7-9a0b-4e482857c666@github.com>

On Fri, 12 Apr 2024 18:11:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8328577: Collect overflowed items in a shadow (overflowBox) pane
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 570:
> 
>> 568:         // The overflowBox must have the same style classes, otherwise the overflow items may get wrong values.
>> 569:         overflowBox.setId(box.getId());
>> 570:         overflowBox.getStyleClass().addAll(box.getStyleClass());
> 
> I think this solution might not be the best one.  One reason is that both the `id` property and the style class list can change at runtime, and this code does not handle that (using `bind()` and `bindContent()` for property and the observable list correspondingly).
> 
> On a higher level, do you think it is possible to simply lay out hidden buttons using width/height of 0 instead?  This way there will be no need for the `overflowBox` and its maintenance.
> 
> What do you think?

I agree with the first point. The style related properties are now bound. See the commit [92921e3](https://github.com/openjdk/jfx/pull/1434/commits/92921e36987e3cd1cfe78c17b464547aa73d241e)

As for the second point, this does work in a quick test. But I have some concerns.
The nodes can define minWidth/minHeight, so 0 is not a valid value and can lead to errors in app code.

You could move the nodes outside the visible area instead, but the nodes can have effects and margins, these can still be visible if they are large enough. Furthermore, in order for the toolbar to continue to return correct values for prefWidth(-1)/prefHeight(-1), we need to use a clip node.

I honestly can't validate that this doesn't lead to any errors.

E.g. shadow of the button, that is moved outside visible area:
![image](https://github.com/openjdk/jfx/assets/53449139/8f4009b0-b68f-4bb0-8085-01a33f7cff54)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1565855543

From duke at openjdk.org  Mon Apr 15 14:14:48 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 14:14:48 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v4]
In-Reply-To: <S0GqZsXOgOHfZUfUQZTygzM4uBW1ouPuT7TtjwADAyo=.8f67d77c-60eb-418e-abe7-7a6cf8831b56@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <Tcj8syDGzzemLeDKGWGAQ2exSBmuNt5fHnilvEdUFlY=.8d1ce077-2c97-4432-a5e7-1a963a8c1069@github.com>
 <LD42T4V-52bxWl3gumMEfS2ervD-qGrtqdnM_gKZzmI=.87b54db1-9496-4436-bf88-e120dc272af1@github.com>
 <S0GqZsXOgOHfZUfUQZTygzM4uBW1ouPuT7TtjwADAyo=.8f67d77c-60eb-418e-abe7-7a6cf8831b56@github.com>
Message-ID: <xFf3Cl_WVCoOGOUUwCNerM4Bij0VqmCCXPBe3Vnb-6o=.d7f95f3c-b350-4715-8c10-401bb3e153f4@github.com>

On Mon, 15 Apr 2024 12:28:55 GMT, eduardsdv <duke at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 783:
>> 
>>> 781:                     CustomMenuItem customMenuItem = new CustomMenuItem(node);
>>> 782: 
>>> 783:                     // RT-36455:
>> 
>> since we moved this code, could we change this line to
>> `     // RT-36455 (JDK-8096292):`
>> 
>> and also make sure that this change introduced no regression w.r.t. JDK-8096292 ?
>> (My limited testing indicates that it still works as expected, but please double check)
>
> I tested it with the Modena application. The bug is not reproducible.

I changed the comment. See [e63b0b9](https://github.com/openjdk/jfx/pull/1434/commits/e63b0b9b313131460fbe154ce8af164a3a97672f)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1565868897

From angorya at openjdk.org  Mon Apr 15 15:27:03 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Apr 2024 15:27:03 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v5]
In-Reply-To: <X6hES2M-LYeSbE01sGyOdcgvbU1SWKcaKwLOn-_d9LI=.45a617d2-9739-44c2-ad9b-4494f45271ca@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <X6hES2M-LYeSbE01sGyOdcgvbU1SWKcaKwLOn-_d9LI=.45a617d2-9739-44c2-ad9b-4494f45271ca@github.com>
Message-ID: <NboB2xu6WOIkAP-_MPyMqeE02X22ElBHwBG9Jksm-70=.37651450-3748-4311-a29a-5e5f000d481c@github.com>

On Mon, 15 Apr 2024 12:38:15 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JDK-8328577: Update comment
>  - JDK-8328577: Bind style related properties

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 573:

> 571:         overflowBox.idProperty().bind(box.idProperty());
> 572:         overflowBox.getStyleClass().setAll(box.getStyleClass());
> 573:         box.getStyleClass().addListener((ListChangeListener<? super String>) change -> overflowBox.getStyleClass().setAll(change.getList()));

I think what you need here (and below) is `Bindings.bindContent(List, ObservableList)`

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 575:

> 573:         box.getStyleClass().addListener((ListChangeListener<? super String>) change -> overflowBox.getStyleClass().setAll(change.getList()));
> 574:         overflowBox.getStylesheets().setAll(box.getStylesheets());
> 575:         box.getStylesheets().addListener((ListChangeListener<? super String>) change -> overflowBox.getStylesheets().setAll(change.getList()));

this is interesting.  

isn't `overflowBox` a sibling of `box`, having the same parent, and therefore inheriting the same set of stylesheets from the parent `Scene`?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1565958505
PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1565977562

From duke at openjdk.org  Mon Apr 15 15:41:19 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 15:41:19 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
Message-ID: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>

> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
> It is now determined before the nodes are removed from the scene graph.
> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
> 
> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.

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

  JDK-8328577: Refactor and fix binding of style related properties

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1434/files
  - new: https://git.openjdk.org/jfx/pull/1434/files/e63b0b9b..9b159e3b

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

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

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

From duke at openjdk.org  Mon Apr 15 15:41:20 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 15:41:20 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v5]
In-Reply-To: <NboB2xu6WOIkAP-_MPyMqeE02X22ElBHwBG9Jksm-70=.37651450-3748-4311-a29a-5e5f000d481c@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <X6hES2M-LYeSbE01sGyOdcgvbU1SWKcaKwLOn-_d9LI=.45a617d2-9739-44c2-ad9b-4494f45271ca@github.com>
 <NboB2xu6WOIkAP-_MPyMqeE02X22ElBHwBG9Jksm-70=.37651450-3748-4311-a29a-5e5f000d481c@github.com>
Message-ID: <P_KPgU6ldZx22lrYpKyRvEsZ0sglsgecnKX-omWeI-0=.5906b7ff-1a13-4390-861d-1366c075d05d@github.com>

On Mon, 15 Apr 2024 15:10:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> eduardsdv has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - JDK-8328577: Update comment
>>  - JDK-8328577: Bind style related properties
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 573:
> 
>> 571:         overflowBox.idProperty().bind(box.idProperty());
>> 572:         overflowBox.getStyleClass().setAll(box.getStyleClass());
>> 573:         box.getStyleClass().addListener((ListChangeListener<? super String>) change -> overflowBox.getStyleClass().setAll(change.getList()));
> 
> I think what you need here (and below) is `Bindings.bindContent(List, ObservableList)`

Good suggestion

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1565996530

From duke at openjdk.org  Mon Apr 15 15:45:00 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 15 Apr 2024 15:45:00 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v5]
In-Reply-To: <NboB2xu6WOIkAP-_MPyMqeE02X22ElBHwBG9Jksm-70=.37651450-3748-4311-a29a-5e5f000d481c@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <X6hES2M-LYeSbE01sGyOdcgvbU1SWKcaKwLOn-_d9LI=.45a617d2-9739-44c2-ad9b-4494f45271ca@github.com>
 <NboB2xu6WOIkAP-_MPyMqeE02X22ElBHwBG9Jksm-70=.37651450-3748-4311-a29a-5e5f000d481c@github.com>
Message-ID: <3sntC9lIyezepl0GpH_sE49Z82dNVssWi2J2_MS6efU=.06417ee3-a087-4491-9416-d1b66a3f766b@github.com>

On Mon, 15 Apr 2024 15:24:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> eduardsdv has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - JDK-8328577: Update comment
>>  - JDK-8328577: Bind style related properties
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 575:
> 
>> 573:         box.getStyleClass().addListener((ListChangeListener<? super String>) change -> overflowBox.getStyleClass().setAll(change.getList()));
>> 574:         overflowBox.getStylesheets().setAll(box.getStylesheets());
>> 575:         box.getStylesheets().addListener((ListChangeListener<? super String>) change -> overflowBox.getStylesheets().setAll(change.getList()));
> 
> this is interesting.  
> 
> isn't `overflowBox` a sibling of `box`, having the same parent, and therefore inheriting the same set of stylesheets from the parent `Scene`?

In addition to those from the scene, each ``Parent`` can have its own stylesheets.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1566002787

From angorya at openjdk.org  Mon Apr 15 15:57:00 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Apr 2024 15:57:00 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 575:

> 573:         Bindings.bindContent(overflowBox.getStyleClass(), box.getStyleClass());
> 574:         Bindings.bindContent(overflowBox.getStylesheets(), box.getStylesheets());
> 575:         box.getPseudoClassStates().addListener((SetChangeListener<? super PseudoClass>) change -> {

you can also use Bindings.bindContent(Set,ObservableSet)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1566011508

From angorya at openjdk.org  Mon Apr 15 15:57:00 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 15 Apr 2024 15:57:00 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v5]
In-Reply-To: <3sntC9lIyezepl0GpH_sE49Z82dNVssWi2J2_MS6efU=.06417ee3-a087-4491-9416-d1b66a3f766b@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <X6hES2M-LYeSbE01sGyOdcgvbU1SWKcaKwLOn-_d9LI=.45a617d2-9739-44c2-ad9b-4494f45271ca@github.com>
 <NboB2xu6WOIkAP-_MPyMqeE02X22ElBHwBG9Jksm-70=.37651450-3748-4311-a29a-5e5f000d481c@github.com>
 <3sntC9lIyezepl0GpH_sE49Z82dNVssWi2J2_MS6efU=.06417ee3-a087-4491-9416-d1b66a3f766b@github.com>
Message-ID: <Gk9zIrS4ZM3rF3vCth4zXX1owae5D61-KLzkgAor8GA=.dc598bd8-e43c-4294-a9b7-2c439a16a4c1@github.com>

On Mon, 15 Apr 2024 15:42:27 GMT, eduardsdv <duke at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 575:
>> 
>>> 573:         box.getStyleClass().addListener((ListChangeListener<? super String>) change -> overflowBox.getStyleClass().setAll(change.getList()));
>>> 574:         overflowBox.getStylesheets().setAll(box.getStylesheets());
>>> 575:         box.getStylesheets().addListener((ListChangeListener<? super String>) change -> overflowBox.getStylesheets().setAll(change.getList()));
>> 
>> this is interesting.  
>> 
>> isn't `overflowBox` a sibling of `box`, having the same parent, and therefore inheriting the same set of stylesheets from the parent `Scene`?
>
> In addition to those from the scene, each ``Parent`` can have its own stylesheets.

OK, you are correct - the `box` is technically visible via node lookup by the "content" style, so the app developer can attach a stylesheet to it (why they would do it is another question, I am sure there are many other places where doing so would break the code).
And we are not creating leaks because both nodes are siblings.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1566017946

From kcr at openjdk.org  Tue Apr 16 14:15:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:15:09 GMT
Subject: RFR: Merge c721a4be906cf3b7b43b779e33eaee4c80bbfa25
Message-ID: <k2l0BxxMBmuria_IIJaD2DWJBgVZ2af4tRLTVQtkbXw=.dcf7e18d-fed8-4ea2-8fb6-8dbe9f136d6e@github.com>

Clean merge of April CPU content into `jfx:master`.

Reviewer: @johanvos

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

Commit messages:
 - Merge branch 'jfx23-cpu-2404' into merge-jfx23-cpu-2404
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8322236: Build failure after JDK-8313064
 - ... and 8 more: https://git.openjdk.org/jfx/compare/44d53baf...b3b0e5ed

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx/pull/1441/files
  Stats: 592 lines in 20 files changed: 426 ins; 49 del; 117 mod
  Patch: https://git.openjdk.org/jfx/pull/1441.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1441/head:pull/1441

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

From kcr at openjdk.org  Tue Apr 16 14:15:30 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:15:30 GMT
Subject: [jfx22u] RFR: 8329794: Create release notes for JavaFX 22.0.1
Message-ID: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>

Release notes for JavaFX 22.0.1.

Notes to reviewers:

I used the following filter to pick the issues:

https://bugs.openjdk.org/issues/?filter=45526

The original filter, with the backport IDs, is here:

https://bugs.openjdk.org/issues/?filter=45525

As usual, I excluded test bugs, cleanup bugs, etc.

NOTE: Once the CPU release ships on 2024-04-16, I will add any security bugs and make this PR `rfr`.

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

Commit messages:
 - Add CPU content
 - 8329794: Create release notes for JavaFX 22.0.1

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

PR: https://git.openjdk.org/jfx22u/pull/24

From kcr at openjdk.org  Tue Apr 16 14:15:30 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:15:30 GMT
Subject: [jfx22u] RFR: 8329794: Create release notes for JavaFX 22.0.1
In-Reply-To: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>
References: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>
Message-ID: <i762-nI6pG8G3zb0lWirW1vihazX6fwvPUN5jfSLz00=.61ee6883-a220-45ff-a9c2-6d9a0701d9ac@github.com>

On Fri, 5 Apr 2024 18:40:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 22.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=45526
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=45525
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2024-04-16, I will add any security bugs and make this PR `rfr`.

Reviewers: @johanvos @abhinayagarwal

@johanvos @abhinayagarwal this is now ready for review

@johanvos can you also `/approve yes` this bug fix?

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

PR Comment: https://git.openjdk.org/jfx22u/pull/24#issuecomment-2040421679
PR Comment: https://git.openjdk.org/jfx22u/pull/24#issuecomment-2059198211

From kcr at openjdk.org  Tue Apr 16 14:17:06 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:17:06 GMT
Subject: [jfx22u] RFR: Merge 2d08a2c79abb3f6330de23b9d4c209cf5f43499b
Message-ID: <Q_AS8iivXat2qSTK5CvgS7H3E3S1t5qih3fQ6PV8yEU=.cbe79503-6260-4454-ab77-1f3edca2fc51@github.com>

Clean merge of April CPU content into `jfx22u:master`.

Reviewer: @johanvos

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

Commit messages:
 - Merge branch 'jfx22.0.1' into merge-jfx22.0.1
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 10 more: https://git.openjdk.org/jfx22u/compare/1e21a6f3...92c8159d

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx22u/pull/26/files
  Stats: 592 lines in 20 files changed: 426 ins; 49 del; 117 mod
  Patch: https://git.openjdk.org/jfx22u/pull/26.diff
  Fetch: git fetch https://git.openjdk.org/jfx22u.git pull/26/head:pull/26

PR: https://git.openjdk.org/jfx22u/pull/26

From jvos at openjdk.org  Tue Apr 16 14:21:02 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:21:02 GMT
Subject: RFR: Merge c721a4be906cf3b7b43b779e33eaee4c80bbfa25
In-Reply-To: <k2l0BxxMBmuria_IIJaD2DWJBgVZ2af4tRLTVQtkbXw=.dcf7e18d-fed8-4ea2-8fb6-8dbe9f136d6e@github.com>
References: <k2l0BxxMBmuria_IIJaD2DWJBgVZ2af4tRLTVQtkbXw=.dcf7e18d-fed8-4ea2-8fb6-8dbe9f136d6e@github.com>
Message-ID: <e4q_qUeNOkwmJp70Du2G3T2iULBPEUokHBe2-e8ZJXk=.5806f2a5-2ce1-477b-a62e-9605b56fa924@github.com>

On Tue, 16 Apr 2024 14:10:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of April CPU content into `jfx:master`.
> 
> Reviewer: @johanvos

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1441#pullrequestreview-2003793361

From jvos at openjdk.org  Tue Apr 16 14:25:08 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:25:08 GMT
Subject: [jfx17u] RFR: Merge 7387036f87b0ad9046ddb3955ebb5ce7040f77b2
Message-ID: <HI7fRrN8Fto5LhFKCBM4dMssXKKsguFRTT0YmerPJO8=.22b76712-93de-4c88-a7bb-8dd964783af4@github.com>

Almost clean merge of April CPU content into jfx17u:master

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

Commit messages:
 - 8322236: Build failure after JDK-8313064
 - 8313064: General enhancements of image handling
 - 8313040: Enhanced Font handling
 - 8313072: Enhanced handling of Fonts
 - 8320441: Additonal fix for JDK-8313032
 - 8313032: Enhanced handling of Glass

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx17u/pull/188/files
  Stats: 578 lines in 20 files changed: 417 ins; 47 del; 114 mod
  Patch: https://git.openjdk.org/jfx17u/pull/188.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/188/head:pull/188

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

From jvos at openjdk.org  Tue Apr 16 14:26:05 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:26:05 GMT
Subject: [jfx21u] RFR: Merge e8c277de53545780662a0fa6a35259a540951a14
Message-ID: <7pYnDLE-31el92X2su7NhUbQxj4YuaDipjMNmpRUf6M=.d924f285-b26b-4063-9a8a-1d61d1091b49@github.com>

Clean merge of April CPU content into jfx21u

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

Commit messages:
 - 8322236: Build failure after JDK-8313064
 - 8313064: General enhancements of image handling
 - 8313040: Enhanced Font handling
 - 8313072: Enhanced handling of Fonts
 - 8320441: Additonal fix for JDK-8313032
 - 8313032: Enhanced handling of Glass

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx21u/pull/55/files
  Stats: 592 lines in 20 files changed: 426 ins; 49 del; 117 mod
  Patch: https://git.openjdk.org/jfx21u/pull/55.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/55/head:pull/55

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

From jvos at openjdk.org  Tue Apr 16 14:27:03 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:27:03 GMT
Subject: [jfx22u] RFR: 8329794: Create release notes for JavaFX 22.0.1
In-Reply-To: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>
References: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>
Message-ID: <Cgh-FFLZ8nx1OR7KZbUkqMadzAegXAd4_I7oESYF-_I=.259d87ec-bff6-4470-9ab7-b2fd2f38be4b@github.com>

On Fri, 5 Apr 2024 18:40:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 22.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=45526
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=45525
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2024-04-16, I will add any security bugs and make this PR `rfr`.

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx22u/pull/24#pullrequestreview-2003810815

From jvos at openjdk.org  Tue Apr 16 14:27:03 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:27:03 GMT
Subject: [jfx22u] RFR: Merge 2d08a2c79abb3f6330de23b9d4c209cf5f43499b
In-Reply-To: <Q_AS8iivXat2qSTK5CvgS7H3E3S1t5qih3fQ6PV8yEU=.cbe79503-6260-4454-ab77-1f3edca2fc51@github.com>
References: <Q_AS8iivXat2qSTK5CvgS7H3E3S1t5qih3fQ6PV8yEU=.cbe79503-6260-4454-ab77-1f3edca2fc51@github.com>
Message-ID: <7q_R9BQ2N9AjwoPu-uUPAyoNnfenUrBg6MBNoRsE0Ec=.b91ae1eb-c2fa-4c9e-ac4e-03e975401293@github.com>

On Tue, 16 Apr 2024 14:11:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of April CPU content into `jfx22u:master`.
> 
> Reviewer: @johanvos

Marked as reviewed by jvos (Reviewer).

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

PR Review: https://git.openjdk.org/jfx22u/pull/26#pullrequestreview-2003809471

From kcr at openjdk.org  Tue Apr 16 14:32:03 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:32:03 GMT
Subject: Integrated: Merge c721a4be906cf3b7b43b779e33eaee4c80bbfa25
In-Reply-To: <k2l0BxxMBmuria_IIJaD2DWJBgVZ2af4tRLTVQtkbXw=.dcf7e18d-fed8-4ea2-8fb6-8dbe9f136d6e@github.com>
References: <k2l0BxxMBmuria_IIJaD2DWJBgVZ2af4tRLTVQtkbXw=.dcf7e18d-fed8-4ea2-8fb6-8dbe9f136d6e@github.com>
Message-ID: <O0nhgWlw_9Q0JNx1YVjRgd3VtuOY980vW6hDP5mkvBY=.0cbac2cd-a06e-4593-9e76-49e9c3b6e512@github.com>

On Tue, 16 Apr 2024 14:10:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of April CPU content into `jfx:master`.
> 
> Reviewer: @johanvos

This pull request has now been integrated.

Changeset: f27077b9
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f27077b958145aa3a1991cdf7749505b24994709
Stats:     592 lines in 20 files changed: 426 ins; 49 del; 117 mod

Merge

Reviewed-by: jvos

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

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

From kcr at openjdk.org  Tue Apr 16 14:33:05 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:33:05 GMT
Subject: [jfx22u] Integrated: Merge 2d08a2c79abb3f6330de23b9d4c209cf5f43499b
In-Reply-To: <Q_AS8iivXat2qSTK5CvgS7H3E3S1t5qih3fQ6PV8yEU=.cbe79503-6260-4454-ab77-1f3edca2fc51@github.com>
References: <Q_AS8iivXat2qSTK5CvgS7H3E3S1t5qih3fQ6PV8yEU=.cbe79503-6260-4454-ab77-1f3edca2fc51@github.com>
Message-ID: <Ap3IaeWppCM8pjjxwybLfAf6-he2qGUQnv6DyrlKbhY=.360eaa6a-7acc-4a42-ba3b-d07f2425d21a@github.com>

On Tue, 16 Apr 2024 14:11:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge of April CPU content into `jfx22u:master`.
> 
> Reviewer: @johanvos

This pull request has now been integrated.

Changeset: 41f04ee1
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx22u/commit/41f04ee1189851d7ed0355497dec99a51b2fecc6
Stats:     592 lines in 20 files changed: 426 ins; 49 del; 117 mod

Merge

Reviewed-by: jvos

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

PR: https://git.openjdk.org/jfx22u/pull/26

From jvos at openjdk.org  Tue Apr 16 14:51:27 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:51:27 GMT
Subject: [jfx21u] RFR: Merge e8c277de53545780662a0fa6a35259a540951a14 [v2]
In-Reply-To: <7pYnDLE-31el92X2su7NhUbQxj4YuaDipjMNmpRUf6M=.d924f285-b26b-4063-9a8a-1d61d1091b49@github.com>
References: <7pYnDLE-31el92X2su7NhUbQxj4YuaDipjMNmpRUf6M=.d924f285-b26b-4063-9a8a-1d61d1091b49@github.com>
Message-ID: <m5AZ5OZH-LAuo6q5K9YWWpPbA7uJGyRmbI0Em1EAIEc=.1f70ae79-ea24-4f81-afe5-329cf778a732@github.com>

> Clean merge of April CPU content into jfx21u

Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jfx21u/pull/55/files
  - new: https://git.openjdk.org/jfx21u/pull/55/files/e8c277de..e8c277de

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

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

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

From kcr at openjdk.org  Tue Apr 16 14:51:27 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 14:51:27 GMT
Subject: [jfx21u] RFR: Merge e8c277de53545780662a0fa6a35259a540951a14 [v2]
In-Reply-To: <m5AZ5OZH-LAuo6q5K9YWWpPbA7uJGyRmbI0Em1EAIEc=.1f70ae79-ea24-4f81-afe5-329cf778a732@github.com>
References: <7pYnDLE-31el92X2su7NhUbQxj4YuaDipjMNmpRUf6M=.d924f285-b26b-4063-9a8a-1d61d1091b49@github.com>
 <m5AZ5OZH-LAuo6q5K9YWWpPbA7uJGyRmbI0Em1EAIEc=.1f70ae79-ea24-4f81-afe5-329cf778a732@github.com>
Message-ID: <el0gP158V_ZUKlQRzSzVvhz5t5YAAAlYz728Hrot9gQ=.234dce3f-ee3d-466f-8021-02eada787f34@github.com>

On Tue, 16 Apr 2024 14:48:06 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Clean merge of April CPU content into jfx21u
>
> Johan Vos 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.

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx21u/pull/55#pullrequestreview-2003870455

From jvos at openjdk.org  Tue Apr 16 14:51:27 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 14:51:27 GMT
Subject: [jfx21u] Integrated: Merge e8c277de53545780662a0fa6a35259a540951a14
In-Reply-To: <7pYnDLE-31el92X2su7NhUbQxj4YuaDipjMNmpRUf6M=.d924f285-b26b-4063-9a8a-1d61d1091b49@github.com>
References: <7pYnDLE-31el92X2su7NhUbQxj4YuaDipjMNmpRUf6M=.d924f285-b26b-4063-9a8a-1d61d1091b49@github.com>
Message-ID: <7-MHUE9SCqOou5BxsQe-t_SANnu6z3M10BwbsbERgQI=.5eae0401-bd23-4b7d-a8f8-d8b05697bf01@github.com>

On Tue, 16 Apr 2024 14:18:57 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Clean merge of April CPU content into jfx21u

This pull request has now been integrated.

Changeset: f26b3506
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/f26b3506a96d2c09a3304948555ee487f0746a9c
Stats:     592 lines in 20 files changed: 426 ins; 49 del; 117 mod

Merge

Reviewed-by: kcr

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

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

From kpk at openjdk.org  Tue Apr 16 14:52:03 2024
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 16 Apr 2024 14:52:03 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
 <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
Message-ID: <H_AkH4LgLONF6X8jZwHOdJRpmgwNrLkgo_L9BDHNd-c=.0af14674-f495-4a9d-9591-b8cb12c93f83@github.com>

On Wed, 10 Apr 2024 11:47:28 GMT, drmarmac <duke at openjdk.org> wrote:

>> This PR should fix the issue and cover all relevant cases with new tests.
>> 
>> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.
>
> drmarmac has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic

LGTM. This PR fixes both the issues mentioned.
Like @andy-goryachev-oracle  mentioned,  better to describe new behaviour in JDK-8242553 description.

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

Marked as reviewed by kpk (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1431#pullrequestreview-2003877662

From jvos at openjdk.org  Tue Apr 16 15:00:31 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 15:00:31 GMT
Subject: [jfx17u] RFR: Merge 7387036f87b0ad9046ddb3955ebb5ce7040f77b2 [v2]
In-Reply-To: <HI7fRrN8Fto5LhFKCBM4dMssXKKsguFRTT0YmerPJO8=.22b76712-93de-4c88-a7bb-8dd964783af4@github.com>
References: <HI7fRrN8Fto5LhFKCBM4dMssXKKsguFRTT0YmerPJO8=.22b76712-93de-4c88-a7bb-8dd964783af4@github.com>
Message-ID: <z6wGl5M_nT4qBOjOlOtl6oe-3TUofL8unJbcNpU8PNI=.e90f3eb5-64f4-411c-8ec0-30a6695586a2@github.com>

> Almost clean merge of April CPU content into jfx17u:master

Johan Vos has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jfx17u/pull/188/files
  - new: https://git.openjdk.org/jfx17u/pull/188/files/7387036f..7387036f

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

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

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

From kcr at openjdk.org  Tue Apr 16 15:00:32 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 15:00:32 GMT
Subject: [jfx17u] RFR: Merge 7387036f87b0ad9046ddb3955ebb5ce7040f77b2 [v2]
In-Reply-To: <z6wGl5M_nT4qBOjOlOtl6oe-3TUofL8unJbcNpU8PNI=.e90f3eb5-64f4-411c-8ec0-30a6695586a2@github.com>
References: <HI7fRrN8Fto5LhFKCBM4dMssXKKsguFRTT0YmerPJO8=.22b76712-93de-4c88-a7bb-8dd964783af4@github.com>
 <z6wGl5M_nT4qBOjOlOtl6oe-3TUofL8unJbcNpU8PNI=.e90f3eb5-64f4-411c-8ec0-30a6695586a2@github.com>
Message-ID: <xuxsLdWdDNcm63v3GsZCwJJ04OcccQO75Y-1tgKzw38=.76816a94-e9e7-4ab1-8983-8bd28471d14b@github.com>

On Tue, 16 Apr 2024 14:57:15 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Almost clean merge of April CPU content into jfx17u:master
>
> Johan Vos 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.

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx17u/pull/188#pullrequestreview-2003894391

From jvos at openjdk.org  Tue Apr 16 15:00:32 2024
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 16 Apr 2024 15:00:32 GMT
Subject: [jfx17u] Integrated: Merge 7387036f87b0ad9046ddb3955ebb5ce7040f77b2
In-Reply-To: <HI7fRrN8Fto5LhFKCBM4dMssXKKsguFRTT0YmerPJO8=.22b76712-93de-4c88-a7bb-8dd964783af4@github.com>
References: <HI7fRrN8Fto5LhFKCBM4dMssXKKsguFRTT0YmerPJO8=.22b76712-93de-4c88-a7bb-8dd964783af4@github.com>
Message-ID: <yHqXk0FVR0BLjSdDPcN4zbptLVIh3v4nNFL3CipseLo=.0b666409-af8f-4358-b4ee-490f53068122@github.com>

On Tue, 16 Apr 2024 14:20:48 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean merge of April CPU content into jfx17u:master

This pull request has now been integrated.

Changeset: fe602e27
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/fe602e27226000cd9f51299c0edc6fa63d2db680
Stats:     578 lines in 20 files changed: 417 ins; 47 del; 114 mod

Merge

Reviewed-by: kcr

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

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

From kcr at openjdk.org  Tue Apr 16 15:32:00 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 16 Apr 2024 15:32:00 GMT
Subject: [jfx22u] Integrated: 8329794: Create release notes for JavaFX 22.0.1
In-Reply-To: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>
References: <hkraSl_rKAZaai85zqREdNgwwrF0vUt4fVCZy176Hpc=.ee56debe-2d53-4eeb-886f-1fd33c4a2f63@github.com>
Message-ID: <7BPnW16CB7RkFySiE99kYsCeAjXn-sKOpWUeW8PNe-g=.e32ff31c-ce3c-4e44-b55f-3af48301959d@github.com>

On Fri, 5 Apr 2024 18:40:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Release notes for JavaFX 22.0.1.
> 
> Notes to reviewers:
> 
> I used the following filter to pick the issues:
> 
> https://bugs.openjdk.org/issues/?filter=45526
> 
> The original filter, with the backport IDs, is here:
> 
> https://bugs.openjdk.org/issues/?filter=45525
> 
> As usual, I excluded test bugs, cleanup bugs, etc.
> 
> NOTE: Once the CPU release ships on 2024-04-16, I will add any security bugs and make this PR `rfr`.

This pull request has now been integrated.

Changeset: bbad3584
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx22u/commit/bbad35849e5d855fc84a3693c9c41e96cd555dd0
Stats:     35 lines in 1 file changed: 35 ins; 0 del; 0 mod

8329794: Create release notes for JavaFX 22.0.1

Reviewed-by: jvos

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

PR: https://git.openjdk.org/jfx22u/pull/24

From duke at openjdk.org  Tue Apr 16 15:33:07 2024
From: duke at openjdk.org (eduardsdv)
Date: Tue, 16 Apr 2024 15:33:07 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <9XcTWE8xHMcm98Ji4jjf5A102n7aQDOzA2zg7GT7LzY=.927b7ce3-3549-47ec-9e67-fbe5752818bb@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

Can this pull request be merged?

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2059372918

From angorya at openjdk.org  Tue Apr 16 15:39:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Apr 2024 15:39:02 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <9XcTWE8xHMcm98Ji4jjf5A102n7aQDOzA2zg7GT7LzY=.927b7ce3-3549-47ec-9e67-fbe5752818bb@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <9XcTWE8xHMcm98Ji4jjf5A102n7aQDOzA2zg7GT7LzY=.927b7ce3-3549-47ec-9e67-fbe5752818bb@github.com>
Message-ID: <n71Am6EpOrK5voW8gxIDOfMitolayN0vUMfGIJJJqGU=.de8f7d72-aecc-43dd-93fd-cd541e25e4e0@github.com>

On Tue, 16 Apr 2024 15:30:26 GMT, eduardsdv <duke at openjdk.org> wrote:

> Can this pull request be merged?

Almost there: please address the remaining review comments, and we need one more reviewer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2059385959

From duke at openjdk.org  Tue Apr 16 15:57:02 2024
From: duke at openjdk.org (eduardsdv)
Date: Tue, 16 Apr 2024 15:57:02 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
Message-ID: <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>

On Mon, 15 Apr 2024 15:49:04 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8328577: Refactor and fix binding of style related properties
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 575:
> 
>> 573:         Bindings.bindContent(overflowBox.getStyleClass(), box.getStyleClass());
>> 574:         Bindings.bindContent(overflowBox.getStylesheets(), box.getStylesheets());
>> 575:         box.getPseudoClassStates().addListener((SetChangeListener<? super PseudoClass>) change -> {
> 
> you can also use Bindings.bindContent(Set,ObservableSet)

Done. See [92921e3](https://github.com/openjdk/jfx/pull/1434/commits/92921e36987e3cd1cfe78c17b464547aa73d241e)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1567603745

From angorya at openjdk.org  Tue Apr 16 16:00:59 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Apr 2024 16:00:59 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
 <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>
Message-ID: <luj4CJyNYivmDXtCM2AJakb-nASQHBak_ldT7ckOVGw=.a671459d-2dc3-419d-b390-a12920deaae1@github.com>

On Tue, 16 Apr 2024 15:54:11 GMT, eduardsdv <duke at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ToolBarSkin.java line 575:
>> 
>>> 573:         Bindings.bindContent(overflowBox.getStyleClass(), box.getStyleClass());
>>> 574:         Bindings.bindContent(overflowBox.getStylesheets(), box.getStylesheets());
>>> 575:         box.getPseudoClassStates().addListener((SetChangeListener<? super PseudoClass>) change -> {
>> 
>> you can also use Bindings.bindContent(Set,ObservableSet)
>
> Done. See [92921e3](https://github.com/openjdk/jfx/pull/1434/commits/92921e36987e3cd1cfe78c17b464547aa73d241e)

line 575 still uses a listener instead of Bindings.bindContent(**Set,ObservableSet**)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1567609882

From angorya at openjdk.org  Tue Apr 16 16:06:58 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Apr 2024 16:06:58 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <PaojUazhH9Oowb9feEVPS5tjtVi7CC_5eLYn6_cITqw=.8b689f50-e1ac-47fb-8f6a-c4a9d1997840@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

@karthikpandelu or @aghaisas could one of you be the second reviewer?

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2059440532

From duke at openjdk.org  Tue Apr 16 16:06:59 2024
From: duke at openjdk.org (eduardsdv)
Date: Tue, 16 Apr 2024 16:06:59 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <luj4CJyNYivmDXtCM2AJakb-nASQHBak_ldT7ckOVGw=.a671459d-2dc3-419d-b390-a12920deaae1@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
 <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>
 <luj4CJyNYivmDXtCM2AJakb-nASQHBak_ldT7ckOVGw=.a671459d-2dc3-419d-b390-a12920deaae1@github.com>
Message-ID: <zkeg9y_PsDH_B55UF54ju6IqU5nvOLndrIYH-4ghKm4=.b141a530-e653-45bf-a100-17934e22a1ae@github.com>

On Tue, 16 Apr 2024 15:58:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> ~~Done. See [92921e3](https://github.com/openjdk/jfx/pull/1434/commits/92921e36987e3cd1cfe78c17b464547aa73d241e)~~
>
> line 575 still uses a listener instead of Bindings.bindContent(**Set,ObservableSet**)

The ``Node.getPseudoClassStates()`` returns an unmodifiable collection. The bindings would not work. Therefore we need to use a listener and change the pseudo-class-state by using the ``Node.pseudoClassStateChanged(PseudoClass, boolean)`` method.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1567619163

From angorya at openjdk.org  Tue Apr 16 16:10:59 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Apr 2024 16:10:59 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <zkeg9y_PsDH_B55UF54ju6IqU5nvOLndrIYH-4ghKm4=.b141a530-e653-45bf-a100-17934e22a1ae@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
 <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>
 <luj4CJyNYivmDXtCM2AJakb-nASQHBak_ldT7ckOVGw=.a671459d-2dc3-419d-b390-a12920deaae1@github.com>
 <zkeg9y_PsDH_B55UF54ju6IqU5nvOLndrIYH-4ghKm4=.b141a530-e653-45bf-a100-17934e22a1ae@github.com>
Message-ID: <umsc7vOFz_QpzO-DDsxHWuofqY7kMj0J6bICi33qXAs=.c96d6fe4-5073-47b4-9a7e-c2f51328d323@github.com>

On Tue, 16 Apr 2024 16:04:34 GMT, eduardsdv <duke at openjdk.org> wrote:

>> line 575 still uses a listener instead of Bindings.bindContent(**Set,ObservableSet**)
>
> The ``Node.getPseudoClassStates()`` returns an unmodifiable collection. The bindings would not work. Therefore we need to use a listener and change the pseudo-class-state by using the ``Node.pseudoClassStateChanged(PseudoClass, boolean)`` method.

how silly of me!  you are right, of course.  thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1567624662

From duke at openjdk.org  Tue Apr 16 16:21:02 2024
From: duke at openjdk.org (eduardsdv)
Date: Tue, 16 Apr 2024 16:21:02 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <umsc7vOFz_QpzO-DDsxHWuofqY7kMj0J6bICi33qXAs=.c96d6fe4-5073-47b4-9a7e-c2f51328d323@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
 <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>
 <luj4CJyNYivmDXtCM2AJakb-nASQHBak_ldT7ckOVGw=.a671459d-2dc3-419d-b390-a12920deaae1@github.com>
 <zkeg9y_PsDH_B55UF54ju6IqU5nvOLndrIYH-4ghKm4=.b141a530-e653-45bf-a100-17934e22a1ae@github.com>
 <umsc7vOFz_QpzO-DDsxHWuofqY7kMj0J6bICi33qXAs=.c96d6fe4-5073-47b4-9a7e-c2f51328d323@github.com>
Message-ID: <4NthZhnjfLQsrAAB_iklHE9t2AhSxpWjKvsH3AjicVs=.7f3b54d9-085e-4683-ae75-fde5e0211262@github.com>

On Tue, 16 Apr 2024 16:08:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The ``Node.getPseudoClassStates()`` returns an unmodifiable collection. The bindings would not work. Therefore we need to use a listener and change the pseudo-class-state by using the ``Node.pseudoClassStateChanged(PseudoClass, boolean)`` method.
>
> how silly of me!  you are right, of course.  thank you for clarification.

You are welcome, partner :-). 
It was a surprise for me too. 
It's strange, why it needs to be an unmodifiable collection.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1567639883

From angorya at openjdk.org  Tue Apr 16 16:40:01 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Apr 2024 16:40:01 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <4NthZhnjfLQsrAAB_iklHE9t2AhSxpWjKvsH3AjicVs=.7f3b54d9-085e-4683-ae75-fde5e0211262@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <mgUNnvhGITeEeOttKD60UAW-C9wdouIbzlLFMRSqyWo=.dabf715e-960a-46b4-a035-1e353c5594b8@github.com>
 <sB-N7SrJSbWRI1dOIzmCcK5y7XRjJHFqfN6Hi05ZLO0=.fc89a6fa-e06e-402e-aff8-0028a90b182d@github.com>
 <luj4CJyNYivmDXtCM2AJakb-nASQHBak_ldT7ckOVGw=.a671459d-2dc3-419d-b390-a12920deaae1@github.com>
 <zkeg9y_PsDH_B55UF54ju6IqU5nvOLndrIYH-4ghKm4=.b141a530-e653-45bf-a100-17934e22a1ae@github.com>
 <umsc7vOFz_QpzO-DDsxHWuofqY7kMj0J6bICi33qXAs=.c96d6fe4-5073-47b4-9a7e-c2f51328d323@github.com>
 <4NthZhnjfLQsrAAB_iklHE9t2AhSxpWjKvsH3AjicVs=.7f3b54d9-085e-4683-ae75-fde5e0211262@github.com>
Message-ID: <dSILmVLeo2cxN3mEwf7z5WY1tgw5y3zRFeE5YLkEU28=.bb00b369-e588-4aa8-95c3-a51d52133f8c@github.com>

On Tue, 16 Apr 2024 16:18:09 GMT, eduardsdv <duke at openjdk.org> wrote:

>> how silly of me!  you are right, of course.  thank you for clarification.
>
> You are welcome, partner :-). 
> It was a surprise for me too. 
> It's strange, why it needs to be an unmodifiable collection.

good question!  admittedly, it might be easier to control what happens as a result of a change if the only mutator is `pseudoClassStateChanged()` method.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1434#discussion_r1567664132

From angorya at openjdk.org  Tue Apr 16 16:46:02 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 16 Apr 2024 16:46:02 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <IALxCGY8ngSExOSPhPs2L-wQC9-WrBB2VEBTmk36tC8=.d135aa25-edef-4043-8929-1238587628b0@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

Looks good on macOS 14.4.1 M1, works as expected, including the case when the application stylesheet gets reloaded at run time.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1434#pullrequestreview-2004153329

From pavelturk2000 at gmail.com  Wed Apr 17 07:46:33 2024
From: pavelturk2000 at gmail.com (PavelTurk)
Date: Wed, 17 Apr 2024 10:46:33 +0300
Subject: What about 5000 issues?
Message-ID: <97515a62-a065-fe00-6ada-1aaae6a375d1@gmail.com>

Hello all.

I've been using JavaFX for a long time. JavaFX is great, but unfortunately rather buggy.
As a user every time I find a new bug I open new issues. So, I opened many issues.

The problem is that from all my issues only one was resolved. Today I decided to
understand what is going on. I used these settings in JavaFX issue tracker:

https://bugs.openjdk.org/browse/JDK-8329638?jql=project%20%3D%20JDK%20AND%20status%20%3D%20Open%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20javafx%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

That showed that there are? 4835 open issues for JavaFX.

Using these settings https://bugs.openjdk.org/browse/JDK-8328994?jql=project%20%3D%20JDK%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20javafx%20AND%20created%20%3E%3D%202024-03-01%20AND%20created%20%3C%3D%202024-03-31%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

I found that 30 issues were created in March 2024.

And finally, using these github settings https://github.com/openjdk/jfx/commits/master/?since=2024-03-01&until=2024-03-31
I see that about 30 issues were fixed in March 2024.

If all my calculations are correct, then about 5000 (with about 3000 bugs) will never be closed.

Can someone explain why so few resources are allocated to JavaFX? Is Oracle experiencing
financial difficulties and unable to afford more? Are any measures being taken to address the situation?

Best regards, Pavel

From thiago.sayao at gmail.com  Wed Apr 17 10:32:38 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 17 Apr 2024 07:32:38 -0300
Subject: What about 5000 issues?
In-Reply-To: <97515a62-a065-fe00-6ada-1aaae6a375d1@gmail.com>
References: <97515a62-a065-fe00-6ada-1aaae6a375d1@gmail.com>
Message-ID: <CAAP_wu=jMnXThyE7_mP-fhMA=nKP2p7zBGPLVEknahKkQuaMfg@mail.gmail.com>

Pavel,

There are companies that offers paid support, like Gluon.

It's an open source project, you can also submit a fix.


-- Thiago


Em qua., 17 de abr. de 2024 04:46, PavelTurk <pavelturk2000 at gmail.com>
escreveu:

> Hello all.
>
> I've been using JavaFX for a long time. JavaFX is great, but unfortunately
> rather buggy.
> As a user every time I find a new bug I open new issues. So, I opened many
> issues.
>
> The problem is that from all my issues only one was resolved. Today I
> decided to
> understand what is going on. I used these settings in JavaFX issue tracker:
>
>
> https://bugs.openjdk.org/browse/JDK-8329638?jql=project%20%3D%20JDK%20AND%20status%20%3D%20Open%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20javafx%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> That showed that there are  4835 open issues for JavaFX.
>
> Using these settings
> https://bugs.openjdk.org/browse/JDK-8328994?jql=project%20%3D%20JDK%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20javafx%20AND%20created%20%3E%3D%202024-03-01%20AND%20created%20%3C%3D%202024-03-31%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> I found that 30 issues were created in March 2024.
>
> And finally, using these github settings
> https://github.com/openjdk/jfx/commits/master/?since=2024-03-01&until=2024-03-31
> I see that about 30 issues were fixed in March 2024.
>
> If all my calculations are correct, then about 5000 (with about 3000 bugs)
> will never be closed.
>
> Can someone explain why so few resources are allocated to JavaFX? Is
> Oracle experiencing
> financial difficulties and unable to afford more? Are any measures being
> taken to address the situation?
>
> Best regards, Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240417/f911e386/attachment.htm>

From duke at openjdk.org  Thu Apr 18 07:29:09 2024
From: duke at openjdk.org (drmarmac)
Date: Thu, 18 Apr 2024 07:29:09 GMT
Subject: Integrated: 8242553: IntegerSpinner and DoubleSpinner do not wrap
 around values correctly in some cases
In-Reply-To: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
Message-ID: <OifPhGv0eIzep-5KB9h_rQQ4L2mHIe80y8ubirvCLEo=.f82ea069-07fe-4123-814b-75935f47168d@github.com>

On Sun, 24 Mar 2024 15:11:16 GMT, drmarmac <duke at openjdk.org> wrote:

> This PR should fix the issue and cover all relevant cases with new tests.
> 
> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.

This pull request has now been integrated.

Changeset: d03b0028
Author:    drmarmac <6900949+drmarmac at users.noreply.github.com>
Committer: Karthik P K <kpk at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d03b0028d1ebefa00df59a20d6f9a4dd9ac5f033
Stats:     218 lines in 4 files changed: 182 ins; 11 del; 25 mod

8242553: IntegerSpinner and DoubleSpinner do not wrap around values correctly in some cases
8193286: IntegerSpinnerFactory does not wrap value correctly

Reviewed-by: angorya, kpk

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

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

From thiago.sayao at gmail.com  Thu Apr 18 10:41:34 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 18 Apr 2024 07:41:34 -0300
Subject: Possible leak on setOnAction
Message-ID: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>

Hi,

I'm pretty sure setOnAction is holding references.

I have a "Open Windows" menu on my application where it lists the Stages
opened and if you click, it calls stage.toFront():

menuItem.seOnAction(e -> stage.toFront())

I had many crash reports, all OOM. I got the hprof files and analyzed them
- turns out this was holding references to all closed stages.

To fix it, I call setOnAction(null) when the stage is closed.

I will investigate further and provide an example.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240418/85874f80/attachment.htm>

From aghaisas at openjdk.org  Thu Apr 18 11:44:59 2024
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Thu, 18 Apr 2024 11:44:59 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <Er7YuCaWaU8W5xRMwqrS0qFVSyEU9B6OuURLp0GaqdU=.e85349c0-23da-4d5a-ba54-10a7d296a2a2@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

The fix looks straightforward and logical.

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

Marked as reviewed by aghaisas (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1439#pullrequestreview-2008650266

From duke at openjdk.org  Thu Apr 18 12:06:35 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 12:06:35 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything into
 TextField
Message-ID: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>

Fixes https://bugs.openjdk.org/browse/JDK-8330462.

If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

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

Commit messages:
 - 8330462: StringIndexOutOfBoundException when typing anything into TextField

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

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

From angorya at openjdk.org  Thu Apr 18 14:21:07 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Apr 2024 14:21:07 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <hmtzzChsmCznrIoiA9I3LHddDSdmgZRsOd9rTRjP1rI=.19c344c0-340c-4318-940a-b0ada07d8ac1@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

the code looks right, I just can't verify the fix on a real system.

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

PR Comment: https://git.openjdk.org/jfx/pull/1439#issuecomment-2063989210

From angorya at openjdk.org  Thu Apr 18 14:47:01 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Apr 2024 14:47:01 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <HhnK1GDI94Xxww6CrA-v8M1xALN_Coza_-Hl1tanO8w=.802ee383-e99a-4fdb-9631-c2b02a2bc738@github.com>

On Thu, 18 Apr 2024 12:01:52 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

would this fix need to be backported?  how far back?

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2064065589

From angorya at openjdk.org  Thu Apr 18 14:50:06 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Apr 2024 14:50:06 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <EFfV1wGYDKnMZBwGl5UHmGuhhZaWI_ZUjW3wTipAOBQ=.e0baad27-01f9-48bb-b77a-d8535b9da3cd@github.com>

On Thu, 18 Apr 2024 12:01:52 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

The code looks right.  I can't verify the fix with the deepl app.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2009127163

From andy.goryachev at oracle.com  Thu Apr 18 14:54:54 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 18 Apr 2024 14:54:54 +0000
Subject: Possible leak on setOnAction
In-Reply-To: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
Message-ID: <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>

You are correct - the lambda strongly references `stage` and since it is in turn is strongly referenced from the menu item it creates a leak.

The lambda is essentially this:

menuItem.setOnAction(new H(stage));
class $1 implements EventHandler<ActionEvent> {
  private final Stage stage;
  public $1(Stage s) {
    this.stage = s; // holds the reference and causes the leak
  }
  public void handle(ActionEvent ev) {
    stage.toFront();
  }
}

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Thursday, April 18, 2024 at 03:42
To: openjfx-dev <openjfx-dev at openjdk.org>
Subject: Possible leak on setOnAction
Hi,

I'm pretty sure setOnAction is holding references.

I have a "Open Windows" menu on my application where it lists the Stages opened and if you click, it calls stage.toFront():

menuItem.seOnAction(e -> stage.toFront())

I had many crash reports, all OOM. I got the hprof files and analyzed them - turns out this was holding references to all closed stages.

To fix it, I call setOnAction(null) when the stage is closed.

I will investigate further and provide an example.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240418/0bd50cd3/attachment-0001.htm>

From angorya at openjdk.org  Thu Apr 18 15:14:05 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Apr 2024 15:14:05 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <w_YPlj5W8R5VkRRpVa42gjGqqDfvFxN1GPeiAcsn7Ec=.13ab9702-4788-4005-9949-41a4c7c23b40@github.com>

On Thu, 18 Apr 2024 12:01:52 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 365:

> 363:         if (text == null) return null;
> 364:         validateRange(text);
> 365:         int endOffset = maxLength >= 0 ? Math.min(end, Math.max(start + maxLength, maxLength)) : end;

there is a similar code on LL 101,102,381,485
would we need to apply the same logic there?
possibly in some kind of a utility method?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1570948582

From kcr at openjdk.org  Thu Apr 18 15:20:03 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Apr 2024 15:20:03 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <verp4t5Yk5HJRtOmwP3tlpxc0mSQ1KQFRk9T6cHAUrQ=.f7aa5c97-5600-43f2-afba-0363aca5d502@github.com>

On Thu, 18 Apr 2024 12:01:52 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

In addition to the comment Andy made about possible other places for the check, I'd like to see a test, if possible. Also, this doesn't follow the usual pattern of checking for integer overflow, so that could be done in the utility method that Andy suggested.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2064196119

From thiago.sayao at gmail.com  Thu Apr 18 15:50:54 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Thu, 18 Apr 2024 12:50:54 -0300
Subject: Possible leak on setOnAction
In-Reply-To: <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>

I was investigating,

It probably should be menuItem.setOnAction(new WeakEventHandler<>(e ->
stage.toFront()));

But I bet it's a common mistake. Maybe the setOnAction should mention it?



Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <
andy.goryachev at oracle.com> escreveu:

> You are correct - the lambda strongly references `stage` and since it is
> in turn is strongly referenced from the menu item it creates a leak.
>
>
>
> The lambda is essentially this:
>
>
>
> menuItem.setOnAction(new H(stage));
>
> class $1 implements EventHandler<ActionEvent> {
>
>   private final Stage stage;
>
>   public $1(Stage s) {
>
>     this.stage = s; // holds the reference and causes the leak
>
>   }
>
>   public void handle(ActionEvent ev) {
>
>     stage.toFront();
>
>   }
>
> }
>
>
>
> -andy
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
> Milczarek Say?o <thiago.sayao at gmail.com>
> *Date: *Thursday, April 18, 2024 at 03:42
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Possible leak on setOnAction
>
> Hi,
>
>
>
> I'm pretty sure setOnAction is holding references.
>
>
>
> I have a "Open Windows" menu on my application where it lists the Stages
> opened and if you click, it calls stage.toFront():
>
>
>
> menuItem.seOnAction(e -> stage.toFront())
>
>
>
> I had many crash reports, all OOM. I got the hprof files and analyzed them
> - turns out this was holding references to all closed stages.
>
>
>
> To fix it, I call setOnAction(null) when the stage is closed.
>
>
>
> I will investigate further and provide an example.
>
>
>
> -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240418/1ea32911/attachment-0001.htm>

From andy.goryachev at oracle.com  Thu Apr 18 16:11:46 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 18 Apr 2024 16:11:46 +0000
Subject: [External] : Re: Possible leak on setOnAction
In-Reply-To: <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
Message-ID: <BL3PR10MB6185AA813448531486406EE5E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>

Well, then all these setOnXXX() should mention it as well, wouldn't you say?

Perhaps a better solution might be a general purpose tutorial which addresses the common pitfalls like memory leaks, and new features like Subscription.

We do have these tutorials for java8 -

https://docs.oracle.com/javase/8/javafx/events-tutorial/events.htm

But since JavaFX has been decoupled from the JDK we don't seem to have anything more recent.  I don't know whether this situation is going to change any time soon.

-andy


From: Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Thursday, April 18, 2024 at 08:51
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: openjfx-dev <openjfx-dev at openjdk.org>
Subject: [External] : Re: Possible leak on setOnAction
I was investigating,

It probably should be menuItem.setOnAction(new WeakEventHandler<>(e -> stage.toFront()));

But I bet it's a common mistake. Maybe the setOnAction should mention it?



Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> escreveu:
You are correct - the lambda strongly references `stage` and since it is in turn is strongly referenced from the menu item it creates a leak.

The lambda is essentially this:

menuItem.setOnAction(new H(stage));
class $1 implements EventHandler<ActionEvent> {
  private final Stage stage;
  public $1(Stage s) {
    this.stage = s; // holds the reference and causes the leak
  }
  public void handle(ActionEvent ev) {
    stage.toFront();
  }
}

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com<mailto:thiago.sayao at gmail.com>>
Date: Thursday, April 18, 2024 at 03:42
To: openjfx-dev <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Possible leak on setOnAction
Hi,

I'm pretty sure setOnAction is holding references.

I have a "Open Windows" menu on my application where it lists the Stages opened and if you click, it calls stage.toFront():

menuItem.seOnAction(e -> stage.toFront())

I had many crash reports, all OOM. I got the hprof files and analyzed them - turns out this was holding references to all closed stages.

To fix it, I call setOnAction(null) when the stage is closed.

I will investigate further and provide an example.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240418/9e53dcab/attachment.htm>

From prr at openjdk.org  Thu Apr 18 17:25:03 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 18 Apr 2024 17:25:03 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <hmtzzChsmCznrIoiA9I3LHddDSdmgZRsOd9rTRjP1rI=.19c344c0-340c-4318-940a-b0ada07d8ac1@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
 <hmtzzChsmCznrIoiA9I3LHddDSdmgZRsOd9rTRjP1rI=.19c344c0-340c-4318-940a-b0ada07d8ac1@github.com>
Message-ID: <Jww52V-mL4MS81ssEdT3ulxjKMzhVN7fIQc9QsiCXCc=.c293f275-9965-45af-8ab3-01d798c4da2e@github.com>

On Thu, 18 Apr 2024 14:18:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> the code looks right, I just can't verify the fix on a real system.

Well, yes, I had to install 23.10 in a VirtualBox VM, then clone FX on to it along with all the tools
needed to build and test.
So it is definitely something that needs work to actually test. It was more work than the actual bug fix.

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

PR Comment: https://git.openjdk.org/jfx/pull/1439#issuecomment-2064644274

From duke at openjdk.org  Thu Apr 18 18:00:04 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 18:00:04 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <verp4t5Yk5HJRtOmwP3tlpxc0mSQ1KQFRk9T6cHAUrQ=.f7aa5c97-5600-43f2-afba-0363aca5d502@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <verp4t5Yk5HJRtOmwP3tlpxc0mSQ1KQFRk9T6cHAUrQ=.f7aa5c97-5600-43f2-afba-0363aca5d502@github.com>
Message-ID: <6pljaRQ6hyk3_1oWNXm12l9WB6Jk1khnkmdPRqKEkSU=.1724ad94-daa2-4596-b514-ee29e2cef483@github.com>

On Thu, 18 Apr 2024 15:17:54 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I'd like to see a test, if possible.

Where can I find hints on this? I would use TestFX, fire up some minimal app and try to hit the branches of WinTextRangeProvider. However, I did not find TestFX as used. And there is no `javafx.graphics/src/test/java/test/com/sun/glass/ui/win`. There is also no  `javafx.graphics/src/test/java/test/com/sun/javafx/scene/control` for testing a TextField.

I assume, I need to create some class in `test.javafx.scene.input`?

Based on my experience, I would create a test for `WinTextRangeProvider` directly and supply some values to it to check that the "right" branches are covered.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2064759752

From duke at openjdk.org  Thu Apr 18 18:23:04 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 18:23:04 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <HhnK1GDI94Xxww6CrA-v8M1xALN_Coza_-Hl1tanO8w=.802ee383-e99a-4fdb-9631-c2b02a2bc738@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <HhnK1GDI94Xxww6CrA-v8M1xALN_Coza_-Hl1tanO8w=.802ee383-e99a-4fdb-9631-c2b02a2bc738@github.com>
Message-ID: <HPylU-ny98ULUB8B_3AIPs6vb23Jw8T1UuCR9bDn-Ic=.69ca09cf-f572-4336-b3b0-f11ee36057c2@github.com>

On Thu, 18 Apr 2024 14:44:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> would this fix need to be backported? how far back?

Yes - JavaFX 22 would be helpful for me.

`8u20-b12` was the first tag appearing with that code. -- I checked "git blame" https://github.com/openjdk/jfx/blame/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java. The commit https://github.com/openjdk/jfx/commit/d66a6dd06eeb199e2e1078f562a8d51de67e4510#diff-17176994e11e44400ad30a7092a1fd738b268811b275884b946e11ce2448c379 changed the implementation from a dummy (`return null;`) to something more meaningful. - I did not find the exact releases.

Since [EOL of JavaFX in Java 8](https://www.oracle.com/uk/java/technologies/java-se-support-roadmap.html) is less than 12 months from now, I would not do it.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2064833330

From duke at openjdk.org  Thu Apr 18 19:41:30 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 19:41:30 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v2]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <Zcou-tgKVZdwvhm_hDhb9NtPFirNeujuWSUVYvIBVNA=.238d9583-b797-4e75-a516-4e481fff8d66@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Introduce getValidStringIndex

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/e81712ca..ff545345

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

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

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

From duke at openjdk.org  Thu Apr 18 19:46:23 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 19:46:23 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v3]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <6nzg6iwnDicxI6W78shgACeGMc8atXNGoTsKU_FP1lg=.fe954515-bc35-49b3-a360-3d3bad5dd8e5@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix handling of requestedSteps < 0

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/ff545345..45c10e17

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

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

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

From duke at openjdk.org  Thu Apr 18 20:22:07 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 20:22:07 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v3]
In-Reply-To: <w_YPlj5W8R5VkRRpVa42gjGqqDfvFxN1GPeiAcsn7Ec=.13ab9702-4788-4005-9949-41a4c7c23b40@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <w_YPlj5W8R5VkRRpVa42gjGqqDfvFxN1GPeiAcsn7Ec=.13ab9702-4788-4005-9949-41a4c7c23b40@github.com>
Message-ID: <RP_xjDjmnfRXpj8hYiCZHWUiW5tWwfOEUIJFL7QXmI8=.0f876c29-4ec6-485d-9cf9-e1703a68c4c9@github.com>

On Thu, 18 Apr 2024 15:10:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix handling of requestedSteps < 0
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 365:
> 
>> 363:         if (text == null) return null;
>> 364:         validateRange(text);
>> 365:         int endOffset = maxLength >= 0 ? Math.min(end, Math.max(start + maxLength, maxLength)) : end;
> 
> there is a similar code on LL 101,102,381,485
> would we need to apply the same logic there?
> possibly in some kind of a utility method?

Done! Hopefully, not too overengeered - https://github.com/openjdk/jfx/pull/1442/files#diff-cf00c7b3f2ccd166df5df3aabcd0940072739356910a2c2107a9442aec6010dfR105

(The JDK code seems to be very compact)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1571325231

From duke at openjdk.org  Thu Apr 18 20:27:16 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 20:27:16 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v4]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <vYpe_giWkJx863ygIAtlvvZe-7LDGuMUSqIQlVxXQgg=.9cada84a-f909-4b17-8672-67370b7a8022@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Streamline code

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/45c10e17..9a45303e

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

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

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

From duke at openjdk.org  Thu Apr 18 21:17:28 2024
From: duke at openjdk.org (n-gabe)
Date: Thu, 18 Apr 2024 21:17:28 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer
Message-ID: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>

There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

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

Commit messages:
 - fix indentation
 - fix ConcurrentModificationException in MediaPlayer.java

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

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

From duke at openjdk.org  Thu Apr 18 21:27:12 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 18 Apr 2024 21:27:12 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v5]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <H4boczxen_YSEe4DlipqtMrfAIo9vRTzbSktkZhPNNA=.c1e0aadf-6759-4fd6-8619-3d6f4f0c4069@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  start should be at most maxEnd

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/9a45303e..e7502d67

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

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

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

From kcr at openjdk.org  Thu Apr 18 22:11:01 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Apr 2024 22:11:01 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v5]
In-Reply-To: <H4boczxen_YSEe4DlipqtMrfAIo9vRTzbSktkZhPNNA=.c1e0aadf-6759-4fd6-8619-3d6f4f0c4069@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <H4boczxen_YSEe4DlipqtMrfAIo9vRTzbSktkZhPNNA=.c1e0aadf-6759-4fd6-8619-3d6f4f0c4069@github.com>
Message-ID: <dGUP8CmZi-w3RLeQsu2X4IuW_r-w0UUHI6QidDQZ_d8=.1249dce4-6b87-4c04-a30e-0391ba3b9bd1@github.com>

On Thu, 18 Apr 2024 21:27:12 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   start should be at most maxEnd

I left one inline comment.

I'd like @arapte to review this, since he is familiar with this code, having fixed other IOOBE bugs in it.

Reviewers: @arapte @andy-goryachev-oracle

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 101:

> 99: 
> 100:         int length = text.length();
> 101:         start = getValidStringIndex(start, 0, length);

This change doesn't seem necessary. There is no possibility of integer overflow here.

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

PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2009986037
PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2065411004
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1571433383

From mfox at openjdk.org  Thu Apr 18 22:24:02 2024
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 18 Apr 2024 22:24:02 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <G2tq-rqT3kblzmXX66mox6Yc2pk5i-H9czK8uiv7I64=.d2e23788-7c59-420d-a7e7-220f6c24f7b0@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

I already had 23.10 ARM VM's configured. I was able to reproduce the original bug and verify that this PR fixes it. I can't comment on the code itself.

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

PR Comment: https://git.openjdk.org/jfx/pull/1439#issuecomment-2065423598

From angorya at openjdk.org  Thu Apr 18 22:34:00 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Apr 2024 22:34:00 GMT
Subject: RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10
 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <wNbqlHokSU4nmzv-uQUHecW_FG3YBlMKqHvr7D8n56s=.50940a85-8ad1-4fba-9e51-10ef86e4b8c6@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

thank you @beldenfox for confirming!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1439#pullrequestreview-2010033898

From kcr at openjdk.org  Thu Apr 18 23:17:03 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 18 Apr 2024 23:17:03 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
 <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
Message-ID: <hFFdtuQ4bnwQW9IVrfUHIZmDXIr09NJ92Q1Mie2pU4A=.e0852799-9219-4d2a-a0ed-eb96a2122a6d@github.com>

On Wed, 10 Apr 2024 11:47:28 GMT, drmarmac <duke at openjdk.org> wrote:

>> This PR should fix the issue and cover all relevant cases with new tests.
>> 
>> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.
>
> drmarmac has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic

Thanks for getting this fixed.

@andy-goryachev-oracle We might want to consider a follow-on fix to change the spec (with a CSR) to document this. What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2065468663

From angorya at openjdk.org  Thu Apr 18 23:20:03 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 18 Apr 2024 23:20:03 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
 <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
Message-ID: <KP0_LYaDxLNTdNA3Q29mWA4sc60MbXi2lBMNuKqpV9c=.75c3dae4-0931-4ccc-a82f-7413bede91d5@github.com>

On Wed, 10 Apr 2024 11:47:28 GMT, drmarmac <duke at openjdk.org> wrote:

>> This PR should fix the issue and cover all relevant cases with new tests.
>> 
>> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.
>
> drmarmac has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic

I like the idea of updating the spec (for SpinnerValueFactory.[Integer|Double}SpinnerFactory classes).

Do we really need the CSR for clarifying the behavior?

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

PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2065471671

From almatvee at openjdk.org  Fri Apr 19 00:40:02 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 19 Apr 2024 00:40:02 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <TtUVGs9XJmrMDkkMiAKb3_R_JkBAuFXyHo7YbyH8wMo=.69558257-b5a6-4160-8b11-05c7522e20c5@github.com>

On Thu, 22 Feb 2024 17:16:42 GMT, n-gabe <duke at openjdk.org> wrote:

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

Do we have a test application to reproduce this issue? I tired to create one based on bug description, but was not able to reproduce issue.

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

PR Comment: https://git.openjdk.org/jfx/pull/1377#issuecomment-2065544045

From nlisker at gmail.com  Fri Apr 19 01:30:22 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Fri, 19 Apr 2024 04:30:22 +0300
Subject: Possible leak on setOnAction
In-Reply-To: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
Message-ID: <CA+0ynh_0crLSXn9n0LrYE7xNaS-0pS9VjEYA9D_+Sc6YPYKj7A@mail.gmail.com>

I didn't find such memory leaks in my application, though I don't do stage
handling. What I would look at is where the `stage` reference in the lambda
is coming from. You say you have a list of open stages. When you close a
stage, do you remove the references to that stage from all places? What
about the object that is holding the reference `stage` in the lambda?

On Thu, Apr 18, 2024 at 1:58?PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> Hi,
>
> I'm pretty sure setOnAction is holding references.
>
> I have a "Open Windows" menu on my application where it lists the Stages
> opened and if you click, it calls stage.toFront():
>
> menuItem.seOnAction(e -> stage.toFront())
>
> I had many crash reports, all OOM. I got the hprof files and analyzed them
> - turns out this was holding references to all closed stages.
>
> To fix it, I call setOnAction(null) when the stage is closed.
>
> I will investigate further and provide an example.
>
> -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240419/1837802b/attachment.htm>

From john.hendrikx at gmail.com  Fri Apr 19 04:37:46 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Fri, 19 Apr 2024 06:37:46 +0200
Subject: Possible leak on setOnAction
In-Reply-To: <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
Message-ID: <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>

This probably is a common mistake, however the Weak wrapper is also easy 
to use wrongly.? You can't just wrap it like you are doing in your 
example, because this is how the references look:

 ???? menuItem ---> WeakEventHandler ---weakly---> Lambda

In effect, the Lambda is weakly referenced, and is the only reference, 
so it can be cleaned up immediately (or whenever the GC decides to run) 
and your menu item will stop working at a random time in the future.? 
The WeakEventHandler will remain, but only as a stub (and gets cleaned 
up when the listener list gets manipulated again at a later stage).

The normal way to use a Weak wrapper is to put a reference to the 
wrapped part in a private field, which in your case would not solve the 
problem.

I'm assuming however that you are also removing the menu item from the 
Open Windows list. This menu item should be cleaned up fully, and so the 
reference to the Stage should also disappear. I'm wondering why that 
isn't happening?? If the removed menu item remains referenced somehow, 
then it's Action will reference the Stage, which in turns keeps the 
Stage in memory.

I'd look into the above first before trying other solutions.

--John


On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
> I was investigating,
>
> It probably should be menuItem.setOnAction(new WeakEventHandler<>(e -> 
> stage.toFront()));
>
> But I bet it's a common mistake. Maybe the setOnAction should mention it?
>
>
>
> Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev 
> <andy.goryachev at oracle.com> escreveu:
>
>     You are correct - the lambda strongly references `stage` and since
>     it is in turn is strongly referenced from the menu item it creates
>     a leak.
>
>     The lambda is essentially this:
>
>     menuItem.setOnAction(new H(stage));
>
>     class $1 implements EventHandler<ActionEvent> {
>
>     ? private final Stage stage;
>
>     ? public $1(Stage s) {
>
>     ??? this.stage = s; // holds the reference and causes the leak
>
>     ? }
>
>     ? public void handle(ActionEvent ev) {
>
>     ??? stage.toFront();
>
>     ? }
>
>     }
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of
>     Thiago Milczarek Say?o <thiago.sayao at gmail.com>
>     *Date: *Thursday, April 18, 2024 at 03:42
>     *To: *openjfx-dev <openjfx-dev at openjdk.org>
>     *Subject: *Possible leak on setOnAction
>
>     Hi,
>
>     I'm pretty sure setOnAction is holding references.
>
>     I have a "Open Windows" menu on my application where it lists the
>     Stages opened and if you click, it calls stage.toFront():
>
>     menuItem.seOnAction(e -> stage.toFront())
>
>     I had many crash reports, all OOM. I got the hprof files and
>     analyzed them - turns out this was holding references to all
>     closed stages.
>
>     To fix it, I call setOnAction(null) when the stage is closed.
>
>     I will investigate further and provide an example.
>
>     -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240419/013e9555/attachment-0001.htm>

From duke at openjdk.org  Fri Apr 19 06:51:12 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 06:51:12 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v6]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <EfsDLGSJ3L3SvCt8E01MTPLb1jePuTVdFs9G1cQqYuI=.6f49dc86-6848-4df2-8337-ca65dce1f3ad@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Revert change in validateRange(String)

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/e7502d67..561b4ae3

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

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

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

From duke at openjdk.org  Fri Apr 19 06:57:02 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 06:57:02 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v6]
In-Reply-To: <RP_xjDjmnfRXpj8hYiCZHWUiW5tWwfOEUIJFL7QXmI8=.0f876c29-4ec6-485d-9cf9-e1703a68c4c9@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <w_YPlj5W8R5VkRRpVa42gjGqqDfvFxN1GPeiAcsn7Ec=.13ab9702-4788-4005-9949-41a4c7c23b40@github.com>
 <RP_xjDjmnfRXpj8hYiCZHWUiW5tWwfOEUIJFL7QXmI8=.0f876c29-4ec6-485d-9cf9-e1703a68c4c9@github.com>
Message-ID: <N-DgN2uQR7G2AyQk5qDmKX75eWdiyAhnBpUej_nAaek=.8deab35b-4968-419a-99bb-0081c0036912@github.com>

On Thu, 18 Apr 2024 20:19:19 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 365:
>> 
>>> 363:         if (text == null) return null;
>>> 364:         validateRange(text);
>>> 365:         int endOffset = maxLength >= 0 ? Math.min(end, Math.max(start + maxLength, maxLength)) : end;
>> 
>> there is a similar code on LL 101,102,381,485
>> would we need to apply the same logic there?
>> possibly in some kind of a utility method?
>
> Done! Hopefully, not too overengineered - https://github.com/openjdk/jfx/pull/1442/files#diff-cf00c7b3f2ccd166df5df3aabcd0940072739356910a2c2107a9442aec6010dfR105
> 
> (The JDK code seems to be very compact)

I implemented it for L101, felt a bit bad and at https://github.com/openjdk/jfx/pull/1442/files/e7502d674c579667545b97ab944e82f2b093a470#diff-cf00c7b3f2ccd166df5df3aabcd0940072739356910a2c2107a9442aec6010df, Kevin also noted it could not be right there. Thus, I reverted to the original.

For the others, I used the new utility method `getValidStringIndex`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1571915290

From jvos at openjdk.org  Fri Apr 19 07:32:03 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 19 Apr 2024 07:32:03 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <6pljaRQ6hyk3_1oWNXm12l9WB6Jk1khnkmdPRqKEkSU=.1724ad94-daa2-4596-b514-ee29e2cef483@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <verp4t5Yk5HJRtOmwP3tlpxc0mSQ1KQFRk9T6cHAUrQ=.f7aa5c97-5600-43f2-afba-0363aca5d502@github.com>
 <6pljaRQ6hyk3_1oWNXm12l9WB6Jk1khnkmdPRqKEkSU=.1724ad94-daa2-4596-b514-ee29e2cef483@github.com>
Message-ID: <dIIE8BA76zFeJLopElx8BKIr9PtQwB5WSK8uxGGXrgk=.57251cb5-f057-44df-822d-85f31317d4ef@github.com>

On Thu, 18 Apr 2024 17:57:42 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Based on my experience, I would create a test for `WinTextRangeProvider` directly and supply some values to it to check that the "right" branches are covered.

Based on what I see from the stacktrace, this sounds good. We now know that the methods in WinTextRangeProvider can be invoked with bogus values. A good test would invoke those methods with bogus values and detect a non-catched Exception before, and no Exception after the patch. This can easily be done with a unit test, no need to fire up a minimal app.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2065944318

From duke at openjdk.org  Fri Apr 19 08:37:02 2024
From: duke at openjdk.org (n-gabe)
Date: Fri, 19 Apr 2024 08:37:02 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <mt1T9_EpzvrPSaUZ_Iel3AdTDXOhNO6FNG1DH1ZfHm8=.7f8e05c8-b5fa-4526-b888-1d56fc3e1bce@github.com>

On Thu, 22 Feb 2024 17:16:42 GMT, n-gabe <duke at openjdk.org> wrote:

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

You may use this simple showcase: https://github.com/n-gabe/jfx-two-media-view-sample

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

PR Comment: https://git.openjdk.org/jfx/pull/1377#issuecomment-2066097662

From kpk at openjdk.org  Fri Apr 19 09:22:02 2024
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 19 Apr 2024 09:22:02 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <ONDcG5FV_8nGW-VVB252p0Qm-IgVWHqufTEEQimrxS0=.dd4a8c05-2179-43b4-9c7f-8ada7d3061ef@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

I see few of issue with the item selection when toolbar items are overflown.

1. If a visible toolbar item is selected and we select an item from overflown list, both the items get marked as selected with blue outline. But overflow icon remains grey.
2. If an item is selected and then change window size so that selected item moves to overflow list, overflow icon becomes blue. If we change the selection to another item in the overflow list, then overflow icon becomes grey. But on hovering anywhere in the window, overflow icon becomes blue again.
3. If an item is selected in the overflow list and we select an item from the visible list, selection in the overflow list remains on opening the overflow list for the first time but overflow icon becomes grey. If we open overflow list again, selection will get removed.

I'm not sure whether this issue is in the scope of this PR.
Other than these, this PR looks good to me.

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

PR Review: https://git.openjdk.org/jfx/pull/1434#pullrequestreview-2010946097

From duke at openjdk.org  Fri Apr 19 10:02:04 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 10:02:04 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField
In-Reply-To: <dIIE8BA76zFeJLopElx8BKIr9PtQwB5WSK8uxGGXrgk=.57251cb5-f057-44df-822d-85f31317d4ef@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <verp4t5Yk5HJRtOmwP3tlpxc0mSQ1KQFRk9T6cHAUrQ=.f7aa5c97-5600-43f2-afba-0363aca5d502@github.com>
 <6pljaRQ6hyk3_1oWNXm12l9WB6Jk1khnkmdPRqKEkSU=.1724ad94-daa2-4596-b514-ee29e2cef483@github.com>
 <dIIE8BA76zFeJLopElx8BKIr9PtQwB5WSK8uxGGXrgk=.57251cb5-f057-44df-822d-85f31317d4ef@github.com>
Message-ID: <2QOT4696l4PRVl1AfwCUKc81lqLqyHwgfVm-wlKasi4=.370056ca-2864-4e7a-b19f-157311dbec0f@github.com>

On Fri, 19 Apr 2024 07:29:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

> This can easily be done with a unit test,

How to create an instance of `WinTextRangeProvider` with a fake `WinAccessible`? I need `WinAccessible.getAttribute(...)`. Normally, I would have used Mockito... `WinAccessible` is `final`. -- I do not dare to remove `final` just for test subclassing ^^.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2066239868

From duke at openjdk.org  Fri Apr 19 10:33:33 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 10:33:33 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Add test for getValidStringIndex

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/561b4ae3..76e80aae

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

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

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

From duke at openjdk.org  Fri Apr 19 11:06:22 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 11:06:22 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v8]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <er-UfaUu4E2jTT1blkUDcCntzqgAkGlWcZdEZ1_bYjQ=.3cb839ca-fa7a-4735-bfd7-c2ca833b9b14@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix test package

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/76e80aae..f421eabe

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

  Stats: 127 lines in 4 files changed: 46 ins; 79 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1442.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442

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

From duke at openjdk.org  Fri Apr 19 11:06:22 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 11:06:22 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
Message-ID: <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>

On Fri, 19 Apr 2024 10:33:33 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test for getValidStringIndex

I am new to testing in the JFX project. It seems that `test.` is required as package prefix. Thus, I did not use the approach of package-private methods and classes, but needed to make the class and the tested method public.

However, now I get the (expected) error that the module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.


class test.com.sun.glass.ui.win.WinTextRangeProviderTest (in unnamed module @0x1e6454ec) cannot access class com.sun.glass.ui.win.WinTextRangeProvider (in module javafx.graphics) because module javafx.graphics does not export com.sun.glass.ui.win to unnamed module @0x1e6454ec
java.lang.IllegalAccessError: class test.com.sun.glass.ui.win.WinTextRangeProviderTest (in unnamed module @0x1e6454ec) cannot access class com.sun.glass.ui.win.WinTextRangeProvider (in module javafx.graphics) because module javafx.graphics does not export com.sun.glass.ui.win to unnamed module @0x1e6454ec
	at test.com.sun.glass.ui.win.WinTextRangeProviderTest.getValidStringIndex

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2066340506

From duke at openjdk.org  Fri Apr 19 12:25:01 2024
From: duke at openjdk.org (eduardsdv)
Date: Fri, 19 Apr 2024 12:25:01 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <5PzTcGdA7jaqsUzrvA-tXQuXLkgI6eG-X2VvK2wZ3jU=.795d5f40-cbb3-4d87-91b1-e7e8ca66a94e@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

I can reproduce the behavior #1 in both versions before PR and after PR.

But I cannot reproduce the #2 and the #3 (may be I do not the necessary steps). Can you make a video or try to reproduce it the version before PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2066457533

From duke at openjdk.org  Fri Apr 19 12:43:33 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 12:43:33 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix test

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/f421eabe..8b594f76

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

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

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

From thiago.sayao at gmail.com  Fri Apr 19 12:47:23 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 19 Apr 2024 09:47:23 -0300
Subject: Possible leak on setOnAction
In-Reply-To: <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
Message-ID: <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>

When the window list changes, I'm calling item.setOnAction(null) on the
"old list" before inserting a new one.
In general it's not a problem because the menu item or button is in a
"context", like a Stage and everything is freed when the stage is closed.
Maybe on long lasting stages.

The code goes like this:

Window.getWindows().addListener((ListChangeListener<? super Window>)
change -> updateWindowList());


private void updateWindowList() {
    Window[] windows = Window.getWindows().toArray(new Window[] {});

    List<MenuItem> items = new ArrayList<>();
    for (Window window : windows) {
        if (window instanceof Stage stage && stage != primaryStage) {
            MenuItem item = new MenuItem();
            item.setText(stage.getTitle());
            item.setOnAction(a -> stage.toFront());
            item.setGraphic(new FontIcon());
            items.add(item);
        }
    }

    for (MenuItem item : btnWindows.getItems()) {
        item.setOnAction(null);
    }

    btnWindows.getItems().setAll(items);
}


Maybe there's a bug, because the old list of items is collectable.



Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx <john.hendrikx at gmail.com>
escreveu:

> This probably is a common mistake, however the Weak wrapper is also easy
> to use wrongly.  You can't just wrap it like you are doing in your example,
> because this is how the references look:
>
>      menuItem ---> WeakEventHandler ---weakly---> Lambda
>
> In effect, the Lambda is weakly referenced, and is the only reference, so
> it can be cleaned up immediately (or whenever the GC decides to run) and
> your menu item will stop working at a random time in the future.  The
> WeakEventHandler will remain, but only as a stub (and gets cleaned up when
> the listener list gets manipulated again at a later stage).
>
> The normal way to use a Weak wrapper is to put a reference to the wrapped
> part in a private field, which in your case would not solve the problem.
>
> I'm assuming however that you are also removing the menu item from the
> Open Windows list. This menu item should be cleaned up fully, and so the
> reference to the Stage should also disappear.  I'm wondering why that isn't
> happening?  If the removed menu item remains referenced somehow, then it's
> Action will reference the Stage, which in turns keeps the Stage in memory.
>
> I'd look into the above first before trying other solutions.
>
> --John
>
>
> On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
>
> I was investigating,
>
> It probably should be menuItem.setOnAction(new WeakEventHandler<>(e ->
> stage.toFront()));
>
> But I bet it's a common mistake. Maybe the setOnAction should mention it?
>
>
>
> Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <
> andy.goryachev at oracle.com> escreveu:
>
>> You are correct - the lambda strongly references `stage` and since it is
>> in turn is strongly referenced from the menu item it creates a leak.
>>
>>
>>
>> The lambda is essentially this:
>>
>>
>>
>> menuItem.setOnAction(new H(stage));
>>
>> class $1 implements EventHandler<ActionEvent> {
>>
>>   private final Stage stage;
>>
>>   public $1(Stage s) {
>>
>>     this.stage = s; // holds the reference and causes the leak
>>
>>   }
>>
>>   public void handle(ActionEvent ev) {
>>
>>     stage.toFront();
>>
>>   }
>>
>> }
>>
>>
>>
>> -andy
>>
>>
>>
>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
>> Milczarek Say?o <thiago.sayao at gmail.com>
>> *Date: *Thursday, April 18, 2024 at 03:42
>> *To: *openjfx-dev <openjfx-dev at openjdk.org>
>> *Subject: *Possible leak on setOnAction
>>
>> Hi,
>>
>>
>>
>> I'm pretty sure setOnAction is holding references.
>>
>>
>>
>> I have a "Open Windows" menu on my application where it lists the Stages
>> opened and if you click, it calls stage.toFront():
>>
>>
>>
>> menuItem.seOnAction(e -> stage.toFront())
>>
>>
>>
>> I had many crash reports, all OOM. I got the hprof files and analyzed
>> them - turns out this was holding references to all closed stages.
>>
>>
>>
>> To fix it, I call setOnAction(null) when the stage is closed.
>>
>>
>>
>> I will investigate further and provide an example.
>>
>>
>>
>> -- Thiago.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240419/cbbb668d/attachment-0001.htm>

From kpk at openjdk.org  Fri Apr 19 12:48:06 2024
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 19 Apr 2024 12:48:06 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <E61hC0ioiSFRMzHr3jsRmZDDs5vFACBqAG1Uk6TULKc=.7f3c12fb-a9b2-4ede-9c9c-fedcb50c81ce@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

Here is the video of issue #2. Strangely I couldn't reproduce the issue when I tried to record it using Mac's inbuilt tool. But using zoom, I could reproduce the issue alternatively.

https://github.com/openjdk/jfx/assets/26969459/60bd48a9-4239-4a16-9c92-8894363b159d

This is the video of issue #3. In this case I was able to reproduce issue #2 as well.

https://github.com/openjdk/jfx/assets/26969459/3ad8b4f2-0b97-4d8e-b80b-64883a9e83e2

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2066498197

From jvos at openjdk.org  Fri Apr 19 13:33:16 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 19 Apr 2024 13:33:16 GMT
Subject: [jfx21u] RFR: 8330683: Change JavaFX release version to 21.0.4 in
 jfx21u
Message-ID: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>

Increase JavaFX release version

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

Commit messages:
 - Increase JavaFX release version to 21.0.4

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

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

From jvos at openjdk.org  Fri Apr 19 13:36:04 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 19 Apr 2024 13:36:04 GMT
Subject: [jfx21u] RFR: 8330683: Change JavaFX release version to 21.0.4 in
 jfx21u
In-Reply-To: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>
References: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>
Message-ID: <YLNMoD2fkrQSis1PDdrjh4c0FxOo3gsw6sJLAat1Hvc=.a4653621-89ec-401b-a2d9-6059a5a89dca@github.com>

On Fri, 19 Apr 2024 13:29:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase JavaFX release version

Reviewers: @jperedadnr

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

PR Comment: https://git.openjdk.org/jfx21u/pull/56#issuecomment-2066600419

From jvos at openjdk.org  Fri Apr 19 13:36:18 2024
From: jvos at openjdk.org (Johan Vos)
Date: Fri, 19 Apr 2024 13:36:18 GMT
Subject: [jfx17u] RFR: 8330682: Change JavaFX release version to 17.0.12 in
 jfx17u
Message-ID: <0kHhjbnzSIVbHC7ATr8GH9nPGcnj7_bTMjoHlhi7nH8=.5f3e1c73-20f6-4cc7-8911-1a3881e41779@github.com>

Increase JavaFX release version to 17.0.12

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

Commit messages:
 - Increase JavaFX release version to 17.0.12

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

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

From duke at openjdk.org  Fri Apr 19 14:21:02 2024
From: duke at openjdk.org (eduardsdv)
Date: Fri, 19 Apr 2024 14:21:02 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <zEpvIrDwkUOUJa-zcNy4nqR3PYUlT_SUjrwUA0JiTZk=.951230fe-97a9-4dc7-bfd4-cace8011da7c@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

So, none of them can be reproduced on windows, only on mac.

The #2 can be reproduced in the version before PR and after PR.

The #3 is reproducible only with PR changes and in my opinion an other bug in JavaFX, which is made to appear by this PR.

It can be quick-fixed by adding a ``Platform.runLater(..)`` into WINDO_HIDDEN event handler:

            popup.addEventHandler(WindowEvent.WINDOW_HIDDEN, e -> {
                // Quick-fix for MacOs:
                // If an item is selected in the overflow list and we select an item from the visible list,
                // selection in the overflow list remains on opening the overflow list for the first time but overflow icon becomes grey.
                // If we open overflow list again, selection will get removed.
                Platform.runLater(() -> {
                    // Put the overflowed items back to the list,
                    // otherwise subsequent prefWidth(..)/prefHeight(..) may return wrong values.
                    overflowItems.clear();
                    for (Node item : getSkinnable().getItems()) {
                        if (!box.getChildren().contains(item)) {
                            overflowItems.add(item);
                        }
                    }
                });
            });


What is your suggestion? Should it be **quick**-fixed in this PR or should a new issue be created for it?

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2066686657

From tsayao at openjdk.org  Fri Apr 19 14:42:23 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Fri, 19 Apr 2024 14:42:23 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v3]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <7peXj3gequ3HGNd_FGJKchYB9ySQ784E1Y2Je2rU8gA=.0cffb403-0e41-4a76-a756-8a2649ad6db7@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

  Forgot debug message

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/7ae1f275..30203eab

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

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

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

From andy.goryachev at oracle.com  Fri Apr 19 14:43:08 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 19 Apr 2024 14:43:08 +0000
Subject: Possible leak on setOnAction
In-Reply-To: <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
 <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
Message-ID: <BL3PR10MB618535AE0EFE91B7726A4D8EE50D2@BL3PR10MB6185.namprd10.prod.outlook.com>

Are you sure the reference to stage is not held by something else?  Setting setOnAction(null) should remove the handler and its stage reference from the menu item's eventHandler, shouldn't it?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Friday, April 19, 2024 at 05:47
To: John Hendrikx <john.hendrikx at gmail.com>
Cc: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Possible leak on setOnAction
When the window list changes, I'm calling item.setOnAction(null) on the "old list" before inserting a new one.
In general it's not a problem because the menu item or button is in a "context", like a Stage and everything is freed when the stage is closed. Maybe on long lasting stages.

The code goes like this:


Window.getWindows().addListener((ListChangeListener<? super Window>) change -> updateWindowList());


private void updateWindowList() {
    Window[] windows = Window.getWindows().toArray(new Window[] {});

    List<MenuItem> items = new ArrayList<>();
    for (Window window : windows) {
        if (window instanceof Stage stage && stage != primaryStage) {
            MenuItem item = new MenuItem();
            item.setText(stage.getTitle());
            item.setOnAction(a -> stage.toFront());
            item.setGraphic(new FontIcon());
            items.add(item);
        }
    }

    for (MenuItem item : btnWindows.getItems()) {
        item.setOnAction(null);
    }

    btnWindows.getItems().setAll(items);
}

Maybe there's a bug, because the old list of items is collectable.



Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>> escreveu:

This probably is a common mistake, however the Weak wrapper is also easy to use wrongly.  You can't just wrap it like you are doing in your example, because this is how the references look:

     menuItem ---> WeakEventHandler ---weakly---> Lambda

In effect, the Lambda is weakly referenced, and is the only reference, so it can be cleaned up immediately (or whenever the GC decides to run) and your menu item will stop working at a random time in the future.  The WeakEventHandler will remain, but only as a stub (and gets cleaned up when the listener list gets manipulated again at a later stage).

The normal way to use a Weak wrapper is to put a reference to the wrapped part in a private field, which in your case would not solve the problem.

I'm assuming however that you are also removing the menu item from the Open Windows list. This menu item should be cleaned up fully, and so the reference to the Stage should also disappear.  I'm wondering why that isn't happening?  If the removed menu item remains referenced somehow, then it's Action will reference the Stage, which in turns keeps the Stage in memory.

I'd look into the above first before trying other solutions.

--John


On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
I was investigating,

It probably should be menuItem.setOnAction(new WeakEventHandler<>(e -> stage.toFront()));

But I bet it's a common mistake. Maybe the setOnAction should mention it?



Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> escreveu:
You are correct - the lambda strongly references `stage` and since it is in turn is strongly referenced from the menu item it creates a leak.

The lambda is essentially this:

menuItem.setOnAction(new H(stage));
class $1 implements EventHandler<ActionEvent> {
  private final Stage stage;
  public $1(Stage s) {
    this.stage = s; // holds the reference and causes the leak
  }
  public void handle(ActionEvent ev) {
    stage.toFront();
  }
}

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com<mailto:thiago.sayao at gmail.com>>
Date: Thursday, April 18, 2024 at 03:42
To: openjfx-dev <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Possible leak on setOnAction
Hi,

I'm pretty sure setOnAction is holding references.

I have a "Open Windows" menu on my application where it lists the Stages opened and if you click, it calls stage.toFront():

menuItem.seOnAction(e -> stage.toFront())

I had many crash reports, all OOM. I got the hprof files and analyzed them - turns out this was holding references to all closed stages.

To fix it, I call setOnAction(null) when the stage is closed.

I will investigate further and provide an example.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240419/4b9d1b3f/attachment-0001.htm>

From thiago.sayao at gmail.com  Fri Apr 19 14:57:57 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Fri, 19 Apr 2024 11:57:57 -0300
Subject: Possible leak on setOnAction
In-Reply-To: <BL3PR10MB618535AE0EFE91B7726A4D8EE50D2@BL3PR10MB6185.namprd10.prod.outlook.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
 <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
 <BL3PR10MB618535AE0EFE91B7726A4D8EE50D2@BL3PR10MB6185.namprd10.prod.outlook.com>
Message-ID: <CAAP_wu=ooH6_L4Q6+dQB+Di7bvvPQTspgzkZOnu-cZ-gRZV4cA@mail.gmail.com>

Calling item.setOnAction(null); avoids the leak.

But the question that remains is: When setItems is called on the menu
button with new items, aren't the old items collectable by the GC?

So if the MenuItem is collectable, the stage also becomes collectable if
it's the only reference left to it.

I might be missing something obvious.


Em sex., 19 de abr. de 2024 ?s 11:43, Andy Goryachev <
andy.goryachev at oracle.com> escreveu:

> Are you sure the reference to stage is not held by something else?
> Setting setOnAction(null) should remove the handler and its stage reference
> from the menu item's eventHandler, shouldn't it?
>
>
>
> -andy
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
> Milczarek Say?o <thiago.sayao at gmail.com>
> *Date: *Friday, April 19, 2024 at 05:47
> *To: *John Hendrikx <john.hendrikx at gmail.com>
> *Cc: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Possible leak on setOnAction
>
> When the window list changes, I'm calling item.setOnAction(null) on the
> "old list" before inserting a new one.
>
> In general it's not a problem because the menu item or button is in a
> "context", like a Stage and everything is freed when the stage is closed.
> Maybe on long lasting stages.
>
>
>
> The code goes like this:
>
>
>
> Window.getWindows().addListener((ListChangeListener<? super Window>) change -> updateWindowList());
>
>
>
> private void updateWindowList() {
>     Window[] windows = Window.getWindows().toArray(new Window[] {});
>
>     List<MenuItem> items = new ArrayList<>();
>     for (Window window : windows) {
>         if (window instanceof Stage stage && stage != primaryStage) {
>             MenuItem item = new MenuItem();
>             item.setText(stage.getTitle());
>             item.setOnAction(a -> stage.toFront());
>             item.setGraphic(new FontIcon());
>             items.add(item);
>         }
>     }
>
>     for (MenuItem item : btnWindows.getItems()) {
>         item.setOnAction(null);
>     }
>
>     btnWindows.getItems().setAll(items);
> }
>
>
>
> Maybe there's a bug, because the old list of items is collectable.
>
>
>
>
>
>
>
> Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx <
> john.hendrikx at gmail.com> escreveu:
>
> This probably is a common mistake, however the Weak wrapper is also easy
> to use wrongly.  You can't just wrap it like you are doing in your example,
> because this is how the references look:
>
>      menuItem ---> WeakEventHandler ---weakly---> Lambda
>
> In effect, the Lambda is weakly referenced, and is the only reference, so
> it can be cleaned up immediately (or whenever the GC decides to run) and
> your menu item will stop working at a random time in the future.  The
> WeakEventHandler will remain, but only as a stub (and gets cleaned up when
> the listener list gets manipulated again at a later stage).
>
> The normal way to use a Weak wrapper is to put a reference to the wrapped
> part in a private field, which in your case would not solve the problem.
>
> I'm assuming however that you are also removing the menu item from the
> Open Windows list. This menu item should be cleaned up fully, and so the
> reference to the Stage should also disappear.  I'm wondering why that isn't
> happening?  If the removed menu item remains referenced somehow, then it's
> Action will reference the Stage, which in turns keeps the Stage in memory.
>
> I'd look into the above first before trying other solutions.
>
> --John
>
>
>
> On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
>
> I was investigating,
>
>
>
> It probably should be menuItem.setOnAction(new WeakEventHandler<>(e ->
> stage.toFront()));
>
>
>
> But I bet it's a common mistake. Maybe the setOnAction should mention it?
>
>
>
>
>
>
>
> Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <
> andy.goryachev at oracle.com> escreveu:
>
> You are correct - the lambda strongly references `stage` and since it is
> in turn is strongly referenced from the menu item it creates a leak.
>
>
>
> The lambda is essentially this:
>
>
>
> menuItem.setOnAction(new H(stage));
>
> class $1 implements EventHandler<ActionEvent> {
>
>   private final Stage stage;
>
>   public $1(Stage s) {
>
>     this.stage = s; // holds the reference and causes the leak
>
>   }
>
>   public void handle(ActionEvent ev) {
>
>     stage.toFront();
>
>   }
>
> }
>
>
>
> -andy
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
> Milczarek Say?o <thiago.sayao at gmail.com>
> *Date: *Thursday, April 18, 2024 at 03:42
> *To: *openjfx-dev <openjfx-dev at openjdk.org>
> *Subject: *Possible leak on setOnAction
>
> Hi,
>
>
>
> I'm pretty sure setOnAction is holding references.
>
>
>
> I have a "Open Windows" menu on my application where it lists the Stages
> opened and if you click, it calls stage.toFront():
>
>
>
> menuItem.seOnAction(e -> stage.toFront())
>
>
>
> I had many crash reports, all OOM. I got the hprof files and analyzed them
> - turns out this was holding references to all closed stages.
>
>
>
> To fix it, I call setOnAction(null) when the stage is closed.
>
>
>
> I will investigate further and provide an example.
>
>
>
> -- Thiago.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240419/040e2ad5/attachment.htm>

From jpereda at openjdk.org  Fri Apr 19 15:41:05 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Fri, 19 Apr 2024 15:41:05 GMT
Subject: [jfx21u] RFR: 8330683: Change JavaFX release version to 21.0.4 in
 jfx21u
In-Reply-To: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>
References: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>
Message-ID: <EuOUCEEqeXIwuKysENzP69mIfneQVyKfFYf90kSb-4Q=.9692d9af-a55a-4d01-98a6-6df7f16a5efc@github.com>

On Fri, 19 Apr 2024 13:29:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase JavaFX release version

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx21u/pull/56#pullrequestreview-2011757631

From andy.goryachev at oracle.com  Fri Apr 19 15:55:14 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Fri, 19 Apr 2024 15:55:14 +0000
Subject: [External] : Re: Possible leak on setOnAction
In-Reply-To: <CAAP_wu=ooH6_L4Q6+dQB+Di7bvvPQTspgzkZOnu-cZ-gRZV4cA@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
 <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
 <BL3PR10MB618535AE0EFE91B7726A4D8EE50D2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=ooH6_L4Q6+dQB+Di7bvvPQTspgzkZOnu-cZ-gRZV4cA@mail.gmail.com>
Message-ID: <BL3PR10MB6185A5E42771F31EA15BEB62E50D2@BL3PR10MB6185.namprd10.prod.outlook.com>

What helped me in the past is to fire up VisualVM tool, select "Monitor" tab, click "Perform GC" button a couple of times, then "Heap Dump".  Once the heap dump is loaded, select the class in question and search for "GC Root".  This will show one of the paths to the root objects, often giving the answer on who is holding the reference.

-andy


From: Thiago Milczarek Say?o <thiago.sayao at gmail.com>
Date: Friday, April 19, 2024 at 07:58
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: John Hendrikx <john.hendrikx at gmail.com>, openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: [External] : Re: Possible leak on setOnAction
Calling item.setOnAction(null); avoids the leak.

But the question that remains is: When setItems is called on the menu button with new items, aren't the old items collectable by the GC?

So if the MenuItem is collectable, the stage also becomes collectable if it's the only reference left to it.

I might be missing something obvious.


Em sex., 19 de abr. de 2024 ?s 11:43, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> escreveu:
Are you sure the reference to stage is not held by something else?  Setting setOnAction(null) should remove the handler and its stage reference from the menu item's eventHandler, shouldn't it?

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com<mailto:thiago.sayao at gmail.com>>
Date: Friday, April 19, 2024 at 05:47
To: John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>>
Cc: openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org> <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Re: Possible leak on setOnAction
When the window list changes, I'm calling item.setOnAction(null) on the "old list" before inserting a new one.
In general it's not a problem because the menu item or button is in a "context", like a Stage and everything is freed when the stage is closed. Maybe on long lasting stages.

The code goes like this:


Window.getWindows().addListener((ListChangeListener<? super Window>) change -> updateWindowList());


private void updateWindowList() {
    Window[] windows = Window.getWindows().toArray(new Window[] {});

    List<MenuItem> items = new ArrayList<>();
    for (Window window : windows) {
        if (window instanceof Stage stage && stage != primaryStage) {
            MenuItem item = new MenuItem();
            item.setText(stage.getTitle());
            item.setOnAction(a -> stage.toFront());
            item.setGraphic(new FontIcon());
            items.add(item);
        }
    }

    for (MenuItem item : btnWindows.getItems()) {
        item.setOnAction(null);
    }

    btnWindows.getItems().setAll(items);
}

Maybe there's a bug, because the old list of items is collectable.



Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>> escreveu:

This probably is a common mistake, however the Weak wrapper is also easy to use wrongly.  You can't just wrap it like you are doing in your example, because this is how the references look:

     menuItem ---> WeakEventHandler ---weakly---> Lambda

In effect, the Lambda is weakly referenced, and is the only reference, so it can be cleaned up immediately (or whenever the GC decides to run) and your menu item will stop working at a random time in the future.  The WeakEventHandler will remain, but only as a stub (and gets cleaned up when the listener list gets manipulated again at a later stage).

The normal way to use a Weak wrapper is to put a reference to the wrapped part in a private field, which in your case would not solve the problem.

I'm assuming however that you are also removing the menu item from the Open Windows list. This menu item should be cleaned up fully, and so the reference to the Stage should also disappear.  I'm wondering why that isn't happening?  If the removed menu item remains referenced somehow, then it's Action will reference the Stage, which in turns keeps the Stage in memory.

I'd look into the above first before trying other solutions.

--John


On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
I was investigating,

It probably should be menuItem.setOnAction(new WeakEventHandler<>(e -> stage.toFront()));

But I bet it's a common mistake. Maybe the setOnAction should mention it?



Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <andy.goryachev at oracle.com<mailto:andy.goryachev at oracle.com>> escreveu:
You are correct - the lambda strongly references `stage` and since it is in turn is strongly referenced from the menu item it creates a leak.

The lambda is essentially this:

menuItem.setOnAction(new H(stage));
class $1 implements EventHandler<ActionEvent> {
  private final Stage stage;
  public $1(Stage s) {
    this.stage = s; // holds the reference and causes the leak
  }
  public void handle(ActionEvent ev) {
    stage.toFront();
  }
}

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org<mailto:openjfx-dev-retn at openjdk.org>> on behalf of Thiago Milczarek Say?o <thiago.sayao at gmail.com<mailto:thiago.sayao at gmail.com>>
Date: Thursday, April 18, 2024 at 03:42
To: openjfx-dev <openjfx-dev at openjdk.org<mailto:openjfx-dev at openjdk.org>>
Subject: Possible leak on setOnAction
Hi,

I'm pretty sure setOnAction is holding references.

I have a "Open Windows" menu on my application where it lists the Stages opened and if you click, it calls stage.toFront():

menuItem.seOnAction(e -> stage.toFront())

I had many crash reports, all OOM. I got the hprof files and analyzed them - turns out this was holding references to all closed stages.

To fix it, I call setOnAction(null) when the stage is closed.

I will investigate further and provide an example.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240419/31031eba/attachment-0001.htm>

From angorya at openjdk.org  Fri Apr 19 16:12:07 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 16:12:07 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <rgdTEv_KTJFCTyuRpG6_7u5j2frpShfjbfv69nWrJfg=.0825d612-e9ad-4597-adf6-88b48324d12b@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

I think these three issues are not related to this PR (even though the behavior seems to have changed a bit).

I would look at this from the perspective of the keyboard-only user.  Can they do everything they need to do, such as selecting/focusing/editing of the items in the toolbar as well as the overflow popup?  (We might need to add a TextField and a CheckBox and maybe a ListView to the toolbar to verify that).

If no function is impaired, we are ok.  If the focus indicator (blue outlines etc) is wrong, or an item cannot be focused or some other function is broken, then we have an issue.

What do you think?

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2066880362

From angorya at openjdk.org  Fri Apr 19 16:17:06 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 16:17:06 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <zEpvIrDwkUOUJa-zcNy4nqR3PYUlT_SUjrwUA0JiTZk=.951230fe-97a9-4dc7-bfd4-cace8011da7c@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <zEpvIrDwkUOUJa-zcNy4nqR3PYUlT_SUjrwUA0JiTZk=.951230fe-97a9-4dc7-bfd4-cace8011da7c@github.com>
Message-ID: <rxH-N6BphuMZj9TPAvUYAKoiaIgZg_XWJ5I3eOra1oM=.599f7896-908e-4542-8ae4-0b5700c275c3@github.com>

On Fri, 19 Apr 2024 14:18:36 GMT, eduardsdv <duke at openjdk.org> wrote:

> Should it be **quick**-fixed in this PR

I would rather not.

We *could* create a ticket named "improve focus handling in ToolBar" but then again, since no functionality is disabled, it will be a P5 (very low priority).

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2066887772

From angorya at openjdk.org  Fri Apr 19 17:36:03 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 17:36:03 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
Message-ID: <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>

On Fri, 19 Apr 2024 11:03:31 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.

I think you need to add

--add-exports javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED

to graphics/src/test/addExports
(see line 7)

@kevinrushforth I wonder if there was a way to auto-generate addExports somehow, at least the part needed for the tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2067004360

From kcr at openjdk.org  Fri Apr 19 17:52:04 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Apr 2024 17:52:04 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
 <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
Message-ID: <uG_GXe4Mzi5WBYZUKkHFxUmT3VsVeVD0em-ITaFALUY=.c91583a3-5678-4e38-986f-98f1ff6b394f@github.com>

On Fri, 19 Apr 2024 17:33:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.
> 
> I think you need to add
> 
> ```
> --add-exports javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED
> ```

Correct.

> @kevinrushforth I wonder if there was a way to auto-generate addExports somehow, at least the part needed for the tests.

I'd rather have it be explicit. It changes rarely.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2067036061

From kcr at openjdk.org  Fri Apr 19 17:55:03 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 19 Apr 2024 17:55:03 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
Message-ID: <y4Cbo2uchUPnppglyIQgAr0Enowch8z70JIncJHVI2E=.c76c3221-8ced-4947-9dee-7671dafe5ad0@github.com>

On Fri, 19 Apr 2024 12:43:33 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

I left a comment regarding the unit test. Please use a shim class instead of making `WinTextRangeProvider` public.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 40:

> 38:  * GlassTextRangeProvider implements ITextRangeProvider.
> 39:  */
> 40: public final class WinTextRangeProvider {

Making both this class and the newly added method public just for the purpose of a unit test is not a pattern we want to use. Instead, leave them as default (package) scope and create a public `WinTextRangeProvideShim` class underneath the shims.

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

PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2012032615
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572720221

From angorya at openjdk.org  Fri Apr 19 18:02:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 18:02:09 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
Message-ID: <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>

On Fri, 19 Apr 2024 12:43:33 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 2:

> 1: /*
> 2:  * Copyright (c) 2014, 2022, 2024, Oracle and/or its affiliates. All rights reserved.

this needs the following form:

Copyright (c) 2014, 2024, Oracle and/or its affiliates. All rights reserved.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 116:

> 114:             return fixedMaxEnd;
> 115:         }
> 116:     }

Frankly, I have hard time understanding this code (maybe a comment describing what the method does and why might help).

It looks to me that all we need to do is to guard against a very large maxLength (which for some reason called here 'requestedSteps' which does not seem right - should the last two arguments be swapped?)


public static int getEndIndex(int start, int length, int maxLength) {
  if(length > maxLength) {
    length = maxLength;
  }
  return start + length;
}


That is, I assume we don't have to worry about start + fixedLength overflowing, we just need to make sure we don't go beyond maxLength.  Or is my assumption wrong and start can be negative, or start+fixedLength might overflow?

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 378:

> 376:         if (text == null) return null;
> 377:         validateRange(text);
> 378:         int endOffset = getValidStringIndex(start, maxLength, end);

If I presume the arguments are (start, length, maxLength), the last two arguments on this line only need to be swapped.  They seem to be correct on LL 394, 498.

modules/javafx.graphics/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 29:

> 27: import org.junit.Test;
> 28: import static org.junit.Assert.*;
> 29: import com.sun.glass.ui.win.WinTextRangeProvider;

since it's a new test, would it be possible to convert it to junit5?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572691354
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572723728
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572725583
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572692653

From angorya at openjdk.org  Fri Apr 19 18:10:32 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 18:10:32 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests [v8]
In-Reply-To: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
References: <T2vVfa1xK2AuPdna2prAZrgx7pkNwDnoqrxv-ecyKY4=.9791d747-ee24-4918-a63f-b1a0c39cdea3@github.com>
Message-ID: <cwunKLkYHtZPzivbsPtmavEEzYTgjpDAHYqtyTv_15U=.f3e978de-510c-430a-b9c8-6dad25639a7f@github.com>

> ## ManualTestWindow
> 
> This facility provides the base class for manual tests which displays the test instructions,
> the UI under test, and the Pass/Fail buttons.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>     }
> 
>     public static void main(String[] args) throws Exception {
>         launch(args);
>     }
> 
>     @Override
>     protected Node createContent() {
>         return new Button("Test");
>     }
> }
> 
> 
> Resulting application window:
> 
> ![ManualTestWindow](https://github.com/openjdk/jfx/assets/107069028/fa29ce47-1ca3-458e-91e9-472da43cd724)
> 
> Readme:
> 
> https://github.com/andy-goryachev-oracle/jfx/blob/8319555.manual/tests/manual/util/README.md
> 
> @prrace 's test EmojiTest has been converted to use the new test window as a demonstration (also fixed the Eclipse project so it works now).
> 
> Q: What other features can be added to the test window?
> 
> Edit: the sources are left in their original place at the root of the project.

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

 - Merge remote-tracking branch 'origin/master' into 8319555.manual
 - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual
 - removed example
 - cleanup
 - whitespace
 - extends application
 - works
 - .
 - sources moved back
 - Merge branch 'master' into 8319555.manual
 - ... and 4 more: https://git.openjdk.org/jfx/compare/d9b9a20e...45e53102

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1413/files
  - new: https://git.openjdk.org/jfx/pull/1413/files/a8fc661b..45e53102

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

  Stats: 1325 lines in 28 files changed: 1113 ins; 64 del; 148 mod
  Patch: https://git.openjdk.org/jfx/pull/1413.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1413/head:pull/1413

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

From angorya at openjdk.org  Fri Apr 19 18:17:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 18:17:09 GMT
Subject: RFR: 8330701: Fix Eclipse project in tests/manual/text
Message-ID: <KoUXZbrBtuA6l0KIkYUZikpSdeAEe5M9Ws0M_Tzl_VY=.388beb04-9f25-4d35-90dc-4d3ec36cc60c@github.com>

Came out of the work on [JDK-8319555](https://bugs.openjdk.org/browse/JDK-8319555): [TestBug] Utility for creating instruction window for manual tests.

This project generates errors if opened in Eclipse. Yes, I can close the project each time, but I would rather fix the setup. This fix is extracted from
https://github.com/openjdk/jfx/pull/1413

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

Commit messages:
 - 8330701: Fix Eclipse project in tests/manual/text

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

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

From duke at openjdk.org  Fri Apr 19 18:30:14 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 18:30:14 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <uG_GXe4Mzi5WBYZUKkHFxUmT3VsVeVD0em-ITaFALUY=.c91583a3-5678-4e38-986f-98f1ff6b394f@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
 <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
 <uG_GXe4Mzi5WBYZUKkHFxUmT3VsVeVD0em-ITaFALUY=.c91583a3-5678-4e38-986f-98f1ff6b394f@github.com>
Message-ID: <ShKqjA5393E4ursgLuuY58L8cg48kgfQaMBX6T1Y_34=.5ab5da2d-5307-4917-8bda-4eb546d23cfa@github.com>

On Fri, 19 Apr 2024 17:49:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I think you need to add

The mentioned issue is fixed. Now, I get 


java.lang.UnsatisfiedLinkError: 'void com.sun.glass.ui.win.WinTextRangeProvider._initIDs()'
	at javafx.graphics at 23-internal/com.sun.glass.ui.win.WinTextRangeProvider._initIDs(Native Method)

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2067086506

From duke at openjdk.org  Fri Apr 19 18:30:14 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 18:30:14 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v10]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <xsrl0s4rnYOXydzjQNY4IltmFw4eEc8bMiZapoTcCUg=.326bca93-1e99-4290-ac13-62dc7b6a6610@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix visibility

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/8b594f76..09ec35d0

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

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

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

From duke at openjdk.org  Fri Apr 19 18:35:03 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 19 Apr 2024 18:35:03 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
 <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
Message-ID: <AZoFXxg_4GWuwacXcfdqNldDfRjcMsnguW9d1eiv4IY=.31971d93-88e6-4f38-9db2-8ed1519d739a@github.com>

On Fri, 19 Apr 2024 17:57:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 378:
> 
>> 376:         if (text == null) return null;
>> 377:         validateRange(text);
>> 378:         int endOffset = getValidStringIndex(start, maxLength, end);
> 
> If I presume the arguments are (start, length, maxLength), the last two arguments on this line only need to be swapped.  They seem to be correct on LL 394, 498.

`maxLength` is the parameter of the `GetText` method. The caller asks for the text, but only with `maxLength` length. Therefore, `start + maxLength`. `end` is the real end of the current string. After `end` there are no characters. Ensured by `validateRange`.

I can add a comment. I love to add comments, but I learned at https://github.com/openjdk/jdk/pull/10704 that only higher-level comments are desired...

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572761689

From angorya at openjdk.org  Fri Apr 19 18:44:08 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 18:44:08 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <AZoFXxg_4GWuwacXcfdqNldDfRjcMsnguW9d1eiv4IY=.31971d93-88e6-4f38-9db2-8ed1519d739a@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
 <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
 <AZoFXxg_4GWuwacXcfdqNldDfRjcMsnguW9d1eiv4IY=.31971d93-88e6-4f38-9db2-8ed1519d739a@github.com>
Message-ID: <J9oK-rX_DopBclJ5mqANOpATTOmvOy3F2WWd7XuRLIk=.ec60325b-aa7e-4bb3-8054-dc2b9a28e03a@github.com>

On Fri, 19 Apr 2024 18:32:06 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 378:
>> 
>>> 376:         if (text == null) return null;
>>> 377:         validateRange(text);
>>> 378:         int endOffset = getValidStringIndex(start, maxLength, end);
>> 
>> If I presume the arguments are (start, length, maxLength), the last two arguments on this line only need to be swapped.  They seem to be correct on LL 394, 498.
>
> `maxLength` is the parameter of the `GetText` method. The caller asks for the text, but only with `maxLength` length. Therefore, `start + maxLength`. `end` is the real end of the current string. After `end` there are no characters. Ensured by `validateRange`.
> 
> I can add a comment. I love to add comments, but I learned at https://github.com/openjdk/jdk/pull/10704 that only higher-level comments are desired...

I think the comment in https://github.com/openjdk/jdk/pull/10704 referred to an external project, so it was deemed as unrelated.

but this method, I feel, is rather convoluted.  why do we need to catch exceptions (malloc!) when we should be able to implement the required functionality with a few `if`s.

So I really have two comments: a) the code looks way too complex and b) if an average developer (like me) cannot figure out what it does within 10 seconds, a good comment would help.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1572773987

From angorya at openjdk.org  Fri Apr 19 19:48:24 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 19:48:24 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters
Message-ID: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>

This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with  Character.isLetterOrDigit(int).

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

Commit messages:
 - 8330590 TextInputControl: previous word fails with Bhojpuri characters

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

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

From prr at openjdk.org  Fri Apr 19 20:27:34 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Apr 2024 20:27:34 GMT
Subject: Integrated: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu
 23.10 and later
In-Reply-To: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
References: <t9JGuChA-FbfeFCmNTJhCJj2GcCl3vK6d2vF3A5mpx8=.adccd2d4-ce9e-4066-96dd-c0cfe5eacc35@github.com>
Message-ID: <J7Zvl_GwAPMMZLSgp_20PizKMQYeo8hVqqOYPf1ITu8=.24853430-6356-4ac9-a561-9286ba80dc5b@github.com>

On Wed, 10 Apr 2024 19:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

> The Linux font lookup code is rejecting CFF OpenType fonts.
> Since these are becoming common because of the Noto family this could soon be quite a problem.
> I expect this fix is a candidate for backporting.

This pull request has now been integrated.

Changeset: 5182ea16
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/5182ea16ace78c4f61e2c38981aab62f6153294e
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10 and later

Reviewed-by: aghaisas, angorya

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

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

From angorya at openjdk.org  Fri Apr 19 20:36:42 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 19 Apr 2024 20:36:42 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
Message-ID: <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>

> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with  Character.isLetterOrDigit(int).

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

 - Merge branch 'master' into 8330590.prev.word
 - 8330590 TextInputControl: previous word fails with Bhojpuri characters

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1444/files
  - new: https://git.openjdk.org/jfx/pull/1444/files/1a3e3e41..97322b08

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

  Stats: 817 lines in 25 files changed: 612 ins; 60 del; 145 mod
  Patch: https://git.openjdk.org/jfx/pull/1444.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1444/head:pull/1444

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

From duke at openjdk.org  Fri Apr 19 21:08:03 2024
From: duke at openjdk.org (duke)
Date: Fri, 19 Apr 2024 21:08:03 GMT
Subject: Withdrawn: 8296266: TextArea: Navigation breaks with RTL text
In-Reply-To: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
References: <-o6JV7MUn48GkFQOkgw0bEQZDiF_NeXOdalCH4T32Bc=.41e592ea-1447-45bd-baa0-d7a01311a357@github.com>
Message-ID: <NMENelbMShagveseRWr0xaIsBWw5wF7RpuhlPBsGxK0=.80d4bbb8-0d60-4848-a847-0f3e89a5730f@github.com>

On Tue, 22 Aug 2023 20:46:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The fix uses character BreakIterator instead of the logic that relies on caretBounds/hitTest/rangeShape in TextInputControl.nextCharacterVisually().
> 
> I believe this is a more reliable method of navigation, as it behaves in sync with the jdk break iterator, thought it might work differently around grapheme clusters, considering a recent change JDK-8291660
> 
> This change also introduces TextInputControlHelper class (impl. detail) which gives access to character- and word- break iterators cached by TextInputControl (*some say* these iterators and associated editing logic should be a part of Content implementation, but that's a discussion for another day).

This pull request has been closed without being integrated.

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

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

From almatvee at openjdk.org  Fri Apr 19 22:10:37 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 19 Apr 2024 22:10:37 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <4khEO6KbCssMjtyAQTRQJ34GVK3R6C-g_xeFqO-Pf9c=.8d424176-c32b-4bc1-bec8-6b9a3451c1e4@github.com>

On Thu, 22 Feb 2024 17:16:42 GMT, n-gabe <duke at openjdk.org> wrote:

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

Look good. Can you update copyright year from 2022 to 2024?

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

Changes requested by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1377#pullrequestreview-2012603389

From kpk at openjdk.org  Sat Apr 20 05:24:34 2024
From: kpk at openjdk.org (Karthik P K)
Date: Sat, 20 Apr 2024 05:24:34 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <rxH-N6BphuMZj9TPAvUYAKoiaIgZg_XWJ5I3eOra1oM=.599f7896-908e-4542-8ae4-0b5700c275c3@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <zEpvIrDwkUOUJa-zcNy4nqR3PYUlT_SUjrwUA0JiTZk=.951230fe-97a9-4dc7-bfd4-cace8011da7c@github.com>
 <rxH-N6BphuMZj9TPAvUYAKoiaIgZg_XWJ5I3eOra1oM=.599f7896-908e-4542-8ae4-0b5700c275c3@github.com>
Message-ID: <DjYjmpHYrqjS9t9yMBz0mrj2DYD9tTnFaobYvYvnlTo=.b9fc9cb4-fc97-4498-a224-fb3335a987d5@github.com>

On Fri, 19 Apr 2024 16:14:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> So, none of them can be reproduced on windows, only on mac.
>> 
>> The #2 can be reproduced in the version before PR and after PR.
>> 
>> The #3 is reproducible only with PR changes and in my opinion an other bug in JavaFX, which is made to appear by this PR.
>> 
>> It can be quick-fixed by adding a ``Platform.runLater(..)`` into WINDO_HIDDEN event handler:
>> 
>>             popup.addEventHandler(WindowEvent.WINDOW_HIDDEN, e -> {
>>                 // Quick-fix for MacOs:
>>                 // If an item is selected in the overflow list and we select an item from the visible list,
>>                 // selection in the overflow list remains on opening the overflow list for the first time but overflow icon becomes grey.
>>                 // If we open overflow list again, selection will get removed.
>>                 Platform.runLater(() -> {
>>                     // Put the overflowed items back to the list,
>>                     // otherwise subsequent prefWidth(..)/prefHeight(..) may return wrong values.
>>                     overflowItems.clear();
>>                     for (Node item : getSkinnable().getItems()) {
>>                         if (!box.getChildren().contains(item)) {
>>                             overflowItems.add(item);
>>                         }
>>                     }
>>                 });
>>             });
>> 
>> 
>> What is your suggestion? Should it be **quick**-fixed in this PR or should a new issue be created for it?
>
>> Should it be **quick**-fixed in this PR
> 
> I would rather not.
> 
> We *could* create a ticket named "improve focus handling in ToolBar" but then again, since no functionality is disabled, it will be a P5 (very low priority).

What @andy-goryachev-oracle  mentioned above seems ok to me. If focus indicator function is not broken, we can go ahead with this PR and create separate ticket to fix other issues.

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2067559676

From john.hendrikx at gmail.com  Sat Apr 20 08:01:35 2024
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Sat, 20 Apr 2024 10:01:35 +0200
Subject: Possible leak on setOnAction
In-Reply-To: <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
 <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
Message-ID: <be72dad5-a99b-00dd-ad02-37c1d30e086a@gmail.com>

I think this code is bug free, and the added fix shouldn't be needed -- 
the old MenuItems should be cleaned up, and so should the referenced Stages.

So I think the bug is elsewhere, maybe not even in your code at all. I 
did see PR's dealing with how MenuItems are linked to their platform 
specific counterparts and how that can be a bit messy. I'm starting to 
suspect maybe the MenuItems themselves are somehow still referenced 
(perhaps only when they've been displayed once). These should also be 
GC'd.? They are however much smaller, so as long as they don't reference 
a Stage it is probably not noticeable memory wise.

An inspection with VisualVM should give an answer (or you could make a 
MenuItem very large by attaching some huge objects to it that are not 
referenced elsewhere, via its properties map for example).

--John

On 19/04/2024 14:47, Thiago Milczarek Say?o wrote:
> When the window list changes, I'm calling item.setOnAction(null) on 
> the "old list" before inserting a new one.
> In general it's not a problem because the menu item or button is in a 
> "context", like a Stage and everything is freed when the stage is 
> closed. Maybe on long lasting stages.
>
> The code goes like this:
>
> Window.getWindows().addListener((ListChangeListener<?super Window>) change ->updateWindowList());
>
> private void updateWindowList() {
>      Window[] windows = Window.getWindows().toArray(new Window[] {});
>
>      List<MenuItem> items =new ArrayList<>();
>      for (Window window : windows) {
>          if (windowinstanceof Stage stage && stage != primaryStage) {
>              MenuItem item =new MenuItem();
>              item.setText(stage.getTitle());
>              item.setOnAction(a ->stage.toFront());
>              item.setGraphic(new FontIcon());
>              items.add(item);
>          }
>      }
>
>      for (MenuItem item : btnWindows.getItems()) {
>          item.setOnAction(null);
>      }
>
>      btnWindows.getItems().setAll(items);
> }
>
> Maybe there's a bug, because the old list of items is collectable.
>
>
>
> Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx 
> <john.hendrikx at gmail.com> escreveu:
>
>     This probably is a common mistake, however the Weak wrapper is
>     also easy to use wrongly.? You can't just wrap it like you are
>     doing in your example, because this is how the references look:
>
>     ???? menuItem ---> WeakEventHandler ---weakly---> Lambda
>
>     In effect, the Lambda is weakly referenced, and is the only
>     reference, so it can be cleaned up immediately (or whenever the GC
>     decides to run) and your menu item will stop working at a random
>     time in the future.? The WeakEventHandler will remain, but only as
>     a stub (and gets cleaned up when the listener list gets
>     manipulated again at a later stage).
>
>     The normal way to use a Weak wrapper is to put a reference to the
>     wrapped part in a private field, which in your case would not
>     solve the problem.
>
>     I'm assuming however that you are also removing the menu item from
>     the Open Windows list. This menu item should be cleaned up fully,
>     and so the reference to the Stage should also disappear.? I'm
>     wondering why that isn't happening? If the removed menu item
>     remains referenced somehow, then it's Action will reference the
>     Stage, which in turns keeps the Stage in memory.
>
>     I'd look into the above first before trying other solutions.
>
>     --John
>
>
>     On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
>>     I was investigating,
>>
>>     It probably should be menuItem.setOnAction(new
>>     WeakEventHandler<>(e -> stage.toFront()));
>>
>>     But I bet it's a common mistake. Maybe the setOnAction should
>>     mention it?
>>
>>
>>
>>     Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev
>>     <andy.goryachev at oracle.com> escreveu:
>>
>>         You are correct - the lambda strongly references `stage` and
>>         since it is in turn is strongly referenced from the menu item
>>         it creates a leak.
>>
>>         The lambda is essentially this:
>>
>>         menuItem.setOnAction(new H(stage));
>>
>>         class $1 implements EventHandler<ActionEvent> {
>>
>>         ? private final Stage stage;
>>
>>         ? public $1(Stage s) {
>>
>>         ??? this.stage = s; // holds the reference and causes the leak
>>
>>         ? }
>>
>>         ? public void handle(ActionEvent ev) {
>>
>>         ??? stage.toFront();
>>
>>         ? }
>>
>>         }
>>
>>         -andy
>>
>>         *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf
>>         of Thiago Milczarek Say?o <thiago.sayao at gmail.com>
>>         *Date: *Thursday, April 18, 2024 at 03:42
>>         *To: *openjfx-dev <openjfx-dev at openjdk.org>
>>         *Subject: *Possible leak on setOnAction
>>
>>         Hi,
>>
>>         I'm pretty sure setOnAction is holding references.
>>
>>         I have a "Open Windows" menu on my application where it lists
>>         the Stages opened and if you click, it calls stage.toFront():
>>
>>         menuItem.seOnAction(e -> stage.toFront())
>>
>>         I had many crash reports, all OOM. I got the hprof files and
>>         analyzed them - turns out this was holding references to all
>>         closed stages.
>>
>>         To fix it, I call setOnAction(null) when the stage is closed.
>>
>>         I will investigate further and provide an example.
>>
>>         -- Thiago.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240420/92716bc7/attachment-0001.htm>

From jvos at openjdk.org  Sat Apr 20 12:46:34 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 20 Apr 2024 12:46:34 GMT
Subject: [jfx21u] Integrated: 8330683: Change JavaFX release version to 21.0.4
 in jfx21u
In-Reply-To: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>
References: <RIdKPDA93xGoTbnMyoxRx4_YbbhUjUYKZzncM_KDuEQ=.318e81ac-e70b-4f6a-b699-2382b16b13e1@github.com>
Message-ID: <8wkGETFU5BJ0g4CtJqIqJEZu6fVvnGK1LGs89c03MRQ=.9bad3143-0c74-4a8f-8fd2-7dc584842968@github.com>

On Fri, 19 Apr 2024 13:29:07 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase JavaFX release version

This pull request has now been integrated.

Changeset: 9a5ff29a
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/9a5ff29ac8f7906280912fbff2a5f5cc4fba999f
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8330683: Change JavaFX release version to 21.0.4 in jfx21u

Reviewed-by: jpereda

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

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

From jpereda at openjdk.org  Sat Apr 20 13:15:36 2024
From: jpereda at openjdk.org (Jose Pereda)
Date: Sat, 20 Apr 2024 13:15:36 GMT
Subject: [jfx17u] RFR: 8330682: Change JavaFX release version to 17.0.12 in
 jfx17u
In-Reply-To: <0kHhjbnzSIVbHC7ATr8GH9nPGcnj7_bTMjoHlhi7nH8=.5f3e1c73-20f6-4cc7-8911-1a3881e41779@github.com>
References: <0kHhjbnzSIVbHC7ATr8GH9nPGcnj7_bTMjoHlhi7nH8=.5f3e1c73-20f6-4cc7-8911-1a3881e41779@github.com>
Message-ID: <eOz_DhzE4PRnVOdquFRF59DhozF80JSP2T9RR9jDc0g=.d8ff668d-16d2-4c27-85ac-bed98a723c8d@github.com>

On Fri, 19 Apr 2024 13:32:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase JavaFX release version to 17.0.12

Marked as reviewed by jpereda (Reviewer).

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

PR Review: https://git.openjdk.org/jfx17u/pull/189#pullrequestreview-2013084899

From thiago.sayao at gmail.com  Sat Apr 20 13:47:16 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 20 Apr 2024 10:47:16 -0300
Subject: Possible leak on setOnAction
In-Reply-To: <be72dad5-a99b-00dd-ad02-37c1d30e086a@gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
 <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
 <be72dad5-a99b-00dd-ad02-37c1d30e086a@gmail.com>
Message-ID: <CAAP_wunBcq2LoS62_nPWGbFS7F4iittjM1en8tY_yXh3RwybyQ@mail.gmail.com>

Yeah, I've been doing some investigating.

Using the below example, when the "Refresh Menu" button is clicked, it will
replace the items making the old one collectable by the GC.
If the Menu was never used/drop down shown, it will get collected.
If it was used (just shown), it remains in memory (seen on VisualVM).

GC Root points to ContextMenuContent.MenuItemContainer

@Override
public void start(Stage primaryStage) {
    this.primaryStage = primaryStage;
    primaryStage.setTitle("Hello World!");
    Button btn = new Button("New Stage");

    Button btnRefresh = new Button("Refresh Menu");

    ButtonBar buttonBar = new ButtonBar();
    buttonBar.getButtons().addAll(menu, btnRefresh);

    btnRefresh.setOnAction(e -> {
        menu.getItems().setAll(getMenuItem());
    });

    Scene scene = new Scene(buttonBar);
    primaryStage.setScene(scene);
    primaryStage.show();
    menu.getItems().add(getMenuItem());
}

private MenuItem getMenuItem() {
    MenuItem item = new MenuItem();
    item.setText("Menu Item");
    item.setOnAction(a -> {
        System.out.println("ACTION");
    });

    return item;
}



Em s?b., 20 de abr. de 2024 ?s 05:01, John Hendrikx <john.hendrikx at gmail.com>
escreveu:

> I think this code is bug free, and the added fix shouldn't be needed --
> the old MenuItems should be cleaned up, and so should the referenced Stages.
>
> So I think the bug is elsewhere, maybe not even in your code at all. I did
> see PR's dealing with how MenuItems are linked to their platform specific
> counterparts and how that can be a bit messy.  I'm starting to suspect
> maybe the MenuItems themselves are somehow still referenced (perhaps only
> when they've been displayed once).  These should also be GC'd.  They are
> however much smaller, so as long as they don't reference a Stage it is
> probably not noticeable memory wise.
>
> An inspection with VisualVM should give an answer (or you could make a
> MenuItem very large by attaching some huge objects to it that are not
> referenced elsewhere, via its properties map for example).
>
> --John
> On 19/04/2024 14:47, Thiago Milczarek Say?o wrote:
>
> When the window list changes, I'm calling item.setOnAction(null) on the
> "old list" before inserting a new one.
> In general it's not a problem because the menu item or button is in a
> "context", like a Stage and everything is freed when the stage is closed.
> Maybe on long lasting stages.
>
> The code goes like this:
>
> Window.getWindows().addListener((ListChangeListener<? super Window>) change -> updateWindowList());
>
>
> private void updateWindowList() {
>     Window[] windows = Window.getWindows().toArray(new Window[] {});
>
>     List<MenuItem> items = new ArrayList<>();
>     for (Window window : windows) {
>         if (window instanceof Stage stage && stage != primaryStage) {
>             MenuItem item = new MenuItem();
>             item.setText(stage.getTitle());
>             item.setOnAction(a -> stage.toFront());
>             item.setGraphic(new FontIcon());
>             items.add(item);
>         }
>     }
>
>     for (MenuItem item : btnWindows.getItems()) {
>         item.setOnAction(null);
>     }
>
>     btnWindows.getItems().setAll(items);
> }
>
>
> Maybe there's a bug, because the old list of items is collectable.
>
>
>
> Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx <
> john.hendrikx at gmail.com> escreveu:
>
>> This probably is a common mistake, however the Weak wrapper is also easy
>> to use wrongly.  You can't just wrap it like you are doing in your example,
>> because this is how the references look:
>>
>>      menuItem ---> WeakEventHandler ---weakly---> Lambda
>>
>> In effect, the Lambda is weakly referenced, and is the only reference, so
>> it can be cleaned up immediately (or whenever the GC decides to run) and
>> your menu item will stop working at a random time in the future.  The
>> WeakEventHandler will remain, but only as a stub (and gets cleaned up when
>> the listener list gets manipulated again at a later stage).
>>
>> The normal way to use a Weak wrapper is to put a reference to the wrapped
>> part in a private field, which in your case would not solve the problem.
>>
>> I'm assuming however that you are also removing the menu item from the
>> Open Windows list. This menu item should be cleaned up fully, and so the
>> reference to the Stage should also disappear.  I'm wondering why that isn't
>> happening?  If the removed menu item remains referenced somehow, then it's
>> Action will reference the Stage, which in turns keeps the Stage in memory.
>>
>> I'd look into the above first before trying other solutions.
>>
>> --John
>>
>>
>> On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
>>
>> I was investigating,
>>
>> It probably should be menuItem.setOnAction(new WeakEventHandler<>(e ->
>> stage.toFront()));
>>
>> But I bet it's a common mistake. Maybe the setOnAction should mention it?
>>
>>
>>
>> Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <
>> andy.goryachev at oracle.com> escreveu:
>>
>>> You are correct - the lambda strongly references `stage` and since it is
>>> in turn is strongly referenced from the menu item it creates a leak.
>>>
>>>
>>>
>>> The lambda is essentially this:
>>>
>>>
>>>
>>> menuItem.setOnAction(new H(stage));
>>>
>>> class $1 implements EventHandler<ActionEvent> {
>>>
>>>   private final Stage stage;
>>>
>>>   public $1(Stage s) {
>>>
>>>     this.stage = s; // holds the reference and causes the leak
>>>
>>>   }
>>>
>>>   public void handle(ActionEvent ev) {
>>>
>>>     stage.toFront();
>>>
>>>   }
>>>
>>> }
>>>
>>>
>>>
>>> -andy
>>>
>>>
>>>
>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
>>> Milczarek Say?o <thiago.sayao at gmail.com>
>>> *Date: *Thursday, April 18, 2024 at 03:42
>>> *To: *openjfx-dev <openjfx-dev at openjdk.org>
>>> *Subject: *Possible leak on setOnAction
>>>
>>> Hi,
>>>
>>>
>>>
>>> I'm pretty sure setOnAction is holding references.
>>>
>>>
>>>
>>> I have a "Open Windows" menu on my application where it lists the Stages
>>> opened and if you click, it calls stage.toFront():
>>>
>>>
>>>
>>> menuItem.seOnAction(e -> stage.toFront())
>>>
>>>
>>>
>>> I had many crash reports, all OOM. I got the hprof files and analyzed
>>> them - turns out this was holding references to all closed stages.
>>>
>>>
>>>
>>> To fix it, I call setOnAction(null) when the stage is closed.
>>>
>>>
>>>
>>> I will investigate further and provide an example.
>>>
>>>
>>>
>>> -- Thiago.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240420/105d3740/attachment-0001.htm>

From duke at openjdk.org  Sat Apr 20 14:52:48 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 20 Apr 2024 14:52:48 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v11]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <E8YNbiFUp9yy4jIgBLcgowPHTJhdtiSrnnYyred1OnM=.8956f881-16c9-411a-bb16-896507703b2b@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Rename method, add comments, simplify method

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/09ec35d0..219137bb

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

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

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

From duke at openjdk.org  Sat Apr 20 14:52:48 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 20 Apr 2024 14:52:48 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
 <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
Message-ID: <TeHUOe8oMb3pnPLeSK81ommJ2kQK1e22ojJuJCWk2kc=.df158d3e-b41b-447e-993e-bf25eee55585@github.com>

On Fri, 19 Apr 2024 17:55:12 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 116:
> 
>> 114:             return fixedMaxEnd;
>> 115:         }
>> 116:     }
> 
> Frankly, I have hard time understanding this code (maybe a comment describing what the method does and why might help).
> 
> It looks to me that all we need to do is to guard against a very large maxLength (which for some reason called here 'requestedSteps' which does not seem right - should the last two arguments be swapped?)
> 
> 
> public static int getEndIndex(int start, int length, int maxLength) {
>   if(length > maxLength) {
>     length = maxLength;
>   }
>   return start + length;
> }
> 
> 
> That is, I assume we don't have to worry about start + fixedLength overflowing, we just need to make sure we don't go beyond maxLength.  Or is my assumption wrong and start can be negative, or start+fixedLength might overflow?

Smalltalk 1: I thought this was easier to understand than some byte code generation in the JVM. ? 

Smalltalk 2: Sometimes, the code for "Calculate a + b, but return c at most" is pretty hard to craft.

Smalltalk 3: The whole checks stem from possible "out of range" values, especially from the other functions mentioned at https://github.com/openjdk/jfx/pull/1442/#discussion_r1570948582. That was too defensive, as only `requestedSteps` AKA `length` can be out of range.

OK, I seem to have understood "Also, this doesn't follow the usual pattern of checking for integer overflow" by Kevin wrong. I googled the Java way of the usual pattern for Integer overflow. Since Java 8, there is `Math.addExact`. I thought, that this was meant. -- I found it from https://stackoverflow.com/a/3001879/873282. (Inlining the code of `Math.addExact` seems to have negative performance impact.)

The proposed code works OKish if strings are not in length area of Integer.MAX_VALUE. I think, we can safely assume that. - It however returns more characters if start is greater then 0. Example: I request start 2, length of 5, but maximum end index  of 3. Then 3 should be returned, not 7.

---

I changed the code accordingly. Also added a comment when an overflow might happen. From the discussion here, it seems, we can ignore these cases.

Note that the old code returned `0` if `start` was negative. New might return some negative value if `start` is negative enough. However, did not seem to happen, because otherwise, IndexOutOfBounds exceptions might have been seen.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1573308526

From duke at openjdk.org  Sat Apr 20 14:56:53 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 20 Apr 2024 14:56:53 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v12]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <nTXwasTqnxmMyHlrWJpGRS4e7MNb99-EWbrgW1SV8rg=.4b5032d3-526a-40bf-ab9e-9de43670455d@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Introduce Shim

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/219137bb..4679c1c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=10-11

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

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

From duke at openjdk.org  Sat Apr 20 15:36:44 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 20 Apr 2024 15:36:44 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v13]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <2m7fBqdnmVJYtnD7HGto0m9_G3MSNrEMvvAhedxoGW8=.a5f81cc1-fc7f-4181-b90e-1ff227398bbf@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp 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 19 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into patch-1
 - Remove accidently commited file
 - Fix method name
 - Check for overflow
 - Add method comment
 - Fix visibility
 - Convert test to JUnit5
 - Introduce Shim
 - Rename method, add comments, simplify method
 - Fix visibility
 - ... and 9 more: https://git.openjdk.org/jfx/compare/3582ea3d...ab651984

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/4679c1c0..ab651984

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=11-12

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

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

From duke at openjdk.org  Sat Apr 20 15:36:44 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 20 Apr 2024 15:36:44 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <J9oK-rX_DopBclJ5mqANOpATTOmvOy3F2WWd7XuRLIk=.ec60325b-aa7e-4bb3-8054-dc2b9a28e03a@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
 <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
 <AZoFXxg_4GWuwacXcfdqNldDfRjcMsnguW9d1eiv4IY=.31971d93-88e6-4f38-9db2-8ed1519d739a@github.com>
 <J9oK-rX_DopBclJ5mqANOpATTOmvOy3F2WWd7XuRLIk=.ec60325b-aa7e-4bb3-8054-dc2b9a28e03a@github.com>
Message-ID: <7WdLsSSw_tv-964j9-4RFq--81DyLbpf1NZDNpV3ZLc=.66a7c4b7-43e6-4929-9509-a2dc7bb53183@github.com>

On Fri, 19 Apr 2024 18:41:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> So I really have two comments: a) the code looks way too complex and b) if an average developer (like me) cannot figure out what it does within 10 seconds, a good comment would help.

Sure thing.

I applied the one "usual pattern" of Integer overflow at a1c135abf7. Maybe, you like it.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1573318392

From duke at openjdk.org  Sat Apr 20 15:57:35 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Sat, 20 Apr 2024 15:57:35 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v13]
In-Reply-To: <2m7fBqdnmVJYtnD7HGto0m9_G3MSNrEMvvAhedxoGW8=.a5f81cc1-fc7f-4181-b90e-1ff227398bbf@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <2m7fBqdnmVJYtnD7HGto0m9_G3MSNrEMvvAhedxoGW8=.a5f81cc1-fc7f-4181-b90e-1ff227398bbf@github.com>
Message-ID: <fm1Es8K5PUesCHHGsbTv1bZK_1hJzHjSUQsUEkrU0nQ=.16d0c8d1-43ea-406c-8d77-1ba48bfda2f0@github.com>

On Sat, 20 Apr 2024 15:36:44 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp 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 19 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into patch-1
>  - Remove accidently commited file
>  - Fix method name
>  - Check for overflow
>  - Add method comment
>  - Fix visibility
>  - Convert test to JUnit5
>  - Introduce Shim
>  - Rename method, add comments, simplify method
>  - Fix visibility
>  - ... and 9 more: https://git.openjdk.org/jfx/compare/d79fe2b5...ab651984

There is use of native code in the `static` block


    private native static void _initIDs();
    static {
        _initIDs();
    }


Currently, all tests fail because that native library is not found

    java.lang.UnsatisfiedLinkError: 'void com.sun.glass.ui.win.WinTextRangeProvider._initIDs()'

I don't know how to load native libraries here. - I could also change that code part of WinTextRangeProvider to behave different in test mode. But that is a bad pattern, isn't it?

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2067714382

From duke at openjdk.org  Sun Apr 21 14:39:46 2024
From: duke at openjdk.org (n-gabe)
Date: Sun, 21 Apr 2024 14:39:46 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v2]
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <y8WVp5fy2XkJXHsKG3Bw-J_LpknLxSvvSfbDem8eioc=.316b050e-097c-43cc-b887-9f772d5943d3@github.com>

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

n-gabe has updated the pull request incrementally with one additional commit since the last revision:

  Update Copyright

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1377/files
  - new: https://git.openjdk.org/jfx/pull/1377/files/857218e8..bdc1af6e

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

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

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

From duke at openjdk.org  Sun Apr 21 14:39:46 2024
From: duke at openjdk.org (n-gabe)
Date: Sun, 21 Apr 2024 14:39:46 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <bsJJcF_MTEVC8EWx0CP4fjuig7WiadhkTx2rCRz4hQQ=.2ee5fc75-93c9-495f-813f-971ab44a8700@github.com>

On Thu, 22 Feb 2024 17:16:42 GMT, n-gabe <duke at openjdk.org> wrote:

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

Sure, done.

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

PR Comment: https://git.openjdk.org/jfx/pull/1377#issuecomment-2068067764

From thiago.sayao at gmail.com  Sun Apr 21 17:05:22 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 21 Apr 2024 14:05:22 -0300
Subject: Possible leak on setOnAction
In-Reply-To: <CAAP_wunBcq2LoS62_nPWGbFS7F4iittjM1en8tY_yXh3RwybyQ@mail.gmail.com>
References: <CAAP_wu=snMAewNPjS6cKMvRjpSaqKUt8rxrxa_PKMneYqZyQBA@mail.gmail.com>
 <BL3PR10MB61854FEB48CD107BF9EA4D99E50E2@BL3PR10MB6185.namprd10.prod.outlook.com>
 <CAAP_wu=WonAYkBVPSgMdUPEXUdFy+aW09xoJTKcNZ2iXkRZ9fQ@mail.gmail.com>
 <3d408afb-422c-8b94-d147-0e1ebbb71c04@gmail.com>
 <CAAP_wunU1X8Ax9tnnP5X-wE6Gfhj-xegH6Y2GPcV7oCfxaiGPQ@mail.gmail.com>
 <be72dad5-a99b-00dd-ad02-37c1d30e086a@gmail.com>
 <CAAP_wunBcq2LoS62_nPWGbFS7F4iittjM1en8tY_yXh3RwybyQ@mail.gmail.com>
Message-ID: <CAAP_wu=iM7peq86qQwc_Mdtej-TvrBkCj6TXDk4q_Pt96iuhxQ@mail.gmail.com>

I think the leaks (seems to be more than one) happens on:

ContextMenuContent.disposeVisualItems

There are visual items holding references.

They seem to be on MenuItemContainer

It looks like its held on:

mouseEnteredEventHandler

mouseReleasedEventHandler

actionEventHandler


And somewhere else I didn't find.

That's my theory for now.


Em s?b., 20 de abr. de 2024 ?s 10:47, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> Yeah, I've been doing some investigating.
>
> Using the below example, when the "Refresh Menu" button is clicked, it
> will replace the items making the old one collectable by the GC.
> If the Menu was never used/drop down shown, it will get collected.
> If it was used (just shown), it remains in memory (seen on VisualVM).
>
> GC Root points to ContextMenuContent.MenuItemContainer
>
> @Override
> public void start(Stage primaryStage) {
>     this.primaryStage = primaryStage;
>     primaryStage.setTitle("Hello World!");
>     Button btn = new Button("New Stage");
>
>     Button btnRefresh = new Button("Refresh Menu");
>
>     ButtonBar buttonBar = new ButtonBar();
>     buttonBar.getButtons().addAll(menu, btnRefresh);
>
>     btnRefresh.setOnAction(e -> {
>         menu.getItems().setAll(getMenuItem());
>     });
>
>     Scene scene = new Scene(buttonBar);
>     primaryStage.setScene(scene);
>     primaryStage.show();
>     menu.getItems().add(getMenuItem());
> }
>
> private MenuItem getMenuItem() {
>     MenuItem item = new MenuItem();
>     item.setText("Menu Item");
>     item.setOnAction(a -> {
>         System.out.println("ACTION");
>     });
>
>     return item;
> }
>
>
>
> Em s?b., 20 de abr. de 2024 ?s 05:01, John Hendrikx <
> john.hendrikx at gmail.com> escreveu:
>
>> I think this code is bug free, and the added fix shouldn't be needed --
>> the old MenuItems should be cleaned up, and so should the referenced Stages.
>>
>> So I think the bug is elsewhere, maybe not even in your code at all. I
>> did see PR's dealing with how MenuItems are linked to their platform
>> specific counterparts and how that can be a bit messy.  I'm starting to
>> suspect maybe the MenuItems themselves are somehow still referenced
>> (perhaps only when they've been displayed once).  These should also be
>> GC'd.  They are however much smaller, so as long as they don't reference a
>> Stage it is probably not noticeable memory wise.
>>
>> An inspection with VisualVM should give an answer (or you could make a
>> MenuItem very large by attaching some huge objects to it that are not
>> referenced elsewhere, via its properties map for example).
>>
>> --John
>> On 19/04/2024 14:47, Thiago Milczarek Say?o wrote:
>>
>> When the window list changes, I'm calling item.setOnAction(null) on the
>> "old list" before inserting a new one.
>> In general it's not a problem because the menu item or button is in a
>> "context", like a Stage and everything is freed when the stage is closed.
>> Maybe on long lasting stages.
>>
>> The code goes like this:
>>
>> Window.getWindows().addListener((ListChangeListener<? super Window>) change -> updateWindowList());
>>
>>
>> private void updateWindowList() {
>>     Window[] windows = Window.getWindows().toArray(new Window[] {});
>>
>>     List<MenuItem> items = new ArrayList<>();
>>     for (Window window : windows) {
>>         if (window instanceof Stage stage && stage != primaryStage) {
>>             MenuItem item = new MenuItem();
>>             item.setText(stage.getTitle());
>>             item.setOnAction(a -> stage.toFront());
>>             item.setGraphic(new FontIcon());
>>             items.add(item);
>>         }
>>     }
>>
>>     for (MenuItem item : btnWindows.getItems()) {
>>         item.setOnAction(null);
>>     }
>>
>>     btnWindows.getItems().setAll(items);
>> }
>>
>>
>> Maybe there's a bug, because the old list of items is collectable.
>>
>>
>>
>> Em sex., 19 de abr. de 2024 ?s 01:37, John Hendrikx <
>> john.hendrikx at gmail.com> escreveu:
>>
>>> This probably is a common mistake, however the Weak wrapper is also easy
>>> to use wrongly.  You can't just wrap it like you are doing in your example,
>>> because this is how the references look:
>>>
>>>      menuItem ---> WeakEventHandler ---weakly---> Lambda
>>>
>>> In effect, the Lambda is weakly referenced, and is the only reference,
>>> so it can be cleaned up immediately (or whenever the GC decides to run) and
>>> your menu item will stop working at a random time in the future.  The
>>> WeakEventHandler will remain, but only as a stub (and gets cleaned up when
>>> the listener list gets manipulated again at a later stage).
>>>
>>> The normal way to use a Weak wrapper is to put a reference to the
>>> wrapped part in a private field, which in your case would not solve the
>>> problem.
>>>
>>> I'm assuming however that you are also removing the menu item from the
>>> Open Windows list. This menu item should be cleaned up fully, and so the
>>> reference to the Stage should also disappear.  I'm wondering why that isn't
>>> happening?  If the removed menu item remains referenced somehow, then it's
>>> Action will reference the Stage, which in turns keeps the Stage in memory.
>>>
>>> I'd look into the above first before trying other solutions.
>>>
>>> --John
>>>
>>>
>>> On 18/04/2024 17:50, Thiago Milczarek Say?o wrote:
>>>
>>> I was investigating,
>>>
>>> It probably should be menuItem.setOnAction(new WeakEventHandler<>(e ->
>>> stage.toFront()));
>>>
>>> But I bet it's a common mistake. Maybe the setOnAction should mention it?
>>>
>>>
>>>
>>> Em qui., 18 de abr. de 2024 ?s 11:54, Andy Goryachev <
>>> andy.goryachev at oracle.com> escreveu:
>>>
>>>> You are correct - the lambda strongly references `stage` and since it
>>>> is in turn is strongly referenced from the menu item it creates a leak.
>>>>
>>>>
>>>>
>>>> The lambda is essentially this:
>>>>
>>>>
>>>>
>>>> menuItem.setOnAction(new H(stage));
>>>>
>>>> class $1 implements EventHandler<ActionEvent> {
>>>>
>>>>   private final Stage stage;
>>>>
>>>>   public $1(Stage s) {
>>>>
>>>>     this.stage = s; // holds the reference and causes the leak
>>>>
>>>>   }
>>>>
>>>>   public void handle(ActionEvent ev) {
>>>>
>>>>     stage.toFront();
>>>>
>>>>   }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> -andy
>>>>
>>>>
>>>>
>>>> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Thiago
>>>> Milczarek Say?o <thiago.sayao at gmail.com>
>>>> *Date: *Thursday, April 18, 2024 at 03:42
>>>> *To: *openjfx-dev <openjfx-dev at openjdk.org>
>>>> *Subject: *Possible leak on setOnAction
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I'm pretty sure setOnAction is holding references.
>>>>
>>>>
>>>>
>>>> I have a "Open Windows" menu on my application where it lists the
>>>> Stages opened and if you click, it calls stage.toFront():
>>>>
>>>>
>>>>
>>>> menuItem.seOnAction(e -> stage.toFront())
>>>>
>>>>
>>>>
>>>> I had many crash reports, all OOM. I got the hprof files and analyzed
>>>> them - turns out this was holding references to all closed stages.
>>>>
>>>>
>>>>
>>>> To fix it, I call setOnAction(null) when the stage is closed.
>>>>
>>>>
>>>>
>>>> I will investigate further and provide an example.
>>>>
>>>>
>>>>
>>>> -- Thiago.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240421/0e48d59c/attachment-0001.htm>

From thiago.sayao at gmail.com  Sun Apr 21 17:51:03 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 21 Apr 2024 14:51:03 -0300
Subject: Wayland
Message-ID: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>

Hi,

I did a small test app to explore Wayland client and portals (for Robot and
dialogs such as file open/save).

https://github.com/tsayao/wayland-test/blob/main/wayland-test.c

It seems it will work as a glass backend, but some walls will be hit on the
way :)

I have tried to use jextract (from project Panama) to work directly with
java, but it seems it does not support wl_ types.

-- Thiago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240421/9fc36f6f/attachment.htm>

From jhendrikx at openjdk.org  Sun Apr 21 19:03:37 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 21 Apr 2024 19:03:37 GMT
Subject: RFR: 8322964: Optimize performance of CSS selector matching [v9]
In-Reply-To: <PQPHfWXLq4jgfldp9_w2IqbhQ9jtSU5sacZkP_viDDs=.60eab870-7eb2-4623-81e6-48453475351f@github.com>
References: <3wqesWqYtqOrpj9uV2rvz5ufqJCU8gGPJ5zm2YlD7XQ=.da6e32d6-c201-45f0-b003-833648f7535c@github.com>
 <PQPHfWXLq4jgfldp9_w2IqbhQ9jtSU5sacZkP_viDDs=.60eab870-7eb2-4623-81e6-48453475351f@github.com>
Message-ID: <K_w9C8ntxvqolVMeyIKHsP3pHvk3IDw2dUTwDXX9iPM=.6de04ba5-3ba3-4393-90c0-8663611fb36d@github.com>

On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Improves performance of selector matching in the CSS subsystem. This is done by using custom set implementation which are highly optimized for the most common cases where the number of selectors is small (most commonly 1 or 2). It also should be more memory efficient for medium sized and large applications which have many style names defined in various CSS files.
>> 
>> Due to the optimization, the concept of `StyleClass`, which was only introduced to assign a fixed bit index for each unique style class name encountered, is no longer needed. This is because style classes are no longer stored in a `BitSet` which required a fixed index per encountered style class.
>> 
>> The performance improvements are the result of several factors:
>> - Less memory use when only very few style class names are used in selectors and styles from a large pool of potential styles (a `BitSet` for potentially 1000 different style names needed 1000 bits (worst case)  as it was not sparse).
>> - Specialized sets for small number of elements (0, 1, 2, 3-9 and 10+)
>> - Specialized sets are append only (reduces code paths) and can be made read only without requiring a wrapper
>> - Iterator creation is avoided when doing `containsAll` check thanks to the inverse function `isSuperSetOf`
>> - Avoids making a copy of the list of style class names to compare (to convert them to `StyleClass` and put them into a `Set`) -- this copy could not be cached and was always discarded immediately after...
>> 
>> The overall performance was tested using the JFXCentral application which displays about 800 nodes on its start page with about 1000 styles in various style sheets (and which allows to refresh this page easily).  
>> 
>> On JavaFX 20, the fastest refresh speed was 121 ms on my machine.  With the improvements in this PR, the fastest refresh had become 89 ms.  The speed improvement is the result of a 30% faster `Scene#doCSSPass`, which takes up the bulk of the time to refresh the JFXCentral main page (about 100 ms before vs 70 ms after the change).
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move getStyleClassNames to location it was introduced to reduce diff

I think this is ready to be integrated. Let me know if there is anything still missing.

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

PR Comment: https://git.openjdk.org/jfx/pull/1316#issuecomment-2068166905

From jvos at openjdk.org  Sun Apr 21 19:20:34 2024
From: jvos at openjdk.org (Johan Vos)
Date: Sun, 21 Apr 2024 19:20:34 GMT
Subject: [jfx17u] Integrated: 8330682: Change JavaFX release version to 17.0.12
 in jfx17u
In-Reply-To: <0kHhjbnzSIVbHC7ATr8GH9nPGcnj7_bTMjoHlhi7nH8=.5f3e1c73-20f6-4cc7-8911-1a3881e41779@github.com>
References: <0kHhjbnzSIVbHC7ATr8GH9nPGcnj7_bTMjoHlhi7nH8=.5f3e1c73-20f6-4cc7-8911-1a3881e41779@github.com>
Message-ID: <KsLB-YT55vevuVdnJQ8K_6jSiKTGrv3irrIU6yaWmqA=.e733e7dc-6f72-4d04-91d0-ed77d3165d02@github.com>

On Fri, 19 Apr 2024 13:32:14 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Increase JavaFX release version to 17.0.12

This pull request has now been integrated.

Changeset: 685b18e3
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/685b18e3625019307d437e38964a0e83ff26b801
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8330682: Change JavaFX release version to 17.0.12 in jfx17u

Reviewed-by: jpereda

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

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

From nlisker at gmail.com  Sun Apr 21 19:38:43 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 21 Apr 2024 22:38:43 +0300
Subject: Wayland
In-Reply-To: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
Message-ID: <CA+0ynh8dmM0e5z8KtsgxCpwKHnxfD=OiBAdZWoH_UcCEC3zBxw@mail.gmail.com>

What are wl_ types? jextract only supports c headers.

On Sun, Apr 21, 2024 at 10:31?PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> Hi,
>
> I did a small test app to explore Wayland client and portals (for Robot
> and dialogs such as file open/save).
>
> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>
> It seems it will work as a glass backend, but some walls will be hit on
> the way :)
>
> I have tried to use jextract (from project Panama) to work directly with
> java, but it seems it does not support wl_ types.
>
> -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240421/4e319067/attachment-0001.htm>

From thiago.sayao at gmail.com  Sun Apr 21 20:35:12 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 21 Apr 2024 17:35:12 -0300
Subject: Wayland
In-Reply-To: <CA+0ynh8dmM0e5z8KtsgxCpwKHnxfD=OiBAdZWoH_UcCEC3zBxw@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <CA+0ynh8dmM0e5z8KtsgxCpwKHnxfD=OiBAdZWoH_UcCEC3zBxw@mail.gmail.com>
Message-ID: <CAAP_wu=XdFTMyVRf9M965cZJrbTUhLKZxWCDzsUhCn3PomhHiA@mail.gmail.com>

jextract --output src -t org.freedesktop.wayland.client --header-class-name
WlClient `pkg-config --cflags-only-I wayland-client` `pkg-config --libs
wayland-client`  /usr/include/wayland-client.h

WARNING: Skipping wl_registry (type Declared(wl_registry) is not supported)

I would need this to hook the events with wl_registry_add_listener, but
currently the code generation for this is not working.





Em dom., 21 de abr. de 2024 ?s 16:39, Nir Lisker <nlisker at gmail.com>
escreveu:

> What are wl_ types? jextract only supports c headers.
>
> On Sun, Apr 21, 2024 at 10:31?PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>> Hi,
>>
>> I did a small test app to explore Wayland client and portals (for Robot
>> and dialogs such as file open/save).
>>
>> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>
>> It seems it will work as a glass backend, but some walls will be hit on
>> the way :)
>>
>> I have tried to use jextract (from project Panama) to work directly with
>> java, but it seems it does not support wl_ types.
>>
>> -- Thiago.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240421/48a4b84e/attachment.htm>

From duke at openjdk.org  Sun Apr 21 20:58:39 2024
From: duke at openjdk.org (leewyatt)
Date: Sun, 21 Apr 2024 20:58:39 GMT
Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor
 [v20]
In-Reply-To: <yXsbSeseMPlZV3J9z1SLsiYcnDFzHu0QT5ERmQpL87w=.d3b84173-cff1-477d-b568-80316b0daa06@github.com>
References: <myVaNZuL7Zs4km0stVW0wW9GUOua7nr0-XQWI-P3GWc=.28e1d213-5753-4bd4-aeb3-fe87822ae5bf@github.com>
 <SSQ_RoY28q3zlCVpoETqNmJnnPZnhp6AQL7P_fjzsYo=.5bfafd08-5970-4bb9-ab46-f30da3189426@github.com>
 <yXsbSeseMPlZV3J9z1SLsiYcnDFzHu0QT5ERmQpL87w=.d3b84173-cff1-477d-b568-80316b0daa06@github.com>
Message-ID: <41eQaMNz0f43kQgq4-h_euiIAn0J7BzBq5V1PZspS0A=.4b693e26-da28-4414-948c-69e18be45620@github.com>

On Sun, 24 Mar 2024 12:13:08 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 94 commits:
>> 
>>  - Merge branch 'master' into new_ime
>>  - Add signals to avoid warnings
>>  - Merge branch 'master' into new_ime
>>    
>>    # Conflicts:
>>    #	modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp
>>  - Add check for jview
>>  - - Fix comment path
>>  - - Fix double keyrelease
>>  - - Use a work-around to relative positioning (until wayland is not officially supported)
>>    - Unref pango attr list
>>  - Merge branch 'master' into new_ime
>>  - Account the case of !filtered
>>  - Fix change of focus when on preedit + add filter on key release
>>  - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565
>
> Would be nice if IME users could provide feedback on this. I can provide test binaries if necessary.

@tsayao Thank you very much, this PR is very useful. We are developers from non-English speaking countries and are looking forward to this PR very much.

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

PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2068195355

From nlisker at gmail.com  Sun Apr 21 21:15:05 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 22 Apr 2024 00:15:05 +0300
Subject: Wayland
In-Reply-To: <CAAP_wu=XdFTMyVRf9M965cZJrbTUhLKZxWCDzsUhCn3PomhHiA@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <CA+0ynh8dmM0e5z8KtsgxCpwKHnxfD=OiBAdZWoH_UcCEC3zBxw@mail.gmail.com>
 <CAAP_wu=XdFTMyVRf9M965cZJrbTUhLKZxWCDzsUhCn3PomhHiA@mail.gmail.com>
Message-ID: <CA+0ynh88zTDfdeW3BErPfC+F007vCqHAkC-h3NrV2uczWFx7oQ@mail.gmail.com>

Can you link to where all the headers are? I found some in
https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
couldn't see where wl_registry is defined. From what I see, wl_XYZ types
are structs, which are supported.

By the way, there's a new guide for jextract at
https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md. When working
with complex headers (includes upon includes), it's important to specify
the correct target header.

On Sun, Apr 21, 2024 at 11:35?PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> jextract --output src -t org.freedesktop.wayland.client
> --header-class-name WlClient `pkg-config --cflags-only-I wayland-client`
> `pkg-config --libs wayland-client`  /usr/include/wayland-client.h
>
> WARNING: Skipping wl_registry (type Declared(wl_registry) is not supported)
>
> I would need this to hook the events with wl_registry_add_listener, but
> currently the code generation for this is not working.
>
>
>
>
>
> Em dom., 21 de abr. de 2024 ?s 16:39, Nir Lisker <nlisker at gmail.com>
> escreveu:
>
>> What are wl_ types? jextract only supports c headers.
>>
>> On Sun, Apr 21, 2024 at 10:31?PM Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I did a small test app to explore Wayland client and portals (for Robot
>>> and dialogs such as file open/save).
>>>
>>> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>
>>> It seems it will work as a glass backend, but some walls will be hit on
>>> the way :)
>>>
>>> I have tried to use jextract (from project Panama) to work directly with
>>> java, but it seems it does not support wl_ types.
>>>
>>> -- Thiago.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/6df2093e/attachment.htm>

From thiago.sayao at gmail.com  Sun Apr 21 22:35:53 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 21 Apr 2024 19:35:53 -0300
Subject: Wayland
In-Reply-To: <CA+0ynh88zTDfdeW3BErPfC+F007vCqHAkC-h3NrV2uczWFx7oQ@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <CA+0ynh8dmM0e5z8KtsgxCpwKHnxfD=OiBAdZWoH_UcCEC3zBxw@mail.gmail.com>
 <CAAP_wu=XdFTMyVRf9M965cZJrbTUhLKZxWCDzsUhCn3PomhHiA@mail.gmail.com>
 <CA+0ynh88zTDfdeW3BErPfC+F007vCqHAkC-h3NrV2uczWFx7oQ@mail.gmail.com>
Message-ID: <CAAP_wukY84t3=K-wAdtTht0TQ=+BhTDaR+LzfikbsbS17zWCSA@mail.gmail.com>

I mailed the jextract list and Jorn Vernee explained that wayland use
opaque types, which are just defined as such:

struct wl_registry;

I guess you just pass it around and it's defined in the internal .c file.
Those are not supported by jextract.

I'll find a way to get around it.

But I've been playing with it all day, it seems very good. I was able to
generate bindings for:

GMain - for the main loop;
GSettings - for reading settings;
XDG Portal - for screen capture, screenshot, file dialogs

It looks like this:

1) To get a setting

try(var a = Arena.ofConfined()) {
    var mouseSettings =
g_settings_new(a.allocateUtf8String("org.gnome.desktop.interface"));
    int size = g_settings_get_int(mouseSettings,
a.allocateUtf8String("cursor-size"));
    g_object_unref(mouseSettings);
    return new Size(size, size);
}


2) Callbacks

@Override
protected void _invokeLater(Runnable runnable) {
    MemorySegment call = GSourceFunc.allocate(p -> {
        runnable.run();
        return 0;
    }, Arena.ofAuto());

    g_idle_add(call, MemorySegment.NULL);
}


It looks correct to me, but untested.

-- Thiago.

Em dom., 21 de abr. de 2024 ?s 18:15, Nir Lisker <nlisker at gmail.com>
escreveu:

> Can you link to where all the headers are? I found some in
> https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
> couldn't see where wl_registry is defined. From what I see, wl_XYZ types
> are structs, which are supported.
>
> By the way, there's a new guide for jextract at
> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md. When
> working with complex headers (includes upon includes), it's important to
> specify the correct target header.
>
> On Sun, Apr 21, 2024 at 11:35?PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>> jextract --output src -t org.freedesktop.wayland.client
>> --header-class-name WlClient `pkg-config --cflags-only-I wayland-client`
>> `pkg-config --libs wayland-client`  /usr/include/wayland-client.h
>>
>> WARNING: Skipping wl_registry (type Declared(wl_registry) is not
>> supported)
>>
>> I would need this to hook the events with wl_registry_add_listener, but
>> currently the code generation for this is not working.
>>
>>
>>
>>
>>
>> Em dom., 21 de abr. de 2024 ?s 16:39, Nir Lisker <nlisker at gmail.com>
>> escreveu:
>>
>>> What are wl_ types? jextract only supports c headers.
>>>
>>> On Sun, Apr 21, 2024 at 10:31?PM Thiago Milczarek Say?o <
>>> thiago.sayao at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I did a small test app to explore Wayland client and portals (for Robot
>>>> and dialogs such as file open/save).
>>>>
>>>> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>
>>>> It seems it will work as a glass backend, but some walls will be hit on
>>>> the way :)
>>>>
>>>> I have tried to use jextract (from project Panama) to work directly
>>>> with java, but it seems it does not support wl_ types.
>>>>
>>>> -- Thiago.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240421/2ad2a330/attachment-0001.htm>

From nlisker at gmail.com  Mon Apr 22 06:14:04 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 22 Apr 2024 09:14:04 +0300
Subject: Wayland
In-Reply-To: <CAAP_wukY84t3=K-wAdtTht0TQ=+BhTDaR+LzfikbsbS17zWCSA@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <CA+0ynh8dmM0e5z8KtsgxCpwKHnxfD=OiBAdZWoH_UcCEC3zBxw@mail.gmail.com>
 <CAAP_wu=XdFTMyVRf9M965cZJrbTUhLKZxWCDzsUhCn3PomhHiA@mail.gmail.com>
 <CA+0ynh88zTDfdeW3BErPfC+F007vCqHAkC-h3NrV2uczWFx7oQ@mail.gmail.com>
 <CAAP_wukY84t3=K-wAdtTht0TQ=+BhTDaR+LzfikbsbS17zWCSA@mail.gmail.com>
Message-ID: <CA+0ynh9Y9yocyrApj++VPhDEF5dwAjm3ni5uXM5g-jzVMd5Liw@mail.gmail.com>

Ah, yes, opaque types are indeed unsupported:
https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#unsupported-features.
As Jorn said there, if the API exposes methods that use opaque types, then
you wouldn't have a problem. Also, if you have the .c file where they are
defined, jextract can handle them. It could be a bit of a hack though.

I wrote a jextract GUI wrapper with JavaFX, which I tested only on Windows
for now. I will try to get the Linux and Mac versions up soon as well. I
find it very helpful compared to the command line and I think it could help
you with the complex headers there.

Note that jextract generates Java 22 compatible code, which is unusable in
JavaFX for now (we comply with Java 21).

On Mon, Apr 22, 2024 at 1:36?AM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> I mailed the jextract list and Jorn Vernee explained that wayland use
> opaque types, which are just defined as such:
>
> struct wl_registry;
>
> I guess you just pass it around and it's defined in the internal .c file.
> Those are not supported by jextract.
>
> I'll find a way to get around it.
>
> But I've been playing with it all day, it seems very good. I was able to
> generate bindings for:
>
> GMain - for the main loop;
> GSettings - for reading settings;
> XDG Portal - for screen capture, screenshot, file dialogs
>
> It looks like this:
>
> 1) To get a setting
>
> try(var a = Arena.ofConfined()) {
>     var mouseSettings = g_settings_new(a.allocateUtf8String("org.gnome.desktop.interface"));
>     int size = g_settings_get_int(mouseSettings, a.allocateUtf8String("cursor-size"));
>     g_object_unref(mouseSettings);
>     return new Size(size, size);
> }
>
>
> 2) Callbacks
>
> @Override
> protected void _invokeLater(Runnable runnable) {
>     MemorySegment call = GSourceFunc.allocate(p -> {
>         runnable.run();
>         return 0;
>     }, Arena.ofAuto());
>
>     g_idle_add(call, MemorySegment.NULL);
> }
>
>
> It looks correct to me, but untested.
>
> -- Thiago.
>
> Em dom., 21 de abr. de 2024 ?s 18:15, Nir Lisker <nlisker at gmail.com>
> escreveu:
>
>> Can you link to where all the headers are? I found some in
>> https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/src, but I
>> couldn't see where wl_registry is defined. From what I see, wl_XYZ types
>> are structs, which are supported.
>>
>> By the way, there's a new guide for jextract at
>> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md. When
>> working with complex headers (includes upon includes), it's important to
>> specify the correct target header.
>>
>> On Sun, Apr 21, 2024 at 11:35?PM Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> wrote:
>>
>>> jextract --output src -t org.freedesktop.wayland.client
>>> --header-class-name WlClient `pkg-config --cflags-only-I wayland-client`
>>> `pkg-config --libs wayland-client`  /usr/include/wayland-client.h
>>>
>>> WARNING: Skipping wl_registry (type Declared(wl_registry) is not
>>> supported)
>>>
>>> I would need this to hook the events with wl_registry_add_listener, but
>>> currently the code generation for this is not working.
>>>
>>>
>>>
>>>
>>>
>>> Em dom., 21 de abr. de 2024 ?s 16:39, Nir Lisker <nlisker at gmail.com>
>>> escreveu:
>>>
>>>> What are wl_ types? jextract only supports c headers.
>>>>
>>>> On Sun, Apr 21, 2024 at 10:31?PM Thiago Milczarek Say?o <
>>>> thiago.sayao at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I did a small test app to explore Wayland client and portals (for
>>>>> Robot and dialogs such as file open/save).
>>>>>
>>>>> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>>
>>>>> It seems it will work as a glass backend, but some walls will be hit
>>>>> on the way :)
>>>>>
>>>>> I have tried to use jextract (from project Panama) to work directly
>>>>> with java, but it seems it does not support wl_ types.
>>>>>
>>>>> -- Thiago.
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/ceff31b1/attachment.htm>

From duke at openjdk.org  Mon Apr 22 08:37:37 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 22 Apr 2024 08:37:37 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <HkyI352RvGuPeOyw4K04u5B8fLbEEAeHHHccdJ8XZh0=.e7139817-2c80-497c-b7ae-64abcd3d0965@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

I tested the focus handling with the MonkeyTest app. I also tested it with a ListView in the toolbar (see PR: https://github.com/andy-goryachev-oracle/MonkeyTest/pull/2).
All components are reachable with the mouse and the keyboard.
I found only one issue with closing the overflow-menu with the ESC key when the currently focused Node (e.g. ListView) processes the ESC itself. This issue is also reproducible in the version before PR.

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2068811858

From kevin.rushforth at oracle.com  Mon Apr 22 13:54:36 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Apr 2024 06:54:36 -0700
Subject: Wayland
In-Reply-To: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
Message-ID: <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>

Note also that we cannot use Panama in the JavaFX internals yet, since 
the minimum version of the JDK is 21.

-- Kevin


On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
> Hi,
>
> I did a small test app to explore Wayland client and portals (for 
> Robot and dialogs such as file open/save).
>
> https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>
> It seems it will work as a glass backend, but some walls will be hit 
> on the way :)
>
> I have tried to use jextract (from project Panama) to work directly 
> with java, but it seems it does not support wl_ types.
>
> -- Thiago.


From kcr at openjdk.org  Mon Apr 22 13:55:42 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Apr 2024 13:55:42 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v2]
In-Reply-To: <y8WVp5fy2XkJXHsKG3Bw-J_LpknLxSvvSfbDem8eioc=.316b050e-097c-43cc-b887-9f772d5943d3@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
 <y8WVp5fy2XkJXHsKG3Bw-J_LpknLxSvvSfbDem8eioc=.316b050e-097c-43cc-b887-9f772d5943d3@github.com>
Message-ID: <WYkur9X3rtgSTpEBX8fb7D249AJ29385owFPgDPsG1Q=.a1772511-9257-474e-b729-5da7ac1de3fa@github.com>

On Sun, 21 Apr 2024 14:39:46 GMT, n-gabe <duke at openjdk.org> wrote:

>> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.
>
> n-gabe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Copyright

modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line 2:

> 1: /*
> 2:  * Copyright (c) 2010, 2022, 2024, Oracle and/or its affiliates. All rights reserved.

Copyright lines must have exactly one or two years. Please remove `, 2022`

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1377#discussion_r1574796815

From thiago.sayao at gmail.com  Mon Apr 22 14:49:20 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 22 Apr 2024 11:49:20 -0300
Subject: Wayland
In-Reply-To: <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
Message-ID: <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>

I was just experimenting, but it seems to be less work than going with JNI.
If I am correct, the next Java LTS will be 25, which will be required on
JavaFX 29 to be released on September/29.

It's 7 years - that's really too much.

Maybe it's still worthwhile to prototype using FFM and then port everything
to JNI.

-- Thiago.


Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
kevin.rushforth at oracle.com> escreveu:

> Note also that we cannot use Panama in the JavaFX internals yet, since
> the minimum version of the JDK is 21.
>
> -- Kevin
>
>
> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
> > Hi,
> >
> > I did a small test app to explore Wayland client and portals (for
> > Robot and dialogs such as file open/save).
> >
> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
> >
> > It seems it will work as a glass backend, but some walls will be hit
> > on the way :)
> >
> > I have tried to use jextract (from project Panama) to work directly
> > with java, but it seems it does not support wl_ types.
> >
> > -- Thiago.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/0807d6fb/attachment.htm>

From nlisker at gmail.com  Mon Apr 22 15:03:47 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 22 Apr 2024 18:03:47 +0300
Subject: Wayland
In-Reply-To: <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
Message-ID: <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>

I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
very useful for JavaFX, but was told we shouldn't since it's not an LTS
version.

I have no idea how long the work on Wayland will take including the code
review (a rather long process), but you should be able to request code
reviews with FFM and have it ready for integration by Java 25.

On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
thiago.sayao at gmail.com> wrote:

> I was just experimenting, but it seems to be less work than going with JNI.
> If I am correct, the next Java LTS will be 25, which will be required on
> JavaFX 29 to be released on September/29.
>
> It's 7 years - that's really too much.
>
> Maybe it's still worthwhile to prototype using FFM and then port
> everything to JNI.
>
> -- Thiago.
>
>
> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
> kevin.rushforth at oracle.com> escreveu:
>
>> Note also that we cannot use Panama in the JavaFX internals yet, since
>> the minimum version of the JDK is 21.
>>
>> -- Kevin
>>
>>
>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>> > Hi,
>> >
>> > I did a small test app to explore Wayland client and portals (for
>> > Robot and dialogs such as file open/save).
>> >
>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>> >
>> > It seems it will work as a glass backend, but some walls will be hit
>> > on the way :)
>> >
>> > I have tried to use jextract (from project Panama) to work directly
>> > with java, but it seems it does not support wl_ types.
>> >
>> > -- Thiago.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/ee367f95/attachment.htm>

From duke at openjdk.org  Mon Apr 22 15:05:07 2024
From: duke at openjdk.org (n-gabe)
Date: Mon, 22 Apr 2024 15:05:07 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v3]
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <n0VycYyj7ZfG-JNhbf_Hj53Qypok5e9HUq_UfrQLqg4=.9cd9154f-0304-4e4c-96e8-05378b59167e@github.com>

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

n-gabe has updated the pull request incrementally with one additional commit since the last revision:

  Remove needless copyright year

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1377/files
  - new: https://git.openjdk.org/jfx/pull/1377/files/bdc1af6e..89c56d29

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

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

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

From duke at openjdk.org  Mon Apr 22 15:05:07 2024
From: duke at openjdk.org (n-gabe)
Date: Mon, 22 Apr 2024 15:05:07 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v2]
In-Reply-To: <WYkur9X3rtgSTpEBX8fb7D249AJ29385owFPgDPsG1Q=.a1772511-9257-474e-b729-5da7ac1de3fa@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
 <y8WVp5fy2XkJXHsKG3Bw-J_LpknLxSvvSfbDem8eioc=.316b050e-097c-43cc-b887-9f772d5943d3@github.com>
 <WYkur9X3rtgSTpEBX8fb7D249AJ29385owFPgDPsG1Q=.a1772511-9257-474e-b729-5da7ac1de3fa@github.com>
Message-ID: <MDwDntjZXp3yd8qipAaDSnd882qDqbvThPvUxUml8Qo=.79860757-edbb-4a13-a2ae-1edd0d03e8e1@github.com>

On Mon, 22 Apr 2024 13:52:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> n-gabe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Copyright
>
> modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2010, 2022, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright lines must have exactly one or two years. Please remove `, 2022`

Oh sorry, I wasn't aware of that. Now it is removed.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1377#discussion_r1574914527

From kevin.rushforth at oracle.com  Mon Apr 22 15:08:08 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 22 Apr 2024 08:08:08 -0700
Subject: [External] : Re: Wayland
In-Reply-To: <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
Message-ID: <b3d6fc38-b772-4740-80cd-007ae8b16ba1@oracle.com>

Your math is a bit off: it's 2 years from now, not 7. We recently bumped 
the minimum for JavaFX 23 to JDK 21. Two years from now, we will bump 
the minimum for JavaFX 27 to JDK 25.

We might consider bumping it even earlier to a non-LTS, as an exception 
to our general practice, specifically to enable Panama, given the need 
to get away from sun.misc.Unsafe (used by Marlin), so there is a 
possibility that it could be less than 2 years. That will require a some 
discussion.

-- Kevin


On 4/22/2024 7:49 AM, Thiago Milczarek Say?o wrote:
> I was just experimenting, but it seems to be less work than going with 
> JNI.
> If I am correct, the next Java LTS will be 25, which will be required 
> on JavaFX 29 to be released on September/29.
>
> It's 7 years - that's really too much.
>
> Maybe it's still worthwhile to prototype using FFM and then port 
> everything to JNI.
>
> -- Thiago.
>
>
> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth 
> <kevin.rushforth at oracle.com> escreveu:
>
>     Note also that we cannot use Panama in the JavaFX internals yet,
>     since
>     the minimum version of the JDK is 21.
>
>     -- Kevin
>
>
>     On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>     > Hi,
>     >
>     > I did a small test app to explore Wayland client and portals (for
>     > Robot and dialogs such as file open/save).
>     >
>     > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>     <https://urldefense.com/v3/__https://github.com/tsayao/wayland-test/blob/main/wayland-test.c__;!!ACWV5N9M2RV99hQ!M9a_ZeceeAYBM6HeFY0zVabze987SRL-VN9JBp4GLwp35yRw8duanIu56wIWzA7FQ_rPopMc-U4nnEW-7brTKy5bIOc$>
>     >
>     > It seems it will work as a glass backend, but some walls will be
>     hit
>     > on the way :)
>     >
>     > I have tried to use jextract (from project Panama) to work directly
>     > with java, but it seems it does not support wl_ types.
>     >
>     > -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/f3c53221/attachment.htm>

From angorya at openjdk.org  Mon Apr 22 15:21:41 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Apr 2024 15:21:41 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <HkyI352RvGuPeOyw4K04u5B8fLbEEAeHHHccdJ8XZh0=.e7139817-2c80-497c-b7ae-64abcd3d0965@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <HkyI352RvGuPeOyw4K04u5B8fLbEEAeHHHccdJ8XZh0=.e7139817-2c80-497c-b7ae-64abcd3d0965@github.com>
Message-ID: <fWi59DSrdJeIz3Ec8NpxJPQh5DzxY8JxrviM9GFUggc=.c18798cb-7dd3-4d8b-8b9e-1c1e3b01ea14@github.com>

On Mon, 22 Apr 2024 08:34:34 GMT, eduardsdv <duke at openjdk.org> wrote:

> closing the overflow-menu with the ESC key when the currently focused Node (e.g. ListView) processes the ESC itself.

On macOS, option-ESC closes the overflow menu.

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2069855676

From angorya at openjdk.org  Mon Apr 22 15:27:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Apr 2024 15:27:38 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v9]
In-Reply-To: <TeHUOe8oMb3pnPLeSK81ommJ2kQK1e22ojJuJCWk2kc=.df158d3e-b41b-447e-993e-bf25eee55585@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <OltH5PbmWvKuhwX56m50i7RxJ_AwWUZobmdFK7xfjMM=.b481e386-cec8-44eb-9418-11e81feeab2c@github.com>
 <49h7Ayv65CsSZWje4i4yqlzVY-BA2Lcbk-LrmdgWmkQ=.a79bce02-7bf6-43d4-9a61-bbd1370a6a95@github.com>
 <TeHUOe8oMb3pnPLeSK81ommJ2kQK1e22ojJuJCWk2kc=.df158d3e-b41b-447e-993e-bf25eee55585@github.com>
Message-ID: <0T_OgAlPcPro0OiXX5hDupACWKcUM5OW4sO9MKgUcUo=.722170c1-18a7-4839-8bc2-da0492c69611@github.com>

On Sat, 20 Apr 2024 14:50:15 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 116:
>> 
>>> 114:             return fixedMaxEnd;
>>> 115:         }
>>> 116:     }
>> 
>> Frankly, I have hard time understanding this code (maybe a comment describing what the method does and why might help).
>> 
>> It looks to me that all we need to do is to guard against a very large maxLength (which for some reason called here 'requestedSteps' which does not seem right - should the last two arguments be swapped?)
>> 
>> 
>> public static int getEndIndex(int start, int length, int maxLength) {
>>   if(length > maxLength) {
>>     length = maxLength;
>>   }
>>   return start + length;
>> }
>> 
>> 
>> That is, I assume we don't have to worry about start + fixedLength overflowing, we just need to make sure we don't go beyond maxLength.  Or is my assumption wrong and start can be negative, or start+fixedLength might overflow?
>
> Smalltalk 1: I thought this was easier to understand than some byte code generation in the JVM. ?  (For me being an outsider, JDK and JavaFX are "close" related somehow - sorry for that!!)
> 
> Smalltalk 2: Sometimes, the code for "Calculate a + b, but return c at most" is pretty hard to craft.
> 
> Smalltalk 3: The whole checks stem from possible "out of range" values, especially from the other functions mentioned at https://github.com/openjdk/jfx/pull/1442/#discussion_r1570948582. That was too defensive, as only `requestedSteps` AKA `length` can be out of range.
> 
> OK, I seem to have understood "Also, this doesn't follow the usual pattern of checking for integer overflow" by Kevin wrong. I googled the Java way of the usual pattern for Integer overflow. Since Java 8, there is `Math.addExact`. I thought, that this was meant. -- I found it from https://stackoverflow.com/a/3001879/873282. (Inlining the code of `Math.addExact` seems to have negative performance impact.)
> 
> The proposed code works OKish if strings are not in length area of Integer.MAX_VALUE. I think, we can safely assume that. - It however returns more characters if start is greater then 0. Example: I request start 2, length of 5, but maximum end index  of 3. Then 3 should be returned, not 7.
> 
> ---
> 
> I changed the code accordingly. Also added a comment when an overflow might happen. From the discussion here, it seems, we can ignore these cases.
> 
> Note that the old code returned `0` if `start` was negative. New might return some negative value if `start` is negative enough. However, did not seem to happen, because otherwise, IndexOutOfBounds exceptions might have been seen.

Thank you!  Somehow the code looks much cleaner and clearer now.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1574951836

From angorya at openjdk.org  Mon Apr 22 15:33:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Apr 2024 15:33:35 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <oP8PAMoRVud_j_BQ0nyeTcc1cUHdt62qsyEoQoLt3iM=.597caab0-f64e-4676-b1e8-9d7f54b5f8bf@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

let's try this one:

Reviewer: @karthikpandelu

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2069907633

From kcr at openjdk.org  Mon Apr 22 15:44:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Apr 2024 15:44:35 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <oP8PAMoRVud_j_BQ0nyeTcc1cUHdt62qsyEoQoLt3iM=.597caab0-f64e-4676-b1e8-9d7f54b5f8bf@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
 <oP8PAMoRVud_j_BQ0nyeTcc1cUHdt62qsyEoQoLt3iM=.597caab0-f64e-4676-b1e8-9d7f54b5f8bf@github.com>
Message-ID: <gqotyC-eEk25nnN1iQqkL56QMFEfvYoYV4U2caazlJE=.0411acce-5bd2-40dc-b696-92fc867bfddc@github.com>

On Mon, 22 Apr 2024 15:31:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> let's try this one:
> 
> Reviewer: @karthikpandelu

Yep.

There is no Skara command to request a review from someone. The `/reviewer` is use to credit someone who has not done a review in GitHub (and is not expected to), but who has reviewed it via some other means. Such an extra reviewer will be credited in the meta-data, but their review will not "count" for the minimum number of reviewers.

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

PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2069948824

From kcr at openjdk.org  Mon Apr 22 15:52:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 22 Apr 2024 15:52:35 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <ShKqjA5393E4ursgLuuY58L8cg48kgfQaMBX6T1Y_34=.5ab5da2d-5307-4917-8bda-4eb546d23cfa@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
 <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
 <uG_GXe4Mzi5WBYZUKkHFxUmT3VsVeVD0em-ITaFALUY=.c91583a3-5678-4e38-986f-98f1ff6b394f@github.com>
 <ShKqjA5393E4ursgLuuY58L8cg48kgfQaMBX6T1Y_34=.5ab5da2d-5307-4917-8bda-4eb546d23cfa@github.com>
Message-ID: <9w4TeF-hA1-s3-MjTfssmAiHTuVAdFHW8JiHc3FfvBw=.7438321a-ba36-414f-ad54-69c8761072a8@github.com>

On Fri, 19 Apr 2024 18:27:12 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> > I think you need to add
> 
> The mentioned issue is fixed. Now, I get
> 
> ```
> java.lang.UnsatisfiedLinkError: 'void com.sun.glass.ui.win.WinTextRangeProvider._initIDs()'
> 	at javafx.graphics at 23-internal/com.sun.glass.ui.win.WinTextRangeProvider._initIDs(Native Method)
> ```

Ah, right, sorry for not noticing this earlier. You cannot access glass from unit tests in the `javafx.graphics` module. Those tests use the StubToolkit which bypasses glass. You will need to move the test to the system tests project under `tests/system/src/test/java/`. Those will use the real toolkit and the glass libraries will be loaded for you. You will need to explicitly start the toolkit (via `Platform.startup` or a call to a utility method to do the same) in an `@BeforeAll` method.

@andy-goryachev-oracle or @arapte should be able to help you with the transition. You would still use the same shim class, which should remain under `javafx.graphics`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2069976918

From nlisker at gmail.com  Mon Apr 22 16:12:34 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 22 Apr 2024 19:12:34 +0300
Subject: Wayland
In-Reply-To: <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
Message-ID: <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>

Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the N-1
rule.

On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:

> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
> very useful for JavaFX, but was told we shouldn't since it's not an LTS
> version.
>
> I have no idea how long the work on Wayland will take including the code
> review (a rather long process), but you should be able to request code
> reviews with FFM and have it ready for integration by Java 25.
>
> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> wrote:
>
>> I was just experimenting, but it seems to be less work than going with
>> JNI.
>> If I am correct, the next Java LTS will be 25, which will be required on
>> JavaFX 29 to be released on September/29.
>>
>> It's 7 years - that's really too much.
>>
>> Maybe it's still worthwhile to prototype using FFM and then port
>> everything to JNI.
>>
>> -- Thiago.
>>
>>
>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>> kevin.rushforth at oracle.com> escreveu:
>>
>>> Note also that we cannot use Panama in the JavaFX internals yet, since
>>> the minimum version of the JDK is 21.
>>>
>>> -- Kevin
>>>
>>>
>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>> > Hi,
>>> >
>>> > I did a small test app to explore Wayland client and portals (for
>>> > Robot and dialogs such as file open/save).
>>> >
>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>> >
>>> > It seems it will work as a glass backend, but some walls will be hit
>>> > on the way :)
>>> >
>>> > I have tried to use jextract (from project Panama) to work directly
>>> > with java, but it seems it does not support wl_ types.
>>> >
>>> > -- Thiago.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/5c737cf3/attachment.htm>

From philip.race at oracle.com  Mon Apr 22 16:24:43 2024
From: philip.race at oracle.com (Philip Race)
Date: Mon, 22 Apr 2024 09:24:43 -0700
Subject: Wayland
In-Reply-To: <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
Message-ID: <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>

As a reminder, using FFM will require all FX *applications* to specify 
--enable-native-access on the command line
Although this is likely coming to JNI soon too.

https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html

But one thing to watch out for with FFM is startup + warm up time.
I struggled a lot with that in using FFM for just one library in the 
java.desktop module.

-phil

On 4/22/24 9:12 AM, Nir Lisker wrote:
> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve?the 
> N-1 rule.
>
> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>
>     I think that we'll be able to bump to Java 25 in JavaFX 25, like
>     we did with 21. I suggested initially to bump to Java 22 exactly
>     for FFM as it's very useful for JavaFX, but was told we shouldn't
>     since it's not an LTS version.
>
>     I have no idea how long the work on Wayland will take including
>     the code review (a rather long process), but you should be able to
>     request code reviews with FFM and have it ready for integration by
>     Java 25.
>
>     On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o
>     <thiago.sayao at gmail.com> wrote:
>
>         I was just experimenting, but it seems to be less work than
>         going with JNI.
>         If I am correct, the next Java LTS will be 25, which will be
>         required on JavaFX 29 to be released on September/29.
>
>         It's 7 years - that's really too much.
>
>         Maybe it's still worthwhile to prototype using FFM and then
>         port everything to JNI.
>
>         -- Thiago.
>
>
>         Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth
>         <kevin.rushforth at oracle.com> escreveu:
>
>             Note also that we cannot use Panama in the JavaFX
>             internals yet, since
>             the minimum version of the JDK is 21.
>
>             -- Kevin
>
>
>             On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>             > Hi,
>             >
>             > I did a small test app to explore Wayland client and
>             portals (for
>             > Robot and dialogs such as file open/save).
>             >
>             >
>             https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>             >
>             > It seems it will work as a glass backend, but some walls
>             will be hit
>             > on the way :)
>             >
>             > I have tried to use jextract (from project Panama) to
>             work directly
>             > with java, but it seems it does not support wl_ types.
>             >
>             > -- Thiago.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/83ca0d2b/attachment-0001.htm>

From angorya at openjdk.org  Mon Apr 22 16:54:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Apr 2024 16:54:37 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v15]
In-Reply-To: <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
Message-ID: <LleP0qzppAupu6lc-Cl6XnAeRSL_nAVqSVN4hAZI9XE=.50e69720-3712-47f6-ab0a-3b94133049af@github.com>

On Sat, 10 Feb 2024 17:24:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change test to use the more common Arial font and add assumptions

This PR is very close to be ready.  It looks like there are only two things that block it:
1. merge conflict
2. resolve the problems with the fonts (could we pick the font(s) that are available via some utility method?)

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2070214332

From angorya at openjdk.org  Mon Apr 22 17:34:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Apr 2024 17:34:38 GMT
Subject: RFR: 8092102: Labeled: truncated property [v9]
In-Reply-To: <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
Message-ID: <Dxa6ELug7o-ZDp-ZZZW2jXhsNO_yUNd1kOeCp5DBwGs=.5c7de067-2d73-4c5d-9df8-28289cd4ef73@github.com>

On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width.
>> 
>> The new property reacts to changes in the following properties:
>> - ellipsisString
>> - font
>> - height
>> - text
>> - width
>> - wrapText
>> 
>> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code.
>> 
>> **Alternative**
>> 
>> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass.  What is the benefit of adding this functionality to the core?
>> 
>> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126).  The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone.
>> 
>> **See Also**
>> 
>> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated
>> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...)
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - missing )
>  - review comments
>  - Merge branch 'master' into 8092102.truncated
>  - add exports
>  - added unit tests
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - Merge branch 'master' into 8092102.truncated
>  - labeled helper
>  - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e

@aghaisas could you take a look at this PR please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2070351050

From angorya at openjdk.org  Mon Apr 22 17:35:32 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 22 Apr 2024 17:35:32 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
Message-ID: <f6PorbbNmxQV7a1g30BFNXmqHNEt-j9pQxP_ZV_434M=.729991ab-45aa-46d1-b166-e9ed807a8ed6@github.com>

On Mon, 1 Apr 2024 19:27:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding alt-ctrl-LEFT/RIGHT (option-command-LEFT/RIGHT) key bindings to
>> 
>> - ListView
>> - TreeView
>> - TableView
>> - TreeTableView
>> 
>> to support keyboard-only horizontal scrolling.  The main reason for the change is to improve accessibility.
>> 
>> **NOTE: For controls in right-to-left orientation, the direction is reversed.**
>> 
>> As far as I can tell, these key combinations do not interfere with editing.
>> 
>> The proposed solution can be further optimized by adding a public method to the VirtualFlow class, something like
>> 
>> 
>> public void horizontalUnitScroll(boolean right);
>> 
>> 
>> Q: Does this change require a CSR to explain the change in the controls' behavior?  We don't yet have the key bindings documented in /doc-files/behavior
>> 
>> Note:
>> Jenkins headful test passed on all mac configurations, failed on all linux configurations (master branch failed also, so it is test issue), while windows configuration is not yet available.
>
> 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 14 additional commits since the last revision:
> 
>  - tests
>  - cleanup
>  - node orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - table view behavior
>  - tree view behavior
>  - list view behavior
>  - orientation
>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>  - Merge branch 'master' into 8313138.horizontal
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/8433be17...5bae5e7a

@aghaisas and @arapte could you also review this please?

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2070355489

From thiago.sayao at gmail.com  Mon Apr 22 18:45:26 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 22 Apr 2024 15:45:26 -0300
Subject: Wayland
In-Reply-To: <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
Message-ID: <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>

I think the startup time might be related to all static symbol lookups.
So I'm manually including just what is needed:

jextract --output src -t com.sun.glass.wayland.extracted \
  --header-class-name GlassWayland \
  `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
  `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
   glass-wayland.h \
   --include-function xdp_portal_initable_new \
   --include-function xdp_session_close \
   --include-function xdp_portal_open_file \
   --include-function xdp_portal_open_file_finish \
   --include-function g_object_unref \
   --include-function g_timeout_add \
   --include-function g_add_idle \
   --include-function g_main_loop_run \
   --include-function g_main_loop_new \
   --include-function g_main_loop_ref \
   --include-function g_main_loop_unref \
   --include-function g_main_loop_quit \
   --include-function g_settings_new \
   --include-function g_settings_get_int \
   --include-function wl_display_connect \
   --include-function wl_display_disconnect \
   --include-function wl_display_roundtrip \
   --include-function wl_display_dispatch_pending \
   --include-typedef GAsyncReadyCallback \
   --include-typedef GSourceFunc \
   --include-typedef GError


Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race <philip.race at oracle.com>
escreveu:

> As a reminder, using FFM will require all FX *applications* to specify
> --enable-native-access on the command line
> Although this is likely coming to JNI soon too.
>
> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>
> But one thing to watch out for with FFM is startup + warm up time.
> I struggled a lot with that in using FFM for just one library in the
> java.desktop module.
>
> -phil
>
> On 4/22/24 9:12 AM, Nir Lisker wrote:
>
> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the N-1
> rule.
>
> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>
>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
>> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
>> very useful for JavaFX, but was told we shouldn't since it's not an LTS
>> version.
>>
>> I have no idea how long the work on Wayland will take including the code
>> review (a rather long process), but you should be able to request code
>> reviews with FFM and have it ready for integration by Java 25.
>>
>> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> wrote:
>>
>>> I was just experimenting, but it seems to be less work than going with
>>> JNI.
>>> If I am correct, the next Java LTS will be 25, which will be required on
>>> JavaFX 29 to be released on September/29.
>>>
>>> It's 7 years - that's really too much.
>>>
>>> Maybe it's still worthwhile to prototype using FFM and then port
>>> everything to JNI.
>>>
>>> -- Thiago.
>>>
>>>
>>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>>> kevin.rushforth at oracle.com> escreveu:
>>>
>>>> Note also that we cannot use Panama in the JavaFX internals yet, since
>>>> the minimum version of the JDK is 21.
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>>> > Hi,
>>>> >
>>>> > I did a small test app to explore Wayland client and portals (for
>>>> > Robot and dialogs such as file open/save).
>>>> >
>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>> >
>>>> > It seems it will work as a glass backend, but some walls will be hit
>>>> > on the way :)
>>>> >
>>>> > I have tried to use jextract (from project Panama) to work directly
>>>> > with java, but it seems it does not support wl_ types.
>>>> >
>>>> > -- Thiago.
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/a67fd99a/attachment-0001.htm>

From philip.race at oracle.com  Mon Apr 22 19:02:37 2024
From: philip.race at oracle.com (Philip Race)
Date: Mon, 22 Apr 2024 12:02:37 -0700
Subject: Wayland
In-Reply-To: <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
Message-ID: <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>

No, it wasn't. I didn't even use jextracted code.
The startup cost is around initialisation of FFM - around 70 ms (IIRC) 
overhead on my MacBook
Then creation of VarHandles and MethodHandles - 2-5 ms each is what I 
measured, so do these lazily if you can.
And warmup cost is that it takes about 10000 iterations to get code 
fully compiled.

java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
 ???? intx CompileThreshold???????????????????????? = 
10000????????????????????????????????? {pd product} {default}
 ??? double CompileThresholdScaling????????????????? = 
1.000000????????????????????????????????? {product} {default}
 ??? uintx IncreaseFirstTierCompileThresholdAt????? = 
50??????????????????????????????????????? {product} {default}
 ???? intx Tier2CompileThreshold??????????????????? = 
0???????????????????????????????????????? {product} {default}
 ???? intx Tier3CompileThreshold??????????????????? = 
2000????????????????????????????????????? {product} {default}
 ???? intx Tier4CompileThreshold??????????????????? = 
15000???????????????????????????????????? {product} {default}

-phil.


On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
> I think the startup time might be related to all static symbol lookups.
> So I'm manually including just what is needed:
> jextract --output src -t com.sun.glass.wayland.extracted \
>    --header-class-name GlassWayland \
>    `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client`  \
>    `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client`  \
>     glass-wayland.h \
>     --include-function xdp_portal_initable_new \
>     --include-function xdp_session_close \
>     --include-function xdp_portal_open_file \
>     --include-function xdp_portal_open_file_finish \
>     --include-function g_object_unref \
>     --include-function g_timeout_add \
>     --include-function g_add_idle \
>     --include-function g_main_loop_run \
>     --include-function g_main_loop_new \
>     --include-function g_main_loop_ref \
>     --include-function g_main_loop_unref \
>     --include-function g_main_loop_quit \
>     --include-function g_settings_new \
>     --include-function g_settings_get_int \
>     --include-function wl_display_connect \
>     --include-function wl_display_disconnect \
>     --include-function wl_display_roundtrip \
>     --include-function wl_display_dispatch_pending \
>     --include-typedef GAsyncReadyCallback \
>     --include-typedef GSourceFunc \
>     --include-typedef GError
>
> Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race 
> <philip.race at oracle.com> escreveu:
>
>     As a reminder, using FFM will require all FX *applications* to
>     specify --enable-native-access on the command line
>     Although this is likely coming to JNI soon too.
>
>     https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>
>     But one thing to watch out for with FFM is startup + warm up time.
>     I struggled a lot with that in using FFM for just one library in
>     the java.desktop module.
>
>     -phil
>
>     On 4/22/24 9:12 AM, Nir Lisker wrote:
>>     Sorry, we bumped to Java 21 in JavaFX 22 I think since we
>>     preserve?the N-1 rule.
>>
>>     On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>>
>>         I think that we'll be able to bump to Java 25 in JavaFX 25,
>>         like we did with 21. I suggested initially to bump to Java 22
>>         exactly for FFM as it's very useful for JavaFX, but was told
>>         we shouldn't since it's not an LTS version.
>>
>>         I have no idea how long the work on Wayland will take
>>         including the code review (a rather long process), but you
>>         should be able to request code reviews with FFM and have it
>>         ready for integration by Java 25.
>>
>>         On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o
>>         <thiago.sayao at gmail.com> wrote:
>>
>>             I was just experimenting, but it seems to be less work
>>             than going with JNI.
>>             If I am correct, the next Java LTS will be 25, which will
>>             be required on JavaFX 29 to be released on September/29.
>>
>>             It's 7 years - that's really too much.
>>
>>             Maybe it's still worthwhile to prototype using FFM and
>>             then port everything to JNI.
>>
>>             -- Thiago.
>>
>>
>>             Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth
>>             <kevin.rushforth at oracle.com> escreveu:
>>
>>                 Note also that we cannot use Panama in the JavaFX
>>                 internals yet, since
>>                 the minimum version of the JDK is 21.
>>
>>                 -- Kevin
>>
>>
>>                 On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>                 > Hi,
>>                 >
>>                 > I did a small test app to explore Wayland client
>>                 and portals (for
>>                 > Robot and dialogs such as file open/save).
>>                 >
>>                 >
>>                 https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>                 >
>>                 > It seems it will work as a glass backend, but some
>>                 walls will be hit
>>                 > on the way :)
>>                 >
>>                 > I have tried to use jextract (from project Panama)
>>                 to work directly
>>                 > with java, but it seems it does not support wl_ types.
>>                 >
>>                 > -- Thiago.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/348abe8d/attachment.htm>

From nlisker at gmail.com  Mon Apr 22 19:16:13 2024
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 22 Apr 2024 22:16:13 +0300
Subject: Wayland
In-Reply-To: <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
Message-ID: <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>

Not sure it helps with warmup, but marking a foreign function as critical
can improve performance:
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
.

On Mon, Apr 22, 2024 at 10:02?PM Philip Race <philip.race at oracle.com> wrote:

> No, it wasn't. I didn't even use jextracted code.
> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
> overhead on my MacBook
> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
> measured, so do these lazily if you can.
> And warmup cost is that it takes about 10000 iterations to get code fully
> compiled.
>
> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>      intx CompileThreshold                         =
> 10000                                  {pd product} {default}
>     double CompileThresholdScaling                  =
> 1.000000                                  {product} {default}
>     uintx IncreaseFirstTierCompileThresholdAt      =
> 50                                        {product} {default}
>      intx Tier2CompileThreshold                    =
> 0                                         {product} {default}
>      intx Tier3CompileThreshold                    =
> 2000                                      {product} {default}
>      intx Tier4CompileThreshold                    =
> 15000                                     {product} {default}
>
> -phil.
>
>
> On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>
> I think the startup time might be related to all static symbol lookups.
> So I'm manually including just what is needed:
>
> jextract --output src -t com.sun.glass.wayland.extracted \
>   --header-class-name GlassWayland \
>   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
>   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
>    glass-wayland.h \
>    --include-function xdp_portal_initable_new \
>    --include-function xdp_session_close \
>    --include-function xdp_portal_open_file \
>    --include-function xdp_portal_open_file_finish \
>    --include-function g_object_unref \
>    --include-function g_timeout_add \
>    --include-function g_add_idle \
>    --include-function g_main_loop_run \
>    --include-function g_main_loop_new \
>    --include-function g_main_loop_ref \
>    --include-function g_main_loop_unref \
>    --include-function g_main_loop_quit \
>    --include-function g_settings_new \
>    --include-function g_settings_get_int \
>    --include-function wl_display_connect \
>    --include-function wl_display_disconnect \
>    --include-function wl_display_roundtrip \
>    --include-function wl_display_dispatch_pending \
>    --include-typedef GAsyncReadyCallback \
>    --include-typedef GSourceFunc \
>    --include-typedef GError
>
>
> Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race <philip.race at oracle.com>
> escreveu:
>
>> As a reminder, using FFM will require all FX *applications* to specify
>> --enable-native-access on the command line
>> Although this is likely coming to JNI soon too.
>>
>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>
>> But one thing to watch out for with FFM is startup + warm up time.
>> I struggled a lot with that in using FFM for just one library in the
>> java.desktop module.
>>
>> -phil
>>
>> On 4/22/24 9:12 AM, Nir Lisker wrote:
>>
>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the
>> N-1 rule.
>>
>> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>>
>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
>>> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
>>> very useful for JavaFX, but was told we shouldn't since it's not an LTS
>>> version.
>>>
>>> I have no idea how long the work on Wayland will take including the code
>>> review (a rather long process), but you should be able to request code
>>> reviews with FFM and have it ready for integration by Java 25.
>>>
>>> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
>>> thiago.sayao at gmail.com> wrote:
>>>
>>>> I was just experimenting, but it seems to be less work than going with
>>>> JNI.
>>>> If I am correct, the next Java LTS will be 25, which will be required
>>>> on JavaFX 29 to be released on September/29.
>>>>
>>>> It's 7 years - that's really too much.
>>>>
>>>> Maybe it's still worthwhile to prototype using FFM and then port
>>>> everything to JNI.
>>>>
>>>> -- Thiago.
>>>>
>>>>
>>>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>>>> kevin.rushforth at oracle.com> escreveu:
>>>>
>>>>> Note also that we cannot use Panama in the JavaFX internals yet, since
>>>>> the minimum version of the JDK is 21.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I did a small test app to explore Wayland client and portals (for
>>>>> > Robot and dialogs such as file open/save).
>>>>> >
>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>> >
>>>>> > It seems it will work as a glass backend, but some walls will be hit
>>>>> > on the way :)
>>>>> >
>>>>> > I have tried to use jextract (from project Panama) to work directly
>>>>> > with java, but it seems it does not support wl_ types.
>>>>> >
>>>>> > -- Thiago.
>>>>>
>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240422/3e2d7639/attachment-0001.htm>

From almatvee at openjdk.org  Mon Apr 22 19:51:34 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 22 Apr 2024 19:51:34 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v3]
In-Reply-To: <n0VycYyj7ZfG-JNhbf_Hj53Qypok5e9HUq_UfrQLqg4=.9cd9154f-0304-4e4c-96e8-05378b59167e@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
 <n0VycYyj7ZfG-JNhbf_Hj53Qypok5e9HUq_UfrQLqg4=.9cd9154f-0304-4e4c-96e8-05378b59167e@github.com>
Message-ID: <zhs9Brgiglowi4U2UubrTYBKnfF14mQGF2gbRUd1zLk=.50fb07dd-9da3-48a6-a49b-b39bfff97eed@github.com>

On Mon, 22 Apr 2024 15:05:07 GMT, n-gabe <duke at openjdk.org> wrote:

>> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.
>
> n-gabe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove needless copyright year

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1377#pullrequestreview-2015678699

From jhendrikx at openjdk.org  Tue Apr 23 05:30:48 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 05:30:48 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v16]
In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
Message-ID: <9O1m--toWgo7hEGYrIkdYWO-CzxlE2yXRuKKoMqoQb4=.0a7289fe-957b-448b-9f52-d0ba739b1c8a@github.com>

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
> 
> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent...

John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Make some tests conditional on platform
 - Fix typo
 - Merge branch 'master' of https://git.openjdk.org/jfx into feature/wrapped-aligned-text-rendering
 - Change test to use the more common Arial font and add assumptions
 - Add failing test to confirm build is running the TextLayoutTest
 - Fix test description
 - Improve test
   
   - Test TextSpans (rich text) and String text (plain text)
   - Add test cases for leading spaces, tabs
   - Fix justified test to take hard wrapped lines into account correctly
 - Convert class to record
 - Add some clarifying documentation
 - Do not collapse trailing spaces of last line (where no soft wrap occurs)
 - ... and 16 more: https://git.openjdk.org/jfx/compare/5182ea16...c3ca720c

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

Changes: https://git.openjdk.org/jfx/pull/1236/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=15
  Stats: 1007 lines in 7 files changed: 762 ins; 231 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/1236.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1236/head:pull/1236

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

From jhendrikx at openjdk.org  Tue Apr 23 05:33:36 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 05:33:36 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v15]
In-Reply-To: <Es7VB4L3mntmiQoX7IOEflDoISy7uxwx6M6qV1m5vRI=.a9984622-c06b-421a-b458-27c7dafaed89@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
 <Es7VB4L3mntmiQoX7IOEflDoISy7uxwx6M6qV1m5vRI=.a9984622-c06b-421a-b458-27c7dafaed89@github.com>
Message-ID: <aoLLenRAZCXcKQ0J5pVYC7z4ezrcjQSxGzJixYJDGOo=.3070ffe6-e111-47dd-a1e3-8257c2cace6b@github.com>

On Mon, 12 Feb 2024 10:00:57 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change test to use the more common Arial font and add assumptions
>
> I ran the tests in my Mac system with macOS 14.3 and found 2 tests are failing with following error:
> 
> 
> TextLayoutTest > caseTest(Case) > test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[10] FAILED
>     org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: <RectBounds { minX:0.0, minY:-10.863281, maxX:158.1914, maxY:2.9355469} (w:158.1914, h:13.798828)> but was: <RectBounds { minX:0.0, minY:-10.863281, maxX:155.3047, maxY:2.9355469} (w:155.3047, h:13.798828)>
>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>         at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
>         at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
>         at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
>         at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501)
> 
> TextLayoutTest > caseTest(Case) > test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[11] FAILED
>     org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps           over the lazy ??????, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: <RectBounds { minX:0.0, minY:-10.863281, maxX:158.1914, maxY:2.9355469} (w:158.1914, h:13.798828)> but was: <RectBounds { minX:0.0, minY:-10.863281, maxX:155.3047, maxY:2.9355469} (w:155.3047, h:13.798828)>
>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>         at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
>         at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
>         at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
>         at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501)
> 
> TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() SKIPPED
> 
> TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED
> 
> 
> The failing tests are SOFT_WRAP_WITH_COMPLEX_TEXT and SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE.
> 
> Added a minor comment inline as well.

@karthikpandelu @kevinrushforth @andy-goryachev-oracle 

I split the failing Mac tests into Windows and Mac variants.  However, the Mac specific tests probably still fail. If one of you could post the test errors, I can fix the values used as I don't have a Mac to test on.

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2071440980

From kpk at openjdk.org  Tue Apr 23 05:35:36 2024
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 23 Apr 2024 05:35:36 GMT
Subject: RFR: 8328577: Toolbar's overflow button overlaps the items [v6]
In-Reply-To: <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
 <H_tbAp7G68_GUzCVaXQivu4ylQqdCQoMbgZ8yVuyYwY=.7e738c4e-932b-44b9-a92d-013ba266f598@github.com>
Message-ID: <CwS5ra_nXAt6LRyznQfV-_yfW67Z3Iti9YU6XWC3PnY=.38733893-25fb-4624-8a9c-62f01e667297@github.com>

On Mon, 15 Apr 2024 15:41:19 GMT, eduardsdv <duke at openjdk.org> wrote:

>> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
>> It is now determined before the nodes are removed from the scene graph.
>> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
>> 
>> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.
>
> eduardsdv has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8328577: Refactor and fix binding of style related properties

Marked as reviewed by kpk (Committer).

Created [JDK-8330859](https://bugs.openjdk.org/browse/JDK-8330859) for tracking focus handling issue in toolbar

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

PR Review: https://git.openjdk.org/jfx/pull/1434#pullrequestreview-2016271085
PR Comment: https://git.openjdk.org/jfx/pull/1434#issuecomment-2071442595

From jhendrikx at openjdk.org  Tue Apr 23 05:54:37 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 05:54:37 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v15]
In-Reply-To: <LleP0qzppAupu6lc-Cl6XnAeRSL_nAVqSVN4hAZI9XE=.50e69720-3712-47f6-ab0a-3b94133049af@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
 <LleP0qzppAupu6lc-Cl6XnAeRSL_nAVqSVN4hAZI9XE=.50e69720-3712-47f6-ab0a-3b94133049af@github.com>
Message-ID: <feQzfAIq4v1_LakdxVUQA6Gv4xOWrADZIByXEArcHUs=.a1148d46-a428-4138-b139-06a44ef0d1c8@github.com>

On Mon, 22 Apr 2024 16:52:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> 2. resolve the problems with the fonts (could we pick the font(s) that are available via some utility method?)

I already left a comment on this before, see here: https://github.com/openjdk/jfx/pull/1236#issuecomment-1939200760

The `TextLayoutTest` tests the reflow logic in `PrismTextLayout`. The code under test is not platform or font specific, it doesn't have different branches for different fonts or platforms.  Adding more fonts for specific platforms therefore would exercise the exact same code paths twice without a tangible benefit.  If the tests fail for Tahoma, the same tests would fail for Monaco.  If it fails on one platform, the exact same failures would occur on another platform.

Duplicating the tests for a new font would require running the tests, checking all the exact metric values, and copying those to the duplicated test.  Adding new tests becomes more of a maintenance burden as now two tests need to be maintained and updated (both would fail if one fails).

Ideally, these tests should be real Unit tests, with a Font definition stored in `src/test/resources` and without requiring the FX platform to run -- the tested code is just some maths after all.  However, FX is insufficiently abstracted to allow for loading certain classes without the platform running, and storing a specific font in the repository may not be possible due to licensing issues (even just to check IF there are licensing issues).

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2071460931

From lkostyra at openjdk.org  Tue Apr 23 06:57:34 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 23 Apr 2024 06:57:34 GMT
Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for
 some index values
In-Reply-To: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com>
References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com>
Message-ID: <5N1nh4P3Yw-wwbjRoqT_D159d8D-4-WTKGxxAu0gbJU=.46fcd02b-cfb2-4335-a4a1-98d28219d25c@github.com>

On Sun, 24 Mar 2024 15:11:29 GMT, drmarmac <duke at openjdk.org> wrote:

> This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown.

LGTM

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

Marked as reviewed by lkostyra (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1432#pullrequestreview-2016405149

From lkostyra at openjdk.org  Tue Apr 23 10:39:58 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 23 Apr 2024 10:39:58 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
Message-ID: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>

JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.

In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.

Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

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

Commit messages:
 - Remove isRTTVolatile native call
 - Remove non-Ex D3D9 device and object

Changes: https://git.openjdk.org/jfx/pull/1445/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1445&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320563
  Stats: 138 lines in 18 files changed: 0 ins; 59 del; 79 mod
  Patch: https://git.openjdk.org/jfx/pull/1445.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1445/head:pull/1445

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

From lkostyra at openjdk.org  Tue Apr 23 10:39:59 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 23 Apr 2024 10:39:59 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <PzldjjGhQJKrklpf0ZBvNHflHOa2s_zBxqFGF0nKKfo=.8582c2fc-a9be-4d35-bfdc-bd79fdafa15d@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

modules/javafx.graphics/src/main/java/com/sun/prism/d3d/D3DRTTexture.java line 175:

> 173:     @Override
> 174:     public boolean isVolatile() {
> 175:         return false;

Quick note - this was checking on native side if we have non-Ex device and returning `true` if we did, `false` if D3D9 was initialized with Ex.

So far I only kept these changes within D3D backend. However, I checked the rest of the code and it seems that only D3D9 non-Ex ever returned anything else than `false`. Right now all the backends (d3d, egl, sw) return `false` in this method, which technically leaves a bit of dead code inside common part of Prism. Should we consider removing this method completely?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1445#discussion_r1576033831

From duke at openjdk.org  Tue Apr 23 11:35:51 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 23 Apr 2024 11:35:51 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v14]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <RMdG_4KTKzoNJ3RZXtvHVqWftsisbP3vFWvoa2QGGB4=.4cf004cb-0a38-4fee-81fb-68ac072f49a8@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:

 - Try to use StubToolkit
 - Refone comment

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/ab651984..9fdc5c64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=12-13

  Stats: 164 lines in 3 files changed: 102 ins; 59 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1442.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442

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

From duke at openjdk.org  Tue Apr 23 11:49:35 2024
From: duke at openjdk.org (eduardsdv)
Date: Tue, 23 Apr 2024 11:49:35 GMT
Subject: Integrated: 8328577: Toolbar's overflow button overlaps the items
In-Reply-To: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
References: <SihTuKXPVSY8OGgSd1obTog7WUbhBD99ajiUFN8_ImQ=.2b5f67df-fc92-47ca-865a-e4720fd0e6cf@github.com>
Message-ID: <e7kX4kywSRvE02Fdva15UPDjwGx3Ij-9HnbK8QPNino=.cb5c2650-f01d-4ca7-aea2-dfbabb050872@github.com>

On Thu, 28 Mar 2024 11:31:14 GMT, eduardsdv <duke at openjdk.org> wrote:

> This change fixes the calculation of which nodes go to the toolbar and which go to the overflow menu.
> It is now determined before the nodes are removed from the scene graph.
> This is important because the values returned by ``Node.prefWidth(..)``/``Node.prefHeight(..)`` may depend on whether the node is added to the scene graph.
> 
> Furthermore I corrected the ``hasOveflow`` value passed to the ``organizeOverflow(double, boolean)`` in ``correctOverflow(double)``.

This pull request has now been integrated.

Changeset: 3333740f
Author:    Eduard Sedov <eduard.sedov at zeiss.com>
Committer: Karthik P K <kpk at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/3333740f1faa5459027f5d078241ce0dc3a9f9cf
Stats:     275 lines in 2 files changed: 182 ins; 62 del; 31 mod

8328577: Toolbar's overflow button overlaps the items

Reviewed-by: angorya, kpk

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

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

From thiago.sayao at gmail.com  Tue Apr 23 12:11:53 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 23 Apr 2024 09:11:53 -0300
Subject: Wayland
In-Reply-To: <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
Message-ID: <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>

I'm doing some work here:
https://github.com/tsayao/glass-wayland

So far it's been a good experience to use FFM / jextract.

The idea is to plug it as a glass wayland backend when it's good enough.



Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker <nlisker at gmail.com>
escreveu:

> Not sure it helps with warmup, but marking a foreign function as critical
> can improve performance:
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
> .
>
> On Mon, Apr 22, 2024 at 10:02?PM Philip Race <philip.race at oracle.com>
> wrote:
>
>> No, it wasn't. I didn't even use jextracted code.
>> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
>> overhead on my MacBook
>> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
>> measured, so do these lazily if you can.
>> And warmup cost is that it takes about 10000 iterations to get code fully
>> compiled.
>>
>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>>      intx CompileThreshold                         =
>> 10000                                  {pd product} {default}
>>     double CompileThresholdScaling                  =
>> 1.000000                                  {product} {default}
>>     uintx IncreaseFirstTierCompileThresholdAt      =
>> 50                                        {product} {default}
>>      intx Tier2CompileThreshold                    =
>> 0                                         {product} {default}
>>      intx Tier3CompileThreshold                    =
>> 2000                                      {product} {default}
>>      intx Tier4CompileThreshold                    =
>> 15000                                     {product} {default}
>>
>> -phil.
>>
>>
>> On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>
>> I think the startup time might be related to all static symbol lookups.
>> So I'm manually including just what is needed:
>>
>> jextract --output src -t com.sun.glass.wayland.extracted \
>>   --header-class-name GlassWayland \
>>   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
>>   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
>>    glass-wayland.h \
>>    --include-function xdp_portal_initable_new \
>>    --include-function xdp_session_close \
>>    --include-function xdp_portal_open_file \
>>    --include-function xdp_portal_open_file_finish \
>>    --include-function g_object_unref \
>>    --include-function g_timeout_add \
>>    --include-function g_add_idle \
>>    --include-function g_main_loop_run \
>>    --include-function g_main_loop_new \
>>    --include-function g_main_loop_ref \
>>    --include-function g_main_loop_unref \
>>    --include-function g_main_loop_quit \
>>    --include-function g_settings_new \
>>    --include-function g_settings_get_int \
>>    --include-function wl_display_connect \
>>    --include-function wl_display_disconnect \
>>    --include-function wl_display_roundtrip \
>>    --include-function wl_display_dispatch_pending \
>>    --include-typedef GAsyncReadyCallback \
>>    --include-typedef GSourceFunc \
>>    --include-typedef GError
>>
>>
>> Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race <philip.race at oracle.com>
>> escreveu:
>>
>>> As a reminder, using FFM will require all FX *applications* to specify
>>> --enable-native-access on the command line
>>> Although this is likely coming to JNI soon too.
>>>
>>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>>
>>> But one thing to watch out for with FFM is startup + warm up time.
>>> I struggled a lot with that in using FFM for just one library in the
>>> java.desktop module.
>>>
>>> -phil
>>>
>>> On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>
>>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the
>>> N-1 rule.
>>>
>>> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>>>
>>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we did
>>>> with 21. I suggested initially to bump to Java 22 exactly for FFM as it's
>>>> very useful for JavaFX, but was told we shouldn't since it's not an LTS
>>>> version.
>>>>
>>>> I have no idea how long the work on Wayland will take including the
>>>> code review (a rather long process), but you should be able to request code
>>>> reviews with FFM and have it ready for integration by Java 25.
>>>>
>>>> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
>>>> thiago.sayao at gmail.com> wrote:
>>>>
>>>>> I was just experimenting, but it seems to be less work than going with
>>>>> JNI.
>>>>> If I am correct, the next Java LTS will be 25, which will be required
>>>>> on JavaFX 29 to be released on September/29.
>>>>>
>>>>> It's 7 years - that's really too much.
>>>>>
>>>>> Maybe it's still worthwhile to prototype using FFM and then port
>>>>> everything to JNI.
>>>>>
>>>>> -- Thiago.
>>>>>
>>>>>
>>>>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>>>>> kevin.rushforth at oracle.com> escreveu:
>>>>>
>>>>>> Note also that we cannot use Panama in the JavaFX internals yet,
>>>>>> since
>>>>>> the minimum version of the JDK is 21.
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I did a small test app to explore Wayland client and portals (for
>>>>>> > Robot and dialogs such as file open/save).
>>>>>> >
>>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>>> >
>>>>>> > It seems it will work as a glass backend, but some walls will be
>>>>>> hit
>>>>>> > on the way :)
>>>>>> >
>>>>>> > I have tried to use jextract (from project Panama) to work directly
>>>>>> > with java, but it seems it does not support wl_ types.
>>>>>> >
>>>>>> > -- Thiago.
>>>>>>
>>>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240423/32ed969d/attachment-0001.htm>

From duke at openjdk.org  Tue Apr 23 12:17:55 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 23 Apr 2024 12:17:55 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v15]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Add missing exports

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/9fdc5c64..874e1df4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=13-14

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

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

From tsayao at openjdk.org  Tue Apr 23 12:18:34 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 23 Apr 2024 12:18:34 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v3]
In-Reply-To: <7peXj3gequ3HGNd_FGJKchYB9ySQ784E1Y2Je2rU8gA=.0cffb403-0e41-4a76-a756-8a2649ad6db7@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <7peXj3gequ3HGNd_FGJKchYB9ySQ784E1Y2Je2rU8gA=.0cffb403-0e41-4a76-a756-8a2649ad6db7@github.com>
Message-ID: <m2pMzDAupVjar1c-IrOh6WUkUj0EUmfm22QayPMQVUQ=.e02e4737-15a5-4f56-858e-cbe2666467a9@github.com>

On Fri, 19 Apr 2024 14:42:23 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot debug message

I have to figure out how to  test  Monocle, since I have changed the logic of defines on `PrismES2Defs.h`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2072146467

From kpk at openjdk.org  Tue Apr 23 12:43:39 2024
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 23 Apr 2024 12:43:39 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v15]
In-Reply-To: <Es7VB4L3mntmiQoX7IOEflDoISy7uxwx6M6qV1m5vRI=.a9984622-c06b-421a-b458-27c7dafaed89@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
 <Es7VB4L3mntmiQoX7IOEflDoISy7uxwx6M6qV1m5vRI=.a9984622-c06b-421a-b458-27c7dafaed89@github.com>
Message-ID: <G5-qY0HgJSgJmngcNNWpEFTcYVMk-o9NiEaalt0dDH0=.410d29eb-1500-430a-a7c0-2cae67858cb5@github.com>

On Mon, 12 Feb 2024 10:00:57 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change test to use the more common Arial font and add assumptions
>
> I ran the tests in my Mac system with macOS 14.3 and found 2 tests are failing with following error:
> 
> 
> TextLayoutTest > caseTest(Case) > test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[10] FAILED
>     org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps over the lazy ??????, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: <RectBounds { minX:0.0, minY:-10.863281, maxX:158.1914, maxY:2.9355469} (w:158.1914, h:13.798828)> but was: <RectBounds { minX:0.0, minY:-10.863281, maxX:155.3047, maxY:2.9355469} (w:155.3047, h:13.798828)>
>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>         at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
>         at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
>         at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
>         at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501)
> 
> TextLayoutTest > caseTest(Case) > test.com.sun.javafx.text.TextLayoutTest.caseTest(Case)[11] FAILED
>     org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 0 for Parameters[text=The quick brown ?????? jumps           over the lazy ??????, wrapWidth=160.0, lineWidths=[158.1914, 93.134766]] ==> expected: <RectBounds { minX:0.0, minY:-10.863281, maxX:158.1914, maxY:2.9355469} (w:158.1914, h:13.798828)> but was: <RectBounds { minX:0.0, minY:-10.863281, maxX:155.3047, maxY:2.9355469} (w:155.3047, h:13.798828)>
>         at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
>         at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
>         at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
>         at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
>         at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:501)
> 
> TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() SKIPPED
> 
> TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED
> 
> 
> The failing tests are SOFT_WRAP_WITH_COMPLEX_TEXT and SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE.
> 
> Added a minor comment inline as well.

> @karthikpandelu @kevinrushforth @andy-goryachev-oracle
> 
> I split the failing Mac tests into Windows and Mac variants. However, the Mac specific tests probably still fail. If one of you could post the test errors, I can fix the values used as I don't have a Mac to test on.

Here is the result of TextLayoutTest in MacOS M1 system.

TextLayoutTest > caseTest(Case) > [12] SOFT_WRAP_WITH_COMPLEX_TEXT_ON_MAC FAILED
    org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 1 for SOFT_WRAP_WITH_COMPLEX_TEXT_ON_MAC ==> expected: <RectBounds { minX:0.0, minY:-10.863281, maxX:93.134766, maxY:2.9355469} (w:93.134766, h:13.798828)> but was: <RectBounds { minX:0.0, minY:-10.863281, maxX:91.04719, maxY:2.9355469} (w:91.04719, h:13.798828)>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
        at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:533)

TextLayoutTest > caseTest(Case) > [13] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE_ON_MAC FAILED
    org.opentest4j.AssertionFailedError: left aligned rich text (spans): line 1 for SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE_ON_MAC ==> expected: <RectBounds { minX:0.0, minY:-10.863281, maxX:93.134766, maxY:2.9355469} (w:93.134766, h:13.798828)> but was: <RectBounds { minX:0.0, minY:-10.863281, maxX:91.04719, maxY:2.9355469} (w:91.04719, h:13.798828)>
        at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55)
        at app//org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62)
        at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
        at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152)
        at app//test.com.sun.javafx.text.TextLayoutTest.caseTest(TextLayoutTest.java:533)


Following are the skipped tests:

TextLayoutTest > caseTest(Case) > [10] SOFT_WRAP_WITH_COMPLEX_TEXT_ON_WINDOWS SKIPPED

TextLayoutTest > caseTest(Case) > [11] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE_ON_WINDOWS SKIPPED

TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() SKIPPED

TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2072197356

From jhendrikx at openjdk.org  Tue Apr 23 13:41:55 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 13:41:55 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v17]
In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
Message-ID: <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
> 
> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent...

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

  Fix mac test values

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1236/files
  - new: https://git.openjdk.org/jfx/pull/1236/files/c3ca720c..6b8f18d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=15-16

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

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

From jhendrikx at openjdk.org  Tue Apr 23 13:41:56 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 13:41:56 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v15]
In-Reply-To: <G5-qY0HgJSgJmngcNNWpEFTcYVMk-o9NiEaalt0dDH0=.410d29eb-1500-430a-a7c0-2cae67858cb5@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <-iVac1XhWZW3QXw-KgL_LLMX_93RXtBf44w8zXEEK20=.fadc80f6-2060-4ea9-bf25-90b7359bbbe9@github.com>
 <Es7VB4L3mntmiQoX7IOEflDoISy7uxwx6M6qV1m5vRI=.a9984622-c06b-421a-b458-27c7dafaed89@github.com>
 <G5-qY0HgJSgJmngcNNWpEFTcYVMk-o9NiEaalt0dDH0=.410d29eb-1500-430a-a7c0-2cae67858cb5@github.com>
Message-ID: <36ZTgCAsX5Uq3w4x3TgIT4XBGqy4XTj2l27h5cTP8D8=.37b1cdea-62b3-4a01-8551-365dad65b1ba@github.com>

On Tue, 23 Apr 2024 12:40:57 GMT, Karthik P K <kpk at openjdk.org> wrote:

> Here is the result of TextLayoutTest in MacOS M1 system.

Thanks very much, I've updated the values now, so no tests should fail anymore on Mac.
 
> Following are the skipped tests:
> 
> ```
> TextLayoutTest > caseTest(Case) > [10] SOFT_WRAP_WITH_COMPLEX_TEXT_ON_WINDOWS SKIPPED
> 
> TextLayoutTest > caseTest(Case) > [11] SOFT_WRAP_WITH_COMPLEX_TEXT_AND_EXTRA_SPACE_ON_WINDOWS SKIPPED
> 
> TextLayoutTest > fixedComplexTestsToEnsureNoFurtherRegressions() SKIPPED
> 
> TextLayoutTest > complexTestsThatAreBrokenSince2013() SKIPPED
> ```

That looks as expected.

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2072350141

From duke at openjdk.org  Tue Apr 23 15:02:39 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 23 Apr 2024 15:02:39 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v15]
In-Reply-To: <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
Message-ID: <D46Xkl4Bd_KLqHGCgeyab0JMXtQmYygIhyCbuINSaR0=.be32b6bb-a49e-4825-ad3c-8f51b8d004b2@github.com>

On Tue, 23 Apr 2024 12:17:55 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing exports

I was thinking about diving into this accessible area. Did not find any existing test and wanted to start with something small (in `test.javafx.scene.control.TextFieldTest`).


    @Test public void setTextAndSeeValueAccessible() throws Exception {
        StackPane stackPane = new StackPane();
        Scene scene = new Scene(stackPane);
        Accessible accessible = SceneHelper.getAccessible(scene);
        TextField textField = new TextField();
        stackPane.getChildren().add(textField);
        textField.setText("This is a test");
        assertEquals("This is a test", accessible.getAttribute(AccessibleAttribute.TEXT));
    }


Fails, because `SceneHelper.getAccessible(scene)` returns `null`. I am not that much into the accessibility activation things - and did not find any accessibility tests.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2072595295

From duke at openjdk.org  Tue Apr 23 17:47:03 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 23 Apr 2024 17:47:03 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:

 - Fix JavaDoc formatting
 - Discard changes to modules/javafx.graphics/src/test/addExports

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/874e1df4..11ddd86b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=14-15

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

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

From duke at openjdk.org  Tue Apr 23 17:47:04 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 23 Apr 2024 17:47:04 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v15]
In-Reply-To: <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
Message-ID: <gLx3J1MnrYf2A6epEAV9khIs9aczlP-RBEhHa7I_m5Q=.5831fb6c-adbf-4bb3-b0d8-06abc5d9fd64@github.com>

On Tue, 23 Apr 2024 12:17:55 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing exports

tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 48:

> 46: import static org.junit.jupiter.api.Assertions.assertEquals;
> 47: 
> 48: @EnabledOnOs({OS.WINDOWS})

I did not use `Platform`s OS detection, because this seems to be more resource friendly and native JUnit5. I can switch to the style of `test.com.sun.glass.ui.gtk.Gtk2RemovalCommon`, i.e., use `if (!PlatformUtil.isWindows()) return;` in all test methdos.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1576649207

From duke at openjdk.org  Tue Apr 23 18:23:35 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Tue, 23 Apr 2024 18:23:35 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
 <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
Message-ID: <qdjRwnZrj5-RDoA6T27QgWBq-Htfnx2ekAx0a0vpsGo=.cd56399d-7b2c-4678-9520-806676773009@github.com>

On Fri, 19 Apr 2024 17:33:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I am new to testing in the JFX project. It seems that `test.` is required as package prefix. Thus, I did not use the approach of package-private methods and classes, but needed to make the class and the tested method public.
>> 
>> However, now I get the (expected) error that the module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.
>> 
>> 
>> class test.com.sun.glass.ui.win.WinTextRangeProviderTest (in unnamed module @0x1e6454ec) cannot access class com.sun.glass.ui.win.WinTextRangeProvider (in module javafx.graphics) because module javafx.graphics does not export com.sun.glass.ui.win to unnamed module @0x1e6454ec
>> java.lang.IllegalAccessError: class test.com.sun.glass.ui.win.WinTextRangeProviderTest (in unnamed module @0x1e6454ec) cannot access class com.sun.glass.ui.win.WinTextRangeProvider (in module javafx.graphics) because module javafx.graphics does not export com.sun.glass.ui.win to unnamed module @0x1e6454ec
>> 	at test.com.sun.glass.ui.win.WinTextRangeProviderTest.getValidStringIndex
>
>> module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.
> 
> I think you need to add
> 
> --add-exports javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED
> 
> to graphics/src/test/addExports
> (see line 7)
> 
> @kevinrushforth I wonder if there was a way to auto-generate addExports somehow, at least the part needed for the tests.

@andy-goryachev-oracle I think, I'm finished. (The "tests" requested at https://github.com/openjdk/jfx/pull/1442#issuecomment-2064196119 were IMHO the "simple" unit tests I provided - not some accessibility engine tests)

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2073091386

From angorya at openjdk.org  Tue Apr 23 18:31:40 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 18:31:40 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v12]
In-Reply-To: <JldIu5PTOTkqAk9tOsW6ym4JRvl01HIaT8jp4gK_wI8=.e892d4a8-a287-47cd-971d-b4111e7ad244@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <m8NLb4RkXHfDaaSZD267s4nYNLKCyVWaSLnJFP7sv1U=.2a57df32-4f4a-430b-a9ae-affcc82c46a8@github.com>
 <nxm9UFZneRCIjJri3as3FjA_73yDEX73ZbUkrFsEBw0=.4af73ec4-0b23-4cc3-b579-91f7363bc2c8@github.com>
 <JldIu5PTOTkqAk9tOsW6ym4JRvl01HIaT8jp4gK_wI8=.e892d4a8-a287-47cd-971d-b4111e7ad244@github.com>
Message-ID: <WdDzRN20fNujRnUkP1WQgvmVPXXBB4LQym9WtbTezJA=.9d9726b8-fe76-423c-bdea-b8a88e2cca42@github.com>

On Fri, 9 Feb 2024 21:34:33 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved.
>> 
>> weird, github shows this file as new, but it is not.
>> 2024
>
> It's sort of new, it's moved, it used to reside in the graphics project, but as it needs real fonts for its tests to work, it had to be a system test.

since it's been modified, please change the year

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1576637908

From angorya at openjdk.org  Tue Apr 23 18:31:42 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 18:31:42 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v17]
In-Reply-To: <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
Message-ID: <wu-xt4U0wmDjUEhdZ8lGPs9dUCWvCzjWFwbOmlWkauQ=.d94abd31-b9ec-4f8e-8b6a-d8cd2803ee3c@github.com>

On Tue, 23 Apr 2024 13:41:55 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix mac test values

tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 430:

> 428:         SOFT_WRAP_WITH_COMPLEX_TEXT_ON_WINDOWS(
> 429:             TextLayoutTest::assumeWindows,
> 430:             "The quick brown ?????? jumps over the lazy ??????",

I hope this translates well... :-)

tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 453:

> 451:             TextLayoutTest::assumeMac,
> 452:             "The quick brown ?????? jumps over the lazy ??????",
> 453:             160.0f, List.of(155.3047f, 91.04719f)

Question: these numbers are compared exactly (Float::compare), can we expect them to be exactly the same on all possible platforms/versions?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1576631367
PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1576647271

From angorya at openjdk.org  Tue Apr 23 19:03:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 19:03:39 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v15]
In-Reply-To: <gLx3J1MnrYf2A6epEAV9khIs9aczlP-RBEhHa7I_m5Q=.5831fb6c-adbf-4bb3-b0d8-06abc5d9fd64@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
 <gLx3J1MnrYf2A6epEAV9khIs9aczlP-RBEhHa7I_m5Q=.5831fb6c-adbf-4bb3-b0d8-06abc5d9fd64@github.com>
Message-ID: <8WqwFMUZ-Qt1STd9e3rJwHVWeQaXXsC6wLBRh62BQuk=.c68dd64a-d132-4f34-9b14-93cd3d0c8e21@github.com>

On Tue, 23 Apr 2024 17:42:03 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing exports
>
> tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 48:
> 
>> 46: import static org.junit.jupiter.api.Assertions.assertEquals;
>> 47: 
>> 48: @EnabledOnOs({OS.WINDOWS})
> 
> I did not use `Platform`s OS detection, because this seems to be more resource friendly and native JUnit5. I can switch to the style of `test.com.sun.glass.ui.gtk.Gtk2RemovalCommon`, i.e., use `if (!PlatformUtil.isWindows()) return;` in all test methdos.

Interesting = @kevinrushforth what do you think?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1576763192

From jhendrikx at openjdk.org  Tue Apr 23 19:04:41 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 19:04:41 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v17]
In-Reply-To: <wu-xt4U0wmDjUEhdZ8lGPs9dUCWvCzjWFwbOmlWkauQ=.d94abd31-b9ec-4f8e-8b6a-d8cd2803ee3c@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
 <wu-xt4U0wmDjUEhdZ8lGPs9dUCWvCzjWFwbOmlWkauQ=.d94abd31-b9ec-4f8e-8b6a-d8cd2803ee3c@github.com>
Message-ID: <B1fdx-0AQ4MNJBf3m85tXA0fVHo-HK2Rra7Dfk2zhKM=.639ae9b1-d45c-4c71-9c25-97e171a97a77@github.com>

On Tue, 23 Apr 2024 17:30:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix mac test values
>
> tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 430:
> 
>> 428:         SOFT_WRAP_WITH_COMPLEX_TEXT_ON_WINDOWS(
>> 429:             TextLayoutTest::assumeWindows,
>> 430:             "The quick brown ?????? jumps over the lazy ??????",
> 
> I hope this translates well... :-)

I doubt it :)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1576764217

From jhendrikx at openjdk.org  Tue Apr 23 19:24:37 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 19:24:37 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v17]
In-Reply-To: <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
Message-ID: <E_bFegCbth8nz0Hh_lggwErYPEmEbkjmbbrEFJszooA=.1098ae02-9170-4e85-ae64-0ac9a5dd9495@github.com>

On Tue, 23 Apr 2024 13:41:55 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix mac test values

> since it's been modified, please change the year

Sorry, I stopped doing that, I thought this was automated.

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2073242347

From jhendrikx at openjdk.org  Tue Apr 23 19:24:38 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 19:24:38 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v17]
In-Reply-To: <wu-xt4U0wmDjUEhdZ8lGPs9dUCWvCzjWFwbOmlWkauQ=.d94abd31-b9ec-4f8e-8b6a-d8cd2803ee3c@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
 <wu-xt4U0wmDjUEhdZ8lGPs9dUCWvCzjWFwbOmlWkauQ=.d94abd31-b9ec-4f8e-8b6a-d8cd2803ee3c@github.com>
Message-ID: <uyXc2SSVu-H2wnLsWF187NL3R9oGVFJjRAZwRA7bzmA=.710bcb3f-8cfb-4392-b86f-1c2b8b616613@github.com>

On Tue, 23 Apr 2024 17:40:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix mac test values
>
> tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 453:
> 
>> 451:             TextLayoutTest::assumeMac,
>> 452:             "The quick brown ?????? jumps over the lazy ??????",
>> 453:             160.0f, List.of(155.3047f, 91.04719f)
> 
> Question: these numbers are compared exactly (Float::compare), can we expect them to be exactly the same on all possible platforms/versions?

Exact comparisons on float numbers should not be a problem, as long as you don't assume that with a different order of operations you will get the same result.  For example, `y + x - y` may not exactly equal `x + y - y` or `x`.  Since we don't have different code paths for different platforms, and since all code paths are deterministic(*), it should be fine to do an exact comparison. 

If this ever does fail, I think then is a good time to do a more thorough investigation. So far these tests have run dozens of time on my machine, and on several of the machines of people reviewing without problems.

(*) In tests, the most often encountered source of non-determinism in Java is when a `Set` or `Map` is involved which contains objects with the default hash code which can change each time a new JVM is created; usually I change such collections to linked versions, or do an explicit sort somewhere to ensure it is deterministic again.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1576784350

From angorya at openjdk.org  Tue Apr 23 19:27:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 19:27:36 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v17]
In-Reply-To: <uyXc2SSVu-H2wnLsWF187NL3R9oGVFJjRAZwRA7bzmA=.710bcb3f-8cfb-4392-b86f-1c2b8b616613@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <VbVuqFNkXp12UGlS3g6cgw4yMyehQXVE7j71JNHNfDw=.75322cc6-795d-44fe-9eb1-115e99830073@github.com>
 <wu-xt4U0wmDjUEhdZ8lGPs9dUCWvCzjWFwbOmlWkauQ=.d94abd31-b9ec-4f8e-8b6a-d8cd2803ee3c@github.com>
 <uyXc2SSVu-H2wnLsWF187NL3R9oGVFJjRAZwRA7bzmA=.710bcb3f-8cfb-4392-b86f-1c2b8b616613@github.com>
Message-ID: <Tx7TzGzruPIF4Xfe83M4zwgQK5Dy6Vnhs1HqcyxQQ9M=.0ded1719-ea19-4984-b5ad-27eb44e6baf8@github.com>

On Tue, 23 Apr 2024 19:20:22 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> tests/system/src/test/java/test/com/sun/javafx/text/TextLayoutTest.java line 453:
>> 
>>> 451:             TextLayoutTest::assumeMac,
>>> 452:             "The quick brown ?????? jumps over the lazy ??????",
>>> 453:             160.0f, List.of(155.3047f, 91.04719f)
>> 
>> Question: these numbers are compared exactly (Float::compare), can we expect them to be exactly the same on all possible platforms/versions?
>
> Exact comparisons on float numbers should not be a problem, as long as you don't assume that with a different order of operations you will get the same result.  For example, `y + x - y` may not exactly equal `x + y - y` or `x`.  Since we don't have different code paths for different platforms, and since all code paths are deterministic(*), it should be fine to do an exact comparison. 
> 
> If this ever does fail, I think then is a good time to do a more thorough investigation. So far these tests have run dozens of time on my machine, and on several of the machines of people reviewing without problems.
> 
> (*) In tests, the most often encountered source of non-determinism in Java is when a `Set` or `Map` is involved which contains objects with the default hash code which can change each time a new JVM is created; usually I change such collections to linked versions, or do an explicit sort somewhere to ensure it is deterministic again.

makes sense, thank you.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1236#discussion_r1576788278

From jhendrikx at openjdk.org  Tue Apr 23 19:30:49 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 23 Apr 2024 19:30:49 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
Message-ID: <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
> 
> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent...

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

  Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1236/files
  - new: https://git.openjdk.org/jfx/pull/1236/files/6b8f18d0..9bdd8f86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1236&range=16-17

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

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

From angorya at openjdk.org  Tue Apr 23 19:47:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 19:47:37 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
Message-ID: <CigPqPs6EpRGMz66j7k9GBEJE2FveOvjG8JkllS9wp4=.1aadde16-c29b-404f-9104-1d84794ce4fb@github.com>

On Tue, 23 Apr 2024 19:30:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

LGTM!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1236#pullrequestreview-2018157978

From angorya at openjdk.org  Tue Apr 23 20:12:36 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 20:12:36 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
Message-ID: <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>

On Tue, 23 Apr 2024 17:47:03 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix JavaDoc formatting
>  - Discard changes to modules/javafx.graphics/src/test/addExports

tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 28:

> 26: 
> 27: import com.sun.javafx.PlatformUtil;
> 28: import com.sun.glass.ui.win.WinTextRangeProviderShim;

this generates an error in Eclipse (the project dependencies must be fixed)


Description	Resource	Path	Location
The import com.sun.glass.ui.win cannot be resolved	WinTextRangeProviderTest.java	/systemTests-test/java/test/com/sun/glass/ui/win	line 28

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1576838501

From angorya at openjdk.org  Tue Apr 23 20:26:35 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 20:26:35 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
 <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>
Message-ID: <okjowXYxvSW2Cx2Cjkea55JuwMY6g7scU4pXZxxC-ZM=.244b915e-201b-4b84-81c4-c5dbe7e4ae83@github.com>

On Tue, 23 Apr 2024 20:09:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix JavaDoc formatting
>>  - Discard changes to modules/javafx.graphics/src/test/addExports
>
> tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 28:
> 
>> 26: 
>> 27: import com.sun.javafx.PlatformUtil;
>> 28: import com.sun.glass.ui.win.WinTextRangeProviderShim;
> 
> this generates an error in Eclipse (the project dependencies must be fixed)
> 
> 
> Description	Resource	Path	Location
> The import com.sun.glass.ui.win cannot be resolved	WinTextRangeProviderTest.java	/systemTests-test/java/test/com/sun/glass/ui/win	line 28

Please replace tests/system/src/test/.classpath with this:


<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry combineaccessrules="false" kind="src" path="/swing">
		<attributes>
			<attribute name="module" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry combineaccessrules="false" kind="src" path="/base">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="javafx.base/com.sun.javafx=ALL-UNNAMED:javafx.base/test.util.memory=ALL-UNNAMED"/>
		</attributes>
	</classpathentry>
	<classpathentry combineaccessrules="false" kind="src" path="/graphics">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="javafx.graphics/com.sun.glass.ui=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.monocle=ALL-UNNAMED:javafx.graphics/com.sun.javafx.sg.prism=ALL-UNNAMED:javafx.graphics/com.sun.prism.impl=ALL-UNNAMED:javafx.graphics/com.sun.javafx.image.impl=ALL-UNNAMED:javafx.graphics/com.sun.glass.events=ALL-UNNAMED:javafx.graphics/com.sun.javafx.application=ALL-UNNAMED:javafx.graphics/com.sun.javafx.css=ALL-UNNAMED:javafx.graphics/com.sun.javafx.geom=ALL-UNNAMED:javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.mac=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED:javafx.graphics/com.sun.javafx.scene.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.font=ALL-UNNAMED"/>
		</attributes>
	</classpathentry>
	<classpathentry combineaccessrules="false" kind="src" path="/controls">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="javafx.controls/test.com.sun.javafx.scene.control.infrastructure=ALL-UNNAMED:javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED"/>
		</attributes>
	</classpathentry>
	<classpathentry combineaccessrules="false" kind="src" path="/fxml">
		<attributes>
			<attribute name="module" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry combineaccessrules="false" kind="src" path="/web">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="javafx.web/com.sun.webkit=ALL-UNNAMED"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
		<attributes>
			<attribute name="module" value="true"/>
			<attribute name="add-exports" value="java.desktop/sun.awt.datatransfer=ALL-UNNAMED"/>
		</attributes>
	</classpathentry>
    <classpathentry kind="con" path="org.eclipse.jdt.junit.JUNIT_CONTAINER/5">
        <attributes>
            <attribute name="test" value="true"/>
        </attributes>
    </classpathentry>
	<classpathentry kind="src" output="bin" path="java">
	    <attributes>
            <attribute name="gradle_scope" value="test"/>
            <attribute name="gradle_used_by_scope" value="test"/>
            <attribute name="test" value="true"/>
        </attributes>
	</classpathentry>
	<classpathentry kind="src" output="bin" path="resources">
        <attributes>
            <attribute name="gradle_scope" value="test"/>
            <attribute name="gradle_used_by_scope" value="test"/>
            <attribute name="test" value="true"/>
        </attributes>
    </classpathentry>
	<classpathentry kind="output" path="bin"/>
</classpath>


(the only change is on line 17)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1576851560

From angorya at openjdk.org  Tue Apr 23 20:45:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 23 Apr 2024 20:45:34 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
Message-ID: <hBLKobguoIGiecGDrB8qYcEefTxAfeB8NKcS3upbDkQ=.1c3d6523-8f03-48be-9f3f-2df64ff7841f@github.com>

On Tue, 23 Apr 2024 17:47:03 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix JavaDoc formatting
>  - Discard changes to modules/javafx.graphics/src/test/addExports

Turns out I cannot reproduce the issue on my windows 11 setup.
Installed deepl app, ctrl-c-c pops up the translation window, translation works, close the window, start the test app - can type into a TextField just fine.

the code looks ok to me, one change must be made to a .classpath file - take a look at
https://github.com/andy-goryachev-oracle/jfx/pull/new/review.1442
branch (I think you can just merge it into yours)

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

PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2018266546

From johan.vos at gluonhq.com  Wed Apr 24 07:19:01 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 24 Apr 2024 09:19:01 +0200
Subject: parallel threads when building webkit
Message-ID: <CABxFH2HtYWF3=2bUp192QUek6F0oYguePMW12cAFXBA5f6ivnA@mail.gmail.com>

Hi,

When building WebKit from the sources, the perl script that invokes the
cmake/make build (build-webkit) will by default set the number of build
threads to the number of available cores.
This is often a bad idea, e.g. with 20 cores and 32GB this leads to a
freeze of the system.

As far as I know, we do not allow passing the number of parallel build
threads (I typically modify them in the perl script). We already have the
"NUM_COMPILE_THREADS" property in the build.gradle but we do not use that
when building webkit. We only pass `--cmakeargs` to the buildscript, and
the number of threads is set via e.g. `--makeargs=-j16`

Is there a known other way to do this, or should we add passing the
NUM_COMPILE_THREADS via `--makeargs` in the build.gradle?

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240424/62fb5a2d/attachment.htm>

From duke at openjdk.org  Wed Apr 24 07:27:56 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 07:27:56 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v17]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <2kUAQEs12wu0_f0Bu9gxfHnRkVIPN23MTEI9BH4s9ug=.fa61eba8-3a93-49f0-a4bd-336d5c0d9582@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  classpath

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/11ddd86b..548f58ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=16
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=15-16

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

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

From duke at openjdk.org  Wed Apr 24 07:45:50 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 07:45:50 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v18]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <DlnKiwtAo7aqjt2zL-nVjLO3yr8WPebVZ9pZOV_N_3g=.e4d17879-c69f-4f74-b73a-39032e683dbc@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/548f58ad..2b31881e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=17
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=16-17

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

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

From duke at openjdk.org  Wed Apr 24 07:48:35 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 07:48:35 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <okjowXYxvSW2Cx2Cjkea55JuwMY6g7scU4pXZxxC-ZM=.244b915e-201b-4b84-81c4-c5dbe7e4ae83@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
 <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>
 <okjowXYxvSW2Cx2Cjkea55JuwMY6g7scU4pXZxxC-ZM=.244b915e-201b-4b84-81c4-c5dbe7e4ae83@github.com>
Message-ID: <oPxU-Qo3xwd2D3OUez4SMHND6e90NBmGlaeWKRVTW84=.48054c7f-288e-49dd-8f0f-255205d8bb2a@github.com>

On Tue, 23 Apr 2024 20:23:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 28:
>> 
>>> 26: 
>>> 27: import com.sun.javafx.PlatformUtil;
>>> 28: import com.sun.glass.ui.win.WinTextRangeProviderShim;
>> 
>> this generates an error in Eclipse (the project dependencies must be fixed)
>> 
>> 
>> Description	Resource	Path	Location
>> The import com.sun.glass.ui.win cannot be resolved	WinTextRangeProviderTest.java	/systemTests-test/java/test/com/sun/glass/ui/win	line 28
>
> Please replace tests/system/src/test/.classpath with this:
> 
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
> 	<classpathentry combineaccessrules="false" kind="src" path="/swing">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 		</attributes>
> 	</classpathentry>
> 	<classpathentry combineaccessrules="false" kind="src" path="/base">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 			<attribute name="add-exports" value="javafx.base/com.sun.javafx=ALL-UNNAMED:javafx.base/test.util.memory=ALL-UNNAMED"/>
> 		</attributes>
> 	</classpathentry>
> 	<classpathentry combineaccessrules="false" kind="src" path="/graphics">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 			<attribute name="add-exports" value="javafx.graphics/com.sun.glass.ui=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.monocle=ALL-UNNAMED:javafx.graphics/com.sun.javafx.sg.prism=ALL-UNNAMED:javafx.graphics/com.sun.prism.impl=ALL-UNNAMED:javafx.graphics/com.sun.javafx.image.impl=ALL-UNNAMED:javafx.graphics/com.sun.glass.events=ALL-UNNAMED:javafx.graphics/com.sun.javafx.application=ALL-UNNAMED:javafx.graphics/com.sun.javafx.css=ALL-UNNAMED:javafx.graphics/com.sun.javafx.geom=ALL-UNNAMED:javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.mac=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED:javafx.graphics/com.sun.javafx.scene.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.font=ALL-UNNAMED"/>
> 		</attributes>
> 	</classpathentry>
> 	<classpathentry combineaccessrules="false" kind="src" path="/controls">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 			<attribute name="add-exports" value="javafx.controls/test.com.sun.javafx.scene.control.infrastructure=ALL-UNNAMED:javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED"/>
> 		</attributes>
> 	</classpathentry>
> 	<classpathentry combineaccessrules="false" kind="src" path="/fxml">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 		</attributes>
> 	</classpathentry>
> 	<classpathentry combineaccessrules="false" kind="src" path="/web">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 			<attribute name="add-exports" value="javafx.web/com.sun.webkit=ALL-UNNAMED"/>
> 		</attributes>
> 	</classpathentry>
> 	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
> 		<attributes>
> 			<attribute name="module" value="true"/>
> 			<attribute name="add-exports" value="java.desktop/sun.awt.datatransfer=ALL-UNNAMED"/>
> 		</attributes>
> 	...

Done.

I opened the project in Eclipse (instead of IntelliJ). How can I run the test in Eclipse?

A simple "run" does not work, because the output is then:


WARNING: Unknown module: javafx.base specified to --patch-module
WARNING: Unknown module: javafx.web specified to --patch-module
WARNING: Unknown module: javafx.controls specified to --patch-module
WARNING: Unknown module: javafx.graphics specified to --patch-module


How do I need to modify the JUnit "run configuration" inside Eclipse?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1577436180

From duke at openjdk.org  Wed Apr 24 08:31:48 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 08:31:48 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v19]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <NvNm-LMVsmIHqd7O6Z5rhjEeoTO8-6vvqh8FWZq6Wqs=.3157d2e2-aaa2-4ab7-9ff8-adf3b512de0d@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Fix tests

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/2b31881e..974bf468

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=18
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=17-18

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

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

From duke at openjdk.org  Wed Apr 24 08:31:48 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 08:31:48 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v18]
In-Reply-To: <DlnKiwtAo7aqjt2zL-nVjLO3yr8WPebVZ9pZOV_N_3g=.e4d17879-c69f-4f74-b73a-39032e683dbc@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <DlnKiwtAo7aqjt2zL-nVjLO3yr8WPebVZ9pZOV_N_3g=.e4d17879-c69f-4f74-b73a-39032e683dbc@github.com>
Message-ID: <JHN8FktHDO7xSwJCRDMl5TFnH74Er0YqI6SoPeIiMSE=.155329e5-f482-495d-a353-6ae955d9db31@github.com>

On Wed, 24 Apr 2024 07:45:50 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import

Note that the tests need to be run using `FULL_TEST = true`. IMHO setting it in `gradle.properties` is enough. I tried the command line `./gradlew --info -PFULL_TEST=true -PTEST_ONLY=true test`, which worked, too.

I needed to start the tests manually, because the CI did not cover that case:

    ./gradlew --info -PFULL_TEST=true -PTEST_ONLY=true systemTests:test --tests "test.com.sun.glass.ui.win.WinTextRangeProviderTest"

The tests needed a fix. Done in 974bf468c82.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2074385269

From thiago.sayao at gmail.com  Wed Apr 24 10:14:45 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 24 Apr 2024 07:14:45 -0300
Subject: parallel threads when building webkit
In-Reply-To: <CABxFH2HtYWF3=2bUp192QUek6F0oYguePMW12cAFXBA5f6ivnA@mail.gmail.com>
References: <CABxFH2HtYWF3=2bUp192QUek6F0oYguePMW12cAFXBA5f6ivnA@mail.gmail.com>
Message-ID: <CAAP_wunDH8+QXuiDoY=_8sY4XBGU5N0c3sK_1qcYxMyerHaCgw@mail.gmail.com>

Johan,

I often have to try to build it a few times before it succeeds (on Linux).
And I used an old Ryzen 7 1700X with 16 threads, 16GB. I have now upgraded
it, but I haven't built webkit yet. I'm really scared of it :)

So limiting the threads seems like a good idea.


Em qua., 24 de abr. de 2024 ?s 04:23, Johan Vos <johan.vos at gluonhq.com>
escreveu:

> Hi,
>
> When building WebKit from the sources, the perl script that invokes the
> cmake/make build (build-webkit) will by default set the number of build
> threads to the number of available cores.
> This is often a bad idea, e.g. with 20 cores and 32GB this leads to a
> freeze of the system.
>
> As far as I know, we do not allow passing the number of parallel build
> threads (I typically modify them in the perl script). We already have the
> "NUM_COMPILE_THREADS" property in the build.gradle but we do not use that
> when building webkit. We only pass `--cmakeargs` to the buildscript, and
> the number of threads is set via e.g. `--makeargs=-j16`
>
> Is there a known other way to do this, or should we add passing the
> NUM_COMPILE_THREADS via `--makeargs` in the build.gradle?
>
> - Johan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240424/f2ed538e/attachment-0001.htm>

From johan.vos at gluonhq.com  Wed Apr 24 11:42:14 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 24 Apr 2024 13:42:14 +0200
Subject: shutdown after test
Message-ID: <CABxFH2F7P0UxSxecTxTQa2BXLgzOzw14XC5svO_8U3eieeOPhw@mail.gmail.com>

While working on the systemtests for the Headless platform, I noticed
timing issues with the Marlin QPath Test. Those have nothing to do with
Marlin, but rather with the lifecycle. After the test ran,
`test.util.Shutdown` is invoked (not on the JavaFX app thread). I noticed
that this caused a timeout almost always when running the systemtest with
the headless platform, and almost never when running with the regular (Gtk)
platform.
The problem is that the `test.util.Shutdown` method is invoking
Platform.runLater() but in some cases (almost always in Headless and almost
never in GTK) the runLater is not accepting runnables anymore. This happens
because of the PlatformImpl.checkIdle which will shutdown the platform in
case there are no windows and no pending runnables (and a few more
conditions). This check runs on the JavaFX app thread, and it might trigger
`tkExit` before the test-thread invokes `test.util.Shutdown`.

There are a number of ways to solve this, e.g.
* get rid of the separate shutdown procedure in the system tests.
* set Platform.setImplicitExit(false) which will prevent tkExit being
called when the last window is gone
* add more safety in test.util.Shutdown so that it doesn't try to use the
FX App thread when that is not accepting new runnables
* ...

Thoughts?

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240424/3463de31/attachment.htm>

From thiago.sayao at gmail.com  Wed Apr 24 12:30:50 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Wed, 24 Apr 2024 09:30:50 -0300
Subject: shutdown after test
In-Reply-To: <CABxFH2F7P0UxSxecTxTQa2BXLgzOzw14XC5svO_8U3eieeOPhw@mail.gmail.com>
References: <CABxFH2F7P0UxSxecTxTQa2BXLgzOzw14XC5svO_8U3eieeOPhw@mail.gmail.com>
Message-ID: <CAAP_wukth1HsJaZcrrWtA1rUoxPp4_yYWJAz8M1McC3zbcrPHg@mail.gmail.com>

I don't know if it's related. But when running systemTests with Robot, it
gets stuck on a Swing test - it never exits.


Em qua., 24 de abr. de 2024 ?s 08:42, Johan Vos <johan.vos at gluonhq.com>
escreveu:

> While working on the systemtests for the Headless platform, I noticed
> timing issues with the Marlin QPath Test. Those have nothing to do with
> Marlin, but rather with the lifecycle. After the test ran,
> `test.util.Shutdown` is invoked (not on the JavaFX app thread). I noticed
> that this caused a timeout almost always when running the systemtest with
> the headless platform, and almost never when running with the regular (Gtk)
> platform.
> The problem is that the `test.util.Shutdown` method is invoking
> Platform.runLater() but in some cases (almost always in Headless and almost
> never in GTK) the runLater is not accepting runnables anymore. This happens
> because of the PlatformImpl.checkIdle which will shutdown the platform in
> case there are no windows and no pending runnables (and a few more
> conditions). This check runs on the JavaFX app thread, and it might trigger
> `tkExit` before the test-thread invokes `test.util.Shutdown`.
>
> There are a number of ways to solve this, e.g.
> * get rid of the separate shutdown procedure in the system tests.
> * set Platform.setImplicitExit(false) which will prevent tkExit being
> called when the last window is gone
> * add more safety in test.util.Shutdown so that it doesn't try to use the
> FX App thread when that is not accepting new runnables
> * ...
>
> Thoughts?
>
> - Johan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240424/d5a04495/attachment.htm>

From duke at openjdk.org  Wed Apr 24 12:54:01 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 12:54:01 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Re-order for more clearness

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/974bf468..1159e3dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=18-19

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

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

From kevin.rushforth at oracle.com  Wed Apr 24 13:13:46 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 24 Apr 2024 06:13:46 -0700
Subject: shutdown after test
In-Reply-To: <CABxFH2F7P0UxSxecTxTQa2BXLgzOzw14XC5svO_8U3eieeOPhw@mail.gmail.com>
References: <CABxFH2F7P0UxSxecTxTQa2BXLgzOzw14XC5svO_8U3eieeOPhw@mail.gmail.com>
Message-ID: <5ece2242-6b5c-4d88-a8ac-08a814338ee8@oracle.com>

> There are a number of ways to solve this, e.g.
> * get rid of the separate shutdown procedure in the system tests.

The utility was added to have a consistent way to shut down the 
platform, so it would seem? a shame to remove it.

> * set Platform.setImplicitExit(false) which will prevent tkExit being 
> called when the last window is gone

I doubt we want to run most systems tests with setImplicitExit(false).

> * add more safety in test.util.Shutdown so that it doesn't try to use 
> the FX App thread when that is not accepting new runnables
> * ...

This seems best, if not too hard to implement. My quick thought on this 
is to add a package scope method to PlatformImpl (with a corresponding 
method in PlatformImplShim) to return the toolkitExit flag, which 
indicates whether or not the toolkit is running.

A fourth option might be to change the runAndWait to runLater, thus 
making it asynchronous. We would need to test whether this causes any 
stability problems on shutdown.

-- Kevin


On 4/24/2024 4:42 AM, Johan Vos wrote:
> While working on the systemtests for the Headless platform, I noticed 
> timing issues with the Marlin QPath Test. Those have nothing to do 
> with Marlin, but rather with the lifecycle. After the test ran, 
> `test.util.Shutdown` is invoked (not on the JavaFX app thread). I 
> noticed that this caused a timeout almost always when running the 
> systemtest with the headless platform, and almost never when running 
> with the regular (Gtk) platform.
> The problem is that the `test.util.Shutdown` method is invoking 
> Platform.runLater() but in some cases (almost always in Headless and 
> almost never in GTK) the runLater is not accepting runnables anymore. 
> This happens because of the PlatformImpl.checkIdle which will shutdown 
> the platform in case there are no windows and no pending runnables 
> (and a few more conditions). This check runs on the JavaFX app thread, 
> and it might trigger `tkExit` before the test-thread invokes 
> `test.util.Shutdown`.
>
> There are a number of ways to solve this, e.g.
> * get rid of the separate shutdown procedure in the system tests.
> * set Platform.setImplicitExit(false) which will prevent tkExit being 
> called when the last window is gone
> * add more safety in test.util.Shutdown so that it doesn't try to use 
> the FX App thread when that is not accepting new runnables
> * ...
>
> Thoughts?
>
> - Johan


From arapte at openjdk.org  Wed Apr 24 14:38:37 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 24 Apr 2024 14:38:37 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
Message-ID: <UoLXQc-SoAnfbFYJR-xg7zJX0IFrRvFYbH9DGPD2kUQ=.00998c8e-1eb1-4772-9fa7-83da88080876@github.com>

On Wed, 24 Apr 2024 12:54:01 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-order for more clearness

Sorry for jumping in little late.
I am reviewing the changes, shall test the fix with some usecases and update.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2075101687

From angorya at openjdk.org  Wed Apr 24 14:38:37 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Apr 2024 14:38:37 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <oPxU-Qo3xwd2D3OUez4SMHND6e90NBmGlaeWKRVTW84=.48054c7f-288e-49dd-8f0f-255205d8bb2a@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
 <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>
 <okjowXYxvSW2Cx2Cjkea55JuwMY6g7scU4pXZxxC-ZM=.244b915e-201b-4b84-81c4-c5dbe7e4ae83@github.com>
 <oPxU-Qo3xwd2D3OUez4SMHND6e90NBmGlaeWKRVTW84=.48054c7f-288e-49dd-8f0f-255205d8bb2a@github.com>
Message-ID: <Yf_7WI0UTA1sw4GeDIPET9cvP5rivbnMFPvB1xiReEs=.1dbd69df-d85c-430b-93a7-c5d67d150c4f@github.com>

On Wed, 24 Apr 2024 07:45:40 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Please replace tests/system/src/test/.classpath with this:
>> 
>> 
>> <?xml version="1.0" encoding="UTF-8"?>
>> <classpath>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/swing">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/base">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.base/com.sun.javafx=ALL-UNNAMED:javafx.base/test.util.memory=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/graphics">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.graphics/com.sun.glass.ui=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.monocle=ALL-UNNAMED:javafx.graphics/com.sun.javafx.sg.prism=ALL-UNNAMED:javafx.graphics/com.sun.prism.impl=ALL-UNNAMED:javafx.graphics/com.sun.javafx.image.impl=ALL-UNNAMED:javafx.graphics/com.sun.glass.events=ALL-UNNAMED:javafx.graphics/com.sun.javafx.application=ALL-UNNAMED:javafx.graphics/com.sun.javafx.css=ALL-UNNAMED:javafx.graphics/com.sun.javafx.geom=ALL-UNNAMED:javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.mac=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED:javafx.graphics/com.sun.javafx.scene.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.font=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/controls">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.controls/test.com.sun.javafx.scene.control.infrastructure=ALL-UNNAMED:javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/fxml">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/web">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.web/com.sun.webkit=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="...
>
> Done.
> 
> I opened the project in Eclipse (instead of IntelliJ). How can I run the test in Eclipse?
> 
> A simple "run" does not work, because the output is then:
> 
> 
> WARNING: Unknown module: javafx.base specified to --patch-module
> WARNING: Unknown module: javafx.web specified to --patch-module
> WARNING: Unknown module: javafx.controls specified to --patch-module
> WARNING: Unknown module: javafx.graphics specified to --patch-module
> 
> 
> How do I need to modify the JUnit "run configuration" inside Eclipse?

Yes, running tests in eclipse requires a bit of set up.  First run the (new) test with  the usual 'Run', this creates a run configuration (should appear under 'JUnit').  Then open that via main menu Run -> Run Configurations... , select "Dependencies" tab, click on "Override Dependencies" button and then the pain starts.

Depending on the type of test, you'd need to either replace or append various `--add-exports`, `--add-modules`, `-Djava.library.path=`, and `-Djavafx.toolkit= `

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1578005144

From duke at openjdk.org  Wed Apr 24 14:50:38 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Wed, 24 Apr 2024 14:50:38 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <UoLXQc-SoAnfbFYJR-xg7zJX0IFrRvFYbH9DGPD2kUQ=.00998c8e-1eb1-4772-9fa7-83da88080876@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
 <UoLXQc-SoAnfbFYJR-xg7zJX0IFrRvFYbH9DGPD2kUQ=.00998c8e-1eb1-4772-9fa7-83da88080876@github.com>
Message-ID: <IQSpEefcIGFSC2MNOH1iMQcfTtrl5tp6i0vWKUlwtT8=.e16fe32c-13f9-4860-83d9-d4f5f2068e08@github.com>

On Wed, 24 Apr 2024 14:35:07 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Sorry for jumping in little late. 

You are jumping in at the perfect time IMHO ?. (We refined the fix, added working tests meanwhile).

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2075129419

From kpk at openjdk.org  Wed Apr 24 15:03:50 2024
From: kpk at openjdk.org (Karthik P K)
Date: Wed, 24 Apr 2024 15:03:50 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
Message-ID: <Z7cL1HnKYL3Iz3DFqIr1a-B22cObvc1eIwfdYmNwdLU=.33801dc2-30d4-4d15-bb8f-f550ed06779e@github.com>

On Tue, 23 Apr 2024 19:30:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

LGTM

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

Marked as reviewed by kpk (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1236#pullrequestreview-2020134947

From johan.vos at gluonhq.com  Wed Apr 24 15:16:46 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 24 Apr 2024 17:16:46 +0200
Subject: shutdown after test
In-Reply-To: <5ece2242-6b5c-4d88-a8ac-08a814338ee8@oracle.com>
References: <CABxFH2F7P0UxSxecTxTQa2BXLgzOzw14XC5svO_8U3eieeOPhw@mail.gmail.com>
 <5ece2242-6b5c-4d88-a8ac-08a814338ee8@oracle.com>
Message-ID: <CABxFH2Hoi+jV22=Y3jKOV60A-BiRn-0PaB+5BJYi-ybSy14FWw@mail.gmail.com>

On Wed, Apr 24, 2024 at 3:14?PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> > There are a number of ways to solve this, e.g.
> > * get rid of the separate shutdown procedure in the system tests.
>
> The utility was added to have a consistent way to shut down the
> platform, so it would seem  a shame to remove it.
>
> > * set Platform.setImplicitExit(false) which will prevent tkExit being
> > called when the last window is gone
>
> I doubt we want to run most systems tests with setImplicitExit(false).
>

I agree. In this case, however, it seems to me that `Util.shutdown` goes
hand in hand with `setImplicitExit(false)`. The `shutdown` method is first
hiding all windows, and then it explicitly invokes Platform.exit(). If
implicitExit was set to true, the latter would be obsolete. If we want to
make sure the shutdown method does what it is intended to do, we should
guarantee that the platform is still running -- hence making sure that it
doesn't exit when there are no windows anymore.
But I might be missing something...

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240424/3820d51e/attachment.htm>

From kcr at openjdk.org  Wed Apr 24 15:28:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 15:28:36 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v15]
In-Reply-To: <8WqwFMUZ-Qt1STd9e3rJwHVWeQaXXsC6wLBRh62BQuk=.c68dd64a-d132-4f34-9b14-93cd3d0c8e21@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
 <gLx3J1MnrYf2A6epEAV9khIs9aczlP-RBEhHa7I_m5Q=.5831fb6c-adbf-4bb3-b0d8-06abc5d9fd64@github.com>
 <8WqwFMUZ-Qt1STd9e3rJwHVWeQaXXsC6wLBRh62BQuk=.c68dd64a-d132-4f34-9b14-93cd3d0c8e21@github.com>
Message-ID: <ZM8tp2sCpZeaQIdjZOai2HnLJHorO_nbp5vPPSb5wkY=.19c79813-5a06-44fc-8657-d67b3d036abf@github.com>

On Tue, 23 Apr 2024 19:00:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 48:
>> 
>>> 46: import static org.junit.jupiter.api.Assertions.assertEquals;
>>> 47: 
>>> 48: @EnabledOnOs({OS.WINDOWS})
>> 
>> I did not use `Platform`s OS detection, because this seems to be more resource friendly and native JUnit5. I can switch to the style of `test.com.sun.glass.ui.gtk.Gtk2RemovalCommon`, i.e., use `if (!PlatformUtil.isWindows()) return;` in all test methdos.
>
> Interesting = @kevinrushforth what do you think?

An excellent question. If it is robust, then it seems OK. Using Junit5 Assumptions is more flexible, though, so might lean toward wanting to use that. Either way, test this on the other platforms to ensure that the test is skipped (and marked as skipped in the report).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1578085887

From arapte at openjdk.org  Wed Apr 24 15:32:37 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 24 Apr 2024 15:32:37 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
Message-ID: <_1PORuiG2jMxIotPa8KMMUkklamw9z_Gfee17aAXNSI=.abae7fcf-8a31-422b-96ce-8f341b0c216d@github.com>

On Wed, 24 Apr 2024 12:54:01 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-order for more clearness

I tested the fix with a simple TextArea sample and observed an issue that: Windows Narrator reads only the last character of the Text in a TextArea, when moving the cursor, and the focus rect does not move with cursor.

Steps:
1. Launch Windows Narrator (shortcut key combination: Windows + Ctrl + Enter)
2. Run a simple TextArea sample with fix 

public class TextAreaTest extends Application  {
    @Override
    public void start(Stage primaryStage) {
        primaryStage.setScene(new Scene(new VBox(new TextArea("javafx test"))));
        primaryStage.show();
    }
}


-> Observe that a Fcous Rect is drawn around all text in TextArea.

3. Press right arrow key to move cursor
-> Observe that:
i. Focus rect is drawn around the last character, even though the cursor is elsewhere
ii. With every right arrow key press, Narrator always read 't'

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2075219300

From kcr at openjdk.org  Wed Apr 24 15:26:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 15:26:41 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
Message-ID: <7qG6BDt-WzGXpT-Joejfi4RTitULD_Yc7R-fqaWqmnI=.966bf691-fa2d-42ba-b15e-537391d323fe@github.com>

On Tue, 23 Apr 2024 19:30:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

One meta comment (not directly related to this review).

> > since it's been modified, please change the year
> 
> Sorry, I stopped doing that, I thought this was automated.

It is optional to update copyrights in a PR for a modified file (new files do need a correctly formatted copyright file with the right year). Ambarish periodically runs a script to update them. If you do update copyrights, you need to make sure that the year is right (if, for example, the PR was started in one year and finished the next yet). I tend to not update them for PRs that I expect to backport, since it increases the likelihood of not being able to use the `/backport` command.

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2075209373

From kcr at openjdk.org  Wed Apr 24 20:08:36 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:08:36 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <oPxU-Qo3xwd2D3OUez4SMHND6e90NBmGlaeWKRVTW84=.48054c7f-288e-49dd-8f0f-255205d8bb2a@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
 <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>
 <okjowXYxvSW2Cx2Cjkea55JuwMY6g7scU4pXZxxC-ZM=.244b915e-201b-4b84-81c4-c5dbe7e4ae83@github.com>
 <oPxU-Qo3xwd2D3OUez4SMHND6e90NBmGlaeWKRVTW84=.48054c7f-288e-49dd-8f0f-255205d8bb2a@github.com>
Message-ID: <yZ4pBMn0DzzV4tzHi-Sd8XJ41qmde1wMdqYRwTnR9rQ=.e3a0c316-59c3-4635-995d-e6fb9bd99cf3@github.com>

On Wed, 24 Apr 2024 07:45:40 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Please replace tests/system/src/test/.classpath with this:
>> 
>> 
>> <?xml version="1.0" encoding="UTF-8"?>
>> <classpath>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/swing">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/base">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.base/com.sun.javafx=ALL-UNNAMED:javafx.base/test.util.memory=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/graphics">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.graphics/com.sun.glass.ui=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.monocle=ALL-UNNAMED:javafx.graphics/com.sun.javafx.sg.prism=ALL-UNNAMED:javafx.graphics/com.sun.prism.impl=ALL-UNNAMED:javafx.graphics/com.sun.javafx.image.impl=ALL-UNNAMED:javafx.graphics/com.sun.glass.events=ALL-UNNAMED:javafx.graphics/com.sun.javafx.application=ALL-UNNAMED:javafx.graphics/com.sun.javafx.css=ALL-UNNAMED:javafx.graphics/com.sun.javafx.geom=ALL-UNNAMED:javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.mac=ALL-UNNAMED:javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED:javafx.graphics/com.sun.javafx.scene.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.text=ALL-UNNAMED:javafx.graphics/com.sun.javafx.font=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/controls">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.controls/test.com.sun.javafx.scene.control.infrastructure=ALL-UNNAMED:javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/fxml">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry combineaccessrules="false" kind="src" path="/web">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="add-exports" value="javafx.web/com.sun.webkit=ALL-UNNAMED"/>
>> 		</attributes>
>> 	</classpathentry>
>> 	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
>> 		<attributes>
>> 			<attribute name="module" value="true"/>
>> 			<attribute name="...
>
> Done.
> 
> I opened the project in Eclipse (instead of IntelliJ). How can I run the test in Eclipse?
> 
> A simple "run" does not work, because the output is then:
> 
> 
> WARNING: Unknown module: javafx.base specified to --patch-module
> WARNING: Unknown module: javafx.web specified to --patch-module
> WARNING: Unknown module: javafx.controls specified to --patch-module
> WARNING: Unknown module: javafx.graphics specified to --patch-module
> 
> 
> How do I need to modify the JUnit "run configuration" inside Eclipse?

@koppor Running the test in Eclipse is optional, so maybe Andy can test that. As long as the test runs in gradle, that's sufficient.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1578459861

From angorya at openjdk.org  Wed Apr 24 20:13:34 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Apr 2024 20:13:34 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v16]
In-Reply-To: <yZ4pBMn0DzzV4tzHi-Sd8XJ41qmde1wMdqYRwTnR9rQ=.e3a0c316-59c3-4635-995d-e6fb9bd99cf3@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <VGiy0WFfhs4sDOH6QfuEZeoRrwUwjGQZsT16NqNJnE0=.ed92ae41-5747-4381-a022-ea7713102c8f@github.com>
 <CY6Q85DJN_DKrFTZJ1pwHZA8oA-i9VdzecKsXetYXu0=.59931e03-55ed-445b-8a87-c4e5e3e66ccb@github.com>
 <okjowXYxvSW2Cx2Cjkea55JuwMY6g7scU4pXZxxC-ZM=.244b915e-201b-4b84-81c4-c5dbe7e4ae83@github.com>
 <oPxU-Qo3xwd2D3OUez4SMHND6e90NBmGlaeWKRVTW84=.48054c7f-288e-49dd-8f0f-255205d8bb2a@github.com>
 <yZ4pBMn0DzzV4tzHi-Sd8XJ41qmde1wMdqYRwTnR9rQ=.e3a0c316-59c3-4635-995d-e6fb9bd99cf3@github.com>
Message-ID: <DnCixttMTQOSTZu8mFX50OEKYVYjqHUjoaJhQRf9IaY=.49160ad0-5498-492b-93ed-7b1a67cb59b2@github.com>

On Wed, 24 Apr 2024 20:05:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Done.
>> 
>> I opened the project in Eclipse (instead of IntelliJ). How can I run the test in Eclipse?
>> 
>> A simple "run" does not work, because the output is then:
>> 
>> 
>> WARNING: Unknown module: javafx.base specified to --patch-module
>> WARNING: Unknown module: javafx.web specified to --patch-module
>> WARNING: Unknown module: javafx.controls specified to --patch-module
>> WARNING: Unknown module: javafx.graphics specified to --patch-module
>> 
>> 
>> How do I need to modify the JUnit "run configuration" inside Eclipse?
>
> @koppor Running the test in Eclipse is optional, so maybe Andy can test that. As long as the test runs in gradle, that's sufficient.

optional, yes, and I verified that the eclipse config change is good.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1578465723

From kcr at openjdk.org  Wed Apr 24 20:18:35 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:18:35 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <KP0_LYaDxLNTdNA3Q29mWA4sc60MbXi2lBMNuKqpV9c=.75c3dae4-0931-4ccc-a82f-7413bede91d5@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
 <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
 <KP0_LYaDxLNTdNA3Q29mWA4sc60MbXi2lBMNuKqpV9c=.75c3dae4-0931-4ccc-a82f-7413bede91d5@github.com>
Message-ID: <FkOqShKZSXKRCCWBLorzLwp7JuD7AoL-7GtrVrCsuFI=.d0664ae3-5bfe-4f5d-adfa-4c5ad3ff628c@github.com>

On Thu, 18 Apr 2024 23:17:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I like the idea of updating the spec (for SpinnerValueFactory.[Integer|Double}SpinnerFactory classes).

Can you file a JBS issue to track this?

> Do we really need the CSR for clarifying the behavior?

If it really is just clarifying the existing behavior, maybe not. I'd like to see the changes and then decide.

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

PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2075766232

From kcr at openjdk.org  Wed Apr 24 20:27:32 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:27:32 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <_662lsBFRBVl5W_yPG2poNdDfGcXLbIFKLLeNwUeVkM=.04c117bc-4bd9-44b9-ad3f-be936e9e3c49@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

I skimmed the PR and it looks good to me, but I'll let @arapte be the primary reviewer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2075781103

From kcr at openjdk.org  Wed Apr 24 20:27:32 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:27:32 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <PzldjjGhQJKrklpf0ZBvNHflHOa2s_zBxqFGF0nKKfo=.8582c2fc-a9be-4d35-bfdc-bd79fdafa15d@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
 <PzldjjGhQJKrklpf0ZBvNHflHOa2s_zBxqFGF0nKKfo=.8582c2fc-a9be-4d35-bfdc-bd79fdafa15d@github.com>
Message-ID: <Xnu8nymNGpCEYVW76EHWVZ_dbY_9FS8KduXxLZjtWz0=.577f69b0-6904-4796-8680-f127f4e4b3d5@github.com>

On Tue, 23 Apr 2024 10:37:01 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> Should we consider removing this method completely?

Not as part of this PR. Maybe in a follow-up if you think it is worth doing as a (low priority) cleanup.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1445#discussion_r1578480274

From kcr at openjdk.org  Wed Apr 24 20:28:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:28:33 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer
In-Reply-To: <bsJJcF_MTEVC8EWx0CP4fjuig7WiadhkTx2rCRz4hQQ=.2ee5fc75-93c9-495f-813f-971ab44a8700@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
 <bsJJcF_MTEVC8EWx0CP4fjuig7WiadhkTx2rCRz4hQQ=.2ee5fc75-93c9-495f-813f-971ab44a8700@github.com>
Message-ID: <pFAJf3MQ9Lq75epYCwBx6j7ysxYutBaPNviVEUWZ6e4=.1a639570-a94e-4aeb-9a2c-e9f4120272e1@github.com>

On Sun, 21 Apr 2024 14:37:23 GMT, n-gabe <duke at openjdk.org> wrote:

>> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.
>
> Sure, done.

@n-gabe This is now ready for you to `/integrate`

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

PR Comment: https://git.openjdk.org/jfx/pull/1377#issuecomment-2075782362

From kcr at openjdk.org  Wed Apr 24 20:33:32 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:33:32 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
Message-ID: <BcZ3hFuRVm3l3fGUw-_hyxO0MHetIX1MNTbwrwVwml8=.fb35e2d8-add4-49cb-934f-82fecdf3a06a@github.com>

On Fri, 19 Apr 2024 20:36:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with  Character.isLetterOrDigit(int).
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330590.prev.word
>  - 8330590 TextInputControl: previous word fails with Bhojpuri characters

@karthikpandelu Can you review this? We'll also need a review by a "R"eviewer.

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

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2075789661

From kcr at openjdk.org  Wed Apr 24 20:34:33 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 20:34:33 GMT
Subject: RFR: 8330701: Fix Eclipse project in tests/manual/text
In-Reply-To: <KoUXZbrBtuA6l0KIkYUZikpSdeAEe5M9Ws0M_Tzl_VY=.388beb04-9f25-4d35-90dc-4d3ec36cc60c@github.com>
References: <KoUXZbrBtuA6l0KIkYUZikpSdeAEe5M9Ws0M_Tzl_VY=.388beb04-9f25-4d35-90dc-4d3ec36cc60c@github.com>
Message-ID: <IRwmn_Nz5sDITLF2G2P3Yom_hd1ROmmaYHVtI_zJaYs=.94518963-8d22-46ab-bfb6-b93456f43155@github.com>

On Fri, 19 Apr 2024 18:13:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Came out of the work on [JDK-8319555](https://bugs.openjdk.org/browse/JDK-8319555): [TestBug] Utility for creating instruction window for manual tests.
> 
> This project generates errors if opened in Eclipse. Yes, I can close the project each time, but I would rather fix the setup. This fix is extracted from
> https://github.com/openjdk/jfx/pull/1413

This looks trivially correct (I didn't test it since I'm not an Eclipse user).

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1443#pullrequestreview-2020888709

From angorya at openjdk.org  Wed Apr 24 20:38:33 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 24 Apr 2024 20:38:33 GMT
Subject: Integrated: 8330701: Fix Eclipse project in tests/manual/text
In-Reply-To: <KoUXZbrBtuA6l0KIkYUZikpSdeAEe5M9Ws0M_Tzl_VY=.388beb04-9f25-4d35-90dc-4d3ec36cc60c@github.com>
References: <KoUXZbrBtuA6l0KIkYUZikpSdeAEe5M9Ws0M_Tzl_VY=.388beb04-9f25-4d35-90dc-4d3ec36cc60c@github.com>
Message-ID: <b_JMAFFY5oOm9b6tjN76Y3BLBURzJg5N2gtZyI1lDTE=.ea4da0fc-67ca-4b98-90f9-3c415afad297@github.com>

On Fri, 19 Apr 2024 18:13:58 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Came out of the work on [JDK-8319555](https://bugs.openjdk.org/browse/JDK-8319555): [TestBug] Utility for creating instruction window for manual tests.
> 
> This project generates errors if opened in Eclipse. Yes, I can close the project each time, but I would rather fix the setup. This fix is extracted from
> https://github.com/openjdk/jfx/pull/1413

This pull request has now been integrated.

Changeset: e72d681f
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/e72d681fbe3b00a40db5a2068f11f2d3420f9432
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8330701: Fix Eclipse project in tests/manual/text

Reviewed-by: kcr

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

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

From kcr at openjdk.org  Wed Apr 24 21:11:31 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 21:11:31 GMT
Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live
 Streaming
In-Reply-To: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
References: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
Message-ID: <rHTvenGUsAvchrcsY2B7aOaduyLT2tTCN-PgX5oH3tY=.41e10250-eae0-4ebb-a205-f8c895194176@github.com>

On Tue, 2 Apr 2024 00:18:04 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming.
> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details):
>   - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag.
> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits.
> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams.
> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend.
> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes.
> - Fixed and improved debug output in Linux AV plugins.
> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time.
> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams.
> - Removed dead code from MediaManager.
> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases.

This will need testing on all platforms.

While testing on Linux, I ran into a compilation error on an older Ubuntu 16.04 system (using the production gcc 13.2 compilers). This suggests that you are missing an include that, in some cases, matters:


../../platform/gstreamer/GstAudioPlaybackPipeline.cpp:1069:21: error: 'strstr' was not declared in this scope
 1069 |                 if (strstr(mimetype, "audio/unsupported") != NULL)
      |                     ^~~~~~
../../platform/gstreamer/GstAudioPlaybackPipeline.cpp:36:1: note: 'strstr' is defined in header '<cstring>'; did you forget to '#include <cstring>'?
   35 | #include <fxplugins_common.h>
  +++ |+#include <cstring>
   36 | 

Makefile:173: recipe for target 'jfx/modules/javafx.media/build/native/linux/Release/obj/jfxmedia/platform/gstreamer/GstAudioPlaybackPipeline.o' failed
make: *** [jfx/modules/javafx.media/build/native/linux/Release/obj/jfxmedia/platform/gstreamer/GstAudioPlaybackPipeline.o] Error 1
make: *** Waiting for unfinished jobs....

../../platform/gstreamer/GstAVPlaybackPipeline.cpp:184:21: error: 'strstr' was not declared in this scope
  184 |                 if (strstr(mimetype, "video/x-h264") != NULL) // H.264
      |                     ^~~~~~
../../platform/gstreamer/GstAVPlaybackPipeline.cpp:37:1: note: 'strstr' is defined in header '<cstring>'; did you forget to '#include <cstring>'?
   36 | #include <fxplugins_common.h>
  +++ |+#include <cstring>
   37 | 
make: *** [jfx/modules/javafx.media/build/native/linux/Release/obj/jfxmedia/platform/gstreamer/GstAVPlaybackPipeline.o] Error 1
Makefile:173: recipe for target 'jfx/modules/javafx.media/build/native/linux/Release/obj/jfxmedia/platform/gstreamer/GstAVPlaybackPipeline.o' failed

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

PR Comment: https://git.openjdk.org/jfx/pull/1435#issuecomment-2075846696

From kcr at openjdk.org  Wed Apr 24 22:30:31 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 24 Apr 2024 22:30:31 GMT
Subject: RFR: 8328603: HLS video stream fails to render consistently
In-Reply-To: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com>
References: <4pI4RPgxKCV-lyQlqNOBwSMSQEHCUD5YqH4VaGUhYb8=.67af9556-48ae-4a58-8752-674cf47f2061@github.com>
Message-ID: <oAFVAQc_rAe8XhNqwpn6FKzdJxjdtQt5jtG-HsHAMxs=.9cf2af0c-4580-4770-a079-bdba85fb4ea7@github.com>

On Sat, 13 Apr 2024 01:36:01 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - When video fails to render AVFoundation outputs frame in `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` format which is not supported. We do force format change after that to `kCVPixelFormatType_422YpCbCr8`, but AVFoundation does not provides any video frames after format change. Not sure why it happens.
> - When video worked for stream in this issue, then AVFoundation was using `kCVPixelFormatType_422YpCbCr8` for some reason instead of `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange`.
> - I tested format fallback from `kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange` to `kCVPixelFormatType_422YpCbCr8` manually and many streams I tried works fine, except one reported in this bug.
> - If AVFoundation is initialized with list of formats JavaFX Media rendering supports, then this issue is no longer reproducible.
> - Fixed by providing list of supported formats to AVFoundation.
> - Removed unused variable `response`.
> - Tested with all streams I have and no issues found.

Looks good.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1440#pullrequestreview-2021055321

From duke at openjdk.org  Thu Apr 25 04:22:36 2024
From: duke at openjdk.org (n-gabe)
Date: Thu, 25 Apr 2024 04:22:36 GMT
Subject: RFR: 8146918: ConcurrentModificationException in MediaPlayer [v3]
In-Reply-To: <n0VycYyj7ZfG-JNhbf_Hj53Qypok5e9HUq_UfrQLqg4=.9cd9154f-0304-4e4c-96e8-05378b59167e@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
 <n0VycYyj7ZfG-JNhbf_Hj53Qypok5e9HUq_UfrQLqg4=.9cd9154f-0304-4e4c-96e8-05378b59167e@github.com>
Message-ID: <ZQse4Eszj3AbDwRQ7CBsSjJvq8zFLgdfoBhoGxxmVrw=.4fd10f39-be51-48b2-8cb5-721308e3911b@github.com>

On Mon, 22 Apr 2024 15:05:07 GMT, n-gabe <duke at openjdk.org> wrote:

>> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.
>
> n-gabe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove needless copyright year

Thanks, please /integrate

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

PR Comment: https://git.openjdk.org/jfx/pull/1377#issuecomment-2076330503

From duke at openjdk.org  Thu Apr 25 06:37:00 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 06:37:00 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v21]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <6NLsGYbB5RVy3_LH20izb4i2wXRfiHGyqtkbcYIV-kM=.f7e980f0-c571-4027-bf88-fb991ff173a6@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Switch from `@EnabledOnOS` to `assumeTrue`

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/1159e3dd..ade506c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=20
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=19-20

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

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

From duke at openjdk.org  Thu Apr 25 06:37:00 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 06:37:00 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v15]
In-Reply-To: <ZM8tp2sCpZeaQIdjZOai2HnLJHorO_nbp5vPPSb5wkY=.19c79813-5a06-44fc-8657-d67b3d036abf@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <ktovaf8bjOHyQeZpVairVlBHn_quA30Az8Mwoc-Z-iE=.ca37b9d4-bfbf-4444-b48a-5ed25462627b@github.com>
 <gLx3J1MnrYf2A6epEAV9khIs9aczlP-RBEhHa7I_m5Q=.5831fb6c-adbf-4bb3-b0d8-06abc5d9fd64@github.com>
 <8WqwFMUZ-Qt1STd9e3rJwHVWeQaXXsC6wLBRh62BQuk=.c68dd64a-d132-4f34-9b14-93cd3d0c8e21@github.com>
 <ZM8tp2sCpZeaQIdjZOai2HnLJHorO_nbp5vPPSb5wkY=.19c79813-5a06-44fc-8657-d67b3d036abf@github.com>
Message-ID: <8Awt4nmBojBuTncGoCNKmVPqG4ZqWAPytCLposH1vJU=.a6fe21bd-a0fa-46fd-889f-650f05695fbe@github.com>

On Wed, 24 Apr 2024 15:26:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Interesting = @kevinrushforth what do you think?
>
> An excellent question. If it is robust, then it seems OK. Using Junit5 Assumptions is more flexible, though, so might lean toward wanting to use that. Either way, test this on the other platforms to ensure that the test is skipped (and marked as skipped in the report).

+1 for flexibility. Switched in [`ade506c` (#1442)](https://github.com/openjdk/jfx/pull/1442/commits/ade506c0e44544f3d61a164765e19b983a99373d).

Note that `assumeTrue` also works in `@BeforeAll` to skip the whole class. (I wonder whether I should rewrite the other tests following that pattern, but that is maybe a job for a follow-up issue)

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1578941716

From duke at openjdk.org  Thu Apr 25 06:51:34 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 06:51:34 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <_1PORuiG2jMxIotPa8KMMUkklamw9z_Gfee17aAXNSI=.abae7fcf-8a31-422b-96ce-8f341b0c216d@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
 <_1PORuiG2jMxIotPa8KMMUkklamw9z_Gfee17aAXNSI=.abae7fcf-8a31-422b-96ce-8f341b0c216d@github.com>
Message-ID: <3YyVXs2QQzF-VJ7GBcpeFYrdju46GnssAgSSSut-xxY=.9789ca7b-1ed8-43cf-b04c-8d3ba0b25e43@github.com>

On Wed, 24 Apr 2024 15:28:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Windows Narrator reads only the last character of the Text in a TextArea, when moving the cursor, and the focus rect does not move with cursor.

I tested it with a JFX distribution without the fix. Also happens there. Can you check, too? - If yes, would it be possible to handle this in a separate issue?

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2076488937

From johan.vos at gluonhq.com  Thu Apr 25 10:15:15 2024
From: johan.vos at gluonhq.com (Johan Vos)
Date: Thu, 25 Apr 2024 12:15:15 +0200
Subject: Update on the headless platform (sandbox)
Message-ID: <CABxFH2EgPYLt=HRyvfDtuAeqoobvdFd3z2kyDkqNOszTcaf+Cw@mail.gmail.com>

Hi,

I did some more work on the JavaFX Headless platform that is available in
[1] and I am using it to run the systemtests. I am not yet running the
robot-based systemtests, but there is already some robot code in the
Headless platform.

The other systemtests are going pretty well. On my linux,

export _JAVA_OPTIONS="-Dglass.platform=Headless"
sh gradlew --info -PFULL_TEST=true :systemTests:cleanTest :systemTests:test

is currently returning
552 tests completed, 3 failed, 24 skipped

I understand why the 3 failed tests are failing, and I will move to
robot-based tests soon.

[1] https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240425/e1fe915b/attachment.htm>

From nlisker at openjdk.org  Thu Apr 25 10:54:34 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 25 Apr 2024 10:54:34 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <MZEl9OB7wl6gqkhbeuTK1B8KxjvVbl62UZZcin7OTBM=.87306d52-fa92-4dc9-ac3d-edff648b5af3@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

I tried to run the 3DLighting application and I'm getting an error. However, it looks like it's not this patch that is causing it since going back a few commits also gives this error. The jfx22 branch doesn't have this issue so it will take some investigation to find out what's going on. I'm on Win 10.


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000001b44b9ad260, pid=6332, tid=18096
#
# JRE version: OpenJDK Runtime Environment (21.0.1+12) (build 21.0.1+12-29)
# Java VM: OpenJDK 64-Bit Server VM (21.0.1+12-29, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# J 170 c2 java.lang.String.length()I java.base at 21.0.1 (11 bytes) @ 0x000001b44b9ad260 [0x000001b44b9ad220+0x0000000000000040]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Nir\git\jfx\tests\performance\3DLighting\hs_err_pid6332.log
[5.830s][warning][os] Loading hsdis library failed
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2076903265

From nlisker at openjdk.org  Thu Apr 25 11:16:33 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 25 Apr 2024 11:16:33 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <daQgYuPdywmofdwXhYfeZyN75eOeHrMQ7Pgj9b0OxD4=.4c6999a6-6efd-4dff-b5af-e9444db57e32@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

I traced the issue to commit id 3914db26f3abb573ed0e320a361477e1d3e7a9ac, which is a merge Kevin did ~6 weeks ago. Placing the head on this commit or after causes the above error, but moving 1 commit back to "Create release notes for JavaFX 22" lets the application start normally.

I understand that this PR has nothing to do with this, I just can't test it considering this problem.

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2076940263

From duke at openjdk.org  Thu Apr 25 12:58:49 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 12:58:49 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
 <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
Message-ID: <o1dSvaQw7w2bg31AfV4oKw6Gm1B7_C5DJau2_fMypNo=.bff7abc0-444d-424a-8ae9-443c23eda226@github.com>

On Fri, 19 Apr 2024 17:33:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I am new to testing in the JFX project. It seems that `test.` is required as package prefix. Thus, I did not use the approach of package-private methods and classes, but needed to make the class and the tested method public.
>> 
>> However, now I get the (expected) error that the module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.
>> 
>> 
>> class test.com.sun.glass.ui.win.WinTextRangeProviderTest (in unnamed module @0x1e6454ec) cannot access class com.sun.glass.ui.win.WinTextRangeProvider (in module javafx.graphics) because module javafx.graphics does not export com.sun.glass.ui.win to unnamed module @0x1e6454ec
>> java.lang.IllegalAccessError: class test.com.sun.glass.ui.win.WinTextRangeProviderTest (in unnamed module @0x1e6454ec) cannot access class com.sun.glass.ui.win.WinTextRangeProvider (in module javafx.graphics) because module javafx.graphics does not export com.sun.glass.ui.win to unnamed module @0x1e6454ec
>> 	at test.com.sun.glass.ui.win.WinTextRangeProviderTest.getValidStringIndex
>
>> module `javafx.graphics` does not export `com.sun.glass.ui.win` to unnamed module @0x1e6454ec.
> 
> I think you need to add
> 
> --add-exports javafx.graphics/com.sun.glass.ui.win=ALL-UNNAMED
> 
> to graphics/src/test/addExports
> (see line 7)
> 
> @kevinrushforth I wonder if there was a way to auto-generate addExports somehow, at least the part needed for the tests.

I put the `TextAreaTest.java`  into `tests\system\src\test\java\test\com\sun\glass\ui\win`. Cannot get it into run in Eclipse. Can you help me @andy-goryachev-oracle (refs https://github.com/openjdk/jfx/pull/1442#discussion_r1578005144). Background: To work on the issue mentioned by Ambarish, I need to do code and fix. Cleanroom development takes too much time for me here.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2077116786

From duke at openjdk.org  Thu Apr 25 13:00:44 2024
From: duke at openjdk.org (n-gabe)
Date: Thu, 25 Apr 2024 13:00:44 GMT
Subject: Integrated: 8146918: ConcurrentModificationException in MediaPlayer
In-Reply-To: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
References: <7QxpMW89XiKK1VhI-PI6PL8FFBpfIGgVoH7ojqneDGk=.f53ce7f2-4db0-430b-b295-29f462a0c103@github.com>
Message-ID: <bXxYlW7iMTa08LDoCVPr-DUogYyJvQGfyWw0DJO6FHU=.7008c862-6dfa-45ca-a26a-5fdcc04b967e@github.com>

On Thu, 22 Feb 2024 17:16:42 GMT, n-gabe <duke at openjdk.org> wrote:

> There is a ConcurrentModificationException in MediaPlayer when removing a MediaView from it. The root cause is that you can't iterate over a HashSet with for (WeakReference<MediaView> vref : viewRefs) and removing items from the collection by viewRefs.remove(vref); within this loop.

This pull request has now been integrated.

Changeset: d8ca38a6
Author:    n-gabe <11182122+n-gabe at users.noreply.github.com>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d8ca38a6b7ed918318b956add150a5ae9c4c0981
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8146918: ConcurrentModificationException in MediaPlayer

Reviewed-by: almatvee

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

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

From kcr at openjdk.org  Thu Apr 25 14:08:41 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 25 Apr 2024 14:08:41 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <FmGA7RMEbHk4c3ALmtdE2rMshamNUCQB_csn8sXtKLo=.89d01f1c-65b5-4afe-986f-72967144ec26@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

> I traced the issue to commit id [3914db2](https://github.com/openjdk/jfx/commit/3914db26f3abb573ed0e320a361477e1d3e7a9ac), which is a merge Kevin did ~6 weeks ago. Placing the head on this commit or after causes the above error, but moving 1 commit back to "Create release notes for JavaFX 22" lets the application start normally.

That merge was to bring in the CPU fixes for the April CPU. This could indicate a problem with one of the fixes. How easy is it to reproduce? Does it reproduce on startup or when you turn on lighting of some sort? Can you reproduce this on more than one system?

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2077286537

From nlisker at openjdk.org  Thu Apr 25 14:08:42 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 25 Apr 2024 14:08:42 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <KSmRKiNNU7Sx4JwxaOTebP3ezxmNZmdTIe5ao_BKauc=.7b15b3fb-e592-49e0-b157-a184b4e31d52@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

Found the problem. That merge bumped the min JDK to 21, which I was using anyway, but it required recompiling the native D3D resources with the new JDK. The application works now.

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2077287504

From lkostyra at openjdk.org  Thu Apr 25 14:20:49 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 25 Apr 2024 14:20:49 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v3]
In-Reply-To: <7peXj3gequ3HGNd_FGJKchYB9ySQ784E1Y2Je2rU8gA=.0cffb403-0e41-4a76-a756-8a2649ad6db7@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <7peXj3gequ3HGNd_FGJKchYB9ySQ784E1Y2Je2rU8gA=.0cffb403-0e41-4a76-a756-8a2649ad6db7@github.com>
Message-ID: <8XGeXEwVKOAsWA1ZhNLkn2zMCWlopDTwNI4z4zbt9aE=.e88a490e-b75d-4553-a051-63b76dac7311@github.com>

On Fri, 19 Apr 2024 14:42:23 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Forgot debug message

I left a few comments, mostly for adjusting error-checking. Once those are fixed and others have their input I'll test those changes.

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 252:

> 250:             eglGetProcAddress("glGetProgramInfoLog");
> 251:     ctxInfo->glTexImage2DMultisample = (PFNGLTEXIMAGE2DMULTISAMPLEPROC)
> 252:             dlsym(RTLD_DEFAULT,"glTexImage2DMultisample");

I think these three functions should also be available via `eglGetProcAddress`

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 258:

> 256:             dlsym(RTLD_DEFAULT,"glBlitFramebuffer");
> 257: 
> 258:     eglSwapInterval(eglDisplay, 0);

`eglSwapInterval` can potentially fail, we should check for errors here

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 267:

> 265: 
> 266:     // Release context once we are all done
> 267:     eglMakeCurrent(eglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);

Similar as above, `eglMakeCurrent` can also fail

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 301:

> 299: 
> 300:     if (!eglMakeCurrent(ctxInfo->eglDisplay, dInfo->eglSurface, dInfo->eglSurface, ctxInfo->context)) {
> 301:         fprintf(stderr, "Failed in eglMakeCurrent");

I think you might be missing a `return` statement here.

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 310:

> 308:     interval = (vSyncNeeded) ? 1 : 0;
> 309:     ctxInfo->state.vSyncEnabled = vSyncNeeded;
> 310:     eglSwapInterval(ctxInfo->eglDisplay, interval);

Check for errors like above

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLDrawable.c line 58:

> 56:     }
> 57: 
> 58:     EGLSurface eglSurface = eglCreateWindowSurface(pfInfo->eglDisplay, pfInfo->eglConfig,

I would add a check to make sure the surface was created successfully, as it can potentially return `EGL_NO_SURFACE`.

Some additional information from `eglGetError` could also come in handy if `eglCreateWindowSurface` does fail.

modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLDrawable.c line 119:

> 117: 
> 118:     eglSwapBuffers(eglGetCurrentDisplay(), dInfo->eglSurface);
> 119:     return JNI_TRUE;

eglSwapBuffers can fail, so I'd `return (eglSwapBuffers(...) == EGL_TRUE);` or something similar

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

PR Review: https://git.openjdk.org/jfx/pull/1381#pullrequestreview-2022336712
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579372523
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579386732
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579387499
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579431452
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579387989
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579376454
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1579379362

From kpk at openjdk.org  Thu Apr 25 14:31:50 2024
From: kpk at openjdk.org (Karthik P K)
Date: Thu, 25 Apr 2024 14:31:50 GMT
Subject: RFR: 8273657 : TextField: all text content must be selected initially
Message-ID: <CY45jcfPBZhdVGGixuWHuef3NMN66jzBHpgRkOoMOys=.b02ddba4-783a-4f88-9ec1-4bb866fabc02@github.com>

The text was not getting selected on adding the `TextField` to the scene initially, subsequently removing and adding the `TextField` to the scene selects the entire text present in the `TextField`. 

Made changes in the `TextFieldBehavior` constructor to select the text on adding the `TextField`.

Added unit test to validate the fix

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

Commit messages:
 - Fix textfield selection issue

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

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

From kcr at openjdk.org  Thu Apr 25 14:49:38 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 25 Apr 2024 14:49:38 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <jgMrv3c5C2bSbA9LFDSLfcDzlRo_ZlgJbnvX27ZS0TM=.27fe3c6e-73bd-4c79-8712-5f1a2c1b93f1@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

Good to hear.

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2077410544

From nlisker at openjdk.org  Thu Apr 25 15:29:39 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 25 Apr 2024 15:29:39 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <5wFv7THFP7x_NTQaBqTHVQzwpQ95MlKTca2502zr1xg=.202e3ef6-48a2-4b31-9708-6fd52837570b@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

Tested the functionality with the 3DLighting app, things look the same as before the patch. Left a minor comment.

modules/javafx.graphics/src/main/native-prism-d3d/D3DPipeline.cc line 237:

> 235: }
> 236: 
> 237: int getMaxSampleSupport(IDirect3D9Ex *d3d9, UINT adapter) {

Minor: In some cases you also change the name of the variable to add the "Ex" suffix., like in

D3DContext::D3DContext(IDirect3D9Ex *pd3dEx, UINT adapter)
                                         ^

Here and In `PiplineManager.h` it's left as `IDirect3D9Ex * pd3d9;` without "Ex".
I don't mind it either way (I would probably not bother changing them myself), but perhaps we should remain consistent.

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

Marked as reviewed by nlisker (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1445#pullrequestreview-2022879147
PR Review Comment: https://git.openjdk.org/jfx/pull/1445#discussion_r1579699815

From angorya at openjdk.org  Thu Apr 25 15:39:42 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Apr 2024 15:39:42 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <3YyVXs2QQzF-VJ7GBcpeFYrdju46GnssAgSSSut-xxY=.9789ca7b-1ed8-43cf-b04c-8d3ba0b25e43@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
 <_1PORuiG2jMxIotPa8KMMUkklamw9z_Gfee17aAXNSI=.abae7fcf-8a31-422b-96ce-8f341b0c216d@github.com>
 <3YyVXs2QQzF-VJ7GBcpeFYrdju46GnssAgSSSut-xxY=.9789ca7b-1ed8-43cf-b04c-8d3ba0b25e43@github.com>
Message-ID: <f1phvRU0IwqgakYoTN4q90PiDn6Rgo44GMYXzxXdJzQ=.588de455-b1ba-4741-9fd5-2acffcd72fe7@github.com>

On Thu, 25 Apr 2024 06:49:24 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> I tested it with a JFX distribution without the fix. Also happens there.

Nope, this fix breaks Narrator.  The window cursor is moving but the narrator outlines the trailing 't' as Ambarish described.

(every time I change branches for the purposes of review, I do a complete gradle build preceded by nuking the build directory:

rm -rf ./build ; gradle clean sdk apps javadoc
```)

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2077595117

From angorya at openjdk.org  Thu Apr 25 15:50:46 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Apr 2024 15:50:46 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v7]
In-Reply-To: <o1dSvaQw7w2bg31AfV4oKw6Gm1B7_C5DJau2_fMypNo=.bff7abc0-444d-424a-8ae9-443c23eda226@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <EuOSHKqWzVg7liGqj_nZeiy1zix79VMcQyRm6OFC7QM=.4b990a05-c8b2-4bbd-b5d2-4d802115806a@github.com>
 <uMy32PegSD-QzfdLXaCy1i_Y79FQLU1bR8bJEjYAbr4=.cc914e90-9325-4226-891a-547751ad2d8b@github.com>
 <wlUn59Prc2lkScRWs35JVMBIvYU9lSbxJ5_nLcGBMmA=.bff286b4-337c-45f3-ba79-c013b3a40451@github.com>
 <o1dSvaQw7w2bg31AfV4oKw6Gm1B7_C5DJau2_fMypNo=.bff7abc0-444d-424a-8ae9-443c23eda226@github.com>
Message-ID: <zbwwOY6vvd_etKGrixqMt356YyLJ_acXZgWuAFap-FY=.d05621d1-6e4f-4373-b874-f770458a65c3@github.com>

On Thu, 25 Apr 2024 12:55:48 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> Can you help me

Sure!  So I copied the test class (renamed, since we have another one with the name of TextAreaTest to `tests\system\src\test\java\test\com\sun\glass\ui\win`, same dir where WinTextRangeProviderTest.java resides.  Here is the file:


package test.com.sun.glass.ui.win;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.TextArea;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class TextAreaTest_Narrator_8330462 extends Application {
    public static void main(String[] args) throws Throwable {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) {
        primaryStage.setScene(new Scene(new VBox(new TextArea("javafx test"))));
        primaryStage.show();
    }
}


then, launch it in Eclipse.  this creates a run configuration, but fails to launch.

Edit the run configuration - select [Dependencies] tab, click on [Override Dependencies] button and replace the text in the bottom area with this:


--add-modules=javafx.base,javafx.graphics,javafx.controls,javafx.swing
--add-opens javafx.controls/test.com.sun.javafx.scene.control.test=javafx.base
--add-exports javafx.base/com.sun.javafx=ALL-UNNAMED
-Djava.library.path="../../../../build/sdk/lib"


like so:

![Screenshot 2024-04-25 at 08 47 25](https://github.com/openjdk/jfx/assets/107069028/73e63c2c-99a8-4434-8915-30751b7553dd)

then run again.  this time it *should* launch.  ;-)

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2077616263

From angorya at openjdk.org  Thu Apr 25 16:18:38 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Apr 2024 16:18:38 GMT
Subject: RFR: 8273657 : TextField: all text content must be selected
 initially
In-Reply-To: <CY45jcfPBZhdVGGixuWHuef3NMN66jzBHpgRkOoMOys=.b02ddba4-783a-4f88-9ec1-4bb866fabc02@github.com>
References: <CY45jcfPBZhdVGGixuWHuef3NMN66jzBHpgRkOoMOys=.b02ddba4-783a-4f88-9ec1-4bb866fabc02@github.com>
Message-ID: <IOWabONCg8TuaTtq41yyHbVVwYFKlu9LjR8ETz4pdwQ=.9fb28f43-4daf-4710-928d-f369af4b38e9@github.com>

On Thu, 25 Apr 2024 14:26:06 GMT, Karthik P K <kpk at openjdk.org> wrote:

> The text was not getting selected on adding the `TextField` to the scene initially, subsequently removing and adding the `TextField` to the scene selects the entire text present in the `TextField`. 
> 
> Made changes in the `TextFieldBehavior` constructor to select the text on adding the `TextField`.
> 
> Added unit test to validate the fix

the fix looks good.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1446#pullrequestreview-2023008742

From duke at openjdk.org  Thu Apr 25 17:39:42 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 17:39:42 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v20]
In-Reply-To: <f1phvRU0IwqgakYoTN4q90PiDn6Rgo44GMYXzxXdJzQ=.588de455-b1ba-4741-9fd5-2acffcd72fe7@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <IzwNFYhOwagprVWb2fMNs-242m0UFOSqTxKDhBiHBM4=.38d66708-a0a2-47cd-8bf6-bd3156954cd2@github.com>
 <_1PORuiG2jMxIotPa8KMMUkklamw9z_Gfee17aAXNSI=.abae7fcf-8a31-422b-96ce-8f341b0c216d@github.com>
 <3YyVXs2QQzF-VJ7GBcpeFYrdju46GnssAgSSSut-xxY=.9789ca7b-1ed8-43cf-b04c-8d3ba0b25e43@github.com>
 <f1phvRU0IwqgakYoTN4q90PiDn6Rgo44GMYXzxXdJzQ=.588de455-b1ba-4741-9fd5-2acffcd72fe7@github.com>
Message-ID: <gz1d4GJbtqh8ZSliXYxrZAqnZlZOqY2w0MfHbKGIzmg=.879fd404-0dc1-46bd-8eb4-e3e3b517ea5f@github.com>

On Thu, 25 Apr 2024 15:37:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Nope, this fix breaks Narrator.

I think, I do not get what Narrator is doing.

If I type "Testx" into a Text field, what should be highlighted?

![image](https://github.com/openjdk/jfx/assets/1366654/690e9331-3a92-4e4f-b6fd-a312f29cc592)

If moving the cursor in the tool [javafxreproducer](https://github.com/Siedlerchr/javafxreproducer) also always the last letter is highlighted. Does my patch sneakly sneak in in all JavaFX code I am running on my machine?

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2077813261

From angorya at openjdk.org  Thu Apr 25 18:05:45 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Apr 2024 18:05:45 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v21]
In-Reply-To: <6NLsGYbB5RVy3_LH20izb4i2wXRfiHGyqtkbcYIV-kM=.f7e980f0-c571-4027-bf88-fb991ff173a6@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <6NLsGYbB5RVy3_LH20izb4i2wXRfiHGyqtkbcYIV-kM=.f7e980f0-c571-4027-bf88-fb991ff173a6@github.com>
Message-ID: <7tpxnKJ8KJiik0i2szrCUnYtKt5AC663ggLSNT27c2Q=.bdfbc539-491d-4793-8cb4-3b54e7292700@github.com>

On Thu, 25 Apr 2024 06:37:00 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Switch from `@EnabledOnOS` to `assumeTrue`

Ok, let's try to narrow down the issue, using the sample TextAreaTest_Narrator_8330462 (it does not matter whether we have a TextArea or a TextField there).

In the master branch, with the Narrator (N.) enabled, the first thing I see it that the whole text is highlighted and the N. reads it.  When the user navigates using left/right arrow keys, the N. focus rectangle follows the windows cursor and announces the letter at the cursor.

With the fix, the windows cursor moves, but the N. rectangle does not move, and that is the issue.

Do you see the same with and without your fix (making sure you do a clean build when switching branches)?

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2077857093

From duke at openjdk.org  Thu Apr 25 19:30:43 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 19:30:43 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v21]
In-Reply-To: <7tpxnKJ8KJiik0i2szrCUnYtKt5AC663ggLSNT27c2Q=.bdfbc539-491d-4793-8cb4-3b54e7292700@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <6NLsGYbB5RVy3_LH20izb4i2wXRfiHGyqtkbcYIV-kM=.f7e980f0-c571-4027-bf88-fb991ff173a6@github.com>
 <7tpxnKJ8KJiik0i2szrCUnYtKt5AC663ggLSNT27c2Q=.bdfbc539-491d-4793-8cb4-3b54e7292700@github.com>
Message-ID: <MK6W-vLrHKUr4GqcI9blhFy6ERVmstRDyin430TXyLo=.d27c4085-0f78-4e21-ac77-d5988eee2420@github.com>

On Thu, 25 Apr 2024 18:03:17 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> focus rectangle follows the windows cursor and announces the letter at the cursor.

I did not change branches, but downloaded a binary from the net.

I type "abcdef" in the text field and then press cursor left - no change of the letter.

Maybe, this behavior was fixed in the main branch meanwhile. The binary uses JavaFX 21.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078027281

From prr at openjdk.org  Thu Apr 25 19:38:50 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Apr 2024 19:38:50 GMT
Subject: [jfx22u] RFR: 8322251: [Linux] JavaFX is not displaying CJK on Ubuntu
 23.10 and later
Message-ID: <KEwsKtzPHbSpRKPOeeFPwJuoKSpZ8XgRm4dlqIV7eT0=.5ccacb5a-4084-4e60-988a-4dbfa5056431@github.com>

Backport to jfx22u

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

Commit messages:
 - Backport 5182ea16ace78c4f61e2c38981aab62f6153294e

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

PR: https://git.openjdk.org/jfx22u/pull/27

From duke at openjdk.org  Thu Apr 25 19:39:02 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 19:39:02 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v22]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp 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 30 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into patch-1
 - Switch from `@EnabledOnOS` to `assumeTrue`
 - Re-order for more clearness
 - Fix tests
 - Remove unused import
 - classpath
 - Fix JavaDoc formatting
 - Discard changes to modules/javafx.graphics/src/test/addExports
 - Add missing exports
 - Try to use StubToolkit
 - ... and 20 more: https://git.openjdk.org/jfx/compare/5d390712...527e1ecf

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/ade506c0..527e1ecf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=21
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=20-21

  Stats: 285 lines in 4 files changed: 188 ins; 62 del; 35 mod
  Patch: https://git.openjdk.org/jfx/pull/1442.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1442/head:pull/1442

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

From duke at openjdk.org  Thu Apr 25 19:57:41 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 19:57:41 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v22]
In-Reply-To: <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>
Message-ID: <P9SEKD90EWvRwA95NFvJGQXX-stoiiIN-wzPyAK8bnw=.58323795-ee5d-48eb-bfa2-e9c9394b5680@github.com>

On Thu, 25 Apr 2024 19:39:02 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp 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 30 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into patch-1
>  - Switch from `@EnabledOnOS` to `assumeTrue`
>  - Re-order for more clearness
>  - Fix tests
>  - Remove unused import
>  - classpath
>  - Fix JavaDoc formatting
>  - Discard changes to modules/javafx.graphics/src/test/addExports
>  - Add missing exports
>  - Try to use StubToolkit
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/15c0f043...527e1ecf

... and no luck with Eclipse ...


WARNING: package test.com.sun.javafx.scene.control.test not in javafx.controls
Graphics Device initialization failed for :  d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078066723

From duke at openjdk.org  Thu Apr 25 20:22:52 2024
From: duke at openjdk.org (Carl Christian Snethlage)
Date: Thu, 25 Apr 2024 20:22:52 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v22]
In-Reply-To: <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>
Message-ID: <MYIp0cldtQPZlPqfkr8f2D2VQVhDqlQc6cbb8BcsEz8=.a8cf839a-4d88-4deb-a4f2-beeb4502041a@github.com>

On Thu, 25 Apr 2024 19:39:02 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp 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 30 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into patch-1
>  - Switch from `@EnabledOnOS` to `assumeTrue`
>  - Re-order for more clearness
>  - Fix tests
>  - Remove unused import
>  - classpath
>  - Fix JavaDoc formatting
>  - Discard changes to modules/javafx.graphics/src/test/addExports
>  - Add missing exports
>  - Try to use StubToolkit
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/a7c1c59f...527e1ecf

Tried on my local machine (win10) w/o patch with narrator:
![grafik](https://github.com/openjdk/jfx/assets/50491877/6603c29b-8f65-41d5-afe9-8db3eaf2fc75)

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078090611

From prr at openjdk.org  Thu Apr 25 20:25:37 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Apr 2024 20:25:37 GMT
Subject: [jfx22u] Integrated: 8322251: [Linux] JavaFX is not displaying CJK on
 Ubuntu 23.10 and later
In-Reply-To: <KEwsKtzPHbSpRKPOeeFPwJuoKSpZ8XgRm4dlqIV7eT0=.5ccacb5a-4084-4e60-988a-4dbfa5056431@github.com>
References: <KEwsKtzPHbSpRKPOeeFPwJuoKSpZ8XgRm4dlqIV7eT0=.5ccacb5a-4084-4e60-988a-4dbfa5056431@github.com>
Message-ID: <i1XhGbxcBRKYycYNvL_tjBfgeWcRo6kxb73SgZorTgs=.9a0a8873-4083-4be6-b69d-2ef49edb8aac@github.com>

On Thu, 25 Apr 2024 19:28:47 GMT, Phil Race <prr at openjdk.org> wrote:

> Backport to jfx22u

This pull request has now been integrated.

Changeset: 77e7e251
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jfx22u/commit/77e7e2514c25fa5f653938a6d0cbd4b1b6abe74f
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8322251: [Linux] JavaFX is not displaying CJK on Ubuntu 23.10 and later

Backport-of: 5182ea16ace78c4f61e2c38981aab62f6153294e

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

PR: https://git.openjdk.org/jfx22u/pull/27

From angorya at openjdk.org  Thu Apr 25 21:07:39 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Apr 2024 21:07:39 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v22]
In-Reply-To: <P9SEKD90EWvRwA95NFvJGQXX-stoiiIN-wzPyAK8bnw=.58323795-ee5d-48eb-bfa2-e9c9394b5680@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>
 <P9SEKD90EWvRwA95NFvJGQXX-stoiiIN-wzPyAK8bnw=.58323795-ee5d-48eb-bfa2-e9c9394b5680@github.com>
Message-ID: <s1FpWuYyBL76T_lc3ujsamf7BGNj31zqZPvytkV0BFk=.7aea256f-4a52-4eee-8844-3db245e1acde@github.com>

On Thu, 25 Apr 2024 19:54:37 GMT, Oliver Kopp <duke at openjdk.org> wrote:

> ... and no luck with Eclipse ...

I assume you imported the whole jfx repository into Eclipse as a gradle build as described here
https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingEclipse

If not, you could still use command line to build and execute tests, and that is described here 
https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX

I admit, there is a bit of pain configuring Eclipse - the main build uses gradle and Eclipse has other ideas when it sees a gradle project, but once you figure it out (I can help) you can debug in eclipse and it is much easier, in my opinion.

On the other hand, we could completely take the IDE out of the picture and just run the command line to build and test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078173790

From angorya at openjdk.org  Thu Apr 25 21:10:43 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Apr 2024 21:10:43 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v22]
In-Reply-To: <MYIp0cldtQPZlPqfkr8f2D2VQVhDqlQc6cbb8BcsEz8=.a8cf839a-4d88-4deb-a4f2-beeb4502041a@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <JSxEuOxRzN71UaJvcy3We3M-k6tYru9fj9yLtAX4GcA=.f82a648c-51ec-4840-a437-66787f17a62e@github.com>
 <MYIp0cldtQPZlPqfkr8f2D2VQVhDqlQc6cbb8BcsEz8=.a8cf839a-4d88-4deb-a4f2-beeb4502041a@github.com>
Message-ID: <rlTNXKctND9Fvvxmr93xy5uqvRcVlWlbhRQ1uh-MKhk=.e41e6546-5a7e-4f1e-859a-dd41c0ead8ca@github.com>

On Thu, 25 Apr 2024 20:09:53 GMT, Carl Christian Snethlage <duke at openjdk.org> wrote:

> Tried on my local machine (win10) w/o patch with narrator:

Thank you for checking this out!

so you see the windows cursor decouple from the narrator focus rectangle?  And when you press left/right, the narrator focus does not change?

just to confirm, you are running the latest master branch, or if now, which version of jfx/jdk?

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078178436

From duke at openjdk.org  Thu Apr 25 21:41:14 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 21:41:14 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Make use of Utils.clamp function

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/527e1ecf..968e3f05

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=22
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=21-22

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

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

From duke at openjdk.org  Thu Apr 25 22:17:41 2024
From: duke at openjdk.org (Carl Christian Snethlage)
Date: Thu, 25 Apr 2024 22:17:41 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
Message-ID: <SF9bj-qlzKSmyvMk3buaRh-ak7usUW4TriTvHv4FEGI=.117ef655-59a2-4dac-a0d2-a20e40646539@github.com>

On Thu, 25 Apr 2024 21:41:14 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make use of Utils.clamp function

I tested with Oracle OpenJDK 22.0.1 and JavaFX 22.0.1+7
Tested moving the cursor around but the narrator focus wont change.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078260806

From duke at openjdk.org  Thu Apr 25 22:37:44 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Thu, 25 Apr 2024 22:37:44 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
Message-ID: <wdUOdIefIHbqGp7YBSUGI4yQ0S-K1jmhFARizBSZGKQ=.d55f5f64-089f-4429-880d-cfb8b26d13af@github.com>

On Thu, 25 Apr 2024 21:41:14 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make use of Utils.clamp function

(I switched to TextField; is a bit easier for me to debug)

Intermedidate testing result:

When pressing "space", the rectangle moves correctly. When moving the cursor "inside" these much spaces, it also moves.

![image](https://github.com/openjdk/jfx/assets/1366654/1a239b18-9b86-4ced-a319-edea341ad2ce)

---

Ctrl+A leads to the box borders be of length of the complete text, not the visible text

![image](https://github.com/openjdk/jfx/assets/1366654/4e4b2610-cee2-450b-b1a6-1bea342a6e2a)

---

I thought, following would help, but does not:


     */
     public void selectRange(int anchor, int caretPosition) {
         caretPosition = Utils.clamp(0, caretPosition, getLength());
         anchor = Utils.clamp(0, anchor, getLength());
 
+        notifyAccessibleAttributeChanged(AccessibleAttribute.SELECTION_START);
+        notifyAccessibleAttributeChanged(AccessibleAttribute.SELECTION_END);
+        notifyAccessibleAttributeChanged(AccessibleAttribute.CARET_OFFSET);
+
         TextFormatter.Change change = new TextFormatter.Change(this, getFormatterAccessor(), anchor, caretPosition);
         TextFormatter<

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078282435

From andy.goryachev at oracle.com  Thu Apr 25 22:51:39 2024
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Thu, 25 Apr 2024 22:51:39 +0000
Subject: Proposal: Public InputMap (v2)
In-Reply-To: <7b20df6b-8c58-4356-8e86-30233eb46d0a@gmail.com>
References: <BL3PR10MB61854AB271D153E123636DC5E5242@BL3PR10MB6185.namprd10.prod.outlook.com>
 <7b20df6b-8c58-4356-8e86-30233eb46d0a@gmail.com>
Message-ID: <BL3PR10MB61857EE150CDC78E6410A854E5172@BL3PR10MB6185.namprd10.prod.outlook.com>

Hi there,

Thank you Robert for your feedback!  As a fellow application and custom component developer, I can't wait for this feature to get in.

I wonder if anyone else have any objections or feedback, specifically John Hendrikx and Martin Fox.  I hope the new proposal addresses the concerns you've raised earlier (support for stateless behaviors and explicit priority of event handlers in Controls), and we can move forward with the feature.

Cheers,
-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Robert Lichtenberger <r.lichtenberger at gmail.com>
Date: Monday, March 11, 2024 at 23:23
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Proposal: Public InputMap (v2)

I've had a look into the proposal and I like it a lot.

I've had numerous encounters with "little tweaks" to keyboard handling and/or behaviour that I had to work around, all of which would (as far as I can tell) have been avoidable, if this API were in existence.

So while there is quite some "API surface", as an application developer I can't wait to see this happening. It will go a long way to make JavaFX more easily usable.



--Robert
Am 11.03.24 um 16:22 schrieb Andy Goryachev:
Dear JavaFX developers:

Thank you all for your feedback on my earlier Behavior/InputMap proposal [6], [7].  There was some positive reaction to the idea of allowing for easy customization of JavaFX controls behavior, as well as some push back.  Some of the objections were:


  *   desire for some static behavior to avoid the per-instance penalty
  *   clearer separation of concerns between controls, skins, and behaviors
  *   desire to have some sort of public API for behaviors
  *   need for addressing an issue with the event handler execution order between application and skins

I would like to restart the discussion by submitting the updated proposal [0] which addresses the issues raised earlier.  The new proposal retains the idea of allowing wider customization of key mappings via the InputMap.  The new features include:


  *   separation of SkinInputMap from the control's InputMap
  *   enabling static skin input maps for stateless behaviors
  *   explicit priority levels for event handlers and key mappings created by the application and by the skin

The ideas put forth in this proposal have been validated with the proof-of-concept migration of some non-trivial controls:


  *   complex popup-like controls: ComboBox, ColorPicker, DatePicker
  *   complex text input controls: PasswordField, TextArea, TextField
  *   control with a stateless behavior: TabPane

as well as a brand new RichTextArea control being incubated [8].

Please take a look at the proposal [0], a list of discussion points [1], and the API Specification (javadoc) [2]. While the proposed API is ready for review, it isn't complete nor set in stone. We are looking for feedback, and will update the proposal based on the suggestions we receive from the community.  We encourage you to comment either in the mailing list, or by leaving comments inline in a draft pull request [3].

For context, the links to the original RFE [4] and the earlier proposals [6], [7] are provided below.

What do you think?
-andy


References

[0] Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md
[1] Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md
[2] API specification (javadoc): https://cr.openjdk.org/~angorya/InputMapV2/javadoc/
[3] Draft Pull Request for API comments and feedback: https://github.com/openjdk/jfx/pull/1395
[4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968
[5] Documenting behaviors (WIP): https://github.com/openjdk/jfx/tree/master/doc-files/behavior
[6] Earlier proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md
[7] Earlier proposal in the OpenJFX mailing list: https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html
[8] RichTextArea (Incubator) https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240425/f9dabe19/attachment-0001.htm>

From duke at openjdk.org  Fri Apr 26 07:16:42 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 26 Apr 2024 07:16:42 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
Message-ID: <0wVeu_CvK4fWA-wTGeaQB_sUi41GqtYkWz9kIzj-GMA=.1db9d681-cffb-4266-a772-c8afacf1f98e@github.com>

On Thu, 25 Apr 2024 21:41:14 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make use of Utils.clamp function

On branch `main`

`rm -rf build && ./gradlew sdk && ./gradlew  --info -PFULL_TEST=true systemTests:test --tests "test.com.sun.glass.ui.win.TextAreaTest_Narrator_8330462" || ./gradlew  --info -PFULL_TEST=true -PTEST_ONLY=true systemTests:test --tests "test.com.sun.glass.ui.win.TextAreaTest_Narrator_8330462"`

With [Carnac](https://github.com/Code52/carnac/) and [ShareX](https://getsharex.com/) I tried to capture what happens on **`main`**. Showing especially interactions with <kbd>Space</kbd> and <kbd>Cursor-left</kbd>.

https://github.com/openjdk/jfx/assets/1366654/f25bb801-565c-4d50-9471-c4391962049d

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2078773098

From lkostyra at openjdk.org  Fri Apr 26 07:40:42 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 26 Apr 2024 07:40:42 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <0Fphxjtor3rb6-a4BM6rQeezbW42NWJ1S0YZ7mAvV9A=.7b2432bd-527e-4d06-8957-467cc751f421@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

I also noticed there's a property in Prism settings called `disableD3D9Ex` - I will also remove it as it is now redundant.

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

PR Comment: https://git.openjdk.org/jfx/pull/1445#issuecomment-2078809190

From lkostyra at openjdk.org  Fri Apr 26 07:40:43 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 26 Apr 2024 07:40:43 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <5wFv7THFP7x_NTQaBqTHVQzwpQ95MlKTca2502zr1xg=.202e3ef6-48a2-4b31-9708-6fd52837570b@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
 <5wFv7THFP7x_NTQaBqTHVQzwpQ95MlKTca2502zr1xg=.202e3ef6-48a2-4b31-9708-6fd52837570b@github.com>
Message-ID: <4jrqJJKSPZxZoA7F-ZhEqhC7lQdV4AUEvN9K3TFVe8A=.60b1b650-de25-4d69-8392-c2a8effa42d7@github.com>

On Thu, 25 Apr 2024 15:20:54 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
>> 
>> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
>> 
>> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.
>
> modules/javafx.graphics/src/main/native-prism-d3d/D3DPipeline.cc line 237:
> 
>> 235: }
>> 236: 
>> 237: int getMaxSampleSupport(IDirect3D9Ex *d3d9, UINT adapter) {
> 
> Minor: In some cases you also change the name of the variable to add the "Ex" suffix., like in
> 
> D3DContext::D3DContext(IDirect3D9Ex *pd3dEx, UINT adapter)
>                                          ^
> 
> Here and In `PiplineManager.h` it's left as `IDirect3D9Ex * pd3d9;` without "Ex".
> I don't mind it either way (I would probably not bother changing them myself), but perhaps we should remain consistent.

You're right. Most places use it as `pd3d9` so I'll leave it this way (remove the `Ex` suffix from other spots).

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1445#discussion_r1580608891

From lkostyra at openjdk.org  Fri Apr 26 07:51:05 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 26 Apr 2024 07:51:05 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex [v2]
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <lwmkiFn5P1gA-lUT_ETJnxhN5lZTmB6lCEJq-AGLeIk=.854b201c-70b3-440c-a120-073d219c5e51@github.com>

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

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

 - Cleanup leftover "Ex" suffixes in variable names
 - Remove leftover disableD3D9Ex Prism setting

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1445/files
  - new: https://git.openjdk.org/jfx/pull/1445/files/2dbed83d..4a9605fc

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

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

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

From lkostyra at openjdk.org  Fri Apr 26 07:53:59 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 26 Apr 2024 07:53:59 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex [v3]
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <8KRlHNHKUI0zXOdqM75MlSKfAkwR3oLiiVvmIfg-zgM=.b9e425e4-17a4-4eca-a142-aa63663e2e35@github.com>

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

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

  Change pd3dEx to pd3d9

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1445/files
  - new: https://git.openjdk.org/jfx/pull/1445/files/4a9605fc..d915c19f

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

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

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

From nlisker at openjdk.org  Fri Apr 26 08:41:38 2024
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 26 Apr 2024 08:41:38 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex [v3]
In-Reply-To: <8KRlHNHKUI0zXOdqM75MlSKfAkwR3oLiiVvmIfg-zgM=.b9e425e4-17a4-4eca-a142-aa63663e2e35@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
 <8KRlHNHKUI0zXOdqM75MlSKfAkwR3oLiiVvmIfg-zgM=.b9e425e4-17a4-4eca-a142-aa63663e2e35@github.com>
Message-ID: <hfLQ0hknC5K3ja35pUK58TkiGcucLe4-SHCX-Qjg760=.19f4f815-4496-4320-8548-1579e7df49a1@github.com>

On Fri, 26 Apr 2024 07:53:59 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
>> 
>> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
>> 
>> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change pd3dEx to pd3d9

Marked as reviewed by nlisker (Reviewer).

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

PR Review: https://git.openjdk.org/jfx/pull/1445#pullrequestreview-2024451797

From kpk at openjdk.org  Fri Apr 26 09:37:45 2024
From: kpk at openjdk.org (Karthik P K)
Date: Fri, 26 Apr 2024 09:37:45 GMT
Subject: Integrated: 8273657 : TextField: all text content must be selected
 initially
In-Reply-To: <CY45jcfPBZhdVGGixuWHuef3NMN66jzBHpgRkOoMOys=.b02ddba4-783a-4f88-9ec1-4bb866fabc02@github.com>
References: <CY45jcfPBZhdVGGixuWHuef3NMN66jzBHpgRkOoMOys=.b02ddba4-783a-4f88-9ec1-4bb866fabc02@github.com>
Message-ID: <imZgZ65ou_XbjWncuxWwFNxP-eVi8l8C7f6D4agTfUU=.ddffe65e-fcdb-4e58-98c7-7c3aa7d48afc@github.com>

On Thu, 25 Apr 2024 14:26:06 GMT, Karthik P K <kpk at openjdk.org> wrote:

> The text was not getting selected on adding the `TextField` to the scene initially, subsequently removing and adding the `TextField` to the scene selects the entire text present in the `TextField`. 
> 
> Made changes in the `TextFieldBehavior` constructor to select the text on adding the `TextField`.
> 
> Added unit test to validate the fix

This pull request has now been integrated.

Changeset: c23ac747
Author:    Karthik P K <kpk at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c23ac74714a88649a65d455a06254e97cd6ecb3f
Stats:     25 lines in 2 files changed: 25 ins; 0 del; 0 mod

8273657: TextField: all text content must be selected initially

Reviewed-by: angorya

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

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

From arapte at openjdk.org  Fri Apr 26 10:00:42 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Fri, 26 Apr 2024 10:00:42 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
Message-ID: <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>

On Thu, 25 Apr 2024 21:41:14 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make use of Utils.clamp function

Here is a capture from my machine.
I have two copies of source code: One with fix and other without fix.
Please do unmute the video playback, you can listen to Narrator voice output.

https://github.com/openjdk/jfx/assets/11330676/bd3efcae-c661-4906-8388-fcb373e7e5c7

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2079046989

From mstrauss at openjdk.org  Fri Apr 26 10:07:39 2024
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 26 Apr 2024 10:07:39 GMT
Subject: RFR: 8320563: Remove D3D9 code paths in favor of D3D9Ex [v3]
In-Reply-To: <8KRlHNHKUI0zXOdqM75MlSKfAkwR3oLiiVvmIfg-zgM=.b9e425e4-17a4-4eca-a142-aa63663e2e35@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
 <8KRlHNHKUI0zXOdqM75MlSKfAkwR3oLiiVvmIfg-zgM=.b9e425e4-17a4-4eca-a142-aa63663e2e35@github.com>
Message-ID: <BqOdVIEYNT2VzsatC8ypX1fodkTZM7wplVLe03Hjve4=.e05f4dcd-f5f0-45ed-b10d-1850677363bc@github.com>

On Fri, 26 Apr 2024 07:53:59 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
>> 
>> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
>> 
>> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.
>
> Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change pd3dEx to pd3d9

LGTM

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

Marked as reviewed by mstrauss (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1445#pullrequestreview-2024655439

From jhendrikx at openjdk.org  Fri Apr 26 10:25:49 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 26 Apr 2024 10:25:49 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <7qG6BDt-WzGXpT-Joejfi4RTitULD_Yc7R-fqaWqmnI=.966bf691-fa2d-42ba-b15e-537391d323fe@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
 <7qG6BDt-WzGXpT-Joejfi4RTitULD_Yc7R-fqaWqmnI=.966bf691-fa2d-42ba-b15e-537391d323fe@github.com>
Message-ID: <8TyjBhKCcnSVP1jFABQsj0yCgyXcQGc-GNvjAOxjiAo=.76b43757-513f-46cd-bab9-4012e875648d@github.com>

On Wed, 24 Apr 2024 15:23:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright years
>
> One meta comment (not directly related to this review).
> 
>> > since it's been modified, please change the year
>> 
>> Sorry, I stopped doing that, I thought this was automated.
> 
> It is optional to update copyrights in a PR for a modified file (new files do need a correctly formatted copyright file with the right year). Ambarish periodically runs a script to update them. If you do update copyrights, you need to make sure that the year is right (if, for example, the PR was started in one year and finished the next yet). I tend to not update them for PRs that I expect to backport, since it increases the likelihood of not being able to use the `/backport` command.

@kevinrushforth This is ready to integrate, but I know the headful tests don't run automatically.  Would it be wise to run these once more before integrating?

Also, I re-read the issues https://bugs.openjdk.org/browse/JDK-8145496 and https://bugs.openjdk.org/browse/JDK-8129014, and I'm positive they're duplicates that would be fixed by this solution.  Shall I add these to this PR?

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2079108947

From kcr at openjdk.org  Fri Apr 26 15:44:01 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Apr 2024 15:44:01 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
 <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>
Message-ID: <yx0z8P0KeFLhTyrImpg2UN5HaZhB-lHZ7uLGNbSwqQI=.5a9eb9b9-0305-4d6b-9956-e73b232e5b74@github.com>

On Fri, 26 Apr 2024 09:57:34 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Here is a capture from my machine.
> I have two copies of source code: One with fix and other without fix.
> Please do unmute the video playback, you can listen to Narrator voice output.

@arapte Thank you for doing this and attaching it. This matches what I see and is, I think, what Andy is seeing as well.

@koppor This clearly shows that the current version of the fix in this PR introduces a regression. You will need to fix it before we can continue the review. While testing and debugging this problem, use a manual program rather than a Robot-based automated test.

Speaking of tests, we cannot reliably test a11y using automated tests, so I wouldn't spend any more time trying to get your new `TextAreaTest_Narrator_8330462` test working. The automated test in this PR that verifies the correctness of the new `getEndIndex` method will have to do (along with manual testing of the a11y functionality). Once you figure out what the problem is with the `getEndIndex` method, you might want to add additional cases to your test.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2079640408

From duke at openjdk.org  Fri Apr 26 15:56:01 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 26 Apr 2024 15:56:01 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
Message-ID: <xAfaaCjMakVR57Cw1nwG54uPYmTSTOY5aCXF5TOv6lQ=.08c9296b-058f-42fa-8577-a37ffc6a631c@github.com>

On Thu, 25 Apr 2024 21:41:14 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make use of Utils.clamp function

Sure thing! I will work on that!

And I will forget about the TextField. TextArea FTW!

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2079659598

From kcr at openjdk.org  Fri Apr 26 16:02:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Apr 2024 16:02:10 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <7qG6BDt-WzGXpT-Joejfi4RTitULD_Yc7R-fqaWqmnI=.966bf691-fa2d-42ba-b15e-537391d323fe@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
 <7qG6BDt-WzGXpT-Joejfi4RTitULD_Yc7R-fqaWqmnI=.966bf691-fa2d-42ba-b15e-537391d323fe@github.com>
Message-ID: <rDGR49mthLfgo3s_jbaNxoBrsq64OPiN8qaTzZkhZ7A=.de3e5f24-e8f3-4bb7-b0bc-8bdc09ef47b8@github.com>

On Wed, 24 Apr 2024 15:23:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright years
>
> One meta comment (not directly related to this review).
> 
>> > since it's been modified, please change the year
>> 
>> Sorry, I stopped doing that, I thought this was automated.
> 
> It is optional to update copyrights in a PR for a modified file (new files do need a correctly formatted copyright file with the right year). Ambarish periodically runs a script to update them. If you do update copyrights, you need to make sure that the year is right (if, for example, the PR was started in one year and finished the next yet). I tend to not update them for PRs that I expect to backport, since it increases the likelihood of not being able to use the `/backport` command.

> @kevinrushforth This is ready to integrate, but I know the headful tests don't run automatically. Would it be wise to run these once more before integrating?

Yes, that would be a good idea. I'll do that and report results here.

> Also, I re-read the issues https://bugs.openjdk.org/browse/JDK-8145496 and https://bugs.openjdk.org/browse/JDK-8129014, and I'm positive they're duplicates that would be fixed by this solution.

I think it's better to close JDK-8145496 as a duplicate. As for JDK-8129014, it is already closed (as not an issue), so we could either leave it alone or reopen it and reclose it as a Duplicate.

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2079670636

From duke at openjdk.org  Fri Apr 26 16:06:02 2024
From: duke at openjdk.org (eduardsdv)
Date: Fri, 26 Apr 2024 16:06:02 GMT
Subject: RFR: 8322619: Parts of SG no longer update during rendering -
 overlapping - culling - dirty [v3]
In-Reply-To: <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com>
References: <sizOHn5bjorTGLngEidSm0-gMLmqUBvaV1VcdOLjoRE=.ea4b54b9-c20f-4fd0-9602-340e38f23d4c@github.com>
 <_84BHtkO-P9Y5ar5wHt2z_B5J-dz7sv0x11FK_EoC7o=.4e5a259a-f454-451f-9898-fdeaab0e97f5@github.com>
Message-ID: <syYzHYipPB5lNyFApeVHk9teCHYybHqEGTOBUuSJP04=.f4754954-4d9a-400c-a7dc-f795af8bcdfb@github.com>

On Tue, 23 Jan 2024 11:51:52 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>> 
>> Explanation:
>> 
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one node is totally covered, and the other node is visible.
>> 
>> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found.
>> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean.
>> 
>> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen.
>> 
>> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early.
>> 
>> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself.
>> 
>> Useful parameters for further investigations:
>> -Djavafx.pulseLogger=true
>> -Dprism.printrendergraph=true
>> -Djavafx.pulseLogger.threshold=0
>> 
>> PR:
>> This PR ensures the dirty flag is set to false of the tree when the culling is used.
>> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it.
>> It would be great to have some feedback on this solution - maybe guiding me to a better solution.
>> 
>> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted accidental change in the .idea folder

I analysed the bug and can confirm the fix.
I summarized it in the following table. 
First column is the node structure, the others the steps: update nodes, render, update nodes, render, ...

| Nodes (L - left and R - right) / Steps			| 1st -> update Circles 	| 2nd -> render 	| 3rd -> update Lines 	| 4th -> render |
|-|-|-|-|-|
|HBox					|dirty				|clearDirty		|dirty				|clearDirty			
|HBox >StackPane-L			|dirty				|clearDirty		|dirty				|clearDirty
|HBox >StackPane-L > Group-L			|dirty				|clearDirty		|dirty				|clearDirty
|HBox >StackPane-L > Group-L >Line-L		|					|				|dirty				|clearDirty
|HBox >StackPane-L > Group-L >Circle-L		|dirty				|clearDirty	    	|
|HBox >StackPane-R			|dirty				|clearDirty  *1		|				|	*3
|HBox >StackPane-R > Group-R			|dirty				|dirty			|dirty  
|HBox >StackPane-R > Group-R > Line-R		|					|				|dirty  *2				|dirty
|HBox >StackPane-R > Group-R > Circle-R		|dirty				|dirty			|dirty				|dirty


*1: > no culling bits for first dirty region (Circle-L) -> skip children -> clearDirty() is not called on children
     > no root path for the second dirty region (Circle-R) -> no rendering and root.clearDirtyTree() stops on StackPane-R (the children stay dirty: Group-R and Circle-R)
	
*2: > Line-R.markTreeDirty() skips marking of further parents because Group-R is already dirty -> the StackPane-R stays clean

*3: > the dirty regions are not collected because the StackPane-R is clean -> Line-R is not rendered and the dirty-flag is not reset

-------
The error is that ``clearDirty()`` is not called in the second step on the children of StackPane-R (see *1). Subsequent changes in Line-R and Circle-R are not propagated to the root node because Group-R is already dirty (see *2) and therefore StackPane-R remains clean. The last changes are therefore ignored in the next rendering phase (see *3).

-------
We can simply say: **the dirty flags must be deleted on all nodes after rendering**.

If this is true, the test can simply check this instead of screenshots or similar.

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

PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2079676517

From kcr at openjdk.org  Fri Apr 26 19:39:00 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Apr 2024 19:39:00 GMT
Subject: RFR: 8314215: Trailing Spaces before Line Breaks Affect the Center
 Alignment of Text [v18]
In-Reply-To: <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
 <45oVKXgCo1DxhAycQl8WySaQG6i6Yf-bQKkI_1QM8Qs=.d7a592cb-40e8-4983-8438-60ca238b1fa9@github.com>
Message-ID: <G9uD13SQ-hcQoRcLC4JcZTvVfvPKyxJkzCdNP7INjts=.46b25ee4-8a59-4a41-9bff-f4181ce2fb09@github.com>

On Tue, 23 Apr 2024 19:30:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There are a number of tickets open related to text rendering:
>> 
>> https://bugs.openjdk.org/browse/JDK-8314215
>> 
>> https://bugs.openjdk.org/browse/JDK-8145496
>> 
>> https://bugs.openjdk.org/browse/JDK-8129014
>> 
>> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
>> 
>> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
>> 
>> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
>> 
>> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
>> 
>> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
>> 
>> The above behavior has NOT changed, is pretty standard for wrapped text controls,...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

The newly added test passes on all platforms.

@hjohn I assigned [JDK-8145496](https://bugs.openjdk.org/browse/JDK-8145496) to you to verify that it is fixed by this PR. If so, please close it as a duplicate of this bug. Since [JDK-8129014](https://bugs.openjdk.org/browse/JDK-8129014) is an old (JDK 7) issue, let's just leave it alone.

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

PR Comment: https://git.openjdk.org/jfx/pull/1236#issuecomment-2080012431

From angorya at openjdk.org  Fri Apr 26 20:03:56 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 26 Apr 2024 20:03:56 GMT
Subject: RFR: 8242553: IntegerSpinner and DoubleSpinner do not wrap around
 values correctly in some cases [v2]
In-Reply-To: <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
References: <yfdk6M8KKmBoePC2XfnR2QMUxdoEJ12Dj9BHYpk4nOw=.5f3c0262-27b9-4712-9b57-fd9381005126@github.com>
 <92DLfEOyMepXtrXQ5EBj3EYDVKe4A_eR7NgNvZVqjLY=.dc3fbc47-4139-4629-b2c8-ce2a8acb15de@github.com>
Message-ID: <yif65na4MGFlLjrlduHntdinSv2Gi0Y9OiLAT4iEAXE=.ea2395af-9754-4e4a-a501-6ee757e73d76@github.com>

On Wed, 10 Apr 2024 11:47:28 GMT, drmarmac <duke at openjdk.org> wrote:

>> This PR should fix the issue and cover all relevant cases with new tests.
>> 
>> Note: This involves a small behavior change, as can be seen in dblSpinner_testWrapAround_decrement_twoSteps() in SpinnerTest.java:749. With this change the wraparound behavior is similar to that of the IntegerSpinner.
>
> drmarmac has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use direction-dependent modulo arithmetic in DoubleSpinnerValueFactory wrap-around logic

Created https://bugs.openjdk.org/browse/JDK-8331214

@drmarmac would you like to update the javadoc or provide the description of the new behavior?

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

PR Comment: https://git.openjdk.org/jfx/pull/1431#issuecomment-2080043462

From duke at openjdk.org  Fri Apr 26 21:07:56 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 26 Apr 2024 21:07:56 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
 <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>
Message-ID: <am8EJaJiVIbnmn5mrXv0BTzzIlceRj28zfAies9hOHA=.3ee46375-3205-471c-a534-db582943e823@github.com>

On Fri, 26 Apr 2024 09:57:34 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make use of Utils.clamp function
>
> Here is a capture from my machine.
> I have two copies of source code: One with fix and other without fix.
> Please do unmute the video playback, you can listen to Narrator voice output.
> 
> https://github.com/openjdk/jfx/assets/11330676/bd3efcae-c661-4906-8388-fcb373e7e5c7

@arapte Please share your concrete Windows setup with me. I cannot reproduce here. I bet, you are on Windows 11. Reason: Here on my Windows 10 machine (and on @calixtus and on @siedlerchr's machine), the Narrator does not work, but the Narrator works on Windows 11. (from `master` branch)

Currently, I can only move on forward blindly. I hope, I find someone with a Windows 11 machine willing to try out the `base` branch of my fork and help me with the values... https://github.com/koppor/jfx/pull/4

---

I could get JFX to get compile on Windows 10, but I have issues to get it to run on Windows 11. You know, this things "java.util.concurrent.ExecutionException: org.gradle.process.internal.ExecException: A problem occurred starting process 'command '/VC/BIN/amd64/cl.exe'' and `rc.exe` not being found etc. (Yes, I followed the instructions, but the binaries are in `Hostx64/x64` instead of `x64`; some tools are only in `Windows Kits\10`. The installation instructions tell about Visual Studio 2022, but the example is windows_tools.properties is for 2019 (https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX).

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2080118102

From almatvee at openjdk.org  Fri Apr 26 22:58:30 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 26 Apr 2024 22:58:30 GMT
Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live
 Streaming [v2]
In-Reply-To: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
References: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
Message-ID: <rLFsBhiszmYAkQGP75-2nV4nBmwlKSr95N0phSfryAQ=.338a06a5-7c3e-459f-acb2-bf19a958c804@github.com>

> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming.
> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details):
>   - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag.
> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits.
> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams.
> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend.
> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes.
> - Fixed and improved debug output in Linux AV plugins.
> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time.
> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams.
> - Removed dead code from MediaManager.
> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases.

Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8282999
 - 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1435/files
  - new: https://git.openjdk.org/jfx/pull/1435/files/c4ac5e9e..0187b577

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

  Stats: 5035 lines in 351 files changed: 3411 ins; 991 del; 633 mod
  Patch: https://git.openjdk.org/jfx/pull/1435.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1435/head:pull/1435

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

From duke at openjdk.org  Fri Apr 26 22:58:37 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 26 Apr 2024 22:58:37 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
Message-ID: <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>

> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
> 
> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.

Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:

  Revert using utility method

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1442/files
  - new: https://git.openjdk.org/jfx/pull/1442/files/968e3f05..92155148

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=23
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1442&range=22-23

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

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

From duke at openjdk.org  Fri Apr 26 22:58:38 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Fri, 26 Apr 2024 22:58:38 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v23]
In-Reply-To: <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <PpfjE7gFiB11pq0II7GlRTn9PxTIxtZPzpU5GRVI4Mw=.d4fb434c-61cc-4d3c-95cc-0ba377d70586@github.com>
 <dTZR8xAoJIEs864S4uCV5086Bxd0bRyB82MiMHABE6M=.d798029c-4ce2-44ec-8038-18380750d2b5@github.com>
Message-ID: <w_AvVhpXbRGawRkDpJzOaKyKRFuaA5ylWep1BU9-23Y=.9a25d9af-dfaa-4eef-9440-23ae89edd754@github.com>

On Fri, 26 Apr 2024 09:57:34 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make use of Utils.clamp function
>
> Here is a capture from my machine.
> I have two copies of source code: One with fix and other without fix.
> Please do unmute the video playback, you can listen to Narrator voice output.
> 
> https://github.com/openjdk/jfx/assets/11330676/bd3efcae-c661-4906-8388-fcb373e7e5c7

@arapte OK, I have one more idea: The usage of the utility method in the non-issue related methods. I reverted the change at that place. Could you please recheck if the Narrator works on Windows 11? (I am still unable to compile JavaFX. Now, it's `stdio.h` missing)

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2080210927

From angorya at openjdk.org  Fri Apr 26 23:35:15 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 26 Apr 2024 23:35:15 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
Message-ID: <0actXomoVEWn8ddJOCnCCxCHVxC2cL9HiD_fPkOyvJc=.d6dab5ab-dc8b-4741-82e0-3f56bfa578e7@github.com>

On Fri, 26 Apr 2024 22:58:37 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert using utility method

Regression seems to be fixed.  No differences in behavior doing a quick test with with TextField/TextArea and Narrator on Windows 11.

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2025994582

From almatvee at openjdk.org  Fri Apr 26 23:36:26 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 26 Apr 2024 23:36:26 GMT
Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live
 Streaming [v3]
In-Reply-To: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
References: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
Message-ID: <3SdmBlkyxgNA-SKS_HBwk57MzX6LNJTXIdjupuVcVC4=.a7ee429c-62e3-4a05-8993-0358de3a0d10@github.com>

> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming.
> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details):
>   - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag.
> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits.
> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams.
> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend.
> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes.
> - Fixed and improved debug output in Linux AV plugins.
> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time.
> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams.
> - Removed dead code from MediaManager.
> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2]

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1435/files
  - new: https://git.openjdk.org/jfx/pull/1435/files/0187b577..84103bd4

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

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

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

From almatvee at openjdk.org  Fri Apr 26 23:38:09 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 26 Apr 2024 23:38:09 GMT
Subject: RFR: 8282999: Add support for EXT-X-MEDIA tag in HTTP Live
 Streaming [v2]
In-Reply-To: <rLFsBhiszmYAkQGP75-2nV4nBmwlKSr95N0phSfryAQ=.338a06a5-7c3e-459f-acb2-bf19a958c804@github.com>
References: <lmQOM8U1NmsrNocEAw6hVDXzdkqN1M-CyWf4oGcBJ7c=.d5df7742-71b2-4456-81c5-ed5d7dc247c9@github.com>
 <rLFsBhiszmYAkQGP75-2nV4nBmwlKSr95N0phSfryAQ=.338a06a5-7c3e-459f-acb2-bf19a958c804@github.com>
Message-ID: <jOwAnL_YVdinwbacQpkS3UP1bFix1exvf06iph1Tbg8=.91415898-826f-41c9-86fd-32c1fe62c29d@github.com>

On Fri, 26 Apr 2024 22:58:30 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - Added support for #EXT-X-MEDIA tag to HTTP Live Streaming.
>> - Following audio renditions via #EXT-X-MEDIA tag will be supported (see CSR for more details):
>>   - MP2T streams with one H.264/AVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and elementary AAC audio stream via #EXT-X-MEDIA tag.
>>   - fMP4 streams with one H.264/AVC or H.265/HEVC video track and fMP4 streams with one AAC audio track via #EXT-X-MEDIA tag.
>> - Separate audio stream will be playback via separate chain of GStreamer elements inside one pipeline. Which means two "javasource" elements will be used inside one pipeline and they will be reading data independently of each other via two separate HLSConnectionHolders. GStreamer will handle audio and video synchronization based on PTS as for other streams. Other solutions were considered such as one "javasource" with multiple source pads, but such implementation will be more complex and does not provide any benefits.
>> - HLSConnectionHolder which handles video stream will also parse all information for separate audio stream and then create child HLSConnectionHolder for separate audio stream which will be responsible for downloading audio segments and seek of audio streams.
>> - Parser in HLSConnectionHolder was reworked to make it more readable and easy to maintain and extend.
>> - JavaDoc updated to point to latest HLS implementation vs old draft. It also updated with information on #EXT-X-MEDIA tag. Also, added missing information on AAC elementary streams and fMP4 from previous fixes.
>> - Fixed and improved debug output in Linux AV plugins.
>> - Added new property to "dshowwrapper" to disable PTS reset for each new segment, since with #EXT-X-MEDIA tag audio and video segments are not align and they can start at different time.
>> - Fixed missing PTS on first buffer after seek in MP2T demuxer in "dshowwrapper". Without it audio and video synchronization breaks with two separate streams.
>> - Removed dead code from MediaManager.
>> - Added handling for GST_MESSAGE_LATENCY. Based on GStreamer doc we need to call gst_bin_recalculate_latency() when such message received. Not sure if we really need to do this, but with separate video and audio streams we do receive this message when seek is done. Most likely due to video and audio is not align perfectly when we seek. For other streams this message is not received in most cases.
>
> Alexander Matveev 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 remote-tracking branch 'upstream/master' into JDK-8282999
>  - 8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming

8282999: Add for support EXT-X-MEDIA tag in HTTP Live Streaming [v2]
- Added missing header. I do not have Ubuntu 16.04 and this issue does not reproduce on Ubuntu 22.04.

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

PR Comment: https://git.openjdk.org/jfx/pull/1435#issuecomment-2080234887

From tsayao at openjdk.org  Sun Apr 28 15:32:22 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Apr 2024 15:32:22 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v4]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <PBxXNxEG4TvTRb-ktVtdXsaoJmOeM2ecB1d6FWlKPtQ=.dee10adb-f88c-470d-878a-ad9b6c5104cc@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

  Improve error handling

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/30203eab..aa321efb

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

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

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

From tsayao at openjdk.org  Sun Apr 28 15:32:23 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sun, 28 Apr 2024 15:32:23 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v3]
In-Reply-To: <8XGeXEwVKOAsWA1ZhNLkn2zMCWlopDTwNI4z4zbt9aE=.e88a490e-b75d-4553-a051-63b76dac7311@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <7peXj3gequ3HGNd_FGJKchYB9ySQ784E1Y2Je2rU8gA=.0cffb403-0e41-4a76-a756-8a2649ad6db7@github.com>
 <8XGeXEwVKOAsWA1ZhNLkn2zMCWlopDTwNI4z4zbt9aE=.e88a490e-b75d-4553-a051-63b76dac7311@github.com>
Message-ID: <DFejdNTRIOy4Wh8s-ApH_LjiAN-uOZFNCLIZ5JdkCfI=.04c83669-a927-438e-8e9a-4f9b51a22e25@github.com>

On Thu, 25 Apr 2024 12:19:19 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Forgot debug message
>
> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 252:
> 
>> 250:             eglGetProcAddress("glGetProgramInfoLog");
>> 251:     ctxInfo->glTexImage2DMultisample = (PFNGLTEXIMAGE2DMULTISAMPLEPROC)
>> 252:             dlsym(RTLD_DEFAULT,"glTexImage2DMultisample");
> 
> I think these three functions should also be available via `eglGetProcAddress`

You're right. Fixed.

> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 258:
> 
>> 256:             dlsym(RTLD_DEFAULT,"glBlitFramebuffer");
>> 257: 
>> 258:     eglSwapInterval(eglDisplay, 0);
> 
> `eglSwapInterval` can potentially fail, we should check for errors here

Removed this call as it needs a surface.

> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 267:
> 
>> 265: 
>> 266:     // Release context once we are all done
>> 267:     eglMakeCurrent(eglDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
> 
> Similar as above, `eglMakeCurrent` can also fail

Fixed.

> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLContext.c line 310:
> 
>> 308:     interval = (vSyncNeeded) ? 1 : 0;
>> 309:     ctxInfo->state.vSyncEnabled = vSyncNeeded;
>> 310:     eglSwapInterval(ctxInfo->eglDisplay, interval);
> 
> Check for errors like above

Fixed. `eglSwapInterval` fails without a surface, so added a check.

> modules/javafx.graphics/src/main/native-prism-es2/linux/egl/LinuxGLDrawable.c line 58:
> 
>> 56:     }
>> 57: 
>> 58:     EGLSurface eglSurface = eglCreateWindowSurface(pfInfo->eglDisplay, pfInfo->eglConfig,
> 
> I would add a check to make sure the surface was created successfully, as it can potentially return `EGL_NO_SURFACE`.
> 
> Some additional information from `eglGetError` could also come in handy if `eglCreateWindowSurface` does fail.

Added.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1582202507
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1582202270
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1582202434
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1582202110
PR Review Comment: https://git.openjdk.org/jfx/pull/1381#discussion_r1582202475

From thiago.sayao at gmail.com  Sun Apr 28 21:45:22 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sun, 28 Apr 2024 18:45:22 -0300
Subject: Wayland
In-Reply-To: <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
 <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
Message-ID: <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>

Hi,

I managed to display a very basic wayland toplevel surface from java:
https://github.com/tsayao/glass-wayland

If you are using intellij, just run the "Test App" (with java 22).

generate.sh will jextract the code from wayland-client.

I rushed to get the window displayed - so it doesn't look good yet (but I
do accept suggestions).

It uses a java wayland-scanner (included) to read protocol xml files and
generate code that uses jextracted calls.

The sample also binds EGL and GL apis, but just because wayland requires a
buffer to display the surface. Maybe it was easier to use a shared memory :)

Credits to (I adapted it to ouput jextract compatible code):
https://github.com/gfxstrand/wayland-java/tree/master/scanner

Cheers

Em ter., 23 de abr. de 2024 ?s 09:11, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> I'm doing some work here:
> https://github.com/tsayao/glass-wayland
>
> So far it's been a good experience to use FFM / jextract.
>
> The idea is to plug it as a glass wayland backend when it's good enough.
>
>
>
> Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker <nlisker at gmail.com>
> escreveu:
>
>> Not sure it helps with warmup, but marking a foreign function as critical
>> can improve performance:
>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
>> .
>>
>> On Mon, Apr 22, 2024 at 10:02?PM Philip Race <philip.race at oracle.com>
>> wrote:
>>
>>> No, it wasn't. I didn't even use jextracted code.
>>> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
>>> overhead on my MacBook
>>> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
>>> measured, so do these lazily if you can.
>>> And warmup cost is that it takes about 10000 iterations to get code
>>> fully compiled.
>>>
>>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>>>      intx CompileThreshold                         =
>>> 10000                                  {pd product} {default}
>>>     double CompileThresholdScaling                  =
>>> 1.000000                                  {product} {default}
>>>     uintx IncreaseFirstTierCompileThresholdAt      =
>>> 50                                        {product} {default}
>>>      intx Tier2CompileThreshold                    =
>>> 0                                         {product} {default}
>>>      intx Tier3CompileThreshold                    =
>>> 2000                                      {product} {default}
>>>      intx Tier4CompileThreshold                    =
>>> 15000                                     {product} {default}
>>>
>>> -phil.
>>>
>>>
>>> On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>>
>>> I think the startup time might be related to all static symbol lookups.
>>> So I'm manually including just what is needed:
>>>
>>> jextract --output src -t com.sun.glass.wayland.extracted \
>>>   --header-class-name GlassWayland \
>>>   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
>>>   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
>>>    glass-wayland.h \
>>>    --include-function xdp_portal_initable_new \
>>>    --include-function xdp_session_close \
>>>    --include-function xdp_portal_open_file \
>>>    --include-function xdp_portal_open_file_finish \
>>>    --include-function g_object_unref \
>>>    --include-function g_timeout_add \
>>>    --include-function g_add_idle \
>>>    --include-function g_main_loop_run \
>>>    --include-function g_main_loop_new \
>>>    --include-function g_main_loop_ref \
>>>    --include-function g_main_loop_unref \
>>>    --include-function g_main_loop_quit \
>>>    --include-function g_settings_new \
>>>    --include-function g_settings_get_int \
>>>    --include-function wl_display_connect \
>>>    --include-function wl_display_disconnect \
>>>    --include-function wl_display_roundtrip \
>>>    --include-function wl_display_dispatch_pending \
>>>    --include-typedef GAsyncReadyCallback \
>>>    --include-typedef GSourceFunc \
>>>    --include-typedef GError
>>>
>>>
>>> Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race <
>>> philip.race at oracle.com> escreveu:
>>>
>>>> As a reminder, using FFM will require all FX *applications* to specify
>>>> --enable-native-access on the command line
>>>> Although this is likely coming to JNI soon too.
>>>>
>>>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>>>
>>>> But one thing to watch out for with FFM is startup + warm up time.
>>>> I struggled a lot with that in using FFM for just one library in the
>>>> java.desktop module.
>>>>
>>>> -phil
>>>>
>>>> On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>>
>>>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the
>>>> N-1 rule.
>>>>
>>>> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>>>>
>>>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we
>>>>> did with 21. I suggested initially to bump to Java 22 exactly for FFM as
>>>>> it's very useful for JavaFX, but was told we shouldn't since it's not an
>>>>> LTS version.
>>>>>
>>>>> I have no idea how long the work on Wayland will take including the
>>>>> code review (a rather long process), but you should be able to request code
>>>>> reviews with FFM and have it ready for integration by Java 25.
>>>>>
>>>>> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
>>>>> thiago.sayao at gmail.com> wrote:
>>>>>
>>>>>> I was just experimenting, but it seems to be less work than going
>>>>>> with JNI.
>>>>>> If I am correct, the next Java LTS will be 25, which will be required
>>>>>> on JavaFX 29 to be released on September/29.
>>>>>>
>>>>>> It's 7 years - that's really too much.
>>>>>>
>>>>>> Maybe it's still worthwhile to prototype using FFM and then port
>>>>>> everything to JNI.
>>>>>>
>>>>>> -- Thiago.
>>>>>>
>>>>>>
>>>>>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>>>>>> kevin.rushforth at oracle.com> escreveu:
>>>>>>
>>>>>>> Note also that we cannot use Panama in the JavaFX internals yet,
>>>>>>> since
>>>>>>> the minimum version of the JDK is 21.
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > I did a small test app to explore Wayland client and portals (for
>>>>>>> > Robot and dialogs such as file open/save).
>>>>>>> >
>>>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>>>> >
>>>>>>> > It seems it will work as a glass backend, but some walls will be
>>>>>>> hit
>>>>>>> > on the way :)
>>>>>>> >
>>>>>>> > I have tried to use jextract (from project Panama) to work
>>>>>>> directly
>>>>>>> > with java, but it seems it does not support wl_ types.
>>>>>>> >
>>>>>>> > -- Thiago.
>>>>>>>
>>>>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240428/b755ff72/attachment-0001.htm>

From lkostyra at openjdk.org  Mon Apr 29 07:32:14 2024
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 29 Apr 2024 07:32:14 GMT
Subject: Integrated: 8320563: Remove D3D9 code paths in favor of D3D9Ex
In-Reply-To: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
References: <KoMMk4ZHlXEZFdlO1971yCFf7Z2b-lm6lelaeHg94oQ=.49db8bf8-015a-4cf3-9e7b-905f09802dd3@github.com>
Message-ID: <yaHKv3VPeMXvMx4HJNO0q3rlRzIn5NKbNphPHQKGoB0=.77c772c6-aa2c-4bfb-b939-6439eda93300@github.com>

On Tue, 23 Apr 2024 10:33:58 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> JFX minimum requirements guarantee 9Ex availability, so old non-Ex paths are no longer needed.
> 
> In multiple parts (ex. Mesh, Graphics, etc.) where the Device is acquired I changed the type to explicitly use `IDirect3DDevice9Ex`. Technically it doesn't matter much (`IDirect3DDevice9Ex` inherits `IDirect3DDevice` - it was leveraged to transparently use the Ex device in the backend) but now we don't have the non-Ex device, so that keeps it a bit more consistent and clear IMO.
> 
> Verified by running tests on Windows 11, did not notice any regressions. Unfortunately I have no way to test this on older systems.

This pull request has now been integrated.

Changeset: 7294849c
Author:    Lukasz Kostyra <lkostyra at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/7294849caefe1c986fdf7764f4c41b5047ed7765
Stats:     142 lines in 19 files changed: 0 ins; 62 del; 80 mod

8320563: Remove D3D9 code paths in favor of D3D9Ex

Reviewed-by: nlisker, mstrauss

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

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

From kpk at openjdk.org  Mon Apr 29 08:58:12 2024
From: kpk at openjdk.org (Karthik P K)
Date: Mon, 29 Apr 2024 08:58:12 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
Message-ID: <Kw4USopvKE05F75vykUes5ru6y1EB_bhaMMQnhLr5vw=.2b3bc2cb-c5e0-4777-a87f-2ada130149c1@github.com>

On Fri, 19 Apr 2024 20:36:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with  Character.isLetterOrDigit(int).
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330590.prev.word
>  - 8330590 TextInputControl: previous word fails with Bhojpuri characters

LGTM
Validated the changes manually and using the unit tests.
The new unit test fails without the fix and passes with the fix provided in this PR as expected.

I have one query though, while moving from left to write by word (using option + RIGHT) for the same text, after the first word "Bhojpuri", it goes to the beginning of the Bhojpuri text and then to the end of the Bhojpuri text. But if it was all English text, then it directly goes to the end of the text and skips space. Is this expected?

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

Marked as reviewed by kpk (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1444#pullrequestreview-2027897621

From fkirmaier at openjdk.org  Mon Apr 29 09:30:18 2024
From: fkirmaier at openjdk.org (Florian Kirmaier)
Date: Mon, 29 Apr 2024 09:30:18 GMT
Subject: RFR: 8322619: Parts of SG no longer update during rendering -
 overlapping - culling - dirty [v4]
In-Reply-To: <sizOHn5bjorTGLngEidSm0-gMLmqUBvaV1VcdOLjoRE=.ea4b54b9-c20f-4fd0-9602-340e38f23d4c@github.com>
References: <sizOHn5bjorTGLngEidSm0-gMLmqUBvaV1VcdOLjoRE=.ea4b54b9-c20f-4fd0-9602-340e38f23d4c@github.com>
Message-ID: <_xmpnIww6iOxModrEdaFZ1lf8EhzwUERbpTeKb-XQJU=.b458c63c-b713-4c96-a504-c5dea68ce7db@github.com>

> In some situations, a part of the SG is no longer rendered.
> I created a test program that showcases this problem.
> 
> Explanation:
> 
> This can happen, when a part of the SG, is covered by another Node.
> In this part, one node is totally covered, and the other node is visible.
> 
> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found.
> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean.
> 
> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen.
> 
> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early.
> 
> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself.
> 
> Useful parameters for further investigations:
> -Djavafx.pulseLogger=true
> -Dprism.printrendergraph=true
> -Djavafx.pulseLogger.threshold=0
> 
> PR:
> This PR ensures the dirty flag is set to false of the tree when the culling is used.
> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it.
> It would be great to have some feedback on this solution - maybe guiding me to a better solution.
> 
> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1310/files
  - new: https://git.openjdk.org/jfx/pull/1310/files/530adc10..5f9f1574

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

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

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

From tsayao at openjdk.org  Mon Apr 29 13:42:53 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 29 Apr 2024 13:42:53 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v5]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <2VvdHSujSOiM9rBCwt0tWMa8NWWV2r56FYFw71IieoU=.808dbc0e-b7a7-43f4-9503-a85f5ead121f@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

  Fix cast

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/aa321efb..4d62744a

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

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

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

From tsayao at openjdk.org  Mon Apr 29 13:46:52 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Mon, 29 Apr 2024 13:46:52 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v6]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <JC28ic4toiDBu8j-Ycjce8aI5wgFBHAPfXQrPYvXcSY=.17707ab2-5788-40d9-8c17-3a64323153cb@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

  Revert "Fix cast"
  
  This reverts commit 4d62744aeedd23090be369e576d492d671fff930.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/4d62744a..f8c61efc

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

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

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

From duke at openjdk.org  Mon Apr 29 14:11:12 2024
From: duke at openjdk.org (yosbits)
Date: Mon, 29 Apr 2024 14:11:12 GMT
Subject: RFR: 8320912: IME should commit on focus change
In-Reply-To: <EaP24kpmtjsfeoTtVgf8PMbgP4f_nvSbO75JFCz-ci0=.746601e8-316c-4c37-97c3-64c5dffde013@github.com>
References: <EaP24kpmtjsfeoTtVgf8PMbgP4f_nvSbO75JFCz-ci0=.746601e8-316c-4c37-97c3-64c5dffde013@github.com>
Message-ID: <0yQsBrdXx7l57n8-hxLkWXnA0OTRCd2Y6CtH1idg13A=.d71474d5-7d76-452b-9cdc-41fa186d1de6@github.com>

On Tue, 30 Jan 2024 20:32:36 GMT, Martin Fox <mfox at openjdk.org> wrote:

> This is a Mac only bug. If the user was in the middle of IM text composition and clicked on a different node the partially composed text was left in the old node and the IM window wasn't dismissed. This PR implements the existing finishInputMethodComposition call so it can commit the text and dismiss the IM window before focus moves away from the node where composition was taking place.
> 
> This PR changes the implementation of `unmarkText` to match what we want and what Apple says it should do ("The text view should accept the marked text as if it had been inserted normally"). With that said I haven't found an IME that calls this routine.

**I found a serious problem with this change.**

After applying this change, the IME cannot be typed after the small window is displayed.
Even basic applications that use ContextMenu, ChoiceBox, ComboBox, MenuButton, etc. are affected.
The impact of this problem will be perceived as block level in the IME usage environment.

This problem is no longer reproduced by reverting the changes in JDK-8320912.
However, since JDK-8301900 depends on the changes in JDK-8320912, 8301900 was also reverted.

This problem can be reproduced with the following application

``` Java
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.ChoiceBox;
import javafx.scene.control.ComboBox;
import javafx.scene.control.Label;
import javafx.scene.control.MenuButton;
import javafx.scene.control.MenuItem;
import javafx.scene.control.TextArea;
import javafx.scene.control.TextField;
import javafx.scene.layout.HBox;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class ImeTest extends Application{

	enum Items {
		A,
		B,
		C
	}
	
	@Override
	public void start(Stage primaryStage) throws Exception {
		ChoiceBox<Items> choiceBox = new ChoiceBox<>();
		ComboBox<Items> comboBox = new ComboBox<>();
		MenuButton menuButton = new MenuButton();
		
		menuButton.getItems().addAll(new MenuItem("1"), new MenuItem("2"));
		choiceBox.getItems().addAll(Items.values());
		comboBox.getItems().addAll(Items.values());
		
		VBox root = new VBox(
			new Label("1. Select any of the following control items."),
			new HBox( 8, choiceBox, comboBox, menuButton),
			new Label("2. Entering text with the IME."),
			new HBox(8, new TextField(), new TextArea()));
		
		Scene scene = new Scene(root, 600, 600);
		primaryStage.setScene(scene);
		primaryStage.show();
		
	}
	
	public static void main(String[] args) {
		Application.launch(args);
	}
}

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

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-2082858747

From arapte at openjdk.org  Mon Apr 29 14:13:14 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 29 Apr 2024 14:13:14 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
Message-ID: <nXyvRKjd6bi7XLdN0uVAjHcMlZMEglOxPbFjVdEI3es=.92adb7ec-e41d-4561-88f6-4d01ee348912@github.com>

On Fri, 26 Apr 2024 22:58:37 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert using utility method

In addition to the evaluation added by @jperedadnr to [JDK-8330462](https://bugs.openjdk.org/browse/JDK-8330462)
- The UI Automation framework offers two sets of APIs.
    1. Provider APIs : to be implemented by UI providers ( JavaFX )
    2. Client APIs : to be implemented by the Client applications like (Screen readers, DeepL)
- Both providers(JavaFX) and client application should follow their respective specification.
- For this scenario
    1. Client Application should follow : [IUIAutomationTextRange::GetText method](https://learn.microsoft.com/en-us/windows/win32/api/uiautomationclient/nf-uiautomationclient-iuiautomationtextrange-gettext#parameters)
    2. JavaFX should follow : [ITextRangeProvider::GetText](https://learn.microsoft.com/en-us/windows/win32/api/uiautomationcore/nf-uiautomationcore-itextrangeprovider-gettext#parameters)
- As per both above spec, the length variable could be either -1 or a valid value.
- The check we had earlier: `length != -1` was based on the spec, but seems like we need to validate against out of range check i.e. `length <= end - start`.
- It seems in this scenario DeepL invokes the GetText call with INT_MAX value, which is the root cause. The check `length <= end - start` should handle that scenario.
- and `length < 0` would future protect us from any negative value though as per spec `length != -1` should suffice

Testing:
- I could reproduce the issue with DeepL
- Issue gets fixed with this fix and also with the change that I suggesting
- A couple tests of negative values for start and end should be removed.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 104:

> 102:         int length = text.length();
> 103:         start = Utils.clamp(0, start, length);
> 104:         end = Utils.clamp(start, end, length);

This is only cleanup and not required for this fix.

modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 124:

> 122:         // In case there was an overflow, return the maximum end index
> 123:         if (res < 0) return maxEndIndex;
> 124:         return res;

In this class,
- The index **start** and **end** are guaranteed to be +ve values such that, `0 <= start <= end <= length` (length is the total length of text in the text component). : please check the method `validateRange()`
- So we only need to validate that the variable `length` in this helper method is valid i.e.
   1. `length > 0` and
   2. `length <= end - start`


    /**
     * In the context of substrings, this is a helper method to get the end offset index
     * from the start index for a given length of a substring.
     *
     * @param startIndex The start index of the range in the string. Needs to be 0 or more (not checked in the code).
     * @param length The requested length of a substring in the range when starting from "start".
     *               Invalid values are treated as full length.
     * @param endIndex The end index of the range in the string. Needs to be equal or greater than startIndex
     *                    (not checked in the code).
     */
    static int getEndOffsetIndex(int startIndex, int length, int endIndex) {
        if (length < 0 || (endIndex - startIndex) <= length) {
            return endIndex;
        }
        return startIndex + length;
    }

- With this change
    1. The start and end index values are always positive and hence negative value tests should be removed.
    2. The name of method is changed so, the Shim class would need a change too.
    3. The fix could be as simple as below one line correction in the ternary statement in the GetText() method, but then we won't be able to add the test. So keeping the helper method would be good idea.
`int endOffset = (length < 0 || (endIndex - startIndex) <= length) ? end : start + maxLength;`

tests/system/src/test/java/test/com/sun/glass/ui/win/WinTextRangeProviderTest.java line 93:

> 91: 
> 92:                 // No range check for maxEndIndex
> 93:                 Arguments.of(-1, -1, 2, -1),

negative valued tests for `start` or `end` are not required for this particular scenario as `0 <= start <= end <= total length of text` is guaranteed.

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

Changes requested by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1442#pullrequestreview-2028389977
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1583158450
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1583019536
PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1583159253

From arapte at openjdk.org  Mon Apr 29 14:20:16 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 29 Apr 2024 14:20:16 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
Message-ID: <_6U9__N33Qa6cY9dvyK3sTyrbZl9wxtKasciO-QK2T0=.25ba8f3d-8fee-4c92-9b9f-d7e00fd2a3c4@github.com>

On Fri, 26 Apr 2024 22:58:37 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> Fixes https://bugs.openjdk.org/browse/JDK-8330462.
>> 
>> If the parameter `maxLength` is larger than `Integer.MAX_VALUE - start`, then an addition of `start` to it leads to a negative value. This is "fixed" by using `Math.max` comparing the `maxLength` and `maxLength + start`.
>
> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert using utility method

Additionally I tried to figure out the reason as to why DeepL makes the `GetText` call with `INT_MAX` value by reading through all APIs of [ITextRangeProvider interface](https://learn.microsoft.com/en-us/windows/win32/api/uiautomationcore/nn-uiautomationcore-itextrangeprovider).
Tried to understand if the client application reads any attributes of the text range that can be used to determine the `maxLength` value.
If we find a dependency then the right way would have to fix that dependency. But I could not identify any attribute or any API that could be related to the `maxLength` value.

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

PR Comment: https://git.openjdk.org/jfx/pull/1442#issuecomment-2082876837

From angorya at openjdk.org  Mon Apr 29 14:49:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 29 Apr 2024 14:49:12 GMT
Subject: RFR: 8320912: IME should commit on focus change
In-Reply-To: <0yQsBrdXx7l57n8-hxLkWXnA0OTRCd2Y6CtH1idg13A=.d71474d5-7d76-452b-9cdc-41fa186d1de6@github.com>
References: <EaP24kpmtjsfeoTtVgf8PMbgP4f_nvSbO75JFCz-ci0=.746601e8-316c-4c37-97c3-64c5dffde013@github.com>
 <0yQsBrdXx7l57n8-hxLkWXnA0OTRCd2Y6CtH1idg13A=.d71474d5-7d76-452b-9cdc-41fa186d1de6@github.com>
Message-ID: <f2AYS38OtTQL4-Kr1DigtTeOP8hqjp0jsG6OjAs2HPQ=.354500be-d980-45f4-a18d-d46cc6ff0167@github.com>

On Mon, 29 Apr 2024 14:09:03 GMT, yosbits <duke at openjdk.org> wrote:

> I found a serious problem with this change.

Thank you!  I've created https://bugs.openjdk.org/browse/JDK-8331319 feel free to update / clarify the information in the ticket.

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

PR Comment: https://git.openjdk.org/jfx/pull/1356#issuecomment-2082942526

From duke at openjdk.org  Mon Apr 29 15:50:15 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 29 Apr 2024 15:50:15 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <nXyvRKjd6bi7XLdN0uVAjHcMlZMEglOxPbFjVdEI3es=.92adb7ec-e41d-4561-88f6-4d01ee348912@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
 <nXyvRKjd6bi7XLdN0uVAjHcMlZMEglOxPbFjVdEI3es=.92adb7ec-e41d-4561-88f6-4d01ee348912@github.com>
Message-ID: <oiuSStHOX444AOkbgYark-n1Lg9MKD6WQqnKwzo4FSI=.f1566360-9b68-4a0b-b6b4-b03f0103318d@github.com>

On Mon, 29 Apr 2024 14:09:52 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert using utility method
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 104:
> 
>> 102:         int length = text.length();
>> 103:         start = Utils.clamp(0, start, length);
>> 104:         end = Utils.clamp(start, end, length);
> 
> This is only cleanup and not required for this fix.

I applied the software engineering principle to leave the code cleaner than seen. (Martin Fowler et all) 

Should I revert this?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1583314511

From angorya at openjdk.org  Mon Apr 29 15:53:12 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 29 Apr 2024 15:53:12 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <Kw4USopvKE05F75vykUes5ru6y1EB_bhaMMQnhLr5vw=.2b3bc2cb-c5e0-4777-a87f-2ada130149c1@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
 <Kw4USopvKE05F75vykUes5ru6y1EB_bhaMMQnhLr5vw=.2b3bc2cb-c5e0-4777-a87f-2ada130149c1@github.com>
Message-ID: <om-YWAgXy-TVE-lwP7T_pp6dRq78ujAKGF8ivA94yn4=.a0a322a0-0c58-4aa3-af62-91899472f756@github.com>

On Mon, 29 Apr 2024 08:55:58 GMT, Karthik P K <kpk at openjdk.org> wrote:

> Is this expected?

I think it might be a bug - even though it's unclear how many words the text "???????" contains, I would not expect it to go to the beginning of that segment.

I suspect the code in `TextInputControl.endOfNextWord(boolean)` is incorrect, and it needs a deeper re-write than the naive replacement with `isLetterOrDigit()`.

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

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2083089021

From duke at openjdk.org  Mon Apr 29 16:08:14 2024
From: duke at openjdk.org (Oliver Kopp)
Date: Mon, 29 Apr 2024 16:08:14 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <nXyvRKjd6bi7XLdN0uVAjHcMlZMEglOxPbFjVdEI3es=.92adb7ec-e41d-4561-88f6-4d01ee348912@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
 <nXyvRKjd6bi7XLdN0uVAjHcMlZMEglOxPbFjVdEI3es=.92adb7ec-e41d-4561-88f6-4d01ee348912@github.com>
Message-ID: <BXilbqz1wh9vHJ3k_ZS6uaOLj3AWiA12YHr9ZeVWvFg=.46f26015-e9fa-415c-afcb-b391c24f901a@github.com>

On Mon, 29 Apr 2024 12:35:19 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Oliver Kopp has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert using utility method
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 124:
> 
>> 122:         // In case there was an overflow, return the maximum end index
>> 123:         if (res < 0) return maxEndIndex;
>> 124:         return res;
> 
> In this class,
> - The index **start** and **end** are guaranteed to be +ve values such that, `0 <= start <= end <= length` (length is the total length of text in the text component). : please check the method `validateRange()`
> - So we only need to validate that the variable `length` in this helper method is valid i.e.
>    1. `length > 0` and
>    2. `length <= end - start`
> 
> 
>     /**
>      * In the context of substrings, this is a helper method to get the end offset index
>      * from the start index for a given length of a substring.
>      *
>      * @param startIndex The start index of the range in the string. Needs to be 0 or more (not checked in the code).
>      * @param length The requested length of a substring in the range when starting from "start".
>      *               Invalid values are treated as full length.
>      * @param endIndex The end index of the range in the string. Needs to be equal or greater than startIndex
>      *                    (not checked in the code).
>      */
>     static int getEndOffsetIndex(int startIndex, int length, int endIndex) {
>         if (length < 0 || (endIndex - startIndex) <= length) {
>             return endIndex;
>         }
>         return startIndex + length;
>     }
> 
> - With this change
>     1. The start and end index values are always positive and hence negative value tests should be removed.
>     2. The name of method is changed so, the Shim class would need a change too.
>     3. The fix could be as simple as below one line correction in the ternary statement in the GetText() method, but then we won't be able to add the test. So keeping the helper method would be good idea.
> `int endOffset = (length < 0 || (endIndex - startIndex) <= length) ? end : start + maxLength;`

Smalltalk: I could go back to my first commit https://github.com/openjdk/jfx/commit/e81712ca12035e6607c9a31379fa0180be8be7fd to be consistent with the other style in the class ???. Only joking, the new code is more readable to Java newcomers IMHO. ???

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1583344489

From duke at openjdk.org  Mon Apr 29 16:22:15 2024
From: duke at openjdk.org (eduardsdv)
Date: Mon, 29 Apr 2024 16:22:15 GMT
Subject: RFR: 8322619: Parts of SG no longer update during rendering -
 overlapping - culling - dirty [v4]
In-Reply-To: <_xmpnIww6iOxModrEdaFZ1lf8EhzwUERbpTeKb-XQJU=.b458c63c-b713-4c96-a504-c5dea68ce7db@github.com>
References: <sizOHn5bjorTGLngEidSm0-gMLmqUBvaV1VcdOLjoRE=.ea4b54b9-c20f-4fd0-9602-340e38f23d4c@github.com>
 <_xmpnIww6iOxModrEdaFZ1lf8EhzwUERbpTeKb-XQJU=.b458c63c-b713-4c96-a504-c5dea68ce7db@github.com>
Message-ID: <3g99pouwEwYgt8XrKs9A-5mhfw60WUQ1u-dMmpJP3m8=.2e61147f-68d1-4aa1-b203-6cbee15e407a@github.com>

On Mon, 29 Apr 2024 09:30:18 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> In some situations, a part of the SG is no longer rendered.
>> I created a test program that showcases this problem.
>> 
>> Explanation:
>> 
>> This can happen, when a part of the SG, is covered by another Node.
>> In this part, one node is totally covered, and the other node is visible.
>> 
>> When the totally covered Node is changed, then it is marked dirty and it's parent, recursively until an already dirty node is found.
>> Due to the Culling, this totally covered Node is not rendered - with the effect that the tree is never marked as Clean.
>> 
>> In this state, a Node is Dirty but not It's parent. Based on my CodeReview, this is an invalid state which should never happen.
>> 
>> In this invalid state, when the other Node is changed, which is visible, then the dirty state is no longer propagated upwards - because the recursive "NGNode.markTreeDirty" algorithm encounters a dirty node early.
>> 
>> This has the effect, that any SG changes in the visible Node are no longer rendered. Sometimes the situation repairs itself.
>> 
>> Useful parameters for further investigations:
>> -Djavafx.pulseLogger=true
>> -Dprism.printrendergraph=true
>> -Djavafx.pulseLogger.threshold=0
>> 
>> PR:
>> This PR ensures the dirty flag is set to false of the tree when the culling is used.
>> It doesn't seem to break any existing tests - but I'm not sure whether this is the right way to fix it.
>> It would be great to have some feedback on this solution - maybe guiding me to a better solution.
>> 
>> I could write a test, that just does the same thing as the test application, but checks every frame that these nodes are not dirty - but maybe there is a better way to test this.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8322619: Clear dirty flag on the node and all its children if they are skipped due to visible==false or opacity==0

After further investigation and testing I would suggest to remove all ``clearDirty()`` and ``clearDirtyTree()`` calls and put only one clear-dirty pass after rendering is done (at the end of ``ViewerPainter.paintImpl(final Graphics backBufferGraphics)``).

Since the ``markDirty()`` method does both, sets the dirty flag and propagates it to the ancestor nodes, it is better if there is only one method for deleting the dirty flag from the node and all its children. Therefore, I would remove the ``clearDirtyTree()`` method and move its content to the ``clearDirty()`` method.

This way we can guarantee that all dirty flags are removed after the rendering is completed.
We also guarantee that a clean parent with dirty children will never occur (the bug this PR addresses).

Furthermore, my quick test shows that fewer ``clearDirty()`` calls are required in the new version. Bonus: We are even faster.


    public void clearDirty() {
        if (dirty != DirtyFlag.CLEAN || childDirty) {
            dirty = DirtyFlag.CLEAN;
            childDirty = false;
            dirtyBounds.makeEmpty();
            dirtyChildrenAccumulated = 0;

            if (this instanceof NGGroup) {
                List<NGNode> children = ((NGGroup) this).getChildren();
                for (NGNode child : children) {
                    child.clearDirtyTree_();
                }
            }
        }

        if (getClipNode() != null) {
            getClipNode().clearDirty();
        }
    }

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

PR Comment: https://git.openjdk.org/jfx/pull/1310#issuecomment-2083153697

From angorya at openjdk.org  Mon Apr 29 16:54:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 29 Apr 2024 16:54:10 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
Message-ID: <J3AWlPHG_ejQsCLH603U_rf3jMKNjnXyNY9XnIH0AGg=.e0a259b7-08c4-4397-af03-4a0ae4f07342@github.com>

On Fri, 19 Apr 2024 20:36:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with  Character.isLetterOrDigit(int).
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330590.prev.word
>  - 8330590 TextInputControl: previous word fails with Bhojpuri characters

I think we need to fix endOf/nextWord as well, as the logic seems to be breaking with the surrogate pairs:

![Screenshot 2024-04-29 at 09 48 33](https://github.com/openjdk/jfx/assets/107069028/02a33046-6d15-45c1-a294-57bf609bdc8d)


The issue can also be seen with Awadhi: ????/???

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

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2083210649

From arapte at openjdk.org  Mon Apr 29 17:56:15 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 29 Apr 2024 17:56:15 GMT
Subject: RFR: 8330462: StringIndexOutOfBoundException when typing anything
 into TextField [v24]
In-Reply-To: <oiuSStHOX444AOkbgYark-n1Lg9MKD6WQqnKwzo4FSI=.f1566360-9b68-4a0b-b6b4-b03f0103318d@github.com>
References: <z0QmwNLUhQ91ybI1_xCnHBpXY6xsMoNY1mrDlZpvyzE=.9a53b95c-7b14-4dc0-b992-70d728e3e87b@github.com>
 <FAsMcf3eKqFI6XlUmyvD3Mn5JPnA7THl6lLgtIg8XWY=.a8146cd9-76ff-4f8f-be27-8e81f17ff04b@github.com>
 <nXyvRKjd6bi7XLdN0uVAjHcMlZMEglOxPbFjVdEI3es=.92adb7ec-e41d-4561-88f6-4d01ee348912@github.com>
 <oiuSStHOX444AOkbgYark-n1Lg9MKD6WQqnKwzo4FSI=.f1566360-9b68-4a0b-b6b4-b03f0103318d@github.com>
Message-ID: <LcIcQQ_2dKwlPmT0TmcHJByLMwlYNLBvge1gM57R5Kg=.64a49a0a-0d88-4da9-88f9-d859ecc60987@github.com>

On Mon, 29 Apr 2024 15:47:54 GMT, Oliver Kopp <duke at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/win/WinTextRangeProvider.java line 104:
>> 
>>> 102:         int length = text.length();
>>> 103:         start = Utils.clamp(0, start, length);
>>> 104:         end = Utils.clamp(start, end, length);
>> 
>> This is only cleanup and not required for this fix.
>
> I applied the software engineering principle to leave the code cleaner than seen. (Martin Fowler et all) 
> 
> Should I revert this?

Sorry for not being clear. I just wanted to point out that it is not required for the issue fix.
Please don't revert. This looks better.

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1442#discussion_r1583488561

From vdyakov at openjdk.org  Mon Apr 29 18:40:13 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Mon, 29 Apr 2024 18:40:13 GMT
Subject: RFR: 8092102: Labeled: truncated property [v9]
In-Reply-To: <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
Message-ID: <g9rKtEVtlAcElhdqe_5N9DUvxo35CxykbGtbBNFn2FY=.d1a46f52-82e3-4589-83b7-320da7cfa230@github.com>

On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width.
>> 
>> The new property reacts to changes in the following properties:
>> - ellipsisString
>> - font
>> - height
>> - text
>> - width
>> - wrapText
>> 
>> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code.
>> 
>> **Alternative**
>> 
>> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass.  What is the benefit of adding this functionality to the core?
>> 
>> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126).  The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone.
>> 
>> **See Also**
>> 
>> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated
>> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...)
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - missing )
>  - review comments
>  - Merge branch 'master' into 8092102.truncated
>  - add exports
>  - added unit tests
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - Merge branch 'master' into 8092102.truncated
>  - labeled helper
>  - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e

@azuev-java please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2083402516

From vdyakov at openjdk.org  Mon Apr 29 18:40:12 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Mon, 29 Apr 2024 18:40:12 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
 <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>
Message-ID: <hDCunDjMo526QObx-aEChMT-dHyuF1fmLUT833UhnZs=.5ea49ed3-06c2-4543-91f2-fa1aa1841ba4@github.com>

On Mon, 8 Apr 2024 18:19:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 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 14 additional commits since the last revision:
>> 
>>  - tests
>>  - cleanup
>>  - node orientation
>>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>>  - table view behavior
>>  - tree view behavior
>>  - list view behavior
>>  - orientation
>>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>>  - Merge branch 'master' into 8313138.horizontal
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/66578503...5bae5e7a
>
> Looks good.

@azuev-java please review

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2083402973

From kevin.rushforth at oracle.com  Mon Apr 29 21:09:39 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Apr 2024 14:09:39 -0700
Subject: Wayland
In-Reply-To: <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
 <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
 <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>
Message-ID: <a0c72cdb-e673-4119-83ff-70f27ce44942@oracle.com>

As a reminder, contributors must not include 3rd-party code in any 
openjdk repo. Per the terms of the OCA, all code that you contribute to 
OpenJDK must be your own code. This includes code you push to 
openjdk/jfx-sandbox and code in a branch of a personal fork of 
openjdk/jfx from which you create a PR.

-- Kevin


On 4/28/2024 2:45 PM, Thiago Milczarek Say?o wrote:
> Hi,
>
> I managed to display a very basic wayland toplevel surface from java:
> https://github.com/tsayao/glass-wayland
>
> If you are using intellij, just run the "Test App" (with java 22).
>
> generate.sh will jextract the code from wayland-client.
>
> I rushed to get the window displayed - so it doesn't look good yet 
> (but I do accept suggestions).
>
> It uses a java wayland-scanner (included) to read protocol xml files 
> and generate code that uses jextracted calls.
>
> The sample also binds EGL and GL apis, but just because wayland 
> requires a buffer to display the surface. Maybe it was easier to use a 
> shared memory :)
>
> Credits to (I adapted it to ouput jextract compatible code):
> https://github.com/gfxstrand/wayland-java/tree/master/scanner
>
> Cheers
>
> Em ter., 23 de abr. de 2024 ?s 09:11, Thiago Milczarek Say?o 
> <thiago.sayao at gmail.com> escreveu:
>
>     I'm doing some work here:
>     https://github.com/tsayao/glass-wayland
>
>     So far it's been a good experience to use FFM / jextract.
>
>     The idea is to plug it as a glass wayland backend when it's good
>     enough.
>
>
>
>     Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker
>     <nlisker at gmail.com> escreveu:
>
>         Not sure it helps with warmup, but marking a foreign function
>         as critical can improve performance:
>         https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean).
>
>         On Mon, Apr 22, 2024 at 10:02?PM Philip Race
>         <philip.race at oracle.com> wrote:
>
>             No, it wasn't. I didn't even use jextracted code.
>             The startup cost is around initialisation of FFM - around
>             70 ms (IIRC) overhead on my MacBook
>             Then creation of VarHandles and MethodHandles - 2-5 ms
>             each is what I measured, so do these lazily if you can.
>             And warmup cost is that it takes about 10000 iterations to
>             get code fully compiled.
>
>             java -XX:+PrintFlagsFinal -version 2>&1 | grep
>             CompileThreshold
>             ???? intx CompileThreshold???????????????????????? =
>             10000????????????????????????????????? {pd product} {default}
>             ??? double CompileThresholdScaling = 1.000000 {product}
>             {default}
>             ??? uintx IncreaseFirstTierCompileThresholdAt????? =
>             50??????????????????????????????????????? {product} {default}
>             ???? intx Tier2CompileThreshold??????????????????? =
>             0???????????????????????????????????????? {product} {default}
>             ???? intx Tier3CompileThreshold??????????????????? =
>             2000????????????????????????????????????? {product} {default}
>             ???? intx Tier4CompileThreshold??????????????????? =
>             15000???????????????????????????????????? {product} {default}
>
>             -phil.
>
>
>             On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>             I think the startup time might be related to all static
>>             symbol lookups.
>>             So I'm manually including just what is needed:
>>             jextract --output src -t com.sun.glass.wayland.extracted \
>>                --header-class-name GlassWayland \
>>                `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client`  \
>>                `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client`  \
>>                 glass-wayland.h \
>>                 --include-function xdp_portal_initable_new \
>>                 --include-function xdp_session_close \
>>                 --include-function xdp_portal_open_file \
>>                 --include-function xdp_portal_open_file_finish \
>>                 --include-function g_object_unref \
>>                 --include-function g_timeout_add \
>>                 --include-function g_add_idle \
>>                 --include-function g_main_loop_run \
>>                 --include-function g_main_loop_new \
>>                 --include-function g_main_loop_ref \
>>                 --include-function g_main_loop_unref \
>>                 --include-function g_main_loop_quit \
>>                 --include-function g_settings_new \
>>                 --include-function g_settings_get_int \
>>                 --include-function wl_display_connect \
>>                 --include-function wl_display_disconnect \
>>                 --include-function wl_display_roundtrip \
>>                 --include-function wl_display_dispatch_pending \
>>                 --include-typedef GAsyncReadyCallback \
>>                 --include-typedef GSourceFunc \
>>                 --include-typedef GError
>>
>>             Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race
>>             <philip.race at oracle.com> escreveu:
>>
>>                 As a reminder, using FFM will require all FX
>>                 *applications* to specify --enable-native-access on
>>                 the command line
>>                 Although this is likely coming to JNI soon too.
>>
>>                 https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>
>>                 But one thing to watch out for with FFM is startup +
>>                 warm up time.
>>                 I struggled a lot with that in using FFM for just one
>>                 library in the java.desktop module.
>>
>>                 -phil
>>
>>                 On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>                 Sorry, we bumped to Java 21 in JavaFX 22 I think
>>>                 since we preserve?the N-1 rule.
>>>
>>>                 On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker
>>>                 <nlisker at gmail.com> wrote:
>>>
>>>                     I think that we'll be able to bump to Java 25 in
>>>                     JavaFX 25, like we did with 21. I suggested
>>>                     initially to bump to Java 22 exactly for FFM as
>>>                     it's very useful for JavaFX, but was told we
>>>                     shouldn't since it's not an LTS version.
>>>
>>>                     I have no idea how long the work on Wayland will
>>>                     take including the code review (a rather long
>>>                     process), but you should be able to request code
>>>                     reviews with FFM and have it ready for
>>>                     integration by Java 25.
>>>
>>>                     On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek
>>>                     Say?o <thiago.sayao at gmail.com> wrote:
>>>
>>>                         I was just experimenting, but it seems to be
>>>                         less work than going with JNI.
>>>                         If I am correct, the next Java LTS will be
>>>                         25, which will be required on JavaFX 29 to
>>>                         be released on September/29.
>>>
>>>                         It's 7 years - that's really too much.
>>>
>>>                         Maybe it's still worthwhile to prototype
>>>                         using FFM and then port everything to JNI.
>>>
>>>                         -- Thiago.
>>>
>>>
>>>                         Em seg., 22 de abr. de 2024 ?s 11:21, Kevin
>>>                         Rushforth <kevin.rushforth at oracle.com> escreveu:
>>>
>>>                             Note also that we cannot use Panama in
>>>                             the JavaFX internals yet, since
>>>                             the minimum version of the JDK is 21.
>>>
>>>                             -- Kevin
>>>
>>>
>>>                             On 4/21/2024 10:51 AM, Thiago Milczarek
>>>                             Say?o wrote:
>>>                             > Hi,
>>>                             >
>>>                             > I did a small test app to explore
>>>                             Wayland client and portals (for
>>>                             > Robot and dialogs such as file open/save).
>>>                             >
>>>                             >
>>>                             https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>                             >
>>>                             > It seems it will work as a glass
>>>                             backend, but some walls will be hit
>>>                             > on the way :)
>>>                             >
>>>                             > I have tried to use jextract (from
>>>                             project Panama) to work directly
>>>                             > with java, but it seems it does not
>>>                             support wl_ types.
>>>                             >
>>>                             > -- Thiago.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240429/d2410fc5/attachment-0001.htm>

From angorya at openjdk.org  Mon Apr 29 21:31:13 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 29 Apr 2024 21:31:13 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
Message-ID: <rEZ42o5gHXbummkxoW3K6NzTLota4eEsJ3XGux3W-0Q=.ec7af8fd-e647-4ef6-8226-50706d7cbb31@github.com>

On Fri, 19 Apr 2024 20:36:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This change replaces Character.isLetterOrDigit(char) which fails with surrogate characters with  Character.isLetterOrDigit(int).
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8330590.prev.word
>  - 8330590 TextInputControl: previous word fails with Bhojpuri characters

Looking at the "next word" functionality across different applications on different platforms, it appears to be a wide variety of behaviors.

One vendor appears to be quite consistent - Microsoft.  Its word, word pad, notepad work exactly the same, with Word working the same across macOS and Win11.

JavaFX TextArea is inconsistent (by design) between macOS and Win11, but also is inconsistent with Swing's JTextArea.

If I were to fix the behavior (if we decide to fix the behavior of the nextWord function, that is), I would make it consistent with MS Word, but let's discuss.

For reference, here is the result of my testing.  Initially, the caret is placed at index 0 and the numbers in parentheses denote successive caret positions after ctrl-RIGHT (option-RIGHT) key presses.  An underline denotes a space, and a (nl) denotes a newline.


source
_english_english_eng:_end,_eng:_(nl)
(nl)
_eng


BreakIterator.getWordInstance()
_(1)english(2)_(3)english(4)_(5)eng(6):(7)_(8)end(9),(10)_(11)eng(12):(13)_(14)(nl)
(15)(nl)
(16)_(17)eng


text area (mac)
_english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_(nl)
(9)(nl)
(10)_eng(11)


ms word (mac) 16.84 24041420 consistent with win11
_(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
(10)(nl)
(11)_(12)eng(13)


text edit (mac)
_english(1)_english(2)_eng(3):_end(4),_eng(5):_(nl)
(nl)
(nl)_eng(6)


chrome (mac) <div contenteditable=true>
&nbsp;english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_<br>
(9)<br>
_(10)eng(11)


eclipse (mac)
_(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
(10)(nl)
(11)_(12)eng


JTextArea (mac)
_(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
(nl)
_(10)eng


ms word 365 ver 2302 build 16.0.16130.20942 (win 11)
same as notepad (win 11)
same as wordpad (win 11)
_(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
(10)(nl)
(11)_(12)eng


TextArea (win11)
_(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
(10)(nl)
_(11)eng

@aghaisas would you please take a look at this also?

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

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2083707096
PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2083707914

From thiago.sayao at gmail.com  Mon Apr 29 21:35:19 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 29 Apr 2024 18:35:19 -0300
Subject: Wayland
In-Reply-To: <a0c72cdb-e673-4119-83ff-70f27ce44942@oracle.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
 <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
 <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>
 <a0c72cdb-e673-4119-83ff-70f27ce44942@oracle.com>
Message-ID: <CAAP_wumDKeeQM-_Sv_MwZXi0Oq+DmKe1eLOueuxxbDg+5tA-fg@mail.gmail.com>

I thought about possible legal conflicts.

The code is on my github - I'm exploring and testing before starting the
real work.

wayland-scanner generates code from the protocol specs, which are xml files.
https://wayland.app/protocols/

I will write a new generator/scanner from scratch - it's not too much work.
The generator/scanner itself does not necessarily need to be part of the
PR, but it might be a good idea to include it, since the protocol changes
over time.

-- Thiago.



Em seg., 29 de abr. de 2024 ?s 18:10, Kevin Rushforth <
kevin.rushforth at oracle.com> escreveu:

> As a reminder, contributors must not include 3rd-party code in any openjdk
> repo. Per the terms of the OCA, all code that you contribute to OpenJDK
> must be your own code. This includes code you push to openjdk/jfx-sandbox
> and code in a branch of a personal fork of openjdk/jfx from which you
> create a PR.
>
> -- Kevin
>
>
> On 4/28/2024 2:45 PM, Thiago Milczarek Say?o wrote:
>
> Hi,
>
> I managed to display a very basic wayland toplevel surface from java:
> https://github.com/tsayao/glass-wayland
>
> If you are using intellij, just run the "Test App" (with java 22).
>
> generate.sh will jextract the code from wayland-client.
>
> I rushed to get the window displayed - so it doesn't look good yet (but I
> do accept suggestions).
>
> It uses a java wayland-scanner (included) to read protocol xml files and
> generate code that uses jextracted calls.
>
> The sample also binds EGL and GL apis, but just because wayland requires a
> buffer to display the surface. Maybe it was easier to use a shared memory :)
>
> Credits to (I adapted it to ouput jextract compatible code):
> https://github.com/gfxstrand/wayland-java/tree/master/scanner
>
> Cheers
>
> Em ter., 23 de abr. de 2024 ?s 09:11, Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> escreveu:
>
>> I'm doing some work here:
>> https://github.com/tsayao/glass-wayland
>>
>> So far it's been a good experience to use FFM / jextract.
>>
>> The idea is to plug it as a glass wayland backend when it's good enough.
>>
>>
>>
>> Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker <nlisker at gmail.com>
>> escreveu:
>>
>>> Not sure it helps with warmup, but marking a foreign function as
>>> critical can improve performance:
>>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
>>> .
>>>
>>> On Mon, Apr 22, 2024 at 10:02?PM Philip Race <philip.race at oracle.com>
>>> wrote:
>>>
>>>> No, it wasn't. I didn't even use jextracted code.
>>>> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
>>>> overhead on my MacBook
>>>> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
>>>> measured, so do these lazily if you can.
>>>> And warmup cost is that it takes about 10000 iterations to get code
>>>> fully compiled.
>>>>
>>>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>>>>      intx CompileThreshold                         =
>>>> 10000                                  {pd product} {default}
>>>>     double CompileThresholdScaling                  =
>>>> 1.000000                                  {product} {default}
>>>>     uintx IncreaseFirstTierCompileThresholdAt      =
>>>> 50                                        {product} {default}
>>>>      intx Tier2CompileThreshold                    =
>>>> 0                                         {product} {default}
>>>>      intx Tier3CompileThreshold                    =
>>>> 2000                                      {product} {default}
>>>>      intx Tier4CompileThreshold                    =
>>>> 15000                                     {product} {default}
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>>>
>>>> I think the startup time might be related to all static symbol lookups.
>>>> So I'm manually including just what is needed:
>>>>
>>>> jextract --output src -t com.sun.glass.wayland.extracted \
>>>>   --header-class-name GlassWayland \
>>>>   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
>>>>   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
>>>>    glass-wayland.h \
>>>>    --include-function xdp_portal_initable_new \
>>>>    --include-function xdp_session_close \
>>>>    --include-function xdp_portal_open_file \
>>>>    --include-function xdp_portal_open_file_finish \
>>>>    --include-function g_object_unref \
>>>>    --include-function g_timeout_add \
>>>>    --include-function g_add_idle \
>>>>    --include-function g_main_loop_run \
>>>>    --include-function g_main_loop_new \
>>>>    --include-function g_main_loop_ref \
>>>>    --include-function g_main_loop_unref \
>>>>    --include-function g_main_loop_quit \
>>>>    --include-function g_settings_new \
>>>>    --include-function g_settings_get_int \
>>>>    --include-function wl_display_connect \
>>>>    --include-function wl_display_disconnect \
>>>>    --include-function wl_display_roundtrip \
>>>>    --include-function wl_display_dispatch_pending \
>>>>    --include-typedef GAsyncReadyCallback \
>>>>    --include-typedef GSourceFunc \
>>>>    --include-typedef GError
>>>>
>>>>
>>>> Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race <
>>>> philip.race at oracle.com> escreveu:
>>>>
>>>>> As a reminder, using FFM will require all FX *applications* to specify
>>>>> --enable-native-access on the command line
>>>>> Although this is likely coming to JNI soon too.
>>>>>
>>>>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>>>>
>>>>> But one thing to watch out for with FFM is startup + warm up time.
>>>>> I struggled a lot with that in using FFM for just one library in the
>>>>> java.desktop module.
>>>>>
>>>>> -phil
>>>>>
>>>>> On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>>>
>>>>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we preserve the
>>>>> N-1 rule.
>>>>>
>>>>> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>>>>>
>>>>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we
>>>>>> did with 21. I suggested initially to bump to Java 22 exactly for FFM as
>>>>>> it's very useful for JavaFX, but was told we shouldn't since it's not an
>>>>>> LTS version.
>>>>>>
>>>>>> I have no idea how long the work on Wayland will take including the
>>>>>> code review (a rather long process), but you should be able to request code
>>>>>> reviews with FFM and have it ready for integration by Java 25.
>>>>>>
>>>>>> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
>>>>>> thiago.sayao at gmail.com> wrote:
>>>>>>
>>>>>>> I was just experimenting, but it seems to be less work than going
>>>>>>> with JNI.
>>>>>>> If I am correct, the next Java LTS will be 25, which will be
>>>>>>> required on JavaFX 29 to be released on September/29.
>>>>>>>
>>>>>>> It's 7 years - that's really too much.
>>>>>>>
>>>>>>> Maybe it's still worthwhile to prototype using FFM and then port
>>>>>>> everything to JNI.
>>>>>>>
>>>>>>> -- Thiago.
>>>>>>>
>>>>>>>
>>>>>>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>>>>>>> kevin.rushforth at oracle.com> escreveu:
>>>>>>>
>>>>>>>> Note also that we cannot use Panama in the JavaFX internals yet,
>>>>>>>> since
>>>>>>>> the minimum version of the JDK is 21.
>>>>>>>>
>>>>>>>> -- Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > I did a small test app to explore Wayland client and portals (for
>>>>>>>> > Robot and dialogs such as file open/save).
>>>>>>>> >
>>>>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>>>>> >
>>>>>>>> > It seems it will work as a glass backend, but some walls will be
>>>>>>>> hit
>>>>>>>> > on the way :)
>>>>>>>> >
>>>>>>>> > I have tried to use jextract (from project Panama) to work
>>>>>>>> directly
>>>>>>>> > with java, but it seems it does not support wl_ types.
>>>>>>>> >
>>>>>>>> > -- Thiago.
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240429/9db33194/attachment-0001.htm>

From kcr at openjdk.org  Mon Apr 29 22:08:10 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 29 Apr 2024 22:08:10 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external
In-Reply-To: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
Message-ID: <uLKoPWNvvNwTTpiAdmNwmwYPH5TKS5khcvqDb_J0DVc=.6920c1e6-3f43-4a10-a1db-68354aa1c9de@github.com>

On Fri, 16 Feb 2024 22:35:49 GMT, Martin Fox <mfox at openjdk.org> wrote:

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations.

The code changes look good. I did a quick test and it seems fine.

Would you be able to provide a manual test program for this case, under `tests/manual/dnd`? Also, can you merge in the latest changes from `master`?

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

PR Review: https://git.openjdk.org/jfx/pull/1371#pullrequestreview-2029735350

From kevin.rushforth at oracle.com  Mon Apr 29 22:57:00 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 29 Apr 2024 15:57:00 -0700
Subject: [External] : Re: Wayland
In-Reply-To: <CAAP_wumDKeeQM-_Sv_MwZXi0Oq+DmKe1eLOueuxxbDg+5tA-fg@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
 <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
 <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>
 <a0c72cdb-e673-4119-83ff-70f27ce44942@oracle.com>
 <CAAP_wumDKeeQM-_Sv_MwZXi0Oq+DmKe1eLOueuxxbDg+5tA-fg@mail.gmail.com>
Message-ID: <d4e3d08d-aad4-4bb8-96bb-f78f0fed96cc@oracle.com>

Thank you.

-- Kevin


On 4/29/2024 2:35 PM, Thiago Milczarek Say?o wrote:
> I thought about possible legal conflicts.
>
> The code is on my github - I'm exploring and testing before starting 
> the real work.
>
> wayland-scanner generates code from the protocol specs, which are xml 
> files.
> https://wayland.app/protocols/ 
> <https://urldefense.com/v3/__https://wayland.app/protocols/__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvIrSwcvY$>
>
> I will write a new generator/scanner from scratch - it's not too much 
> work.
> The generator/scanner itself does not necessarily?need to be part of 
> the PR, but it might be a good idea to include it, since the protocol 
> changes over time.
>
> -- Thiago.
>
>
>
> Em seg., 29 de abr. de 2024 ?s 18:10, Kevin Rushforth 
> <kevin.rushforth at oracle.com> escreveu:
>
>     As a reminder, contributors must not include 3rd-party code in any
>     openjdk repo. Per the terms of the OCA, all code that you
>     contribute to OpenJDK must be your own code. This includes code
>     you push to openjdk/jfx-sandbox and code in a branch of a personal
>     fork of openjdk/jfx from which you create a PR.
>
>     -- Kevin
>
>
>     On 4/28/2024 2:45 PM, Thiago Milczarek Say?o wrote:
>>     Hi,
>>
>>     I managed to display a very basic wayland toplevel surface from java:
>>     https://github.com/tsayao/glass-wayland
>>     <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>
>>     If you are using intellij, just run the "Test App" (with java 22).
>>
>>     generate.sh will jextract the code from wayland-client.
>>
>>     I rushed to get the window displayed - so it doesn't look good
>>     yet (but I do accept suggestions).
>>
>>     It uses a java wayland-scanner (included) to read protocol xml
>>     files and generate code that uses jextracted calls.
>>
>>     The sample also binds EGL and GL apis, but just because wayland
>>     requires a buffer to display the surface. Maybe it was easier to
>>     use a shared memory :)
>>
>>     Credits to (I adapted it to ouput jextract compatible code):
>>     https://github.com/gfxstrand/wayland-java/tree/master/scanner
>>     <https://urldefense.com/v3/__https://github.com/gfxstrand/wayland-java/tree/master/scanner__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv70bWagY$>
>>
>>     Cheers
>>
>>     Em ter., 23 de abr. de 2024 ?s 09:11, Thiago Milczarek Say?o
>>     <thiago.sayao at gmail.com> escreveu:
>>
>>         I'm doing some work here:
>>         https://github.com/tsayao/glass-wayland
>>         <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>
>>         So far it's been a good experience to use FFM / jextract.
>>
>>         The idea is to plug it as a glass wayland backend when it's
>>         good enough.
>>
>>
>>
>>         Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker
>>         <nlisker at gmail.com> escreveu:
>>
>>             Not sure it helps with warmup, but marking a foreign
>>             function as critical can improve performance:
>>             https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean).
>>
>>             On Mon, Apr 22, 2024 at 10:02?PM Philip Race
>>             <philip.race at oracle.com> wrote:
>>
>>                 No, it wasn't. I didn't even use jextracted code.
>>                 The startup cost is around initialisation of FFM -
>>                 around 70 ms (IIRC) overhead on my MacBook
>>                 Then creation of VarHandles and MethodHandles - 2-5
>>                 ms each is what I measured, so do these lazily if you
>>                 can.
>>                 And warmup cost is that it takes about 10000
>>                 iterations to get code fully compiled.
>>
>>                 java -XX:+PrintFlagsFinal -version 2>&1 | grep
>>                 CompileThreshold
>>                 ???? intx CompileThreshold???????????????????????? =
>>                 10000????????????????????????????????? {pd product}
>>                 {default}
>>                 ??? double CompileThresholdScaling????????????????? =
>>                 1.000000 {product} {default}
>>                 ??? uintx IncreaseFirstTierCompileThresholdAt????? =
>>                 50 {product} {default}
>>                 ???? intx Tier2CompileThreshold??????????????????? =
>>                 0 {product} {default}
>>                 ???? intx Tier3CompileThreshold??????????????????? =
>>                 2000 {product} {default}
>>                 ???? intx Tier4CompileThreshold??????????????????? =
>>                 15000 {product} {default}
>>
>>                 -phil.
>>
>>
>>                 On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>>                 I think the startup time might be related to all
>>>                 static symbol lookups.
>>>                 So I'm manually including just what is needed:
>>>                 jextract --output src -t com.sun.glass.wayland.extracted \
>>>                    --header-class-name GlassWayland \
>>>                    `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client`  \
>>>                    `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client`  \
>>>                     glass-wayland.h \
>>>                     --include-function xdp_portal_initable_new \
>>>                     --include-function xdp_session_close \
>>>                     --include-function xdp_portal_open_file \
>>>                     --include-function xdp_portal_open_file_finish \
>>>                     --include-function g_object_unref \
>>>                     --include-function g_timeout_add \
>>>                     --include-function g_add_idle \
>>>                     --include-function g_main_loop_run \
>>>                     --include-function g_main_loop_new \
>>>                     --include-function g_main_loop_ref \
>>>                     --include-function g_main_loop_unref \
>>>                     --include-function g_main_loop_quit \
>>>                     --include-function g_settings_new \
>>>                     --include-function g_settings_get_int \
>>>                     --include-function wl_display_connect \
>>>                     --include-function wl_display_disconnect \
>>>                     --include-function wl_display_roundtrip \
>>>                     --include-function wl_display_dispatch_pending \
>>>                     --include-typedef GAsyncReadyCallback \
>>>                     --include-typedef GSourceFunc \
>>>                     --include-typedef GError
>>>
>>>                 Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race
>>>                 <philip.race at oracle.com> escreveu:
>>>
>>>                     As a reminder, using FFM will require all FX
>>>                     *applications* to specify --enable-native-access
>>>                     on the command line
>>>                     Although this is likely coming to JNI soon too.
>>>
>>>                     https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>>
>>>                     But one thing to watch out for with FFM is
>>>                     startup + warm up time.
>>>                     I struggled a lot with that in using FFM for
>>>                     just one library in the java.desktop module.
>>>
>>>                     -phil
>>>
>>>                     On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>>                     Sorry, we bumped to Java 21 in JavaFX 22 I
>>>>                     think since we preserve?the N-1 rule.
>>>>
>>>>                     On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker
>>>>                     <nlisker at gmail.com> wrote:
>>>>
>>>>                         I think that we'll be able to bump to Java
>>>>                         25 in JavaFX 25, like we did with 21. I
>>>>                         suggested initially to bump to Java 22
>>>>                         exactly for FFM as it's very useful for
>>>>                         JavaFX, but was told we shouldn't since
>>>>                         it's not an LTS version.
>>>>
>>>>                         I have no idea how long the work on Wayland
>>>>                         will take including the code review (a
>>>>                         rather long process), but you should be
>>>>                         able to request code reviews with FFM and
>>>>                         have it ready for integration by Java 25.
>>>>
>>>>                         On Mon, Apr 22, 2024 at 5:49?PM Thiago
>>>>                         Milczarek Say?o <thiago.sayao at gmail.com> wrote:
>>>>
>>>>                             I was just experimenting, but it seems
>>>>                             to be less work than going with JNI.
>>>>                             If I am correct, the next Java LTS will
>>>>                             be 25, which will be required on JavaFX
>>>>                             29 to be released on September/29.
>>>>
>>>>                             It's 7 years - that's really too much.
>>>>
>>>>                             Maybe it's still worthwhile to
>>>>                             prototype using FFM and then port
>>>>                             everything to JNI.
>>>>
>>>>                             -- Thiago.
>>>>
>>>>
>>>>                             Em seg., 22 de abr. de 2024 ?s 11:21,
>>>>                             Kevin Rushforth
>>>>                             <kevin.rushforth at oracle.com> escreveu:
>>>>
>>>>                                 Note also that we cannot use Panama
>>>>                                 in the JavaFX internals yet, since
>>>>                                 the minimum version of the JDK is 21.
>>>>
>>>>                                 -- Kevin
>>>>
>>>>
>>>>                                 On 4/21/2024 10:51 AM, Thiago
>>>>                                 Milczarek Say?o wrote:
>>>>                                 > Hi,
>>>>                                 >
>>>>                                 > I did a small test app to explore
>>>>                                 Wayland client and portals (for
>>>>                                 > Robot and dialogs such as file
>>>>                                 open/save).
>>>>                                 >
>>>>                                 >
>>>>                                 https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>                                 <https://urldefense.com/v3/__https://github.com/tsayao/wayland-test/blob/main/wayland-test.c__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv-uSsniA$>
>>>>                                 >
>>>>                                 > It seems it will work as a glass
>>>>                                 backend, but some walls will be hit
>>>>                                 > on the way :)
>>>>                                 >
>>>>                                 > I have tried to use jextract
>>>>                                 (from project Panama) to work directly
>>>>                                 > with java, but it seems it does
>>>>                                 not support wl_ types.
>>>>                                 >
>>>>                                 > -- Thiago.
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240429/c95e6862/attachment-0001.htm>

From kcr at openjdk.org  Tue Apr 30 00:58:11 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 00:58:11 GMT
Subject: RFR: 8271865: SortedList::getViewIndex behaves not correctly for
 some index values
In-Reply-To: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com>
References: <4V7s75mYi7DNsCscIGNAr48RvsRAo7twE23ozQtk6x4=.4fad76ac-f23a-483c-9714-e6aecccfcd9a@github.com>
Message-ID: <o9vH93StbWBfz3Io7EYXYpPKW2EKPmAt8YdPcCjmO8k=.041a0d54-ce2e-4a5a-8514-0b142fea3aef@github.com>

On Sun, 24 Mar 2024 15:11:29 GMT, drmarmac <duke at openjdk.org> wrote:

> This PR adds the missing checks, as well as code documentation that an IndexOutOfBoundsException may be thrown.

The fix and tests look good. I left a couple comments on the docs.

modules/javafx.base/src/main/java/javafx/collections/transformation/TransformationList.java line 121:

> 119:      * @param index the index in this list
> 120:      * @return the index of the element's origin in the source list
> 121:      * @throws IndexOutOfBoundsException if the index is out of range (index &lt; 0 || index >= size())

Suggestion: consider using code case for the variables and equation?

modules/javafx.base/src/main/java/javafx/collections/transformation/TransformationList.java line 134:

> 132:      * @param index the index of an element in this list
> 133:      * @return the index of the element's origin in the provided list
> 134:      * @throws IndexOutOfBoundsException if the index is out of range (index &lt; 0 || index >= list.getSource().size())

There is no`getSource` method in `ObservableList`. That should be `... index >= size())`

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

PR Review: https://git.openjdk.org/jfx/pull/1432#pullrequestreview-2029789757
PR Review Comment: https://git.openjdk.org/jfx/pull/1432#discussion_r1583998595
PR Review Comment: https://git.openjdk.org/jfx/pull/1432#discussion_r1583874591

From kizune at openjdk.org  Tue Apr 30 09:46:14 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 30 Apr 2024 09:46:14 GMT
Subject: RFR: 8313138: Horizontal Scrollbar Keyboard enhancement [v5]
In-Reply-To: <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>
References: <hfUzHEaC5H7sWdMLw5OXVIaUmipviJEDq9bhZFgUxUc=.3ce86b2a-e36b-415e-8369-3236b5215911@github.com>
 <stc2gkbsuYUEkWdc_tb90Vrj0zd0VNKZ7_nAxjX9c8s=.75e999bc-5916-4a7d-9306-745af37ab3d4@github.com>
 <swqgVnZ_IFcPIuATS_c55ZBBEda2TuuO7GDEjhtZZOU=.e2c855cb-354d-41b3-bfa9-442d47d7a214@github.com>
Message-ID: <vsXQ-qR5NiI5qE5CXa2_2VrufH2Zhj2Gkln-wWE9YWg=.2de02c84-6f2e-47c1-9024-942a5706699f@github.com>

On Mon, 8 Apr 2024 18:19:22 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 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 14 additional commits since the last revision:
>> 
>>  - tests
>>  - cleanup
>>  - node orientation
>>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>>  - table view behavior
>>  - tree view behavior
>>  - list view behavior
>>  - orientation
>>  - Merge remote-tracking branch 'origin/master' into 8313138.horizontal
>>  - Merge branch 'master' into 8313138.horizontal
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/0ee41fb4...5bae5e7a
>
> Looks good.

> @azuev-java does the choice of key combination make sense?

Perfectly fine. When Voice Over is active it will override any defined key combination but with Voice Over we do not really care about the scrolling for better readability - and if there is any element that can be selected with VO cursor it will do scrolling by itself.

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

PR Comment: https://git.openjdk.org/jfx/pull/1393#issuecomment-2084850013

From arapte at openjdk.org  Tue Apr 30 11:58:11 2024
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 30 Apr 2024 11:58:11 GMT
Subject: RFR: 8092102: Labeled: truncated property [v9]
In-Reply-To: <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
References: <r0Iz0ydjEQmbbNeg-5PpJY6H5ZGhL_LAg0TjEfe_Dj4=.90493f0c-a4f5-4354-9531-1e71ec05518e@github.com>
 <TkZyx5OzPZQCp4DCHBN7ZIOzHR_MoJm5H-Y7gpwNYBY=.2d081409-01ae-4f7e-8d2b-80288633a418@github.com>
Message-ID: <lHraH7jnP6nx7Ewkl1G99lCstdlZz3oqvw5RfuCnqZk=.ba25de8c-9351-47b4-8188-8c59ae5b7ad8@github.com>

On Wed, 10 Apr 2024 21:25:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adds **Labeled.textTruncated** property which indicates when the text is visually truncated (and the ellipsis string is inserted) in order to fit the available width.
>> 
>> The new property reacts to changes in the following properties:
>> - ellipsisString
>> - font
>> - height
>> - text
>> - width
>> - wrapText
>> 
>> I don't think it's worth creating a headful test (headless won't work) due to relative simplicity of the code.
>> 
>> **Alternative**
>> 
>> The desired functionality can be just as easily achieved on an application level, by adding a similar property to a subclass.  What is the benefit of adding this functionality to the core?
>> 
>> UPDATE 2024/03/07: turns out Labeled in a TableView (in a TreeTableView as well) lives by different rules (TableCellSkinBase:152, TreeTableCellSkin:126).  The consequence of this is that the new functionality **cannot** be fully implemented with the public APIs alone.
>> 
>> **See Also**
>> 
>> * [JDK-8327483](https://bugs.openjdk.org/browse/JDK-8327483) TreeView: Allow for tooltip when cell text is truncated
>> * [JDK-8205211](https://bugs.openjdk.org/browse/JDK-8205211) Ability to show Tooltip only when text is shown with ellipsis (...)
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - missing )
>  - review comments
>  - Merge branch 'master' into 8092102.truncated
>  - add exports
>  - added unit tests
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - test
>  - Merge remote-tracking branch 'origin/master' into 8092102.truncated
>  - Merge branch 'master' into 8092102.truncated
>  - labeled helper
>  - ... and 5 more: https://git.openjdk.org/jfx/compare/0eb4d719...aa28eb4e

Testing looks good. Works as expected.
The change looks good. Please allow me a little more time to take a more closer look.

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

PR Comment: https://git.openjdk.org/jfx/pull/1389#issuecomment-2085127845

From tsayao at openjdk.org  Tue Apr 30 12:22:34 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Apr 2024 12:22:34 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

  - Use EGL_DEFAULT_DISPLAY
  - Deallocate the resources correctly
  - Use PBuffer as the dummy surface

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/f8c61efc..0c78b749

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

  Stats: 106 lines in 10 files changed: 54 ins; 33 del; 19 mod
  Patch: https://git.openjdk.org/jfx/pull/1381.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381

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

From tsayao at openjdk.org  Tue Apr 30 12:38:11 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Apr 2024 12:38:11 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]
In-Reply-To: <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>
Message-ID: <ijVkUVNLH0d0_SfDADOwUlIl-vXmzZW9KDdUQzxO1Hg=.96b38bb3-1d33-4ff8-acb2-1696d0e3fd7a@github.com>

On Tue, 30 Apr 2024 12:22:34 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Use EGL_DEFAULT_DISPLAY
>   - Deallocate the resources correctly
>   - Use PBuffer as the dummy surface

I changed it to use EGL_DEFAULT_DISPLAY in a attempt to make no assumptions on the platform. It works, but I'm not sure if it's correct. I'm looking at Mesa egl source to be sure.

I also changed the dummy window to use PBUFFER (also to make no assumptions on the platform, so there's no need to create a XWindow). I'm also not sure about that.

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2085214672

From thiago.sayao at gmail.com  Tue Apr 30 13:41:51 2024
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 30 Apr 2024 10:41:51 -0300
Subject: [External] : Re: Wayland
In-Reply-To: <d4e3d08d-aad4-4bb8-96bb-f78f0fed96cc@oracle.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
 <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
 <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>
 <a0c72cdb-e673-4119-83ff-70f27ce44942@oracle.com>
 <CAAP_wumDKeeQM-_Sv_MwZXi0Oq+DmKe1eLOueuxxbDg+5tA-fg@mail.gmail.com>
 <d4e3d08d-aad4-4bb8-96bb-f78f0fed96cc@oracle.com>
Message-ID: <CAAP_wumMx4TppaWqy7hJ6R08iNtyCO1TZeWZ75QFvzqJ4V7zWQ@mail.gmail.com>

Hi,

I rewrote the scanner, so it's all my own code now. No legal issues since I
signed the OCA.

Generated java code looks like this:
https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java


-- Thiago.

Em seg., 29 de abr. de 2024 ?s 19:57, Kevin Rushforth <
kevin.rushforth at oracle.com> escreveu:

> Thank you.
>
> -- Kevin
>
>
> On 4/29/2024 2:35 PM, Thiago Milczarek Say?o wrote:
>
> I thought about possible legal conflicts.
>
> The code is on my github - I'm exploring and testing before starting the
> real work.
>
> wayland-scanner generates code from the protocol specs, which are xml
> files.
> https://wayland.app/protocols/
> <https://urldefense.com/v3/__https://wayland.app/protocols/__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvIrSwcvY$>
>
> I will write a new generator/scanner from scratch - it's not too much
> work.
> The generator/scanner itself does not necessarily need to be part of the
> PR, but it might be a good idea to include it, since the protocol changes
> over time.
>
> -- Thiago.
>
>
>
> Em seg., 29 de abr. de 2024 ?s 18:10, Kevin Rushforth <
> kevin.rushforth at oracle.com> escreveu:
>
>> As a reminder, contributors must not include 3rd-party code in any
>> openjdk repo. Per the terms of the OCA, all code that you contribute to
>> OpenJDK must be your own code. This includes code you push to
>> openjdk/jfx-sandbox and code in a branch of a personal fork of openjdk/jfx
>> from which you create a PR.
>>
>> -- Kevin
>>
>>
>> On 4/28/2024 2:45 PM, Thiago Milczarek Say?o wrote:
>>
>> Hi,
>>
>> I managed to display a very basic wayland toplevel surface from java:
>> https://github.com/tsayao/glass-wayland
>> <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>
>> If you are using intellij, just run the "Test App" (with java 22).
>>
>> generate.sh will jextract the code from wayland-client.
>>
>> I rushed to get the window displayed - so it doesn't look good yet (but I
>> do accept suggestions).
>>
>> It uses a java wayland-scanner (included) to read protocol xml files and
>> generate code that uses jextracted calls.
>>
>> The sample also binds EGL and GL apis, but just because wayland requires
>> a buffer to display the surface. Maybe it was easier to use a shared memory
>> :)
>>
>> Credits to (I adapted it to ouput jextract compatible code):
>> https://github.com/gfxstrand/wayland-java/tree/master/scanner
>> <https://urldefense.com/v3/__https://github.com/gfxstrand/wayland-java/tree/master/scanner__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv70bWagY$>
>>
>> Cheers
>>
>> Em ter., 23 de abr. de 2024 ?s 09:11, Thiago Milczarek Say?o <
>> thiago.sayao at gmail.com> escreveu:
>>
>>> I'm doing some work here:
>>> https://github.com/tsayao/glass-wayland
>>> <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>>
>>> So far it's been a good experience to use FFM / jextract.
>>>
>>> The idea is to plug it as a glass wayland backend when it's good enough.
>>>
>>>
>>>
>>> Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker <nlisker at gmail.com>
>>> escreveu:
>>>
>>>> Not sure it helps with warmup, but marking a foreign function as
>>>> critical can improve performance:
>>>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean)
>>>> .
>>>>
>>>> On Mon, Apr 22, 2024 at 10:02?PM Philip Race <philip.race at oracle.com>
>>>> wrote:
>>>>
>>>>> No, it wasn't. I didn't even use jextracted code.
>>>>> The startup cost is around initialisation of FFM - around 70 ms (IIRC)
>>>>> overhead on my MacBook
>>>>> Then creation of VarHandles and MethodHandles - 2-5 ms each is what I
>>>>> measured, so do these lazily if you can.
>>>>> And warmup cost is that it takes about 10000 iterations to get code
>>>>> fully compiled.
>>>>>
>>>>> java -XX:+PrintFlagsFinal -version 2>&1 | grep CompileThreshold
>>>>>      intx CompileThreshold                         =
>>>>> 10000                                  {pd product} {default}
>>>>>     double CompileThresholdScaling                  =
>>>>> 1.000000                                  {product} {default}
>>>>>     uintx IncreaseFirstTierCompileThresholdAt      =
>>>>> 50                                        {product} {default}
>>>>>      intx Tier2CompileThreshold                    =
>>>>> 0                                         {product} {default}
>>>>>      intx Tier3CompileThreshold                    =
>>>>> 2000                                      {product} {default}
>>>>>      intx Tier4CompileThreshold                    =
>>>>> 15000                                     {product} {default}
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>>>>
>>>>> I think the startup time might be related to all static symbol
>>>>> lookups.
>>>>> So I'm manually including just what is needed:
>>>>>
>>>>> jextract --output src -t com.sun.glass.wayland.extracted \
>>>>>   --header-class-name GlassWayland \
>>>>>   `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client` \
>>>>>   `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client` \
>>>>>    glass-wayland.h \
>>>>>    --include-function xdp_portal_initable_new \
>>>>>    --include-function xdp_session_close \
>>>>>    --include-function xdp_portal_open_file \
>>>>>    --include-function xdp_portal_open_file_finish \
>>>>>    --include-function g_object_unref \
>>>>>    --include-function g_timeout_add \
>>>>>    --include-function g_add_idle \
>>>>>    --include-function g_main_loop_run \
>>>>>    --include-function g_main_loop_new \
>>>>>    --include-function g_main_loop_ref \
>>>>>    --include-function g_main_loop_unref \
>>>>>    --include-function g_main_loop_quit \
>>>>>    --include-function g_settings_new \
>>>>>    --include-function g_settings_get_int \
>>>>>    --include-function wl_display_connect \
>>>>>    --include-function wl_display_disconnect \
>>>>>    --include-function wl_display_roundtrip \
>>>>>    --include-function wl_display_dispatch_pending \
>>>>>    --include-typedef GAsyncReadyCallback \
>>>>>    --include-typedef GSourceFunc \
>>>>>    --include-typedef GError
>>>>>
>>>>>
>>>>> Em seg., 22 de abr. de 2024 ?s 13:24, Philip Race <
>>>>> philip.race at oracle.com> escreveu:
>>>>>
>>>>>> As a reminder, using FFM will require all FX *applications* to
>>>>>> specify --enable-native-access on the command line
>>>>>> Although this is likely coming to JNI soon too.
>>>>>>
>>>>>> https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>>>>>
>>>>>> But one thing to watch out for with FFM is startup + warm up time.
>>>>>> I struggled a lot with that in using FFM for just one library in the
>>>>>> java.desktop module.
>>>>>>
>>>>>> -phil
>>>>>>
>>>>>> On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>>>>
>>>>>> Sorry, we bumped to Java 21 in JavaFX 22 I think since we
>>>>>> preserve the N-1 rule.
>>>>>>
>>>>>> On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker <nlisker at gmail.com> wrote:
>>>>>>
>>>>>>> I think that we'll be able to bump to Java 25 in JavaFX 25, like we
>>>>>>> did with 21. I suggested initially to bump to Java 22 exactly for FFM as
>>>>>>> it's very useful for JavaFX, but was told we shouldn't since it's not an
>>>>>>> LTS version.
>>>>>>>
>>>>>>> I have no idea how long the work on Wayland will take including the
>>>>>>> code review (a rather long process), but you should be able to request code
>>>>>>> reviews with FFM and have it ready for integration by Java 25.
>>>>>>>
>>>>>>> On Mon, Apr 22, 2024 at 5:49?PM Thiago Milczarek Say?o <
>>>>>>> thiago.sayao at gmail.com> wrote:
>>>>>>>
>>>>>>>> I was just experimenting, but it seems to be less work than going
>>>>>>>> with JNI.
>>>>>>>> If I am correct, the next Java LTS will be 25, which will be
>>>>>>>> required on JavaFX 29 to be released on September/29.
>>>>>>>>
>>>>>>>> It's 7 years - that's really too much.
>>>>>>>>
>>>>>>>> Maybe it's still worthwhile to prototype using FFM and then port
>>>>>>>> everything to JNI.
>>>>>>>>
>>>>>>>> -- Thiago.
>>>>>>>>
>>>>>>>>
>>>>>>>> Em seg., 22 de abr. de 2024 ?s 11:21, Kevin Rushforth <
>>>>>>>> kevin.rushforth at oracle.com> escreveu:
>>>>>>>>
>>>>>>>>> Note also that we cannot use Panama in the JavaFX internals yet,
>>>>>>>>> since
>>>>>>>>> the minimum version of the JDK is 21.
>>>>>>>>>
>>>>>>>>> -- Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/21/2024 10:51 AM, Thiago Milczarek Say?o wrote:
>>>>>>>>> > Hi,
>>>>>>>>> >
>>>>>>>>> > I did a small test app to explore Wayland client and portals
>>>>>>>>> (for
>>>>>>>>> > Robot and dialogs such as file open/save).
>>>>>>>>> >
>>>>>>>>> > https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>>>>>> <https://urldefense.com/v3/__https://github.com/tsayao/wayland-test/blob/main/wayland-test.c__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv-uSsniA$>
>>>>>>>>> >
>>>>>>>>> > It seems it will work as a glass backend, but some walls will be
>>>>>>>>> hit
>>>>>>>>> > on the way :)
>>>>>>>>> >
>>>>>>>>> > I have tried to use jextract (from project Panama) to work
>>>>>>>>> directly
>>>>>>>>> > with java, but it seems it does not support wl_ types.
>>>>>>>>> >
>>>>>>>>> > -- Thiago.
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240430/dd44de26/attachment-0001.htm>

From kevin.rushforth at oracle.com  Tue Apr 30 13:48:23 2024
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 30 Apr 2024 06:48:23 -0700
Subject: [External] : Re: Wayland
In-Reply-To: <CAAP_wumMx4TppaWqy7hJ6R08iNtyCO1TZeWZ75QFvzqJ4V7zWQ@mail.gmail.com>
References: <CAAP_wun9nsp=0xrxYfXUTbrjQzNujTkdiauAdtkn_b1yqAR_HA@mail.gmail.com>
 <221cc308-a6a8-4638-ab80-d4c3d98c3735@oracle.com>
 <CAAP_wun7B0ECnrSZY0JOgTaf5SLNCav1dLcoeaveTZt1ZMUgSw@mail.gmail.com>
 <CA+0ynh-txDPee3nZsQsmXrs=NJ5_WcEe0AZCywtrYdqfKn_3xw@mail.gmail.com>
 <CA+0ynh99vgonC=SFHc5tKeFrtPT9iZiSxc4YcsHGDBoweRAD_w@mail.gmail.com>
 <b8598561-94a5-45a0-b3a9-577335d6ddc7@oracle.com>
 <CAAP_wu=U0jgqvPaKO4mbWzSX9m2U=fKWXCmqgFW3XuwOqsSd_g@mail.gmail.com>
 <b3e80ff5-acc7-4a37-a3a9-c0fc6edb4c48@oracle.com>
 <CA+0ynh8QWszUo+StiUTRmnM-PWu7pqU3rtB5TP9WPzVSOO537A@mail.gmail.com>
 <CAAP_wum7-0ojUpGmiDx7Bnjya=XjsRfr+vVPun3MO7VeSwOnng@mail.gmail.com>
 <CAAP_wu=__1KE7R32fLKA0ENstt3G+pwHX6DmuY1arf-MixJp9w@mail.gmail.com>
 <a0c72cdb-e673-4119-83ff-70f27ce44942@oracle.com>
 <CAAP_wumDKeeQM-_Sv_MwZXi0Oq+DmKe1eLOueuxxbDg+5tA-fg@mail.gmail.com>
 <d4e3d08d-aad4-4bb8-96bb-f78f0fed96cc@oracle.com>
 <CAAP_wumMx4TppaWqy7hJ6R08iNtyCO1TZeWZ75QFvzqJ4V7zWQ@mail.gmail.com>
Message-ID: <6a1a5b46-0bb0-4abe-ab46-aaafaa9d1ce8@oracle.com>

Thanks.

-- Kevin

On 4/30/2024 6:41 AM, Thiago Milczarek Say?o wrote:
> Hi,
>
> I rewrote the scanner, so it's all my own code now. No legal issues 
> since I signed the OCA.
>
> Generated java code looks like this:
> https://github.com/tsayao/glass-wayland/blob/main/src/com/sun/glass/wayland/extracted/XdgToplevel.java
>
>
> -- Thiago.
>
> Em seg., 29 de abr. de 2024 ?s 19:57, Kevin Rushforth 
> <kevin.rushforth at oracle.com> escreveu:
>
>     Thank you.
>
>     -- Kevin
>
>
>     On 4/29/2024 2:35 PM, Thiago Milczarek Say?o wrote:
>>     I thought about possible legal conflicts.
>>
>>     The code is on my github - I'm exploring and testing before
>>     starting the real work.
>>
>>     wayland-scanner generates code from the protocol specs, which are
>>     xml files.
>>     https://wayland.app/protocols/
>>     <https://urldefense.com/v3/__https://wayland.app/protocols/__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvIrSwcvY$>
>>
>>     I will write a new generator/scanner from scratch - it's not too
>>     much work.
>>     The generator/scanner itself does not necessarily?need to be part
>>     of the PR, but it might be a good idea to include it, since the
>>     protocol changes over time.
>>
>>     -- Thiago.
>>
>>
>>
>>     Em seg., 29 de abr. de 2024 ?s 18:10, Kevin Rushforth
>>     <kevin.rushforth at oracle.com> escreveu:
>>
>>         As a reminder, contributors must not include 3rd-party code
>>         in any openjdk repo. Per the terms of the OCA, all code that
>>         you contribute to OpenJDK must be your own code. This
>>         includes code you push to openjdk/jfx-sandbox and code in a
>>         branch of a personal fork of openjdk/jfx from which you
>>         create a PR.
>>
>>         -- Kevin
>>
>>
>>         On 4/28/2024 2:45 PM, Thiago Milczarek Say?o wrote:
>>>         Hi,
>>>
>>>         I managed to display a very basic wayland toplevel surface
>>>         from java:
>>>         https://github.com/tsayao/glass-wayland
>>>         <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>>
>>>         If you are using intellij, just run the "Test App" (with
>>>         java 22).
>>>
>>>         generate.sh will jextract the code from wayland-client.
>>>
>>>         I rushed to get the window displayed - so it doesn't look
>>>         good yet (but I do accept suggestions).
>>>
>>>         It uses a java wayland-scanner (included) to read protocol
>>>         xml files and generate code that uses jextracted calls.
>>>
>>>         The sample also binds EGL and GL apis, but just because
>>>         wayland requires a buffer to display the surface. Maybe it
>>>         was easier to use a shared memory :)
>>>
>>>         Credits to (I adapted it to ouput jextract compatible code):
>>>         https://github.com/gfxstrand/wayland-java/tree/master/scanner
>>>         <https://urldefense.com/v3/__https://github.com/gfxstrand/wayland-java/tree/master/scanner__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv70bWagY$>
>>>
>>>         Cheers
>>>
>>>         Em ter., 23 de abr. de 2024 ?s 09:11, Thiago Milczarek Say?o
>>>         <thiago.sayao at gmail.com> escreveu:
>>>
>>>             I'm doing some work here:
>>>             https://github.com/tsayao/glass-wayland
>>>             <https://urldefense.com/v3/__https://github.com/tsayao/glass-wayland__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyvrMZe-eM$>
>>>
>>>             So far it's been a good experience to use FFM / jextract.
>>>
>>>             The idea is to plug it as a glass wayland backend when
>>>             it's good enough.
>>>
>>>
>>>
>>>             Em seg., 22 de abr. de 2024 ?s 16:16, Nir Lisker
>>>             <nlisker at gmail.com> escreveu:
>>>
>>>                 Not sure it helps with warmup, but marking a foreign
>>>                 function as critical can improve performance:
>>>                 https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/foreign/Linker.Option.html#critical(boolean).
>>>
>>>                 On Mon, Apr 22, 2024 at 10:02?PM Philip Race
>>>                 <philip.race at oracle.com> wrote:
>>>
>>>                     No, it wasn't. I didn't even use jextracted code.
>>>                     The startup cost is around initialisation of FFM
>>>                     - around 70 ms (IIRC) overhead on my MacBook
>>>                     Then creation of VarHandles and MethodHandles -
>>>                     2-5 ms each is what I measured, so do these
>>>                     lazily if you can.
>>>                     And warmup cost is that it takes about 10000
>>>                     iterations to get code fully compiled.
>>>
>>>                     java -XX:+PrintFlagsFinal -version 2>&1 | grep
>>>                     CompileThreshold
>>>                     ???? intx CompileThreshold = 10000 {pd product}
>>>                     {default}
>>>                     ??? double CompileThresholdScaling = 1.000000
>>>                     {product} {default}
>>>                     ??? uintx IncreaseFirstTierCompileThresholdAt =
>>>                     50 {product} {default}
>>>                     ???? intx Tier2CompileThreshold = 0 {product}
>>>                     {default}
>>>                     ???? intx Tier3CompileThreshold = 2000 {product}
>>>                     {default}
>>>                     ???? intx Tier4CompileThreshold = 15000
>>>                     {product} {default}
>>>
>>>                     -phil.
>>>
>>>
>>>                     On 4/22/24 11:45 AM, Thiago Milczarek Say?o wrote:
>>>>                     I think the startup time might be related to
>>>>                     all static symbol lookups.
>>>>                     So I'm manually including just what is needed:
>>>>                     jextract --output src -t com.sun.glass.wayland.extracted \
>>>>                        --header-class-name GlassWayland \
>>>>                        `pkg-config --libs glib-2.0 gio-2.0 libportal wayland-client`  \
>>>>                        `pkg-config --cflags-only-I glib-2.0 gio-2.0 libportal wayland-client`  \
>>>>                         glass-wayland.h \
>>>>                         --include-function xdp_portal_initable_new \
>>>>                         --include-function xdp_session_close \
>>>>                         --include-function xdp_portal_open_file \
>>>>                         --include-function xdp_portal_open_file_finish \
>>>>                         --include-function g_object_unref \
>>>>                         --include-function g_timeout_add \
>>>>                         --include-function g_add_idle \
>>>>                         --include-function g_main_loop_run \
>>>>                         --include-function g_main_loop_new \
>>>>                         --include-function g_main_loop_ref \
>>>>                         --include-function g_main_loop_unref \
>>>>                         --include-function g_main_loop_quit \
>>>>                         --include-function g_settings_new \
>>>>                         --include-function g_settings_get_int \
>>>>                         --include-function wl_display_connect \
>>>>                         --include-function wl_display_disconnect \
>>>>                         --include-function wl_display_roundtrip \
>>>>                         --include-function wl_display_dispatch_pending \
>>>>                         --include-typedef GAsyncReadyCallback \
>>>>                         --include-typedef GSourceFunc \
>>>>                         --include-typedef GError
>>>>
>>>>                     Em seg., 22 de abr. de 2024 ?s 13:24, Philip
>>>>                     Race <philip.race at oracle.com> escreveu:
>>>>
>>>>                         As a reminder, using FFM will require all
>>>>                         FX *applications* to specify
>>>>                         --enable-native-access on the command line
>>>>                         Although this is likely coming to JNI soon too.
>>>>
>>>>                         https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
>>>>
>>>>                         But one thing to watch out for with FFM is
>>>>                         startup + warm up time.
>>>>                         I struggled a lot with that in using FFM
>>>>                         for just one library in the java.desktop
>>>>                         module.
>>>>
>>>>                         -phil
>>>>
>>>>                         On 4/22/24 9:12 AM, Nir Lisker wrote:
>>>>>                         Sorry, we bumped to Java 21 in JavaFX 22 I
>>>>>                         think since we preserve?the N-1 rule.
>>>>>
>>>>>                         On Mon, Apr 22, 2024 at 6:03?PM Nir Lisker
>>>>>                         <nlisker at gmail.com> wrote:
>>>>>
>>>>>                             I think that we'll be able to bump to
>>>>>                             Java 25 in JavaFX 25, like we did with
>>>>>                             21. I suggested initially to bump to
>>>>>                             Java 22 exactly for FFM as it's very
>>>>>                             useful for JavaFX, but was told we
>>>>>                             shouldn't since it's not an LTS version.
>>>>>
>>>>>                             I have no idea how long the work on
>>>>>                             Wayland will take including the code
>>>>>                             review (a rather long process), but
>>>>>                             you should be able to request code
>>>>>                             reviews with FFM and have it ready for
>>>>>                             integration by Java 25.
>>>>>
>>>>>                             On Mon, Apr 22, 2024 at 5:49?PM Thiago
>>>>>                             Milczarek Say?o
>>>>>                             <thiago.sayao at gmail.com> wrote:
>>>>>
>>>>>                                 I was just experimenting, but it
>>>>>                                 seems to be less work than going
>>>>>                                 with JNI.
>>>>>                                 If I am correct, the next Java LTS
>>>>>                                 will be 25, which will be required
>>>>>                                 on JavaFX 29 to be released on
>>>>>                                 September/29.
>>>>>
>>>>>                                 It's 7 years - that's really too much.
>>>>>
>>>>>                                 Maybe it's still worthwhile to
>>>>>                                 prototype using FFM and then port
>>>>>                                 everything to JNI.
>>>>>
>>>>>                                 -- Thiago.
>>>>>
>>>>>
>>>>>                                 Em seg., 22 de abr. de 2024 ?s
>>>>>                                 11:21, Kevin Rushforth
>>>>>                                 <kevin.rushforth at oracle.com> escreveu:
>>>>>
>>>>>                                     Note also that we cannot use
>>>>>                                     Panama in the JavaFX internals
>>>>>                                     yet, since
>>>>>                                     the minimum version of the JDK
>>>>>                                     is 21.
>>>>>
>>>>>                                     -- Kevin
>>>>>
>>>>>
>>>>>                                     On 4/21/2024 10:51 AM, Thiago
>>>>>                                     Milczarek Say?o wrote:
>>>>>                                     > Hi,
>>>>>                                     >
>>>>>                                     > I did a small test app to
>>>>>                                     explore Wayland client and
>>>>>                                     portals (for
>>>>>                                     > Robot and dialogs such as
>>>>>                                     file open/save).
>>>>>                                     >
>>>>>                                     >
>>>>>                                     https://github.com/tsayao/wayland-test/blob/main/wayland-test.c
>>>>>                                     <https://urldefense.com/v3/__https://github.com/tsayao/wayland-test/blob/main/wayland-test.c__;!!ACWV5N9M2RV99hQ!Jo_TDwcs-PU92bLqkpeok4ZlEQPsXiuBR6VfTF1dPSZ9mw24pohF8OxE3mlESTQMdQw0OeOFkX-vr7oN_qyv-uSsniA$>
>>>>>                                     >
>>>>>                                     > It seems it will work as a
>>>>>                                     glass backend, but some walls
>>>>>                                     will be hit
>>>>>                                     > on the way :)
>>>>>                                     >
>>>>>                                     > I have tried to use jextract
>>>>>                                     (from project Panama) to work
>>>>>                                     directly
>>>>>                                     > with java, but it seems it
>>>>>                                     does not support wl_ types.
>>>>>                                     >
>>>>>                                     > -- Thiago.
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240430/1d37c834/attachment-0001.htm>

From tsayao at openjdk.org  Tue Apr 30 14:07:11 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Apr 2024 14:07:11 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]
In-Reply-To: <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>
Message-ID: <LOIL-bhNyxh66Xyzr2STEECkcc-U0HJ2h8aRrJwQmGc=.4514e7ca-5726-4a74-b1e5-1bf68374bce2@github.com>

On Tue, 30 Apr 2024 12:22:34 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Use EGL_DEFAULT_DISPLAY
>   - Deallocate the resources correctly
>   - Use PBuffer as the dummy surface

It is possible to set the platform with `EGL_PLATFORM=x11` environment variable. 
Using ` EGL_LOG_LEVEL=debug ` currently outputs that the platform was detected in build time - I think it's wrong.

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2085427160

From tsayao at openjdk.org  Tue Apr 30 14:53:09 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Apr 2024 14:53:09 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v7]
In-Reply-To: <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <G_cJo55X4YVcBeoUew64P0qfsMKTS3KOhW6M191nka0=.a22e584c-a05e-4dc8-ae22-98d80aa2c72e@github.com>
Message-ID: <TRGeIIkL6Se9Pw42qyVF10cqtaAgFw2qTXR7B130ArI=.2a145f04-fe0f-4640-9a63-f7c5545cdeb9@github.com>

On Tue, 30 Apr 2024 12:22:34 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Use EGL_DEFAULT_DISPLAY
>   - Deallocate the resources correctly
>   - Use PBuffer as the dummy surface

I'll have to fix it

I got a reply explaining it (the docs where not very clear)
https://lists.freedesktop.org/archives/mesa-users/2024-April/001727.html

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2085554001

From mfox at openjdk.org  Tue Apr 30 14:59:16 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 30 Apr 2024 14:59:16 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
Message-ID: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>

When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.

It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

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

Commit messages:
 - Check that input context is active before calling discardMarkedText

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

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

From kcr at openjdk.org  Tue Apr 30 14:59:17 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 14:59:17 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <38kN2C9_mn-c5TaxuEwuHMkeoHoDravfZjstxsrulRs=.8829b6b3-0641-4ccc-89b0-dec559c97e00@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

Reviewers: @andy-goryachev-oracle @kevinrushforth

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

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085565591

From kcr at openjdk.org  Tue Apr 30 15:09:08 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 15:09:08 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <3tVxBjRCc9JrNhXEVYEDtqJYfntkRgeAFI1CXsWblp8=.6a3711bf-28d3-474f-b8a7-757f131b6ada@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

Looks good. I verified on my macOS 13.6.6 system that this fixes the problem. I also verified that the test program from JDK-8320912 still works correctly.

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1447#pullrequestreview-2031686652

From angorya at openjdk.org  Tue Apr 30 15:30:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Apr 2024 15:30:10 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <sYgJFifPDJkBxyJNaKC37hBJpE0ME35_iB0npkZMfPU=.89a40be9-7d85-4660-9015-48458ac0f335@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

Seems to work with the little test program.

Observed a weird behavior in the Monkey Tester
https://github.com/andy-goryachev-oracle/MonkeyTest

- open TextArea page
- set font to System Regular
- select text: "Writing Systems"
- click on any English word, invoke IME (I use Japanese), observe candidate inserted correctly
- click on non-English word, invoke IME, the candidate is still shows up correctly
- click on an English word, invoke IME and the candidate shows garbage.  

It seems to me it might be using font from the previous invocation?
This could be a different issue though.

![Screenshot 2024-04-30 at 08 18 55](https://github.com/openjdk/jfx/assets/107069028/9435df5d-18e4-4aa4-88bd-a42fee0811cf)

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

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085670379

From kcr at openjdk.org  Tue Apr 30 15:33:09 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 15:33:09 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <9hIi1ilCwq1CpBQATm47ngfRQ4VxfHAMnHM6FI8DMWI=.fb9ed3f5-f4d7-49e6-b6df-90e5546c5899@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

That seems likely a different issue. Can you try it with a build without the current PR? And maybe also try it with JavaFX 22 to rule out other recently-introduced problems?

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

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085676916

From angorya at openjdk.org  Tue Apr 30 15:38:10 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Apr 2024 15:38:10 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <lKtlXjRh90dRVWnJ5P9BMopIU6Z7k3Cw2DQMi0q9Z_A=.0d9119c3-bfb7-4c08-ac2b-7ed4f3c49d74@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

same issue without the fix.  I agree - this is likely unrelated.

I won't be able to try with an earlier jdk in the next couple of hours, sorry.

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

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2085695130

From angorya at openjdk.org  Tue Apr 30 17:16:09 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Apr 2024 17:16:09 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <OVX5iiStfCTcqM5kjxsw485cxDszonvuyN1HeA8W9Cc=.97ec8921-80a3-4e58-a671-46d02b5c760f@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
 <rEZ42o5gHXbummkxoW3K6NzTLota4eEsJ3XGux3W-0Q=.ec7af8fd-e647-4ef6-8226-50706d7cbb31@github.com>
 <OVX5iiStfCTcqM5kjxsw485cxDszonvuyN1HeA8W9Cc=.97ec8921-80a3-4e58-a671-46d02b5c760f@github.com>
Message-ID: <Df5WIDruLQIOG9D7ctqGaKUXpB9N-GOp9aN4c30pZHY=.74724e5e-17a7-4525-823f-5cb95fb289ac@github.com>

On Tue, 30 Apr 2024 17:11:25 GMT, Karthik P K <kpk at openjdk.org> wrote:

>> Looking at the "next word" functionality across different applications on different platforms, it appears to be a wide variety of behaviors.
>> 
>> One vendor appears to be quite consistent - Microsoft.  Its word, word pad, notepad work exactly the same, with Word working the same across macOS and Win11.
>> 
>> JavaFX TextArea is inconsistent (by design) between macOS and Win11, but also is inconsistent with Swing's JTextArea.
>> 
>> If I were to fix the behavior (if we decide to fix the behavior of the nextWord function, that is), I would make it consistent with MS Word, but let's discuss.
>> 
>> For reference, here is the result of my testing.  Initially, the caret is placed at index 0 and the numbers in parentheses denote successive caret positions after ctrl-RIGHT (option-RIGHT) key presses.  An underline denotes a space, and a (nl) denotes a newline.
>> 
>> 
>> source
>> _english_english_eng:_end,_eng:_(nl)
>> (nl)
>> _eng
>> 
>> 
>> BreakIterator.getWordInstance()
>> _(1)english(2)_(3)english(4)_(5)eng(6):(7)_(8)end(9),(10)_(11)eng(12):(13)_(14)(nl)
>> (15)(nl)
>> (16)_(17)eng
>> 
>> 
>> text area (mac)
>> _english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_(nl)
>> (9)(nl)
>> (10)_eng(11)
>> 
>> 
>> ms word (mac) 16.84 24041420 consistent with win11
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng(13)
>> 
>> 
>> text edit (mac)
>> _english(1)_english(2)_eng(3):_end(4),_eng(5):_(nl)
>> (nl)
>> (nl)_eng(6)
>> 
>> 
>> chrome (mac) <div contenteditable=true>
>> &nbsp;english(1)_english(2)_eng(3):(4)_end(5),(6)_eng(7):(8)_<br>
>> (9)<br>
>> _(10)eng(11)
>> 
>> 
>> eclipse (mac)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng
>> 
>> 
>> JTextArea (mac)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (nl)
>> _(10)eng
>> 
>> 
>> ms word 365 ver 2302 build 16.0.16130.20942 (win 11)
>> same as notepad (win 11)
>> same as wordpad (win 11)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> (11)_(12)eng
>> 
>> 
>> TextArea (win11)
>> _(1)english_(2)english_(3)eng(4):_(5)end(6),_(7)eng(8):_(9)(nl)
>> (10)(nl)
>> _(11)eng
>
>> If I were to fix the behavior (if we decide to fix the behavior of the nextWord function, that is), I would make it consistent with MS Word, but let's discuss.
>> 
> The behaviour in MS word looks to be easy to understand and what we would expect. +1 for this.
> 
> Thanks @andy-goryachev-oracle for checking the behaviour and providing the details.

thank you @karthikpandelu for raising the question!

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

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2086058099

From kpk at openjdk.org  Tue Apr 30 17:16:08 2024
From: kpk at openjdk.org (Karthik P K)
Date: Tue, 30 Apr 2024 17:16:08 GMT
Subject: RFR: 8330590: TextInputControl: previous word fails with Bhojpuri
 characters [v2]
In-Reply-To: <rEZ42o5gHXbummkxoW3K6NzTLota4eEsJ3XGux3W-0Q=.ec7af8fd-e647-4ef6-8226-50706d7cbb31@github.com>
References: <yWffFgdFEsKKmFepZWSK3ya4I2bBpUGy8KVH75th04Y=.f908b341-f93e-4f3b-aef5-26da7c4ce7c6@github.com>
 <KJHwE205xrpH6V1Jd4iNm99MG4Lr6u87GduLHlmoi6w=.03a1f3e1-0f89-4c0f-9105-a3c497cdeb7a@github.com>
 <rEZ42o5gHXbummkxoW3K6NzTLota4eEsJ3XGux3W-0Q=.ec7af8fd-e647-4ef6-8226-50706d7cbb31@github.com>
Message-ID: <OVX5iiStfCTcqM5kjxsw485cxDszonvuyN1HeA8W9Cc=.97ec8921-80a3-4e58-a671-46d02b5c760f@github.com>

On Mon, 29 Apr 2024 21:27:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> If I were to fix the behavior (if we decide to fix the behavior of the nextWord function, that is), I would make it consistent with MS Word, but let's discuss.
> 
The behaviour in MS word looks to be easy to understand and what we would expect. +1 for this.

Thanks @andy-goryachev-oracle for checking the behaviour and providing the details.

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

PR Comment: https://git.openjdk.org/jfx/pull/1444#issuecomment-2086045856

From mfox at openjdk.org  Tue Apr 30 17:31:38 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 30 Apr 2024 17:31:38 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external [v2]
In-Reply-To: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
Message-ID: <0ZODxPAAcF6zosomDJBGsxEzDH_KYyTXKYH2gZ59z6k=.85e3fb8d-508b-4627-8260-c1b614c65297@github.com>

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations.

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

 - Added manual test that covers all the DnD basics
 - Merge remote-tracking branch 'upstream/master' into macdropop
 - Using OS to determine DRAG_DONE operation

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1371/files
  - new: https://git.openjdk.org/jfx/pull/1371/files/4f088cc3..c0bbbf5c

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

  Stats: 32641 lines in 1003 files changed: 17817 ins; 6536 del; 8288 mod
  Patch: https://git.openjdk.org/jfx/pull/1371.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1371/head:pull/1371

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

From mfox at openjdk.org  Tue Apr 30 17:42:22 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 30 Apr 2024 17:42:22 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external [v3]
In-Reply-To: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
Message-ID: <hZwFmGdvW_AHKBvezkyrO3EHq8xALnH4f2DLbzQm17g=.188a4604-1a77-48cd-8956-54d395530603@github.com>

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Fixed whitespace errors

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1371/files
  - new: https://git.openjdk.org/jfx/pull/1371/files/c0bbbf5c..4eed575a

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

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

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

From angorya at openjdk.org  Tue Apr 30 18:12:04 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Apr 2024 18:12:04 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <E-0VLl_cZ2TKWvAexocmmkFnlvT_FcLdQt2qbRcRlL4=.a03b7ecd-9696-4e32-8f4b-7bada10c963b@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

With jfx21-ea+12, I see the same incorrect font, so it must be a different issue.


java --module-path "REDACTED/Java/javafx-sdk-21/lib" --add-modules javafx.base,javafx.graphics,javafx.controls,javafx.swing,javafx.web -jar "REDACTED/MonkeyTest2/MonkeyTest/dist/MonkeyTester.jar"

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

PR Comment: https://git.openjdk.org/jfx/pull/1447#issuecomment-2086266422

From jhendrikx at openjdk.org  Tue Apr 30 18:13:11 2024
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 30 Apr 2024 18:13:11 GMT
Subject: Integrated: 8314215: Trailing Spaces before Line Breaks Affect the
 Center Alignment of Text
In-Reply-To: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
References: <0tsayf-5NTyzH_EYdH1wmKEvKpqJhozoi1RoI0bBAd0=.2aaabdbd-7766-4f68-8b3b-1f92f52f0783@github.com>
Message-ID: <p16j1rWDGCJc0XFkY0GDEDP3y8Vqsm8YG04clWlG1nk=.765abc80-6b02-407a-af74-3efcdddd93d5@github.com>

On Sun, 10 Sep 2023 20:50:18 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> There are a number of tickets open related to text rendering:
> 
> https://bugs.openjdk.org/browse/JDK-8314215
> 
> https://bugs.openjdk.org/browse/JDK-8145496
> 
> https://bugs.openjdk.org/browse/JDK-8129014
> 
> They have in common that wrapped text is taking the trailing spaces on each wrapped line into account when calculating where to wrap.  This looks okay for text that is left aligned (as the spaces will be trailing the lines and generally aren't a problem, but looks weird with CENTER and RIGHT alignments.  Even with LEFT alignment there are artifacts of this behavior, where a line like `AAA  BBB  CCC` (note the **double** spaces) gets split up into `AAA  `, `BBB  ` and `CCC`, but if space reduces further, it will wrap **too** early because the space is taken into account (ie. `AAA` may still have fit just fine, but `AAA  ` doesn't, so the engine wraps it to `AA` + `A  ` or something).
> 
> The fix for this is two fold; first the individual lines of text should not include any trailing spaces into their widths; second, the code that is taking the trailing space into account when wrapping should ignore all trailing spaces (currently it is ignoring all but one trailing space).  With these two fixes, the layout in LEFT/CENTER/RIGHT alignments all look great, and there is no more early wrapping due to a space being taking into account while the actual text still would have fit (this is annoying in tight layouts, where a line can be wrapped early even though it looks like it would have fit).
> 
> If it were that simple, we'd be done, but there may be another issue here that needs solving: wrapped aligned TextArea's.
> 
> TextArea don't directly support text alignment (via a setTextAlignment method like Label) but you can change it via CSS.
> 
> For Left alignment + wrapping, TextArea will ignore any spaces typed before a line that was wrapped.  In other words, you can type spaces as much as you want, and they won't show up and the cursor won't move.  The spaces are all getting appended to the previous line.  When you cursor through these spaces, the cursor can be rendered out of the control's bounds.  To illustrate, if you have the text `AAA                 BBB CCC`, and the text gets wrapped to `AAA`, `BBB`, `CCC`, typing spaces before `BBB` will not show up.  If you cursor back, the cursor may be outside the control bounds because so many spaces are trailing `AAA`.
> 
> The above behavior has NOT changed, is pretty standard for wrapped text controls, and IMHO does not need further attent...

This pull request has now been integrated.

Changeset: 398f104d
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/398f104d6ba721f4534d6e7afdc903b2384e147f
Stats:     1011 lines in 7 files changed: 762 ins; 231 del; 18 mod

8314215: Trailing Spaces before Line Breaks Affect the Center Alignment of Text

Reviewed-by: kpk, angorya

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

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

From kcr at openjdk.org  Tue Apr 30 18:36:02 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 18:36:02 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external [v3]
In-Reply-To: <hZwFmGdvW_AHKBvezkyrO3EHq8xALnH4f2DLbzQm17g=.188a4604-1a77-48cd-8956-54d395530603@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
 <hZwFmGdvW_AHKBvezkyrO3EHq8xALnH4f2DLbzQm17g=.188a4604-1a77-48cd-8956-54d395530603@github.com>
Message-ID: <d2oHU0qFArTmCaAh56RgoNw8mMx3ZOG2okHaSWv6CVk=.27f6d386-0019-43cc-9c42-4e7789901a74@github.com>

On Tue, 30 Apr 2024 17:42:22 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
>> 
>> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed whitespace errors

Looks good. Thanks for the new manual test program. I left one minor formatting comment on the test, but I'll approve it anyway (and reapprove if you update it).

tests/manual/dnd/DndBasic.java line 169:

> 167: 
> 168:     private Group createTarget(TransferMode[] modes)
> 169:     {

Minor: move brace to previous line

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

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1371#pullrequestreview-2032195751
PR Review Comment: https://git.openjdk.org/jfx/pull/1371#discussion_r1585313426

From mfox at openjdk.org  Tue Apr 30 18:51:24 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 30 Apr 2024 18:51:24 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external [v4]
In-Reply-To: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
Message-ID: <AJuNSfj9a_QGTxoY-NaaMqgKSVR3HXPqEbhm4Iwtqf8=.fe7e0f42-53d7-48d7-b8ca-76e66d818345@github.com>

> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
> 
> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Update to match coding standards

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1371/files
  - new: https://git.openjdk.org/jfx/pull/1371/files/4eed575a..e2052e9d

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

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

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

From angorya at openjdk.org  Tue Apr 30 18:56:58 2024
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 30 Apr 2024 18:56:58 GMT
Subject: RFR: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <qt4I2LAZm5F__OiU6XXPyjyP98IRTQ-hYHogK2uC-HY=.7de743f6-e2f8-4ebe-bf86-5f68020c2804@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

ship it!

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

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1447#pullrequestreview-2032245187

From tsayao at openjdk.org  Tue Apr 30 20:03:18 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Apr 2024 20:03:18 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v8]
In-Reply-To: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
Message-ID: <AYMLtOum2kZcMU62iVY3Cdw5ZfD_MCHYZxwJX4WclZE=.ee41b082-a3d7-4e17-8033-f6c67e230f74@github.com>

> Wayland implementation will require EGL. 
> 
> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
> 
> 
> See:
> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)

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

 - Rollback file
 - rollback file
 - - Rollback EGL_DEFAULT_DISPLAY
   - Don't trust eglGetDisplay without platform
   - Rollback Use PBuffer as the dummy surface
 - Revert "- Use EGL_DEFAULT_DISPLAY"
   
   This reverts commit 0c78b7490aae221b8441028323bdfa7803e6252e.

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1381/files
  - new: https://git.openjdk.org/jfx/pull/1381/files/0c78b749..619ae9c4

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

  Stats: 115 lines in 11 files changed: 52 ins; 29 del; 34 mod
  Patch: https://git.openjdk.org/jfx/pull/1381.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381

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

From tsayao at openjdk.org  Tue Apr 30 20:09:58 2024
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Tue, 30 Apr 2024 20:09:58 GMT
Subject: RFR: 8329820: [Linux] Prefer EGL over GLX [v8]
In-Reply-To: <AYMLtOum2kZcMU62iVY3Cdw5ZfD_MCHYZxwJX4WclZE=.ee41b082-a3d7-4e17-8033-f6c67e230f74@github.com>
References: <yS68_vamDOOham0rHXHcivhY1ALGkw-XZQKIjOQ0cdo=.bc990fac-ed81-44eb-b28d-11555d21488e@github.com>
 <AYMLtOum2kZcMU62iVY3Cdw5ZfD_MCHYZxwJX4WclZE=.ee41b082-a3d7-4e17-8033-f6c67e230f74@github.com>
Message-ID: <NlfJWjOaA9dYNJ4lrOrahbdovBu090h80NRFXMNHeTg=.58f5e3d1-db17-4348-87bb-fec3d0e4d73d@github.com>

On Tue, 30 Apr 2024 20:03:18 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Wayland implementation will require EGL. 
>> 
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails, fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>> 
>> 
>> See:
>> [Switching the Linux graphics stack from GLX to EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/)
>> [Prefer EGL to GLX for the GL support on X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540)
>
> Thiago Milczarek Sayao has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rollback file
>  - rollback file
>  - - Rollback EGL_DEFAULT_DISPLAY
>    - Don't trust eglGetDisplay without platform
>    - Rollback Use PBuffer as the dummy surface
>  - Revert "- Use EGL_DEFAULT_DISPLAY"
>    
>    This reverts commit 0c78b7490aae221b8441028323bdfa7803e6252e.

I changed it to use platform specific way to get `EGLDisplay` so `eglGetDisplay` does not have to guess the platform (it can guess wrong).

It can be seen by setting `EGL_LOG_LEVEL=debug` (with `eglGetDisplay` it will output the guessing part).

I also reverted the Dummy window code change.

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

PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2087018281

From mfox at openjdk.org  Tue Apr 30 20:10:56 2024
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 30 Apr 2024 20:10:56 GMT
Subject: Integrated: 8331319: IME Window breaks after popup menu
In-Reply-To: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
References: <4zzaICDDYJXliecKXpNgBBNs5iggb-lWHMBCwEbbrLE=.a57f3a6a-e704-4349-9f49-e865864f2f78@github.com>
Message-ID: <-0DEXJELZd4kUJkF6oYWb4qvLsbWJGk4UCzXEJpZS4E=.34a42d34-6a63-4078-8d44-121d204bf662@github.com>

On Tue, 30 Apr 2024 14:52:50 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When focus moves away from a node JavaFX calls `finishInputMethodComposition` so glass can clean up any in-progress IME editing. On Mac we call `discardMarkedText` on the view's NSTextInputContext to dismiss the IME.
> 
> It appears that the OS can get confused if `discardMarkedText` is called on an NSTextInputContext that is not the current active context. JavaFX popups are displayed in windows that don't have OS focus and therefore do not have the active input context but the JavaFX scene associated with the popup doesn't know this and still makes calls to manipulate the IME. This seems to be triggering a bug in the OS that leads to bad behavior which persists until the user moves focus away from the main JavaFX stage altogether and then brings it back.

This pull request has now been integrated.

Changeset: cac81b52
Author:    Martin Fox <mfox at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/cac81b52fdeca763f3da21523c1582af3407aaf3
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8331319: IME Window breaks after popup menu

Reviewed-by: kcr, angorya

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

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

From kcr at openjdk.org  Tue Apr 30 20:35:00 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 20:35:00 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external [v4]
In-Reply-To: <FbfV3oqYrM3yrZjRzuj5QhfDUl7PKikBYyHj-BmHyVw=.1c86fab8-de1b-4de6-b72e-20e467938d53@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
 <FbfV3oqYrM3yrZjRzuj5QhfDUl7PKikBYyHj-BmHyVw=.1c86fab8-de1b-4de6-b72e-20e467938d53@github.com>
Message-ID: <Ek0cTH0ZtPwbxAir8UQDmawNiSsQ5eUaaTnWMS__lLs=.f766c4e9-9579-4f38-a0e7-1a32f976642d@github.com>

On Thu, 28 Mar 2024 12:53:24 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update to match coding standards
>
> LGTM

@lukostyra Can you please re-review?

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

PR Comment: https://git.openjdk.org/jfx/pull/1371#issuecomment-2087148313

From kcr at openjdk.org  Tue Apr 30 20:34:59 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 20:34:59 GMT
Subject: RFR: 8325591: [Mac] DRAG_DONE reports null transferMode when
 destination is external [v4]
In-Reply-To: <AJuNSfj9a_QGTxoY-NaaMqgKSVR3HXPqEbhm4Iwtqf8=.fe7e0f42-53d7-48d7-b8ca-76e66d818345@github.com>
References: <tx-Jso2XRchQhsRHJcecFPzwNsOkiNUI4wM8NaJ-8UU=.44ca9cb2-5bfe-4b08-9ce0-d51f38fae07e@github.com>
 <AJuNSfj9a_QGTxoY-NaaMqgKSVR3HXPqEbhm4Iwtqf8=.fe7e0f42-53d7-48d7-b8ca-76e66d818345@github.com>
Message-ID: <JXGo1gvEEZ0MVxCeQNpuOHw06KDJDHmEMP1CK6wJEaY=.0909a950-30cf-43b8-bda4-4a661a9f6006@github.com>

On Tue, 30 Apr 2024 18:51:24 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> At the end of a drag operation the Mac Glass code sends out a DRAG_DONE event using the operation mask tracked in the GlassDragSource to determine the final transfer mode. That mask is only updated when a window in the JavaFX app is the drop destination. If the drag moves to an external destination the mask is set to NONE. If the drag terminates in the external destination that NONE forms the basis of the transfer mode sent via the DRAG_DONE event.
>> 
>> At the very end of the drag the OS calls the NSDraggingSource (GlassDraggingSource) with the final drag operation. This PR issues the DRAG_DONE from that callback so it can get the final transfer mode correct for both internal and external destinations.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update to match coding standards

Marked as reviewed by kcr (Lead).

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

PR Review: https://git.openjdk.org/jfx/pull/1371#pullrequestreview-2032469234

From kcr at openjdk.org  Tue Apr 30 23:24:00 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 30 Apr 2024 23:24:00 GMT
Subject: RFR: 8326619: Stage.sizeToScene() on maximized/fullscreen Stage
 breaks the Window [v3]
In-Reply-To: <oRYnvnSzu5Ro9dW7b8TCRcXLasx_DBmUfaavhs_9OS0=.f8db5b04-1948-4892-a4a4-483852ef1863@github.com>
References: <iLZXWKXwQINtUmCNkY_mS9H_Wd9CT78CUQlCHe0Rx4Q=.743085fb-ea97-4a15-b6a3-fddd2926dff5@github.com>
 <oRYnvnSzu5Ro9dW7b8TCRcXLasx_DBmUfaavhs_9OS0=.f8db5b04-1948-4892-a4a4-483852ef1863@github.com>
Message-ID: <16tHtx97hXBO0ouOygAIlrJvp12xtFkiuk4yWpTAfDw=.81eaabda-6c47-47f6-950b-464b35a61ee7@github.com>

On Sat, 9 Mar 2024 18:41:10 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is broken when `sizeToScene()` was called before or after.
>> 
>> The approach here is to ignore the `sizeToScene()` request when the `Stage` is maximized or set to fullscreen. 
>> Otherwise the Window Manager of the OS will be confused and you will get weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize' button still shows the 'Restore' Icon, while we already resized the `Stage` to not be maximized).
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve tests

The fix looks good. The spec changes (updated javadocs) look good. Can you create the CSR for the spec change?

I have a couple overall comments:

* I wanted to verify different orders of operation, so I wrote a (manual) test program and attached it to the JBS bug. It covers the following cases:
    * set ; sizeToScene ; show
    * sizeToScene ; set ; show
    * show ; set ; sizeToScene
    * show ; sizeToScene ; set

I verified that the first 3 are broken today. All cases work with your fix. I think it might be a good idea to add automated tests for the different orderings.

* Please merge the latest master. Note that the calls to Util.shutdown in the tests must be fixed after this is done or they will no longer compile.

tests/system/src/test/java/test/javafx/stage/SizeToSceneFullscreenTest.java line 69:

> 67:     @AfterAll
> 68:     public static void teardown() {
> 69:         Util.shutdown(stage);

You will need to remove the `stage` argument after you merge the latest master.

tests/system/src/test/java/test/javafx/stage/SizeToSceneMaximizeTest.java line 69:

> 67:     @AfterAll
> 68:     public static void teardown() {
> 69:         Util.shutdown(stage);

You will need to remove the `stage` argument after you merge the latest master.

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

PR Review: https://git.openjdk.org/jfx/pull/1382#pullrequestreview-2032228167
PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1585330069
PR Review Comment: https://git.openjdk.org/jfx/pull/1382#discussion_r1585330320