From mhanl at openjdk.java.net Tue Feb 1 17:41:47 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 1 Feb 2022 17:41:47 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v4] In-Reply-To: References: Message-ID: <0WzVd0GNDRoZ_O-Sbrhz6alHa6nCu2mPCpbegVDzMlM=.ff7acf10-e114-48bc-b2ec-b6a14d9398a4@github.com> > This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. > In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. > > This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8251481: Added jdk ticket reference in TreeTableCellTest + Grammar ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/716/files - new: https://git.openjdk.java.net/jfx/pull/716/files/a8d99555..a706068e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=716&range=02-03 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/716.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/716/head:pull/716 PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Tue Feb 1 17:41:50 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 1 Feb 2022 17:41:50 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v3] In-Reply-To: <0KfzvfTmEt753F_yPzBc4bLtS9uvXaAvy8Np7SSqLcM=.e84d2e84-14e4-42ad-ad7f-2a9aa6b704c1@github.com> References: <0KfzvfTmEt753F_yPzBc4bLtS9uvXaAvy8Np7SSqLcM=.e84d2e84-14e4-42ad-ad7f-2a9aa6b704c1@github.com> Message-ID: On Sat, 29 Jan 2022 13:57:01 GMT, Jeanette Winzenburg wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8251481: Using global stageLoader now > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 690: > >> 688: */ >> 689: @Test >> 690: public void testRowIsNotNullWhenAutoSizing() { > > same as autosizing test for TableCell: would like the issue id :) done ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From arapte at openjdk.java.net Wed Feb 2 07:58:46 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 2 Feb 2022 07:58:46 GMT Subject: RFR: 8278980: Update to 613.1 version of WebKit Message-ID: Update JavaFX WebKit to GTK WebKit 2.34 (613.1). Verified the updated version build, tests run and sanity testing. This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) ------------- Commit messages: - webkit update 613.1 Changes: https://git.openjdk.java.net/jfx/pull/723/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=723&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278980 Stats: 413083 lines in 6742 files changed: 231443 ins; 135747 del; 45893 mod Patch: https://git.openjdk.java.net/jfx/pull/723.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/723/head:pull/723 PR: https://git.openjdk.java.net/jfx/pull/723 From fastegal at openjdk.java.net Wed Feb 2 12:01:14 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 2 Feb 2022 12:01:14 GMT Subject: RFR: 8251481: TableCell accessing row: NPE on auto-sizing [v4] In-Reply-To: <0WzVd0GNDRoZ_O-Sbrhz6alHa6nCu2mPCpbegVDzMlM=.ff7acf10-e114-48bc-b2ec-b6a14d9398a4@github.com> References: <0WzVd0GNDRoZ_O-Sbrhz6alHa6nCu2mPCpbegVDzMlM=.ff7acf10-e114-48bc-b2ec-b6a14d9398a4@github.com> Message-ID: On Tue, 1 Feb 2022 17:41:47 GMT, Marius Hanl wrote: >> This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. >> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. >> >> This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). > > Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: > > 8251481: Added jdk ticket reference in TreeTableCellTest + Grammar okay ------------- Marked as reviewed by fastegal (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/716 From mhanl at openjdk.java.net Wed Feb 2 12:38:08 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 2 Feb 2022 12:38:08 GMT Subject: Integrated: 8251481: TableCell accessing row: NPE on auto-sizing In-Reply-To: References: Message-ID: <3MUq5mFctJuqj4G4gFBnst0JrHJ0t16CCeqzS2wIWxw=.e729aa81-3f79-4cbd-8ab1-d4eaafa01eb7@github.com> On Fri, 14 Jan 2022 00:04:49 GMT, Marius Hanl wrote: > This PR will fix a simple NPE which may happens when using the `TableRow` inside a `TableCell` during the initial auto sizing. > In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will return null and it is not possible to e.g. access the row item. > > This is fixed by adding the `TableRow` in the `resizeColumnToFitContent` method, similar as it is already done for the `TreeTableView` (`TreeTableRow`). This pull request has now been integrated. Changeset: 59cd8ec2 Author: Marius Hanl Committer: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/59cd8ec2d6a221a19ac4eb3a26f65535766410cc Stats: 52 lines in 3 files changed: 49 ins; 0 del; 3 mod 8251481: TableCell accessing row: NPE on auto-sizing Reviewed-by: fastegal ------------- PR: https://git.openjdk.java.net/jfx/pull/716 From kcr at openjdk.java.net Wed Feb 2 12:49:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Feb 2022 12:49:16 GMT Subject: RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: <2AAFXim3oetr_xME79GCKcntVJt33-JxhssZNfzZfzU=.0dd25be1-ca33-4e33-a77f-949ebdb4bdfd@github.com> On Wed, 2 Feb 2022 07:34:55 GMT, Ambarish Rapte wrote: > Update JavaFX WebKit to GTK WebKit 2.34 (613.1). > > Verified the updated version build, tests run and sanity testing. > This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. > It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) One other thing to note about this update is that WebKit 613.1 will not compile with Visual Studio 2017 -- it requires VS 2019. This is similar to the previous 612.1 update, [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), where a follow-on fix, [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), was needed. I filed a similar bug this time: [JDK-8278983](https://bugs.openjdk.java.net/browse/JDK-8278983): WebKit 613.1 build fails with Visual Studio 2017 but it doesn't seem so straight-forward. We are likely at the point where we need to require VS 2019 to build (I note that WebKit itself has required VS 2019 for about 1.5 years). In order to eventually backport this to JavaFX 11, we will need to solve a long-standing problem when `jlink`ing the JavaFX jmods into a JDK that was built with an earlier version of the Visual Studio compiler than the one used to build JavaFX. I filed the following to track this: [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089): JavaFX built with VS2019 and jlinked into JDK 11.x fails to start ------------- PR: https://git.openjdk.java.net/jfx/pull/723 From johan.vos at gluonhq.com Wed Feb 2 12:53:58 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 2 Feb 2022 13:53:58 +0100 Subject: RFR: 8278980: Update WebKit to 613.1 In-Reply-To: <2AAFXim3oetr_xME79GCKcntVJt33-JxhssZNfzZfzU=.0dd25be1-ca33-4e33-a77f-949ebdb4bdfd@github.com> References: <2AAFXim3oetr_xME79GCKcntVJt33-JxhssZNfzZfzU=.0dd25be1-ca33-4e33-a77f-949ebdb4bdfd@github.com> Message-ID: Hi Kevin, Thanks for filing [JDK-8281089]. I think this is the way forward indeed. The longer we delay moving to VS 2019, the more problems we can expect. I'll build/test the WebKit 613.1 as well. - Johan On Wed, Feb 2, 2022 at 1:49 PM Kevin Rushforth wrote: > On Wed, 2 Feb 2022 07:34:55 GMT, Ambarish Rapte > wrote: > > > Update JavaFX WebKit to GTK WebKit 2.34 (613.1). > > > > Verified the updated version build, tests run and sanity testing. > > This does not cause any issues except a unit test failure > `IrresponsiveScriptTest`. > > It is recorded and ignored using [JDK-8280421]( > https://bugs.openjdk.java.net/browse/JDK-8280421) > > One other thing to note about this update is that WebKit 613.1 will not > compile with Visual Studio 2017 -- it requires VS 2019. This is similar to > the previous 612.1 update, [JDK-8268849]( > https://bugs.openjdk.java.net/browse/JDK-8268849), where a follow-on fix, > [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), was > needed. I filed a similar bug this time: > > [JDK-8278983](https://bugs.openjdk.java.net/browse/JDK-8278983): WebKit > 613.1 build fails with Visual Studio 2017 > > but it doesn't seem so straight-forward. We are likely at the point where > we need to require VS 2019 to build (I note that WebKit itself has required > VS 2019 for about 1.5 years). In order to eventually backport this to > JavaFX 11, we will need to solve a long-standing problem when `jlink`ing > the JavaFX jmods into a JDK that was built with an earlier version of the > Visual Studio compiler than the one used to build JavaFX. I filed the > following to track this: > > [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089): JavaFX > built with VS2019 and jlinked into JDK 11.x fails to start > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/723 > From duke at openjdk.java.net Wed Feb 2 13:46:09 2022 From: duke at openjdk.java.net (yosbits) Date: Wed, 2 Feb 2022 13:46:09 GMT Subject: RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: <7ZP9_dhGrsqeCFi4LHttzm_2_nT4KVm2yVXW0exOrLg=.ed6d70a3-6794-4ce3-bc81-6b6383da52ac@github.com> On Wed, 2 Feb 2022 07:34:55 GMT, Ambarish Rapte wrote: > Update JavaFX WebKit to GTK WebKit 2.34 (613.1). > > Verified the updated version build, tests run and sanity testing. > This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. > It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) You may have noticed ... The change file contains changes that are not related to the WebKit upgrade. It looks like you're reverting to an older version. ------------- PR: https://git.openjdk.java.net/jfx/pull/723 From kcr at openjdk.java.net Wed Feb 2 13:54:22 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Feb 2022 13:54:22 GMT Subject: RFR: 8278980: Update WebKit to 613.1 In-Reply-To: <7ZP9_dhGrsqeCFi4LHttzm_2_nT4KVm2yVXW0exOrLg=.ed6d70a3-6794-4ce3-bc81-6b6383da52ac@github.com> References: <7ZP9_dhGrsqeCFi4LHttzm_2_nT4KVm2yVXW0exOrLg=.ed6d70a3-6794-4ce3-bc81-6b6383da52ac@github.com> Message-ID: On Wed, 2 Feb 2022 13:42:53 GMT, yosbits wrote: > The change file contains changes that are not related to the WebKit upgrade. Thanks for pointing this out! It looks like the patch was applied incorrectly. @arapte please fix this. ------------- PR: https://git.openjdk.java.net/jfx/pull/723 From fastegal at openjdk.java.net Wed Feb 2 14:27:40 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 2 Feb 2022 14:27:40 GMT Subject: RFR: 8187309: TreeCell must not change tree's data Message-ID: Issue was TreeView commit editing implementation violated the spec'ed mechanism: - no default commit handler on TreeView - TreeCell modifying the data directly Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. ------------- Commit messages: - 8187309: TreeCell must not change tree's data Changes: https://git.openjdk.java.net/jfx/pull/724/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=724&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8187309 Stats: 95 lines in 4 files changed: 89 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/724.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/724/head:pull/724 PR: https://git.openjdk.java.net/jfx/pull/724 From arapte at openjdk.java.net Wed Feb 2 15:29:51 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 2 Feb 2022 15:29:51 GMT Subject: RFR: 8278980: Update WebKit to 613.1 [v2] In-Reply-To: References: Message-ID: > Update JavaFX WebKit to GTK WebKit 2.34 (613.1). > > Verified the updated version build, tests run and sanity testing. > This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. > It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: Restore commits that were mistakenly reverted. 8279013: ES2Pipeline fails to detect AMD vega20 graphics card 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning 8277122: SplitPane divider drag can hang the layout ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/723/files - new: https://git.openjdk.java.net/jfx/pull/723/files/b1cd88e7..ef730f84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=723&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=723&range=00-01 Stats: 121 lines in 5 files changed: 112 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/723.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/723/head:pull/723 PR: https://git.openjdk.java.net/jfx/pull/723 From arapte at openjdk.java.net Wed Feb 2 15:55:11 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 2 Feb 2022 15:55:11 GMT Subject: RFR: 8278980: Update WebKit to 613.1 In-Reply-To: <7ZP9_dhGrsqeCFi4LHttzm_2_nT4KVm2yVXW0exOrLg=.ed6d70a3-6794-4ce3-bc81-6b6383da52ac@github.com> References: <7ZP9_dhGrsqeCFi4LHttzm_2_nT4KVm2yVXW0exOrLg=.ed6d70a3-6794-4ce3-bc81-6b6383da52ac@github.com> Message-ID: On Wed, 2 Feb 2022 13:42:53 GMT, yosbits wrote: > You may have noticed ... The change file contains changes that are not related to the WebKit upgrade. It looks like you're reverting to an older version. Thanks for pointing it out. It is corrected now. Thanks @kevinrushforth for quick fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/723 From duke at openjdk.java.net Thu Feb 3 08:26:19 2022 From: duke at openjdk.java.net (Sebastian Stenzel) Date: Thu, 3 Feb 2022 08:26:19 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors In-Reply-To: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Wed, 1 Dec 2021 17:44:21 GMT, Martin Fox wrote: > Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. > > The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. What about usages of deprecated [NSWindowStyleMasks](https://developer.apple.com/documentation/appkit/nswindowstylemask) in `GlassWindow.m`? Shouldn't they get fixed as well? e.g. `NSTexturedBackgroundWindowMask` ? `NSWindowStyleMaskTexturedBackground` ------------- PR: https://git.openjdk.java.net/jfx/pull/687 From sebastian.stenzel at gmail.com Thu Feb 3 08:44:27 2022 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Thu, 3 Feb 2022 09:44:27 +0100 Subject: Suggestions for StageStyle.UNIFIED on macOS Message-ID: Hi, I did some experiments on macOS with StageStyle.UNIFIED and I think the L&F can be improved significantly. As I can not post attachments on this mailing lists, I uploaded some screenshots to [1]. What the screenshots don't tell: While the last one looks great, it doesn't allow moving the window (resizing works fine, though). I tried ... [window->nsWindow setMovableByWindowBackground:YES]; [window->nsWindow setMovable:YES]; ... but to no avail. In Cocoa this should work, but there might be some event handling related code that prevents the Scene from being treated as "background". Before wasting more time investigating this, would this even be a welcome change or is there a reason why the current implementation uses `NSTexturedBackgroundWindowMask` (which btw has been deprecated by now)? Best regards, Sebastian [1] https://gist.github.com/overheadhunter/29af68f4c4eb7de28dd4a3a4772a0f09 From aghaisas at openjdk.java.net Thu Feb 3 10:55:13 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 3 Feb 2022 10:55:13 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 19:36:45 GMT, Jose Pereda wrote: > This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. This looks good to me. @mstr2, I see that you have some made some suggestions on JBS. It would be great if you can review this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From fastegal at openjdk.java.net Thu Feb 3 11:45:38 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 3 Feb 2022 11:45:38 GMT Subject: RFR: 8280951: Testbug: fix commented asserts in XXViewTest.test_rt_29650 Message-ID: the issue was commented asserts in a test methods - they had been failing due to incorrect usage of registering an edit commit handler fix was to correct the registration and uncomment the assert (ListViewTest). For Tree/TableViewTest, had to adjust value access also (was: c&p from ListViewTest). Verified that the uncommented (corrected) asserts are failing/passing before/after fix of test bug ------------- Commit messages: - 8280951: Testbug: fix commented asserts in XXViewTest.test_rt_29650 Changes: https://git.openjdk.java.net/jfx/pull/725/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=725&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280951 Stats: 10 lines in 3 files changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/725.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/725/head:pull/725 PR: https://git.openjdk.java.net/jfx/pull/725 From kcr at openjdk.java.net Thu Feb 3 15:15:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Feb 2022 15:15:15 GMT Subject: RFR: 8278980: Update WebKit to 613.1 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 15:29:51 GMT, Ambarish Rapte wrote: >> Update JavaFX WebKit to GTK WebKit 2.34 (613.1). >> >> Verified the updated version build, tests run and sanity testing. >> This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. >> It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Restore commits that were mistakenly reverted. > > 8279013: ES2Pipeline fails to detect AMD vega20 graphics card > 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning > 8277122: SplitPane divider drag can hang the layout Testing complete on all platforms. Looks good. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/723 From zjx001202 at gmail.com Thu Feb 3 16:07:49 2022 From: zjx001202 at gmail.com (Glavo) Date: Fri, 4 Feb 2022 00:07:49 +0800 Subject: OpenJFX does not support fonts installed per-user on Windows 10/11 Message-ID: See JDK-8218914: Starting from build 17704, Windows 10 supports per-user font installation > (see > https://blogs.windows.com/windowsexperience/2018/06/27/announcing-windows-10-insider-preview-build-17704/#SgtQaWxPhRKl3mHR.97). > This installation method actually becomes default, while 'Install for all > users' action does it now the old (system-wide) way. > JRE currently doesn't recognize fonts installed in the new way. In > particular, GraphicsEnvironment.getAllFonts() doesn't list them, and such > fonts cannot be used by passing their name to Font constructor. Starting with Java 13, java.awt.GraphicsEnvironment::getAllFonts() can correctly find the font installed for the current user on Windows 10/11, but javafx.scene.text.Font is not yet supported. I checked the source code of OpenJFX and found that PrismFontFactory::getPlatformFontDirs() tried to distinguish between the system font folder and the user font folder. But unfortunately, PrismFontFactory::getFontPath() ( https://github.com/openjdk/jfx/blob/717cfdc85817aee57d5326e592340c849382d7a4/modules/javafx.graphics/src/main/native-font/fontpath.c#L68) doesn't seem to work properly. It always seems to find the same folder on windows. I didn't see the corresponding issue on JBS, and I don't have a JBS account. If you need to open an issue for this problem, please do it for me, thanks. From kcr at openjdk.java.net Thu Feb 3 16:32:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 3 Feb 2022 16:32:11 GMT Subject: RFR: 8280951: Testbug: fix commented asserts in XXViewTest.test_rt_29650 In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 11:38:55 GMT, Jeanette Winzenburg wrote: > the issue was commented asserts in a test methods - they had been failing due to incorrect usage of registering an edit commit handler > > fix was to correct the registration and uncomment the assert (ListViewTest). For Tree/TableViewTest, had to adjust value access also (was: c&p from ListViewTest). Verified that the uncommented (corrected) asserts are failing/passing before/after fix of test bug LGTM ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/725 From duke at openjdk.java.net Thu Feb 3 16:37:20 2022 From: duke at openjdk.java.net (Martin Fox) Date: Thu, 3 Feb 2022 16:37:20 GMT Subject: RFR: 8278021: Fix warnings in macOS glass native code and treat warnings as errors In-Reply-To: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> References: <3Tr4lhOlGVVrqdBCTLiumLpqQHEBU8lKhZtz-R1Eh-0=.c973b5f9-62ba-487a-a989-7910b09e3592@github.com> Message-ID: On Wed, 1 Dec 2021 17:44:21 GMT, Martin Fox wrote: > Turning on warnings-as-errors for the macOS glass native code. Deprecated declarations are excluded and still appear as warnings. > > In the code that tries to locate the application's dock icon there were three instances where `NO` was being passed into a method that required a pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that the path pointed to an existing file but not a directory. Since JavaFX has gone this long without screening out directories correctly I decided not to fix that behavior except at the very end. > > The only other changes of note are sending some NSNotification objects to delegate API's that require them even though we know they're ignored on the other side. It was the easiest way to get rid of the warning. Yes, the deprecated constants should be fixed as the code is updated. They weren't included in this PR because there's a lot of them and they're all cosmetic. ------------- PR: https://git.openjdk.java.net/jfx/pull/687 From kevin.rushforth at oracle.com Thu Feb 3 16:52:16 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 3 Feb 2022 08:52:16 -0800 Subject: JavaFX 18 is in Rampdown Phase Two (RDP2) Message-ID: To: OpenJFX Developers As a reminder, JavaFX 18 is now in Rampdown Phase Two (RDP2). [1] P1-P2 bugs, and test or doc bugs of any priority, can be fixed during RDP2. Explicit approval is needed for bug fixes (except for doc and test fixes), and all enhancements to go in to the jfx18 branch. The bar for approving bug fixes is appropriately high at this point. We do not anticipate approving any more enhancements. We will use the same rules for RDP2 that the JDK uses [2], with two modifications: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 18 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx18-fix-request", "openjfx18-fix-yes", "openjfx18-fix-no" and "openjfx18-fix-nmi", "openjfx18-enhancement-request", "openjfx18-enhancement-yes", "openjfx18-enhancement-no" and "openjfx18-enhancement-nmi" as corresponding labels. Note that if a fix is approved to integrate into jfx18 (with the appropriate approval label added by a lead), then the PR should be targeted to the jfx18 branch. There is no need to also create a separate PR to integrate it into master -- we will continue to periodically sync jfx18 --> master for the duration of the openjfx18 release. Now that we are in RDP2, the goal is to stabilize what is there, fixing bugs that are new in openjfx18. We need to be extremely careful about including anything that introduces risk. IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 19 as of today). This is usually what we want. A PR should be targeted to `jfx18` if, and only if, it is intended for OpenJFX 18 and meets the criteria for the current rampdown phase (we're in RDP2 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx18`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 19. Reviewers also need to be extra careful when reviewing PRs targeted to jfx18 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-November/032657.html [2] http://openjdk.java.net/jeps/3 From fastegal at openjdk.java.net Thu Feb 3 16:56:24 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 3 Feb 2022 16:56:24 GMT Subject: Integrated: 8280951: Testbug: fix commented asserts in XXViewTest.test_rt_29650 In-Reply-To: References: Message-ID: On Thu, 3 Feb 2022 11:38:55 GMT, Jeanette Winzenburg wrote: > the issue was commented asserts in a test methods - they had been failing due to incorrect usage of registering an edit commit handler > > fix was to correct the registration and uncomment the assert (ListViewTest). For Tree/TableViewTest, had to adjust value access also (was: c&p from ListViewTest). Verified that the uncommented (corrected) asserts are failing/passing before/after fix of test bug This pull request has now been integrated. Changeset: 929e7c92 Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/929e7c9217ff7ea04f9bb31bd5c1bf7d74086752 Stats: 10 lines in 3 files changed: 0 ins; 3 del; 7 mod 8280951: Testbug: fix commented asserts in XXViewTest.test_rt_29650 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/725 From martin at martinfox.com Thu Feb 3 19:55:12 2022 From: martin at martinfox.com (Martin Fox) Date: Thu, 3 Feb 2022 11:55:12 -0800 Subject: Suggestions for StageStyle.UNIFIED on macOS In-Reply-To: References: Message-ID: <827F518D-F761-4E93-8808-B02EC9A42141@martinfox.com> I took a look at this and discovered that UNIFIED doesn?t really work on any platform. It was never supported on Linux, the Mac implementation doesn?t really unify anything, and Windows is broken (see JDK-8154847 ). In that bug report it?s suggested that UNIFIED be deprecated. I don?t think the UNIFIED API was ever complete. For example, I don?t see a way of querying the system to discover the location of the OS window controls so you can position your JavaFX controls appropriately. Getting this right on the Mac would require some plumbing. We would need an API so we know which JavaFX controls are supposed to be in the unified title bar area so we can get the hit-testing right to enable dragging, title bar double-clicks, etc. I could imagine a new control that you could wrap around an existing control (like a Toolbar) that would handle the hit-testing and positioning correctly. I?m fuzzier on what it would take on Windows and there?s still the drawing problems to sort out. Would be nice to have, the unified look is ascendant. From jvos at openjdk.java.net Fri Feb 4 08:57:17 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Fri, 4 Feb 2022 08:57:17 GMT Subject: RFR: 8278980: Update WebKit to 613.1 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 15:29:51 GMT, Ambarish Rapte wrote: >> Update JavaFX WebKit to GTK WebKit 2.34 (613.1). >> >> Verified the updated version build, tests run and sanity testing. >> This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. >> It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Restore commits that were mistakenly reverted. > > 8279013: ES2Pipeline fails to detect AMD vega20 graphics card > 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning > 8277122: SplitPane divider drag can hang the layout builds on all platforms, basic tests are ok. We should do an EA release soon after this is merged, so we can have more testers. ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/723 From aghaisas at openjdk.java.net Fri Feb 4 10:42:12 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 4 Feb 2022 10:42:12 GMT Subject: RFR: 8278980: Update WebKit to 613.1 [v2] In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 15:29:51 GMT, Ambarish Rapte wrote: >> Update JavaFX WebKit to GTK WebKit 2.34 (613.1). >> >> Verified the updated version build, tests run and sanity testing. >> This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. >> It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > Restore commits that were mistakenly reverted. > > 8279013: ES2Pipeline fails to detect AMD vega20 graphics card > 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning > 8277122: SplitPane divider drag can hang the layout Marked as reviewed by aghaisas (Reviewer). I have tested on macOS and Windows. No new issue observed. ------------- PR: https://git.openjdk.java.net/jfx/pull/723 From almatvee at openjdk.java.net Fri Feb 4 11:30:31 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 4 Feb 2022 11:30:31 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming Message-ID: - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. - Added support for elementary AAC streams without any container for audio only streams. - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. ------------- Commit messages: - 8277309: Add support for H.265/HEVC to HTTP Live Streaming Changes: https://git.openjdk.java.net/jfx/pull/726/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=726&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277309 Stats: 2637 lines in 27 files changed: 2343 ins; 126 del; 168 mod Patch: https://git.openjdk.java.net/jfx/pull/726.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/726/head:pull/726 PR: https://git.openjdk.java.net/jfx/pull/726 From arapte at openjdk.java.net Fri Feb 4 12:29:24 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 4 Feb 2022 12:29:24 GMT Subject: Integrated: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 07:34:55 GMT, Ambarish Rapte wrote: > Update JavaFX WebKit to GTK WebKit 2.34 (613.1). > > Verified the updated version build, tests run and sanity testing. > This does not cause any issues except a unit test failure `IrresponsiveScriptTest`. > It is recorded and ignored using [JDK-8280421](https://bugs.openjdk.java.net/browse/JDK-8280421) This pull request has now been integrated. Changeset: 6f28d912 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod 8278980: Update WebKit to 613.1 Co-authored-by: Ajit Ghaisas Co-authored-by: Jay Bhaskar Co-authored-by: Kevin Rushforth Reviewed-by: kcr, jvos, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/723 From duke at openjdk.java.net Fri Feb 4 17:22:32 2022 From: duke at openjdk.java.net (yosbits) Date: Fri, 4 Feb 2022 17:22:32 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. Why not use BitSet instead of ArrayList? ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From mstrauss at openjdk.java.net Fri Feb 4 17:36:21 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 4 Feb 2022 17:36:21 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 19:36:45 GMT, Jose Pereda wrote: > This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java line 172: > 170: .map(TablePositionBase::getRow) > 171: .filter(removeRowFilter) > 172: .distinct() Maybe `distinct` should be applied before `filter`. This can cut down the number of times the predicate is invoked (which iterates over all selected cells, so it may be a performance issue for large selections). ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From kcr at openjdk.java.net Fri Feb 4 17:52:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Feb 2022 17:52:18 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 17:19:36 GMT, yosbits wrote: > Why not use BitSet instead of ArrayList? Can you be more specific? The only use of `ArrayList` that I see in the patch is in code that uses a few already-existing lists. Changing that to some other data structure would be an unrelated change that seems out of scope for this fix. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From nlisker at openjdk.java.net Fri Feb 4 18:26:57 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 4 Feb 2022 18:26:57 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5] In-Reply-To: References: Message-ID: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: Changed description of ambient light ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/717/files - new: https://git.openjdk.java.net/jfx/pull/717/files/cae874d6..987a6165 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=717&range=03-04 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/717.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/717/head:pull/717 PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Fri Feb 4 18:26:57 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Fri, 4 Feb 2022 18:26:57 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5] In-Reply-To: References: <1HVL-H84XizlRUzvtFRxC0mNWA_fAsimBUsQElWAdpQ=.e79815e6-e372-440e-a90d-b069ce0d27e9@github.com> Message-ID: On Thu, 27 Jan 2022 19:01:32 GMT, Kevin Rushforth wrote: >> I think the description should focus on the meaning of the respective term in the lighting equation, and not on a non-technical analogy. In this case, the analogy is a bit misleading on several aspects, including the fact that ambient lighting is not dependent on an area being enclosed. Here's a suggestion: >> >> Ambient lights add a constant term to the amount of light reflected by each point on >> the surface of an object, thereby increasing the brightness of the object uniformly and >> independently of the orientation of its surfaces. It is often used to represent the base >> amount of illumination in a scene. > > I think the key aspects of an Ambient light are that: the light seems to come from all directions (and thus has no position or direction), and that it illuminates objects independently of the position or orientation of the object. > > I don't have a problem with also giving a real-world analogy if one can be found that makes it easier to understand without causing confusion. I tried to unify some of the points that were brought up. See if you would like more changes. ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From duke at openjdk.java.net Fri Feb 4 18:33:16 2022 From: duke at openjdk.java.net (yosbits) Date: Fri, 4 Feb 2022 18:33:16 GMT Subject: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java I noticed that in this change, ArrayList is rewritten as ArrayList<>. The BitSet rewrite needs some thought, so it might be a good idea to make it a separate issue. In the file I pointed out, it is used in many more places than the one I pointed out. ------------- PR: https://git.openjdk.java.net/jfx/pull/726 From kcr at openjdk.java.net Fri Feb 4 22:07:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Feb 2022 22:07:15 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5] In-Reply-To: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> References: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> Message-ID: <3jAAI2YqbpyhXe7wkz2qKi4E2L9wqngIkDAbMvIJ5Ko=.c8633410-1bde-4be6-b259-23095e762dab@github.com> On Fri, 4 Feb 2022 18:26:57 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Changed description of ambient light LGTM. I like your updated AmbientLight description. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/717 From duke at openjdk.java.net Sat Feb 5 04:23:02 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 04:23:02 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: Message-ID: <7jinFdMf7ajr7U8NKviXwUEcoXLfx9HQpimrribWBxQ=.53c24756-2427-4783-9044-2e48fd398585@github.com> > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar 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 'openjdk:master' into PRLocalstorage - Window.close(), Fix for localstoarge ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/12f97feb..73299577 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=00-01 Stats: 416909 lines in 6905 files changed: 234954 ins; 135768 del; 46187 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 07:36:59 2022 From: duke at openjdk.java.net (yosbits) Date: Sat, 5 Feb 2022 07:36:59 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 19:36:45 GMT, Jose Pereda wrote: > This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. Why not use IntPredicate? before ``` java public static void updateSelectedIndices(MultipleSelectionModelBase sm, ListChangeListener.Change> c, Predicate removeRowFilter) { after ``` java public static void updateSelectedIndices(MultipleSelectionModelBase sm, ListChangeListener.Change> c, IntPredicate removeRowFilter) { before ``` java .map(TablePositionBase::getRow) after ``` java .mapToInt(TablePositionBase::getRow) ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From duke at openjdk.java.net Sat Feb 5 07:37:16 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 07:37:16 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: On Fri, 28 Jan 2022 00:11:40 GMT, Kevin Rushforth wrote: >> Jay Bhaskar 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 'openjdk:master' into PRLocalstorage >> - Window.close(), Fix for localstoarge > > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved. > > Copyright should be a single year (2022) done > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 48: > >> 46: final WebEngine webEngine = getEngine(); >> 47: webEngine.setJavaScriptEnabled(true); >> 48: webEngine.setUserDataDirectory(new File("/tmp/java-store")); > > You should not hard-code /tmp/. You can either use a local subdirectory in the build dir (which some other tests do), or else you will need to use something like `Files.createTempDirectory("webstorage")`. If you use the latter, then you will need to worry about how to clean up after the test, so the former seems better. i think /tmp/java-store is ok, as it would not require cleanup > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 70: > >> 68: WebView view = getView(); >> 69: view.getEngine().executeScript("test_local_storage_set();"); >> 70: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); > > This will work, but it might be cleaner to add a JavaScript `getLocalStorage` method so you don't have to get it from a DOM element. The method webEngine.executeScript("localStorage;") returns JSObject and in to get data members we need to call js.getMember(...) , getMember is not available in our code base, so i used tring s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 80: > >> 78: submit(() -> { >> 79: WebView view = getView(); >> 80: view.getEngine().executeScript("delete_items();"); > > You need to set some items first before deleting them if you want it to be an effective test of this case. The test runs after testLocalStorageSet , so there would be items in localstorage ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 12:58:20 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 12:58:20 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: On Fri, 28 Jan 2022 00:10:31 GMT, Kevin Rushforth wrote: >> Jay Bhaskar 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 'openjdk:master' into PRLocalstorage >> - Window.close(), Fix for localstoarge > > modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 859: > >> 857: if (page->isClosing() && m_localStorage) >> 858: return m_localStorage.get(); >> 859: > > If you make the earlier modification I suggested, then you don't need this block. We must check if localstorage setting is disabled, then return nullptr first.,as below if (!page->settings().localStorageEnabled()) return nullptr; and there after the section if (page->isClosing() && m_localStorage) return m_localStorage.get(); would become as below if (m_localStorage) return m_localStorage.get(); ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 12:58:20 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 12:58:20 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: On Sat, 5 Feb 2022 12:51:58 GMT, Jay Bhaskar wrote: >> modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 859: >> >>> 857: if (page->isClosing() && m_localStorage) >>> 858: return m_localStorage.get(); >>> 859: >> >> If you make the earlier modification I suggested, then you don't need this block. > > We must check if localstorage setting is disabled, then return nullptr first.,as below > if (!page->settings().localStorageEnabled()) > return nullptr; > > and there after the section > if (page->isClosing() && m_localStorage) > return m_localStorage.get(); > would become as below > if (m_localStorage) > return m_localStorage.get(); in recent code base (webkit upgrade)the localstorage is false , @@ -1579,7 +1579,7 @@ NeedsSiteSpecificQuirks: WebKit: default: true WebCore: - default: false + default: true So , it needs to be enable also. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From lbourges at openjdk.java.net Sat Feb 5 14:33:18 2022 From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sat, 5 Feb 2022 14:33:18 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords Hi Kevin, I am running again MapBench tests to determine good conditions proving this DPQS patch has much benefits in real cases. I added a new TextPage (50 lines of long text) scene. I remember (2019) that dpqs rocks really when the edge density is high (200 to 1000 items to sort per scanline) but it can happen quite easily: - AA disabled => 8 times more crossings to sort at each scanline (the test case of the plot https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/marlin-0.9.4/diff-marlin-094-gain.png) - zoomed out scene so the all complex paths are really small that maximizes the density, like 1/8 ot 1/20 ... of course, the scene must contain long paths (many edges) like a complex polyline, polygon or text (as shape) @iaroslavski could you answer the IP / legal question ? More results soon, Laurent ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From kcr at openjdk.java.net Sat Feb 5 15:13:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Feb 2022 15:13:15 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: On Fri, 28 Jan 2022 00:09:11 GMT, Kevin Rushforth wrote: >> Jay Bhaskar 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 'openjdk:master' into PRLocalstorage >> - Window.close(), Fix for localstoarge > > modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 857: > >> 855: return m_localStorage.get(); >> 856: } >> 857: > > This will change the behavior for the case where page is null or where the page is valid, but not closing. I think you should partially revert this part of the fix, restoring it as follows: > > > if (m_localStorage) > return m_localStorage.get(); I still think you need to restore this block, but without the check for `isClosing`. > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 60: > >> 58: assertNotNull(webEngine.executeScript("localStorage;")); >> 59: getEngine().executeScript("window.close();"); >> 60: assertNotNull(webEngine.executeScript("localStorage;")); > > It seems useful to verify the contents by writing something before the window is closed, and then verifying that the same value can be read. Can you comment on this? ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Sat Feb 5 15:13:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Feb 2022 15:13:15 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: <0HlcVr-BYWv6WXudRZTbw0_M9scLYIDXtrJa7qlAUrQ=.15bc2539-96a8-4246-8613-c6ad5963bf54@github.com> On Sat, 5 Feb 2022 12:54:43 GMT, Jay Bhaskar wrote: >> We must check if localstorage setting is disabled, then return nullptr first.,as below >> if (!page->settings().localStorageEnabled()) >> return nullptr; >> >> and there after the section >> if (page->isClosing() && m_localStorage) >> return m_localStorage.get(); >> would become as below >> if (m_localStorage) >> return m_localStorage.get(); > > in recent code base (webkit upgrade)the localstorage is false , > @@ -1579,7 +1579,7 @@ NeedsSiteSpecificQuirks: > WebKit: > default: true > WebCore: > - default: false > + default: true > > So , it needs to be enable also. 1. My point was that if you initially check for `m_localStorage` being non-null, without the check for `isClosing` (see my earlier comment), then you don't need to check it here. 2. Regarding the enabling of local storage in WebCore, are you seeing any problems as a result of not having it enabled? ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Sat Feb 5 15:13:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Feb 2022 15:13:16 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: <_mP1ENMwlyz2c_6yEnLHZyV-wBx8DQ7EUbmsKdqqunY=.c0b75456-0e94-48e2-90e7-a70d4b912de9@github.com> On Sat, 5 Feb 2022 05:41:25 GMT, Jay Bhaskar wrote: >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2011, 2020, Oracle and/or its affiliates. All rights reserved. >> >> Copyright should be a single year (2022) > > done Did you forget to push the change? It doesn't show up in the PR. >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 48: >> >>> 46: final WebEngine webEngine = getEngine(); >>> 47: webEngine.setJavaScriptEnabled(true); >>> 48: webEngine.setUserDataDirectory(new File("/tmp/java-store")); >> >> You should not hard-code /tmp/. You can either use a local subdirectory in the build dir (which some other tests do), or else you will need to use something like `Files.createTempDirectory("webstorage")`. If you use the latter, then you will need to worry about how to clean up after the test, so the former seems better. > > i think /tmp/java-store is ok, as it would not require cleanup No, it's not OK for two reasons: 1. It prevents concurrent execution of tests from two different directories 2. The Java temp directory might be something other than "/tmp" on some systems. Best is to use a local subdir under the build directory. >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 70: >> >>> 68: WebView view = getView(); >>> 69: view.getEngine().executeScript("test_local_storage_set();"); >>> 70: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); >> >> This will work, but it might be cleaner to add a JavaScript `getLocalStorage` method so you don't have to get it from a DOM element. > > The method webEngine.executeScript("localStorage;") returns JSObject and in to get data members we need to call js.getMember(...) , getMember is not available in our code base, so i used tring s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); OK. You could also have gotten it by calling a JavaScript method that you provided, but if this works, then that's fine. >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 80: >> >>> 78: submit(() -> { >>> 79: WebView view = getView(); >>> 80: view.getEngine().executeScript("delete_items();"); >> >> You need to set some items first before deleting them if you want it to be an effective test of this case. > > The test runs after testLocalStorageSet , so there would be items in localstorage No, this is a common misconception when writing JUnit tests. The test execution order is _not_ guaranteed and will change. Each test method needs to run as if it were the first (or only) test. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 15:23:17 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 15:23:17 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: On Sat, 5 Feb 2022 15:02:09 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 60: >> >>> 58: assertNotNull(webEngine.executeScript("localStorage;")); >>> 59: getEngine().executeScript("window.close();"); >>> 60: assertNotNull(webEngine.executeScript("localStorage;")); >> >> It seems useful to verify the contents by writing something before the window is closed, and then verifying that the same value can be read. > > Can you comment on this? yes, your are right , i would change it ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 15:23:16 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 15:23:16 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: <0HlcVr-BYWv6WXudRZTbw0_M9scLYIDXtrJa7qlAUrQ=.15bc2539-96a8-4246-8613-c6ad5963bf54@github.com> References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> <0HlcVr-BYWv6WXudRZTbw0_M9scLYIDXtrJa7qlAUrQ=.15bc2539-96a8-4246-8613-c6ad5963bf54@github.com> Message-ID: On Sat, 5 Feb 2022 14:58:25 GMT, Kevin Rushforth wrote: >> in recent code base (webkit upgrade)the localstorage is false , >> @@ -1579,7 +1579,7 @@ NeedsSiteSpecificQuirks: >> WebKit: >> default: true >> WebCore: >> - default: false >> + default: true >> >> So , it needs to be enable also. > > 1. My point was that if you initially check for `m_localStorage` being non-null, without the check for `isClosing` (see my earlier comment), then you don't need to check it here. > > 2. Regarding the enabling of local storage in WebCore, are you seeing any problems as a result of not having it enabled? yes, in case of not enable , in any case localstorage would be null ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 15:23:17 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 15:23:17 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: <8XKudVF51JewV5rwJOqQgaL0PVlUVVm3o6wBcqXfQtw=.da376a7c-bc76-448b-acf0-63a32a5d0ba7@github.com> On Sat, 5 Feb 2022 15:17:46 GMT, Jay Bhaskar wrote: >> Can you comment on this? > > yes, your are right , i would change it i will test unit case again after your suggested chnage ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sat Feb 5 15:23:17 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 5 Feb 2022 15:23:17 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: <_mP1ENMwlyz2c_6yEnLHZyV-wBx8DQ7EUbmsKdqqunY=.c0b75456-0e94-48e2-90e7-a70d4b912de9@github.com> References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> <_mP1ENMwlyz2c_6yEnLHZyV-wBx8DQ7EUbmsKdqqunY=.c0b75456-0e94-48e2-90e7-a70d4b912de9@github.com> Message-ID: On Sat, 5 Feb 2022 15:04:37 GMT, Kevin Rushforth wrote: >> The test runs after testLocalStorageSet , so there would be items in localstorage > > No, this is a common misconception when writing JUnit tests. The test execution order is _not_ guaranteed and will change. Each test method needs to run as if it were the first (or only) test. i would change as suggested , test and then pushed the changes ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Sat Feb 5 15:28:20 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 5 Feb 2022 15:28:20 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> <0HlcVr-BYWv6WXudRZTbw0_M9scLYIDXtrJa7qlAUrQ=.15bc2539-96a8-4246-8613-c6ad5963bf54@github.com> Message-ID: On Sat, 5 Feb 2022 15:15:26 GMT, Jay Bhaskar wrote: >> 1. My point was that if you initially check for `m_localStorage` being non-null, without the check for `isClosing` (see my earlier comment), then you don't need to check it here. >> >> 2. Regarding the enabling of local storage in WebCore, are you seeing any problems as a result of not having it enabled? > > yes, in case of not enable , in any case localstorage would be null That's what I would have guessed, but since it seems to be working well, I'm puzzled. Are there cases where local storage is disabled when it should be enabled? ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 6 11:57:16 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 6 Feb 2022 11:57:16 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v2] In-Reply-To: <_mP1ENMwlyz2c_6yEnLHZyV-wBx8DQ7EUbmsKdqqunY=.c0b75456-0e94-48e2-90e7-a70d4b912de9@github.com> References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> <_mP1ENMwlyz2c_6yEnLHZyV-wBx8DQ7EUbmsKdqqunY=.c0b75456-0e94-48e2-90e7-a70d4b912de9@github.com> Message-ID: On Sat, 5 Feb 2022 15:01:37 GMT, Kevin Rushforth wrote: >> i think /tmp/java-store is ok, as it would not require cleanup > > No, it's not OK for two reasons: > > 1. It prevents concurrent execution of tests from two different directories > 2. The Java temp directory might be something other than "/tmp" on some systems. > > Best is to use a local subdir under the build directory. i am unable to find other test case which uses local sub-directory in the build dir so let me know i can use this String defaultBaseDir = System.getProperty("java.io.tmpdir"); webEngine.setUserDataDirectory(new File(defaultBaseDir + "localstorage") ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Mon Feb 7 08:14:50 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 7 Feb 2022 08:14:50 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: References: Message-ID: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with three additional commits since the last revision: - Change Dir Path and use local Dir and set data before clearing localstorage test - Merge branch 'PRLocalstorage' of https://github.com/jaybhaskar/jfx into PRLocalstorage - Merge branch 'master' into PRLocalstorage ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/73299577..a8647839 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=01-02 Stats: 78 lines in 3 files changed: 68 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Mon Feb 7 08:17:20 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 7 Feb 2022 08:17:20 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> <_mP1ENMwlyz2c_6yEnLHZyV-wBx8DQ7EUbmsKdqqunY=.c0b75456-0e94-48e2-90e7-a70d4b912de9@github.com> Message-ID: On Sun, 6 Feb 2022 11:54:14 GMT, Jay Bhaskar wrote: >> No, it's not OK for two reasons: >> >> 1. It prevents concurrent execution of tests from two different directories >> 2. The Java temp directory might be something other than "/tmp" on some systems. >> >> Best is to use a local subdir under the build directory. > > i am unable to find other test case which uses local sub-directory in the build dir so let me know i can use this > String defaultBaseDir = System.getProperty("java.io.tmpdir"); > webEngine.setUserDataDirectory(new File(defaultBaseDir + "localstorage") I have updated your suggestions and used local dir for setUserDataDirectory ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From jpereda at openjdk.java.net Mon Feb 7 10:14:13 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 7 Feb 2022 10:14:13 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected In-Reply-To: References: Message-ID: On Sat, 5 Feb 2022 05:08:54 GMT, yosbits wrote: >> This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. >> >> Two tests have been added as well, that fail without this PR and pass with it. > > Why not use IntPredicate? > > before > > ``` java > public static void updateSelectedIndices(MultipleSelectionModelBase sm, > ListChangeListener.Change> c, > Predicate removeRowFilter) { > > > after > > ``` java > public static void updateSelectedIndices(MultipleSelectionModelBase sm, > ListChangeListener.Change> c, > IntPredicate removeRowFilter) { > > > before > ``` java > .map(TablePositionBase::getRow) > > > after > ``` java > .mapToInt(TablePositionBase::getRow) @yososs Do you see any possible gain by using `IntPredicate` vs `Predicate? It changes the `Stream` to `IntStream`, and that needs an extra `.boxed()` operation (or alternatively an extra operation to transform the int array with `.collect(ArrayList::new, ArrayList::add, ArrayList::addAll)`). So I'm wondering if this is worthy? ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From jpereda at openjdk.java.net Mon Feb 7 10:24:01 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 7 Feb 2022 10:24:01 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v2] In-Reply-To: References: Message-ID: > This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. 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.java.net/jfx/pull/709/files - new: https://git.openjdk.java.net/jfx/pull/709/files/34491051..fe943d4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=709&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=709&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/709/head:pull/709 PR: https://git.openjdk.java.net/jfx/pull/709 From jpereda at openjdk.java.net Mon Feb 7 10:24:02 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 7 Feb 2022 10:24:02 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v2] In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 17:33:18 GMT, Michael Strau? 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/main/java/javafx/scene/control/ControlUtils.java line 172: > >> 170: .map(TablePositionBase::getRow) >> 171: .filter(removeRowFilter) >> 172: .distinct() > > Maybe `distinct` should be applied before `filter`. This can cut down the number of times the predicate is invoked (which iterates over all selected cells, so it may be a performance issue for large selections). Makes sense. Done ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From duke at openjdk.java.net Mon Feb 7 10:24:45 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Mon, 7 Feb 2022 10:24:45 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 Message-ID: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. Website : https://www.sqlite.org/index.html Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) Verified the updated version with unit tests and sanity testing. No issues are observed. ------------- Commit messages: - Remove trailing whitespaces - Update SQLite to 3.37.2 Changes: https://git.openjdk.java.net/jfx/pull/727/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=727&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280841 Stats: 22876 lines in 4 files changed: 11629 ins; 3597 del; 7650 mod Patch: https://git.openjdk.java.net/jfx/pull/727.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/727/head:pull/727 PR: https://git.openjdk.java.net/jfx/pull/727 From arapte at openjdk.java.net Mon Feb 7 10:31:14 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Feb 2022 10:31:14 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 17:30:55 GMT, Michael Strau? wrote: >> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: >> >> 1. If the specified image subtype is not supported, an exception will be thrown. >> 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: >> >> >> Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' >> >> >> Also, the javadoc of `javafx.scene.image.Image` incorrectly states: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> 95 * and the MIME type must either be empty or a subtype of the >> 96 * {@code image} type. >> >> However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". >> >> The solution is to fix the documentation: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> - 95 * and the MIME type must either be empty or a subtype of the >> - 96 * {@code image} type. >> + 95 * and the MIME type must be a subtype of the {@code image} type. >> + 96 * The MIME type must match the image format of the data contained in >> + 97 * the URL. In case of a mismatch between MIME type and image format, >> + 98 * the image will be loaded if the image format can be determined by >> + 99 * JavaFX, and a warning will be logged. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Don't let EOFException bubble up Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From aghaisas at openjdk.java.net Mon Feb 7 10:57:36 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 7 Feb 2022 10:57:36 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs Message-ID: This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. Changes done for all the Properties of the TabPane - - Moved the property description to be over the property field. - Removed the unnecessary docs on property setter/getter and Property method. ------------- Commit messages: - Fix Property javadocs Changes: https://git.openjdk.java.net/jfx/pull/728/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=728&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271085 Stats: 122 lines in 1 file changed: 17 ins; 97 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/728.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/728/head:pull/728 PR: https://git.openjdk.java.net/jfx/pull/728 From arapte at openjdk.java.net Mon Feb 7 11:21:18 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 7 Feb 2022 11:21:18 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5] In-Reply-To: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> References: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> Message-ID: On Fri, 4 Feb 2022 18:26:57 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Changed description of ambient light Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From thiago.sayao at gmail.com Mon Feb 7 13:20:22 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Mon, 7 Feb 2022 10:20:22 -0300 Subject: JavaFX with Python/JS Message-ID: Hi, Would it be possible to use JavaFx with python/graalvm ? Maybe javascript? Gluon, Would that not be a huge marketing opportunity? Write apps in python/js ? Cheers. From johan.vos at gluonhq.com Mon Feb 7 13:27:48 2022 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 7 Feb 2022 14:27:48 +0100 Subject: JavaFX with Python/JS In-Reply-To: References: Message-ID: Hi Thiago, Yes, that is possible, and I've done that years ago with some simple python code, that resulted in a array of numbers that can then be visualised with JavaFX. It is really cool indeed, but back then the Python support was limited (e.g. no numpy). As for huge marketing opportunity: the problem is most often that someone has to *do* the marketing. Which is typically harder/more expensive than doing the technical work. But from a pure technical point: it makes very much sense. - Johan On Mon, Feb 7, 2022 at 2:21 PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > Hi, > > Would it be possible to use JavaFx with python/graalvm ? > Maybe javascript? > > Gluon, > > Would that not be a huge marketing opportunity? Write apps in python/js ? > > Cheers. > From nlisker at openjdk.java.net Mon Feb 7 15:00:21 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 7 Feb 2022 15:00:21 GMT Subject: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5] In-Reply-To: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> References: <-XewN60UnsKv4zR3hTubfl8kcu36q3ZTJhQwBTRNZV8=.4a4589b3-b195-43c5-a0fe-bf0c25a0f656@github.com> Message-ID: On Fri, 4 Feb 2022 18:26:57 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional commit since the last revision: > > Changed description of ambient light Thanks for the reviews everyone! ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From nlisker at openjdk.java.net Mon Feb 7 15:00:21 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 7 Feb 2022 15:00:21 GMT Subject: [jfx18] Integrated: 8279345: Realign class docs of LightBase and subclasses In-Reply-To: References: Message-ID: On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote: > Now that the standard concrete light types were added, there is an opportunity to rearrange and rewrite some of the class docs. Here is a summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since different light types share characteristics. `LightBase` now contains a summary of its subtypes and all the explanations of the properties/characteristics of the lights divided into sections: Color, Scope, Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. This pull request has now been integrated. Changeset: ed399825 Author: Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/ed39982515e1f4399841ffd75849988ff651396d Stats: 152 lines in 5 files changed: 96 ins; 26 del; 30 mod 8279345: Realign class docs of LightBase and subclasses Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/717 From duke at openjdk.java.net Mon Feb 7 15:06:13 2022 From: duke at openjdk.java.net (yosbits) Date: Mon, 7 Feb 2022 15:06:13 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6] In-Reply-To: References: Message-ID: On Sat, 8 Jan 2022 17:30:55 GMT, Michael Strau? wrote: >> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: >> >> 1. If the specified image subtype is not supported, an exception will be thrown. >> 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: >> >> >> Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' >> >> >> Also, the javadoc of `javafx.scene.image.Image` incorrectly states: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> 95 * and the MIME type must either be empty or a subtype of the >> 96 * {@code image} type. >> >> However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". >> >> The solution is to fix the documentation: >> >> 94 * If a URL uses the "data" scheme, the data must be base64-encoded >> - 95 * and the MIME type must either be empty or a subtype of the >> - 96 * {@code image} type. >> + 95 * and the MIME type must be a subtype of the {@code image} type. >> + 96 * The MIME type must match the image format of the data contained in >> + 97 * the URL. In case of a mismatch between MIME type and image format, >> + 98 * the image will be loaded if the image format can be determined by >> + 99 * JavaFX, and a warning will be logged. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > Don't let EOFException bubble up At least the following method do not need to remove the static modifier, but they do. Is there any benefit? ``` java public int getNumBands(ImageType type) { ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From duke at openjdk.java.net Mon Feb 7 15:44:24 2022 From: duke at openjdk.java.net (yosbits) Date: Mon, 7 Feb 2022 15:44:24 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v2] In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 10:24:01 GMT, Jose Pereda wrote: >> This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. >> >> Two tests have been added as well, that fail without this PR and pass with it. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback from reviewer getRow () returns an int. It is more efficient to process the primitive as it is. The code below will be less boxing. Because filter and distinct are processes for primitives It can be done at high speed. ``` java final List removed = c.getRemoved().stream() .mapToInt(TablePositionBase::getRow) .distinct() .filter(removeRowFilter) .boxed() .peek(sm.selectedIndices::clear) .collect(Collectors.toList()); final int addedSize = (int)c.getAddedSubList().stream() .mapToInt(TablePositionBase::getRow) .distinct() .boxed() .peek(sm.selectedIndices::set) .count(); ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From kcr at openjdk.java.net Mon Feb 7 16:17:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Feb 2022 16:17:15 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. Since we are in rampdown (RDP2) for JavaFX 18, I'd like @arapte to review this also. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From nlisker at openjdk.java.net Mon Feb 7 16:29:18 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 7 Feb 2022 16:29:18 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. I'm reviewing this right now. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From kcr at openjdk.java.net Mon Feb 7 16:36:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Feb 2022 16:36:11 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. I looked at the first two properties, and they look fine. I'll do a detailed review of the rest, but I wanted to point out one thing first. See below. modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 188: > 186: * the TabPane will immediately update the location of the tabs to reflect > 187: * this.

> 188: * The default position for the tabs is {@code Side.Top}. Ordinarily we would use a `@defaultValue` tag here. In this case, you are just moving existing docs from one method to another, so it could be done in a follow-up bug. Can you file a follow-up bug? ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From duke at openjdk.java.net Mon Feb 7 17:02:15 2022 From: duke at openjdk.java.net (iaroslavski) Date: Mon, 7 Feb 2022 17:02:15 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords Hi all, I'm the dpqs author and I worked with Laurent, so the proposed dpqs patch is our own IP that we agree to contribute under OCA to both openjdk & openjfx projects. ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From mstrauss at openjdk.java.net Mon Feb 7 17:07:21 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 7 Feb 2022 17:07:21 GMT Subject: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6] In-Reply-To: References: Message-ID: <7zKBvAQaD-vZ4BLCRcxyYLdJ5tsOzvaaGt-F-nmwqo8=.8b750f7d-a009-49ec-835d-5ee646f80230@github.com> On Mon, 7 Feb 2022 15:03:07 GMT, yosbits wrote: > At least the following method do not need to remove the static modifier, but they do. Is there any benefit? > > ```java > public int getNumBands(ImageType type) { > ``` I think the fact that the method doesn't access any instance fields is an arbitrary implementation detail. Making the method non-static aligns its usage with all other methods, which can only be called on a instance reference. ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From mstrauss at openjdk.java.net Mon Feb 7 17:13:11 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 7 Feb 2022 17:13:11 GMT Subject: Integrated: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs In-Reply-To: References: Message-ID: On Mon, 22 Nov 2021 17:52:06 GMT, Michael Strau? wrote: > `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype specified for images encoded in data URIs. This should be improved as follows: > > 1. If the specified image subtype is not supported, an exception will be thrown. > 2. If the specified image subtype is supported, but the data contained in the URI is of a different (but also supported) image format, the image will be loaded and a warning will be logged. For example, if the MIME type is "image/jpeg", but the image data is PNG, the following warning will be generated: > > > Image format 'PNG' does not match MIME type 'image/jpeg' in URI 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC' > > > Also, the javadoc of `javafx.scene.image.Image` incorrectly states: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > 95 * and the MIME type must either be empty or a subtype of the > 96 * {@code image} type. > > However, omitting the MIME type of a data URI is specified to imply "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI` class is implemented according to this specification, trying to load an image without MIME type correctly fails with an `ImageStorageException`: "Unexpected MIME type: text". > > The solution is to fix the documentation: > > 94 * If a URL uses the "data" scheme, the data must be base64-encoded > - 95 * and the MIME type must either be empty or a subtype of the > - 96 * {@code image} type. > + 95 * and the MIME type must be a subtype of the {@code image} type. > + 96 * The MIME type must match the image format of the data contained in > + 97 * the URL. In case of a mismatch between MIME type and image format, > + 98 * the image will be loaded if the image format can be determined by > + 99 * JavaFX, and a warning will be logged. This pull request has now been integrated. Changeset: f326e78f Author: Michael Strau? Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/f326e78ffdfcbbc9085bc50a38e0b4454b757157 Stats: 266 lines in 16 files changed: 170 ins; 8 del; 88 mod 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/676 From kcr at openjdk.java.net Mon Feb 7 17:13:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Feb 2022 17:13:14 GMT Subject: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2] In-Reply-To: References: <4fgYcFUaRV6ni8Kj-_TL4YhCcVVBjNeK9gT5XSCzimc=.1cc862b6-afba-4470-91fa-a2e603ef1877@github.com> Message-ID: On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourg?s wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS 19.05 with many variants, improving almost-sorted datasets. We are collaborating to provide a complete Sort framework (15 algorithms, many various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourg?s has updated the pull request incrementally with one additional commit since the last revision: > > added test for huge polygon coords Thank you for confirming. ------------- PR: https://git.openjdk.java.net/jfx/pull/674 From mstrauss at openjdk.java.net Mon Feb 7 17:32:08 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 7 Feb 2022 17:32:08 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. Looks good to me. ------------- Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.java.net/jfx/pull/724 From nlisker at openjdk.java.net Mon Feb 7 18:07:15 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Mon, 7 Feb 2022 18:07:15 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. Moving the test to the property field and removing it from the methods looks good. I added some suggestions to touch up the docs a bit and correct some mistakes. modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 174: > 172: /** > 173: *

Sets the model used for tab selection. By changing the model you can alter > 174: * how the tabs are selected and which tabs are first or last.

This description is phrased like it's a setter. Probably The selection model used for selecting tabs. Changing the model alters how the tabs are selected and which tabs are first or last. (there's no need to the `

` either) modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 188: > 186: * the TabPane will immediately update the location of the tabs to reflect > 187: * this.

> 188: * The default position for the tabs is {@code Side.Top}. I would rephrase a bit: The position of the tabs in the {@code TabPane}. Changes to the value of this property immediately update the location of the tabs. @defaultValue {@code Side.Top} The 2nd sentence seems redundant anyway and I suggest to remove it. Unless otherwise specified, all value changes are applied immediately (only `Animation` properties come to mind that specify that the animation has to be stopped for the changes to take effect). modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 244: > 242: *

Refer to the {@link TabClosingPolicy} enumeration for further details.

> 243: * > 244: * The default closing policy is TabClosingPolicy.SELECTED_TAB * The default value should be in an `@defaultValue` annotation. * Missing `{@code }`s * The line "Refer to the {@link TabClosingPolicy}" is redundant I think since it's linked in the signature/definition, and if we want to keep it then an `@see` might be preferable. * "end-user's" (missing apostrophe) modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 270: > 268: * the graphic isn't rotated, resulting in it always appearing upright. If > 269: * rotateGraphic is set to {@code true}, the graphic will rotate such that it > 270: * rotates with the tab text.

* Missing `@code`s * I would rephrase the 2nd paragraph to be simpler: ``` If the value is {@code false}, the graphic isn't rotated, resulting in it always appearing upright. If it is {@code true}, the graphic is rotate with the tab text. ``` * `@defaultValue {@code false}` modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 295: > 293: * > 294: * This value can also be set via CSS using {@code -fx-tab-min-width}. > 295: *

I would write The minimum width of a tab in the TabPane. This can be used to limit the length of text in tabs to prevent truncation. Setting the same minimum and maximum widths will fix the width of the tab. It makes it clear that it applies to each tab individually (and not the total width of the tabs). The same applies for the other min/max height/width properties. The sentence "By default the min equals to the max." seems wrong. The `DEFAULT_TAB_MIN_WIDTH` constant is set to 0. It should also be in a `@defaultValue`. The CSS mention is good, bit I never saw it mentioned for properties before. Makes me wonder if we should add the CSS property as part of a property's description in general via the automated javadoc tool. modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 337: > 335: * > 336: * This value can also be set via CSS using {@code -fx-tab-max-width}. > 337: *

* "By default the min equals to the max." The default is `Double.MAX_VALUE`. * Comma before "the text will be truncated". modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 378: > 376: * > 377: * This value can also be set via CSS using {@code -fx-tab-min-height}. > 378: *

Same comments as for the width properties. modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 419: > 417: * > 418: * This value can also be set via CSS using {@code -fx-tab-max-height}. > 419: *

Same comments as for the width properties. modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 779: > 777: * The drag policy for the tabs. The policy can be changed dynamically. > 778: * > 779: * @defaultValue TabDragPolicy.FIXED I think that the 2nd sentence is redundant again. I would add an explanation like "Specifies if tabs can be reordered or not" to elaborate on what a "drag policy" is. Also, `{@code TabDragPolicy.FIXED}`. ------------- Changes requested by nlisker (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/728 From jpereda at openjdk.java.net Mon Feb 7 18:46:55 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Mon, 7 Feb 2022 18:46:55 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v3] In-Reply-To: References: Message-ID: > This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. 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.java.net/jfx/pull/709/files - new: https://git.openjdk.java.net/jfx/pull/709/files/fe943d4b..8e96bb3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=709&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=709&range=01-02 Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/709/head:pull/709 PR: https://git.openjdk.java.net/jfx/pull/709 From mstrauss at openjdk.java.net Mon Feb 7 22:13:16 2022 From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 7 Feb 2022 22:13:16 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v3] In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 18:46:55 GMT, Jose Pereda wrote: >> This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. >> >> Two tests have been added as well, that fail without this PR and pass with it. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback from reviewer Marked as reviewed by mstrauss (Author). ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From tsayao at openjdk.java.net Tue Feb 8 00:34:17 2022 From: tsayao at openjdk.java.net (Thiago Milczarek Sayao) Date: Tue, 8 Feb 2022 00:34:17 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7] In-Reply-To: References: <-MXyupqtuXdX-v1-O746rNnQkgHnNKaVRdJuuwPyUsg=.254a5ed2-fe40-4181-a78b-de9dd098fbe6@github.com> Message-ID: On Sat, 11 Dec 2021 00:32:06 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Minimize changes > > On my Ubuntu 20.04 VM the bug still happens about 1/2 the time with this fix. @kevinrushforth can you try this lastest version, please? ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From aghaisas at openjdk.java.net Tue Feb 8 09:56:12 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 8 Feb 2022 09:56:12 GMT Subject: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v3] In-Reply-To: References: Message-ID: <9XOTEbfPk1TUXxd6N5DGJFwK3jw5KcC-QT03AIBhxDo=.134a8fb8-000d-4090-97cf-7e6f08944086@github.com> On Mon, 7 Feb 2022 18:46:55 GMT, Jose Pereda wrote: >> This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. >> >> Two tests have been added as well, that fail without this PR and pass with it. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Address feedback from reviewer Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From arapte at openjdk.java.net Tue Feb 8 11:00:15 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 8 Feb 2022 11:00:15 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 In-Reply-To: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: On Fri, 4 Feb 2022 12:53:51 GMT, Hima Bindu Meda wrote: > Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. > > Website : https://www.sqlite.org/index.html > Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) > > Verified the updated version with unit tests and sanity testing. > No issues are observed. The source files match with https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip Sanity testing looks good. I would recommend to add UPDATING.txt to document the steps. You can refer: [libxml UPDATING.txt](https://github.com/openjdk/jfx/blob/f326e78ffdfcbbc9085bc50a38e0b4454b757157/modules/javafx.web/src/main/native/Source/ThirdParty/libxml/UPDATING.txt) , [icu UPDATING.txt](https://github.com/openjdk/jfx/blob/f326e78ffdfcbbc9085bc50a38e0b4454b757157/modules/javafx.web/src/main/native/Source/ThirdParty/icu/UPDATING.txt) ------------- PR: https://git.openjdk.java.net/jfx/pull/727 From duke at openjdk.java.net Tue Feb 8 11:50:30 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 8 Feb 2022 11:50:30 GMT Subject: RFR: 8269115: WebView paste event contains old data Message-ID: Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. ------------- Commit messages: - 8269115:WebView paste event contains old data Changes: https://git.openjdk.java.net/jfx/pull/729/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269115 Stats: 26 lines in 3 files changed: 12 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From mhanl at openjdk.java.net Tue Feb 8 12:55:21 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Tue, 8 Feb 2022 12:55:21 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: References: Message-ID: <2koW-Cjod6WIA0nBk1mWbvJx8E39fDrK17gSukl1b4k=.7aeb3ccd-d78c-4cdd-8646-c20c449e9795@github.com> On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. Looks good to me too. The commitEdit(..) method of TreeCell is now in sync with the other cells. Just left two minor comments. modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java line 944: > 942: } > 943: > 944: Very minor: Empty line modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java line 957: > 955: > 956: /** > 957: * Test test setup. Minor: I would rephrase that a bit. Something like: `Tests the cell editing setup`. ------------- Marked as reviewed by mhanl (Author). PR: https://git.openjdk.java.net/jfx/pull/724 From duke at openjdk.java.net Wed Feb 9 04:40:49 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Wed, 9 Feb 2022 04:40:49 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 [v2] In-Reply-To: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: > Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. > > Website : https://www.sqlite.org/index.html > Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) > > Verified the updated version with unit tests and sanity testing. > No issues are observed. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Create UPDATING.txt to explain SQLite version update ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/727/files - new: https://git.openjdk.java.net/jfx/pull/727/files/2fe0874d..de605fd2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=727&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=727&range=00-01 Stats: 34 lines in 1 file changed: 34 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/727.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/727/head:pull/727 PR: https://git.openjdk.java.net/jfx/pull/727 From jpereda at openjdk.java.net Wed Feb 9 08:45:12 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Wed, 9 Feb 2022 08:45:12 GMT Subject: Integrated: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected In-Reply-To: References: Message-ID: On Fri, 7 Jan 2022 19:36:45 GMT, Jose Pereda wrote: > This PR adds a predicate to TableView and TreeTableView selection models order to remove rows from the selection only when there are no selected cells in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. This pull request has now been integrated. Changeset: 590033f4 Author: Jose Pereda URL: https://git.openjdk.java.net/jfx/commit/590033f4cb2b5bbe02261a845c554dd08c7866ff Stats: 116 lines in 5 files changed: 111 ins; 0 del; 5 mod 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected Reviewed-by: mstrauss, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/709 From aghaisas at openjdk.java.net Wed Feb 9 09:33:15 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Feb 2022 09:33:15 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 16:17:32 GMT, Nir Lisker wrote: >> This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. >> >> Changes done for all the Properties of the TabPane - >> - Moved the property description to be over the property field. >> - Removed the unnecessary docs on property setter/getter and Property method. > > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 174: > >> 172: /** >> 173: *

Sets the model used for tab selection. By changing the model you can alter >> 174: * how the tabs are selected and which tabs are first or last.

> > This description is phrased like it's a setter. Probably > > The selection model used for selecting tabs. Changing the model alters > how the tabs are selected and which tabs are first or last. > > (there's no need to the `

` either) Fixed. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 188: > >> 186: * the TabPane will immediately update the location of the tabs to reflect >> 187: * this.

>> 188: * The default position for the tabs is {@code Side.Top}. > > I would rephrase a bit: > > The position of the tabs in the {@code TabPane}. Changes to the value of this property > immediately update the location of the tabs. > > @defaultValue {@code Side.Top} > > The 2nd sentence seems redundant anyway and I suggest to remove it. Unless otherwise specified, all value changes are applied immediately (only `Animation` properties come to mind that specify that the animation has to be stopped for the changes to take effect). I like the rephrased version. I prefer keeping the 2nd sentence in this case as it indicates a non-trivial visual update. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 244: > >> 242: *

Refer to the {@link TabClosingPolicy} enumeration for further details.

>> 243: * >> 244: * The default closing policy is TabClosingPolicy.SELECTED_TAB > > * The default value should be in an `@defaultValue` annotation. > * Missing `{@code }`s > * The line "Refer to the {@link TabClosingPolicy}" is redundant I think since it's linked in the signature/definition, and if we want to keep it then an `@see` might be preferable. > * "end-user's" (missing apostrophe) Fixed points 1, 2 and 4. Regarding point 3 - I have removed the description regarding possible options and have kept only the line- `Refer to the {@link TabClosingPolicy} enumeration for further details.` Mentioning all the options here seems to be a duplication of Javadoc for enumeration TabClosingPolicy. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 270: > >> 268: * the graphic isn't rotated, resulting in it always appearing upright. If >> 269: * rotateGraphic is set to {@code true}, the graphic will rotate such that it >> 270: * rotates with the tab text.

> > * Missing `@code`s > * I would rephrase the 2nd paragraph to be simpler: > ``` > If the value is {@code false}, the graphic isn't rotated, resulting in it always appearing upright. > If it is {@code true}, the graphic is rotate with the tab text. > ``` > * `@defaultValue {@code false}` Fixed. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 295: > >> 293: * >> 294: * This value can also be set via CSS using {@code -fx-tab-min-width}. >> 295: *

> > I would write > > The minimum width of a tab in the TabPane. This can be used to limit > the length of text in tabs to prevent truncation. Setting the same minimum > and maximum widths will fix the width of the tab. > > It makes it clear that it applies to each tab individually (and not the total width of the tabs). The same applies for the other min/max height/width properties. > > The sentence "By default the min equals to the max." seems wrong. The `DEFAULT_TAB_MIN_WIDTH` constant is set to 0. It should also be in a `@defaultValue`. > > The CSS mention is good, bit I never saw it mentioned for properties before. Makes me wonder if we should add the CSS property as part of a property's description in general via the automated javadoc tool. Good suggestion. Fixed. Regarding CSS mention for properties, I am not sure whether that can be automated. If there is a way to achieve it, I can file a separate bug to address it. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 337: > >> 335: * >> 336: * This value can also be set via CSS using {@code -fx-tab-max-width}. >> 337: *

> > * "By default the min equals to the max." The default is `Double.MAX_VALUE`. > * Comma before "the text will be truncated". Fixed. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 378: > >> 376: * >> 377: * This value can also be set via CSS using {@code -fx-tab-min-height}. >> 378: *

> > Same comments as for the width properties. Fixed. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 419: > >> 417: * >> 418: * This value can also be set via CSS using {@code -fx-tab-max-height}. >> 419: *

> > Same comments as for the width properties. Fixed. > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 779: > >> 777: * The drag policy for the tabs. The policy can be changed dynamically. >> 778: * >> 779: * @defaultValue TabDragPolicy.FIXED > > I think that the 2nd sentence is redundant again. I would add an explanation like "Specifies if tabs can be reordered or not" to elaborate on what a "drag policy" is. > > Also, `{@code TabDragPolicy.FIXED}`. Fixed. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From aghaisas at openjdk.java.net Wed Feb 9 09:33:15 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Feb 2022 09:33:15 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 16:24:46 GMT, Kevin Rushforth wrote: >> This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. >> >> Changes done for all the Properties of the TabPane - >> - Moved the property description to be over the property field. >> - Removed the unnecessary docs on property setter/getter and Property method. > > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 188: > >> 186: * the TabPane will immediately update the location of the tabs to reflect >> 187: * this.

>> 188: * The default position for the tabs is {@code Side.Top}. > > Ordinarily we would use a `@defaultValue` tag here. In this case, you are just moving existing docs from one method to another, so it could be done in a follow-up bug. Can you file a follow-up bug? I have fixed it as part of this PR itself. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From aghaisas at openjdk.java.net Wed Feb 9 09:39:46 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Feb 2022 09:39:46 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v2] In-Reply-To: References: Message-ID: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/728/files - new: https://git.openjdk.java.net/jfx/pull/728/files/31ae34d7..66630a39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=728&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=728&range=00-01 Stats: 59 lines in 1 file changed: 11 ins; 14 del; 34 mod Patch: https://git.openjdk.java.net/jfx/pull/728.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/728/head:pull/728 PR: https://git.openjdk.java.net/jfx/pull/728 From aghaisas at openjdk.java.net Wed Feb 9 11:02:17 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Feb 2022 11:02:17 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: References: Message-ID: <6ZPYrNzbzEqi-Knv9I4bMFXgjd1CImLDO2pgKSemUMY=.7d26a227-6d89-49c2-9e7e-226785cafc23@github.com> On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. modules/javafx.controls/src/main/java/javafx/scene/control/TreeView.java line 341: > 339: setFocusModel(new TreeViewFocusModel(this)); > 340: > 341: setOnEditCommit(DEFAULT_EDIT_COMMIT_HANDLER); You are adding the default edit commit handler to TreeView. Although it seems to be correct, this default handler is likely to be overwritten if the user code already has a setOnEditCommit() call. This is shown by the test_rt_29650() failure in TreeviewTest.java which you have corrected. The changes done in this PR makes TreeView similar to ListView and TableView in terms of having the default edit commit handler. Unfortunately, I do not see how can we avoid user code accidentally overwriting the default edit commit handler. Documenting this possibility seems to be the only way ahead. Any other idea? ------------- PR: https://git.openjdk.java.net/jfx/pull/724 From jose.pereda at gluonhq.com Wed Feb 9 12:20:29 2022 From: jose.pereda at gluonhq.com (=?UTF-8?B?Sm9zw6kgUGVyZWRh?=) Date: Wed, 9 Feb 2022 13:20:29 +0100 Subject: WebView, HTTP/2 and authentication Message-ID: Hi, With JDK 11 (or with com.sun.webkit.useHTTP2Loader=false) WebView defaults to the old HTTP 1.1 and via HttpURLConnection [2] it has access to basic and digest authentication. But since JDK 12+ (or with com.sun.webkit.useHTTP2Loader=true) WebView uses HTTP/2 and HttpClient [1], which doesn't provide any kind of built-in validation, as far as I know. As a quick test, adding: private final static HttpClient HTTP_CLIENT = AccessController.doPrivileged((PrivilegedAction) () -> HttpClient.newBuilder() .version(Version.HTTP_2) // this is the default .followRedirects(Redirect.NEVER) // WebCore handles redirection .connectTimeout(Duration.ofSeconds(30)) // FIXME: Add a property to control the timeout .cookieHandler(CookieHandler.getDefault()) + .authenticator(Authenticator.getDefault()) .build()); helps with getting at least basic authentication from the user's code with: Authenticator.setDefault(new Authenticator() { @Override protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication("$user", "$password".toCharArray()); } }); However, this doesn't work for digest authentication. A different (and probably better) approach would be adding headers to the HttpRequest [3] allowing any kind of authentication type: final var request = HttpRequest.newBuilder() .uri(uri) .headers(getRequestHeaders()) // headers from WebCore .headers(getCustomHeaders()) // headers set by us + .headers("Authorization", "$authenticationString") .version(Version.HTTP_2) // this is the default .method(method, getFormDataPublisher()) .build(); Note that none of the existing headers allow user customization, if I get it right. I understand that adding an API for this authorization header can be complex, but, without this (or any other alternative), how can WebView and HTTP2 can be used to address authentication? Thanks for any input on this, Jose [1] https://github.com/openjdk/jfx11u/blob/master/modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java#L105 [2] https://github.com/openjdk/jfx11u/blob/master/modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoader.java#L406 [3] https://github.com/openjdk/jfx11u/blob/master/modules/javafx.web/src/main/java/com/sun/webkit/network/HTTP2Loader.java#L396 -- From sebastian.stenzel at gmail.com Wed Feb 9 12:22:33 2022 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 9 Feb 2022 13:22:33 +0100 Subject: Suggestions for StageStyle.UNIFIED on macOS In-Reply-To: <827F518D-F761-4E93-8808-B02EC9A42141@martinfox.com> References: <827F518D-F761-4E93-8808-B02EC9A42141@martinfox.com> Message-ID: <6246220E-D396-48A5-A003-9111753EC1D6@gmail.com> Since there aren't any further comments on this, I assume there isn't much interest in this. Deprecating it is probably the right move, if it never worked as intended on any platform. I think I'm going to try and get this working as some kind of library instead. > On 3. Feb 2022, at 20:55, Martin Fox wrote: > > I took a look at this and discovered that UNIFIED doesn?t really work on any platform. It was never supported on Linux, the Mac implementation doesn?t really unify anything, and Windows is broken (see JDK-8154847 ). In that bug report it?s suggested that UNIFIED be deprecated. > > I don?t think the UNIFIED API was ever complete. For example, I don?t see a way of querying the system to discover the location of the OS window controls so you can position your JavaFX controls appropriately. > > Getting this right on the Mac would require some plumbing. We would need an API so we know which JavaFX controls are supposed to be in the unified title bar area so we can get the hit-testing right to enable dragging, title bar double-clicks, etc. I could imagine a new control that you could wrap around an existing control (like a Toolbar) that would handle the hit-testing and positioning correctly. I?m fuzzier on what it would take on Windows and there?s still the drawing problems to sort out. > > Would be nice to have, the unified look is ascendant. > > > From nlisker at openjdk.java.net Wed Feb 9 13:13:17 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 9 Feb 2022 13:13:17 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v2] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 09:39:46 GMT, Ajit Ghaisas wrote: >> This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. >> >> Changes done for all the Properties of the TabPane - >> - Moved the property description to be over the property field. >> - Removed the unnecessary docs on property setter/getter and Property method. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Looks good to me. I added 1 optional comment. modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 738: > 736: > 737: /** > 738: *

This specifies how the {@code TabPane} handles tab closing from an end-user's Since you are fixing the description here, can you remove the "This" in the beginning? ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From nlisker at openjdk.java.net Wed Feb 9 13:13:18 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 9 Feb 2022 13:13:18 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v2] In-Reply-To: References: Message-ID: <6jFx4ecfBvHnYQqW9UJ9Ay8bixf0azzeymOS5HMegt0=.45b11766-76b6-4519-be82-4b7ada5375ad@github.com> On Wed, 9 Feb 2022 07:32:20 GMT, Ajit Ghaisas wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 295: >> >>> 293: * >>> 294: * This value can also be set via CSS using {@code -fx-tab-min-width}. >>> 295: *

>> >> I would write >> >> The minimum width of a tab in the TabPane. This can be used to limit >> the length of text in tabs to prevent truncation. Setting the same minimum >> and maximum widths will fix the width of the tab. >> >> It makes it clear that it applies to each tab individually (and not the total width of the tabs). The same applies for the other min/max height/width properties. >> >> The sentence "By default the min equals to the max." seems wrong. The `DEFAULT_TAB_MIN_WIDTH` constant is set to 0. It should also be in a `@defaultValue`. >> >> The CSS mention is good, but I never saw it mentioned for properties before. Makes me wonder if we should add the CSS property as part of a property's description in general via the automated javadoc tool. > > Good suggestion. Fixed. > > Regarding CSS mention for properties, I am not sure whether that can be automated. If there is a way to achieve it, I can file a separate bug to address it. The CSS remark was me thinking out loud. I'll write about it in the mailing list since it's a whole new capability of the doc tool. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From kcr at openjdk.java.net Wed Feb 9 13:20:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Feb 2022 13:20:14 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v2] In-Reply-To: References: Message-ID: <7oDm_YhXKLnK5Mgwvr5MWBy6qoku-z-gU5idBAAS6JQ=.1728cbce-e451-4a99-bba0-5342642cf65f@github.com> On Wed, 9 Feb 2022 13:06:58 GMT, Nir Lisker wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 738: > >> 736: >> 737: /** >> 738: *

This specifies how the {@code TabPane} handles tab closing from an end-user's > > Since you are fixing the description here, can you remove the "This" in the beginning? Good suggestion. Also optional, you can remove the `

` since they are not needed for the initial paragraph. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From nlisker at openjdk.java.net Wed Feb 9 13:37:15 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 9 Feb 2022 13:37:15 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v2] In-Reply-To: <7oDm_YhXKLnK5Mgwvr5MWBy6qoku-z-gU5idBAAS6JQ=.1728cbce-e451-4a99-bba0-5342642cf65f@github.com> References: <7oDm_YhXKLnK5Mgwvr5MWBy6qoku-z-gU5idBAAS6JQ=.1728cbce-e451-4a99-bba0-5342642cf65f@github.com> Message-ID: On Wed, 9 Feb 2022 13:17:14 GMT, Kevin Rushforth wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 738: >> >>> 736: >>> 737: /** >>> 738: *

This specifies how the {@code TabPane} handles tab closing from an end-user's >> >> Since you are fixing the description here, can you remove the "This" in the beginning? > > Good suggestion. > > Also optional, you can remove the `

` since they are not needed for the initial paragraph. There are many redundant `

` tags in the property docs too if you want to deal with them as well for consistency (not important). ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From fastegal at openjdk.java.net Wed Feb 9 14:08:14 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Wed, 9 Feb 2022 14:08:14 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: <6ZPYrNzbzEqi-Knv9I4bMFXgjd1CImLDO2pgKSemUMY=.7d26a227-6d89-49c2-9e7e-226785cafc23@github.com> References: <6ZPYrNzbzEqi-Knv9I4bMFXgjd1CImLDO2pgKSemUMY=.7d26a227-6d89-49c2-9e7e-226785cafc23@github.com> Message-ID: On Wed, 9 Feb 2022 10:51:54 GMT, Ajit Ghaisas wrote: >> Issue was TreeView commit editing implementation violated the spec'ed mechanism: >> >> - no default commit handler on TreeView >> - TreeCell modifying the data directly >> >> Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. >> >> Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. > > modules/javafx.controls/src/main/java/javafx/scene/control/TreeView.java line 341: > >> 339: setFocusModel(new TreeViewFocusModel(this)); >> 340: >> 341: setOnEditCommit(DEFAULT_EDIT_COMMIT_HANDLER); > > You are adding the default edit commit handler to TreeView. Although it seems to be correct, this default handler is likely to be overwritten if the user code already has a setOnEditCommit() call. This is shown by the test_rt_29650() failure in TreeviewTest.java which you have corrected. > > The changes done in this PR makes TreeView similar to ListView and TableView in terms of having the default edit commit handler. > > Unfortunately, I do not see how can we avoid user code accidentally overwriting the default edit commit handler. Documenting this possibility seems to be the only way ahead. > Any other idea? Yes, the change might break application code, though that code would be buggy. Actually, the behavior as implemented now, _already is_ documented :) > It is very important to note that if you call setOnEditCommit(javafx.event.EventHandler) with your own EventHandler, then you will be removing the default handler. Unless you then handle the writeback to the property (or the relevant data source), nothing will happen. so: if they have a custom handler that doesn't save the data, they were violating the specification (though were getting away with it due to the bug). Personally, I think that we cannot keep backward compatibility to bugs. ------------- PR: https://git.openjdk.java.net/jfx/pull/724 From kcr at openjdk.java.net Wed Feb 9 14:57:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Feb 2022 14:57:14 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 [v2] In-Reply-To: References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: <8gElVT5IqErHFRAwRrX9VRL7aDJYwOZ7B5K-V31-T04=.417787ef-4dbf-49fb-a0e1-fa9ba071ada3@github.com> On Wed, 9 Feb 2022 04:40:49 GMT, Hima Bindu Meda wrote: >> Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. >> >> Website : https://www.sqlite.org/index.html >> Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) >> >> Verified the updated version with unit tests and sanity testing. >> No issues are observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Create UPDATING.txt to explain SQLite version update Sanity testing looks good. I left one comment on `UPDATING.txt`. modules/javafx.web/src/main/native/Source/ThirdParty/sqlite/UPDATING.txt line 29: > 27: 7.1 > cd modules/javafx.web/src/main/native/Source/ThirdParty/sqlite > 28: 7.2 Remove tabs from source files: > 29: > sudo apt install moreutils This section seems overly specific in terms of instructions. I think something something like the following, taken from `icu/UPDATING.txt`, might be sufficient: 7. Expand tabs and remove trailing white spaces from source files. ------------- PR: https://git.openjdk.java.net/jfx/pull/727 From nlisker at gmail.com Wed Feb 9 15:11:26 2022 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 9 Feb 2022 17:11:26 +0200 Subject: Mention of the CSS properties in JavaDocs Message-ID: Hi, When reviewing the docs changes to TabPane, I saw that some properties mention the CSS that is related to them. I was wondering if we could standardize it through something like a @css tag that is given the css string constant, or read automatically through the CssMetaData. As an example: /** * Specifies the maximum width of a tab. * ... * @css -fx-tab-max-width * @defaultValue 10 */ If the javadoc tool has access to these during its runtime, it can read the string by looking in the getCssMetaData() override of the property and then read the first argument of the CssMetaData constructor. Thoughts? From aghaisas at openjdk.java.net Wed Feb 9 18:27:55 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Feb 2022 18:27:55 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v3] In-Reply-To: References: Message-ID: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Address additional review comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/728/files - new: https://git.openjdk.java.net/jfx/pull/728/files/66630a39..537dcac1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=728&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=728&range=01-02 Stats: 25 lines in 1 file changed: 0 ins; 4 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/728.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/728/head:pull/728 PR: https://git.openjdk.java.net/jfx/pull/728 From aghaisas at openjdk.java.net Wed Feb 9 18:27:56 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 9 Feb 2022 18:27:56 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v2] In-Reply-To: References: <7oDm_YhXKLnK5Mgwvr5MWBy6qoku-z-gU5idBAAS6JQ=.1728cbce-e451-4a99-bba0-5342642cf65f@github.com> Message-ID: On Wed, 9 Feb 2022 13:34:13 GMT, Nir Lisker wrote: >> Good suggestion. >> >> Also optional, you can remove the `

` since they are not needed for the initial paragraph. > > There are many redundant `

` tags in the property docs too if you want to deal with them as well for consistency (not important). Fixed the description. Also, removed many redundant `

` tags. ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From nlisker at openjdk.java.net Wed Feb 9 18:42:16 2022 From: nlisker at openjdk.java.net (Nir Lisker) Date: Wed, 9 Feb 2022 18:42:16 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v3] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 18:27:55 GMT, Ajit Ghaisas wrote: >> This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. >> >> Changes done for all the Properties of the TabPane - >> - Moved the property description to be over the property field. >> - Removed the unnecessary docs on property setter/getter and Property method. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Address additional review comments Marked as reviewed by nlisker (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From arapte at openjdk.java.net Wed Feb 9 19:22:30 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 9 Feb 2022 19:22:30 GMT Subject: RFR: 8281459: WebKit 613.1 build broken on M1 Message-ID: This seems like a bad merge issue. There were duplicate copies of four methods in `MacroAssemblerARM64.h` which caused WebKit build failure on Mac M1 machines. Just removing the methods removes the error. With the changes in this PR, now the file `MacroAssemblerARM64.h` matches with the WebKit mainline. ------------- Commit messages: - MacOS M1 arch64 build error Changes: https://git.openjdk.java.net/jfx/pull/730/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=730&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281459 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/730.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/730/head:pull/730 PR: https://git.openjdk.java.net/jfx/pull/730 From jvos at openjdk.java.net Wed Feb 9 21:13:17 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 9 Feb 2022 21:13:17 GMT Subject: RFR: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches with the WebKit mainline. Thanks for the quick patch. This looks good om Linux-aarch64 (which suffered from the same issue). I'll do a test on M1 tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/730 From kcr at openjdk.java.net Thu Feb 10 00:09:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Feb 2022 00:09:16 GMT Subject: RFR: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches with the WebKit mainline. Looks good. Tested on macOS aarch64. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/730 From duke at openjdk.java.net Thu Feb 10 05:56:47 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Thu, 10 Feb 2022 05:56:47 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 [v3] In-Reply-To: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: > Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. > > Website : https://www.sqlite.org/index.html > Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) > > Verified the updated version with unit tests and sanity testing. > No issues are observed. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Accomodated PR comments ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/727/files - new: https://git.openjdk.java.net/jfx/pull/727/files/de605fd2..00e669ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=727&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=727&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/727.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/727/head:pull/727 PR: https://git.openjdk.java.net/jfx/pull/727 From duke at openjdk.java.net Thu Feb 10 06:01:07 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Thu, 10 Feb 2022 06:01:07 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 [v2] In-Reply-To: <8gElVT5IqErHFRAwRrX9VRL7aDJYwOZ7B5K-V31-T04=.417787ef-4dbf-49fb-a0e1-fa9ba071ada3@github.com> References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> <8gElVT5IqErHFRAwRrX9VRL7aDJYwOZ7B5K-V31-T04=.417787ef-4dbf-49fb-a0e1-fa9ba071ada3@github.com> Message-ID: On Wed, 9 Feb 2022 13:44:09 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Create UPDATING.txt to explain SQLite version update > > modules/javafx.web/src/main/native/Source/ThirdParty/sqlite/UPDATING.txt line 29: > >> 27: 7.1 > cd modules/javafx.web/src/main/native/Source/ThirdParty/sqlite >> 28: 7.2 Remove tabs from source files: >> 29: > sudo apt install moreutils > > This section seems overly specific in terms of instructions. I think something something like the following, taken from `icu/UPDATING.txt`, might be sufficient: > > 7. Expand tabs and remove trailing white spaces from source files. Updated as per the comments ------------- PR: https://git.openjdk.java.net/jfx/pull/727 From aghaisas at openjdk.java.net Thu Feb 10 06:01:09 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 10 Feb 2022 06:01:09 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/724 From aghaisas at openjdk.java.net Thu Feb 10 06:01:09 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 10 Feb 2022 06:01:09 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: References: <6ZPYrNzbzEqi-Knv9I4bMFXgjd1CImLDO2pgKSemUMY=.7d26a227-6d89-49c2-9e7e-226785cafc23@github.com> Message-ID: On Wed, 9 Feb 2022 14:04:55 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/TreeView.java line 341: >> >>> 339: setFocusModel(new TreeViewFocusModel(this)); >>> 340: >>> 341: setOnEditCommit(DEFAULT_EDIT_COMMIT_HANDLER); >> >> You are adding the default edit commit handler to TreeView. Although it seems to be correct, this default handler is likely to be overwritten if the user code already has a setOnEditCommit() call. This is shown by the test_rt_29650() failure in TreeviewTest.java which you have corrected. >> >> The changes done in this PR makes TreeView similar to ListView and TableView in terms of having the default edit commit handler. >> >> Unfortunately, I do not see how can we avoid user code accidentally overwriting the default edit commit handler. Documenting this possibility seems to be the only way ahead. >> Any other idea? > > Yes, the change might break application code, though that code would be buggy. Actually, the behavior as implemented now, _already is_ documented :) > >> It is very important to note that if you call setOnEditCommit(javafx.event.EventHandler) with your own EventHandler, then you will be removing the default handler. Unless you then handle the writeback to the property (or the relevant data source), nothing will happen. > > so: if they have a custom handler that doesn't save the data, they were violating the specification (though were getting away with it due to the bug). > > Personally, I think that we cannot keep backward compatibility to bugs. Thanks for the explanation. I see that it is already well documented. ------------- PR: https://git.openjdk.java.net/jfx/pull/724 From jvos at openjdk.java.net Thu Feb 10 08:19:07 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 10 Feb 2022 08:19:07 GMT Subject: RFR: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches with the WebKit mainline. Confirmed that this now builds fine on M1 ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/730 From jpereda at openjdk.java.net Thu Feb 10 10:16:36 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 10 Feb 2022 10:16:36 GMT Subject: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView [v3] In-Reply-To: References: Message-ID: <90A5xjTv1oMbNGvVnxxfc3eBj1CnW8jpguVwwvlajeQ=.9b33c3a6-f34b-4af0-84ba-c3b7e9862b38@github.com> > This PR converts the change's `from` field from a list of tablePositions into a list of selected indices of rows. > > It includes two tests for TableView and one for TreeTableView (the second test wasn't included due to an [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key navigation), that pass with this PR and fail without it. Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8273339-changefrom - Apply change only when cell selection is enabled - Convert change from list of tablePosition to list of rows ------------- Changes: https://git.openjdk.java.net/jfx/pull/710/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=710&range=02 Stats: 148 lines in 5 files changed: 141 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/710.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/710/head:pull/710 PR: https://git.openjdk.java.net/jfx/pull/710 From jpereda at openjdk.java.net Thu Feb 10 10:19:12 2022 From: jpereda at openjdk.java.net (Jose Pereda) Date: Thu, 10 Feb 2022 10:19:12 GMT Subject: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView [v2] In-Reply-To: <9UHlTn7GwMq-jxi39MMI4ntLgnIL8tRfAj26Przc4HU=.56d65c7b-8f72-4256-8f7b-705fecb22899@github.com> References: <9UHlTn7GwMq-jxi39MMI4ntLgnIL8tRfAj26Przc4HU=.56d65c7b-8f72-4256-8f7b-705fecb22899@github.com> Message-ID: On Fri, 14 Jan 2022 20:18:57 GMT, Jose Pereda wrote: >> This PR converts the change's `from` field from a list of tablePositions into a list of selected indices of rows. >> >> It includes two tests for TableView and one for TreeTableView (the second test wasn't included due to an [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key navigation), that pass with this PR and fail without it. > > Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: > > Apply change only when cell selection is enabled After #709 was integrated, there were merge conflicts. So I needed to merge from master to fix them. ------------- PR: https://git.openjdk.java.net/jfx/pull/710 From fastegal at openjdk.java.net Thu Feb 10 10:26:20 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 10 Feb 2022 10:26:20 GMT Subject: RFR: 8187309: TreeCell must not change tree's data In-Reply-To: <2koW-Cjod6WIA0nBk1mWbvJx8E39fDrK17gSukl1b4k=.7aeb3ccd-d78c-4cdd-8646-c20c449e9795@github.com> References: <2koW-Cjod6WIA0nBk1mWbvJx8E39fDrK17gSukl1b4k=.7aeb3ccd-d78c-4cdd-8646-c20c449e9795@github.com> Message-ID: On Tue, 8 Feb 2022 12:49:59 GMT, Marius Hanl wrote: >> Issue was TreeView commit editing implementation violated the spec'ed mechanism: >> >> - no default commit handler on TreeView >> - TreeCell modifying the data directly >> >> Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. >> >> Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java line 957: > >> 955: >> 956: /** >> 957: * Test test setup. > > Minor: I would rephrase that a bit. Something like: > `Tests the cell editing setup`. oops .. forgot to change this (and the other comment) before integration - sry ------------- PR: https://git.openjdk.java.net/jfx/pull/724 From fastegal at openjdk.java.net Thu Feb 10 10:26:20 2022 From: fastegal at openjdk.java.net (Jeanette Winzenburg) Date: Thu, 10 Feb 2022 10:26:20 GMT Subject: Integrated: 8187309: TreeCell must not change tree's data In-Reply-To: References: Message-ID: On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test for default commit that passed also before). Also fixed a test bug (incorrect registration of custom commit handler, see [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in TreeViewTest.test_rt_29650 to keep it passing. This pull request has now been integrated. Changeset: 4cf66d9f Author: Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/4cf66d9f6e96aab29c4c5fc72fa3e81a38a8d783 Stats: 95 lines in 4 files changed: 89 ins; 4 del; 2 mod 8187309: TreeCell must not change tree's data Reviewed-by: mstrauss, mhanl, aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/724 From duke at openjdk.java.net Thu Feb 10 11:41:32 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Thu, 10 Feb 2022 11:41:32 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView Message-ID: Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. Solution: Do not add thickness to the y position of end point of line. Start Point(x,y) ----------End Point(x + width, 0) ------------- Commit messages: - 8280020: Underline and line-through not straight in WebView Changes: https://git.openjdk.java.net/jfx/pull/731/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280020 Stats: 64 lines in 2 files changed: 63 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Thu Feb 10 13:10:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Feb 2022 13:10:15 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 [v3] In-Reply-To: References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: On Thu, 10 Feb 2022 05:56:47 GMT, Hima Bindu Meda wrote: >> Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. >> >> Website : https://www.sqlite.org/index.html >> Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) >> >> Verified the updated version with unit tests and sanity testing. >> No issues are observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Accomodated PR comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/727 From arapte at openjdk.java.net Thu Feb 10 13:28:11 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 10 Feb 2022 13:28:11 GMT Subject: Integrated: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches with the WebKit mainline. This pull request has now been integrated. Changeset: cdebc6cb Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/cdebc6cbafb579148b4addee44d307bd9739454b Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8281459: WebKit 613.1 build broken on M1 Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/730 From thiago.sayao at gmail.com Thu Feb 10 16:35:46 2022 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 10 Feb 2022 13:35:46 -0300 Subject: Use pure X11 backend for glass native In-Reply-To: References: Message-ID: Hi, So far, it seems native Xlib is a good fit: https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib It's still a big mess since I'm porting gradually while learning X11. -- Thiago. Em ter., 25 de jan. de 2022 ?s 12:06, Thiago Milczarek Say?o < thiago.sayao at gmail.com> escreveu: > > I put some thoughts on Linux glass backend and I think a pure Xlib backend > would be the ideal choice. > > Why? > > 1. X11/Xlib is supported by Xwayland, so it will work for decades > (probably). Having two backends to support for one platform would not be > ideal, so sticking with X11 would be the most "compatible choice". I will > probably be forever supported, since many applications rely on it. > > 2. Gdk4 moved away from being a "general toolkit layer" to being a "gtk4 > platform abstraction layer", so many things are missing such as: > - Moving windows; > - Drawing directly on a window; > - Relative window positioning; > - Changing window stacking; > - Pointer warping; > > Glass needs it, so it would be required to use a Xlib call anyways, since > Xwayland currently does not support those operations as well (except > through the X11 compatibility layer). > > Newer gtk3 versions deprecate a lot of functions and make a path to gtk4, > so even gtk3 is hard to use. > > 3. It would be possible to migrate from gtk3 to Xlib progressively since > Gdk3 with X11 backend translates to Xlib calls; > > 4. It would drop the gtk dependency (except for webkit-gtk). OS-specific > dialogs such as file save would be a problem (but not too hard to solve I > think). > > > References: > https://www.x.org/releases/current/doc/libX11/libX11/libX11.html > > https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/9 > https://discourse.gnome.org/t/custom-drawing-with-gtk4/7737 > > > From kcr at openjdk.java.net Thu Feb 10 20:10:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Feb 2022 20:10:13 GMT Subject: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v3] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 18:27:55 GMT, Ajit Ghaisas wrote: >> This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. >> >> Changes done for all the Properties of the TabPane - >> - Moved the property description to be over the property field. >> - Removed the unnecessary docs on property setter/getter and Property method. > > Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: > > Address additional review comments Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From kcr at openjdk.java.net Thu Feb 10 20:10:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Feb 2022 20:10:15 GMT Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9] In-Reply-To: References: Message-ID: <_tgPJBdoF7TwfDFHVMTnGA_wMV-vloehjPvifWZkJPg=.27ffd809-c731-455c-87f8-23eb0ec2fb2f@github.com> On Tue, 25 Jan 2022 23:57:09 GMT, Thiago Milczarek Sayao wrote: >> Found the problem thru this path: >> >> **WindowStage.java** >> >> final void handleFocusDisabled() { >> if (activeWindows.isEmpty()) { >> return; >> } >> WindowStage window = activeWindows.get(activeWindows.size() - 1); >> window.setIconified(false); >> window.requestToFront(); >> window.requestFocus(); >> } >> >> >> **glass_window.cpp** >> >> void WindowContextBase::process_focus(GdkEventFocus* event) { >> ... >> >> if (jwindow) { >> if (!event->in || isEnabled()) { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus, >> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST); >> CHECK_JNI_EXCEPTION(mainEnv) >> } else { >> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); >> CHECK_JNI_EXCEPTION(mainEnv) >> } >> } >> } >> >> >> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code). >> >> The docs states: >> >> /** >> * Enables or disables the window. >> * >> * A disabled window is unfocusable by definition. >> * Also, key or mouse events aren't generated for disabled windows. >> * >> * When a user tries to activate a disabled window, or the window gets >> * accidentally brought to the top of the stacking order, the window >> * generates the FOCUS_DISABLED window event. A Glass client should react >> * to this event and bring the currently active modal blocker of the >> * disabled window to top by calling blocker's minimize(false), toFront(), >> * and requestFocus() methods. It may also 'blink' the blocker window to >> * further attract user's attention. >> * >> ..... >> >> >> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window. >> >> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Capture event serial on process_key I'll review and test it on a couple different systems. ------------- PR: https://git.openjdk.java.net/jfx/pull/598 From kcr at openjdk.java.net Thu Feb 10 21:08:15 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Feb 2022 21:08:15 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) The fix looks good. The test needs to be different, since it doesn't actually test this fix. A good test will fail before the fix and pass after the fix. Since you need to render something, it needs to be a system test, probably using snapshot. See [PageFillTest.java](https://github.com/openjdk/jfx/tree/master/tests/system/src/test/java/test/javafx/scene/web/PageFillTest.java) for a recent example. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From aghaisas at openjdk.java.net Fri Feb 11 05:19:21 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 11 Feb 2022 05:19:21 GMT Subject: [jfx18] Integrated: 8271085: TabPane: Redundant API docs In-Reply-To: References: Message-ID: On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. This pull request has now been integrated. Changeset: 8b879eef Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/8b879eef96c9635a9ed16599344fa90568be2845 Stats: 173 lines in 1 file changed: 22 ins; 109 del; 42 mod 8271085: TabPane: Redundant API docs Reviewed-by: kcr, nlisker ------------- PR: https://git.openjdk.java.net/jfx/pull/728 From arapte at openjdk.java.net Fri Feb 11 05:58:17 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 11 Feb 2022 05:58:17 GMT Subject: RFR: 8280841: Update SQLite to 3.37.2 [v3] In-Reply-To: References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: On Thu, 10 Feb 2022 05:56:47 GMT, Hima Bindu Meda wrote: >> Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. >> >> Website : https://www.sqlite.org/index.html >> Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) >> >> Verified the updated version with unit tests and sanity testing. >> No issues are observed. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Accomodated PR comments Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/727 From duke at openjdk.java.net Fri Feb 11 06:45:20 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Fri, 11 Feb 2022 06:45:20 GMT Subject: Integrated: 8280841: Update SQLite to 3.37.2 In-Reply-To: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> References: <1I5BOzU6ba_vlD11sjrViCr2nXLuOquYRkbAjA48fvs=.13cc6b87-299d-4291-a8ce-1dde6f4be98a@github.com> Message-ID: On Fri, 4 Feb 2022 12:53:51 GMT, Hima Bindu Meda wrote: > Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. > > Website : https://www.sqlite.org/index.html > Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) > > Verified the updated version with unit tests and sanity testing. > No issues are observed. This pull request has now been integrated. Changeset: 6b7b463c Author: Hima Bindu Meda Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/6b7b463cd2286658ad7d236824ded9b1020329e7 Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod 8280841: Update SQLite to 3.37.2 Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/727 From duke at openjdk.java.net Fri Feb 11 09:09:14 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 11 Feb 2022 09:09:14 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) [PageFillTest.java](https://github.com/openjdk/jfx/tree/master/tests/system/src/test/java/test/javafx/scene/web/PageFillTest.java) this example only for taking snapshot and read color property. It will not help to test line drawing. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Fri Feb 11 11:38:11 2022 From: duke at openjdk.java.net (yosbits) Date: Fri, 11 Feb 2022 11:38:11 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Looking at the GraphicsContexCG source, we can see that the It looks correct to call fill rect instead of draw line. The GraphicsContexJava implementation seems to be the cause of the underline tilt. Also, there seems to be no need to call drawLine() multiple times by referring to last(). ``` cpp void GraphicsContextCG::drawLinesForText(const FloatPoint& point, float thickness, const DashArray& widths, bool printing, bool doubleLines, StrokeStyle strokeStyle) { if (!widths.size()) return; Color localStrokeColor(strokeColor()); FloatRect bounds = computeLineBoundsAndAntialiasingModeForText(FloatRect(point, FloatSize(widths.last(), thickness)), printing, localStrokeColor); if (bounds.isEmpty()) return; bool fillColorIsNotEqualToStrokeColor = fillColor() != localStrokeColor; Vector dashBounds; ASSERT(!(widths.size() % 2)); dashBounds.reserveInitialCapacity(dashBounds.size() / 2); float dashWidth = 0; switch (strokeStyle) { case DottedStroke: dashWidth = bounds.height(); break; case DashedStroke: dashWidth = 2 * bounds.height(); break; case SolidStroke: default: break; } for (size_t i = 0; i < widths.size(); i += 2) { auto left = widths[i]; auto width = widths[i+1] - widths[i]; if (!dashWidth) dashBounds.append(CGRectMake(bounds.x() + left, bounds.y(), width, bounds.height())); else { auto startParticle = static_cast(std::ceil(left / (2 * dashWidth))); auto endParticle = static_cast((left + width) / (2 * dashWidth)); for (auto j = startParticle; j < endParticle; ++j) dashBounds.append(CGRectMake(bounds.x() + j * 2 * dashWidth, bounds.y(), dashWidth, bounds.height())); } } if (doubleLines) { // The space between double underlines is equal to the height of the underline for (size_t i = 0; i < widths.size(); i += 2) dashBounds.append(CGRectMake(bounds.x() + widths[i], bounds.y() + 2 * bounds.height(), widths[i+1] - widths[i], bounds.height())); } if (fillColorIsNotEqualToStrokeColor) setCGFillColor(platformContext(), localStrokeColor); CGContextFillRects(platformContext(), dashBounds.data(), dashBounds.size()); if (fillColorIsNotEqualToStrokeColor) setCGFillColor(platformContext(), fillColor()); } ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Fri Feb 11 13:23:16 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 11 Feb 2022 13:23:16 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) void GraphicsContextCG::drawLinesForText(const FloatPoint& point, float thickness, const DashArray& widths, bool printing, bool doubleLines, StrokeStyle strokeStyle) { if (!widths.size()) return; Color localStrokeColor(strokeColor()); FloatRect bounds = computeLineBoundsAndAntialiasingModeForText(FloatRect(point, FloatSize(widths.last(), thickness)), printing, localStrokeColor); if (bounds.isEmpty()) ---------------------------------- computeLineBoundsAndAntialiasingModeForText this will return rect after considering thickness. The TextDecorationPainter::paintTextDecoration.. FloatRect underlineBoundingBox = m_context.computeUnderlineBoundsForText(rect, m_isPrinting); DashArray intersections = m_font.dashesForIntersectionsWithRect(textRun, textOrigin, underlineBoundingBox); DashArray boundaries = translateIntersectionPointsToSkipInkBoundaries(intersections, underlineBoundingBox.height(), rect.width()); ASSERT(!(boundaries.size() % 2)); // We don't use underlineBoundingBox here because drawLinesForText() will run computeUnderlineBoundsForText() internally. m_context.drawLinesForText(rect.location(), rect.height(), boundaries, m_isPrinting, style == TextDecorationStyle::Double, strokeStyle); This is already calculating underlineBoundingBox and generates boundaries. m_context.drawLinesForText(rect.location(), rect.height(), boundaries, m_isPrinting, style == TextDecorationStyle::Double, strokeStyle); rect.height() is passed as thickness. So, void GraphicsContextJava::drawLinesForText(const FloatPoint& origin, float thickness, const DashArray& widths, bool, bool, StrokeStyle stroke) { if (paintingDisabled()) return; for (const auto& width : widths) { // This is a workaround for http://bugs.webkit.org/show_bug.cgi?id=15659 StrokeStyle savedStrokeStyle = strokeStyle(); setStrokeStyle(stroke); // do not add thickness to y position of end point , as line should be straight to the origin FloatPoint endPoint = origin + FloatPoint(width, 0); drawLine( IntPoint(origin.x(), origin.y()), IntPoint(endPoint.x(), endPoint.y())); setStrokeStyle(savedStrokeStyle); } } To calculate end point , we should not add thickess to the end point. Let it draw with default thickness. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Fri Feb 11 13:43:12 2022 From: duke at openjdk.java.net (yosbits) Date: Fri, 11 Feb 2022 13:43:12 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) The discussion points are * Whether to use a simplified implementation that satisfies some of the specifications. * Whether to assume that lines will be broken. * * If you use the same origin, there is a waste that the line will be overlapped and the load will increase. Probably the following computational load * O(1/2*n*(n+1)) ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Fri Feb 11 14:23:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 14:23:18 GMT Subject: RFR: Merge jfx18 Message-ID: Merge `jfx18` into `master`. ------------- Commit messages: - Merge jfx18 - 8271085: TabPane: Redundant API docs - 8279345: Realign class docs of LightBase and subclasses The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/jfx/pull/732/files Stats: 325 lines in 6 files changed: 118 ins; 135 del; 72 mod Patch: https://git.openjdk.java.net/jfx/pull/732.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/732/head:pull/732 PR: https://git.openjdk.java.net/jfx/pull/732 From kcr at openjdk.java.net Fri Feb 11 14:33:07 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 14:33:07 GMT Subject: Integrated: Merge jfx18 In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 14:19:08 GMT, Kevin Rushforth wrote: > Merge `jfx18` into `master`. This pull request has now been integrated. Changeset: 2561e313 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/2561e3137f955ba151a84ae49bed683b96280406 Stats: 325 lines in 6 files changed: 118 ins; 135 del; 72 mod Merge ------------- PR: https://git.openjdk.java.net/jfx/pull/732 From kcr at openjdk.java.net Fri Feb 11 16:53:32 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 16:53:32 GMT Subject: [jfx17u] RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Message-ID: Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. ------------- Commit messages: - 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Changes: https://git.openjdk.java.net/jfx17u/pull/30/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=30&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277457 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx17u/pull/30.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/30/head:pull/30 PR: https://git.openjdk.java.net/jfx17u/pull/30 From kcr at openjdk.java.net Fri Feb 11 16:58:31 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 16:58:31 GMT Subject: [jfx17u] RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS Message-ID: Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. ------------- Commit messages: - 8278260: JavaFX shared libraries not stripped on Linux or macOS Changes: https://git.openjdk.java.net/jfx17u/pull/31/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=31&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278260 Stats: 68 lines in 3 files changed: 65 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx17u/pull/31.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/31/head:pull/31 PR: https://git.openjdk.java.net/jfx17u/pull/31 From kcr at openjdk.java.net Fri Feb 11 16:58:34 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 16:58:34 GMT Subject: [jfx17u] RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog Message-ID: <_Yj3f9p-TDzkG6iio2gCHBlPRITMgzgOJmW2xOwRSJk=.1baf6e66-6b2b-4d75-8f34-5e0ed1ef8fc9@github.com> Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. ------------- Commit messages: - 8242544: CMD+ENTER key event crashes the application when invoked on dialog Changes: https://git.openjdk.java.net/jfx17u/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=32&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242544 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx17u/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/32/head:pull/32 PR: https://git.openjdk.java.net/jfx17u/pull/32 From fastegal at swingempire.de Fri Feb 11 17:03:14 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Fri, 11 Feb 2022 18:03:14 +0100 Subject: Sneak preview: cell edit api to support commit-on-focusLost Message-ID: <20220211180314.Horde.n4MVwEW-gUC9KEIDCi4XJg3@webmail.df.eu> Hi folks, after fixing a bunch of edit-related issues, time feels right for nudging elephant out of the room :) Which is the bigger goal of supporting commit-on-focusLost. Working on a PoC (ListView/-Cell only) in a branch of my fork https://github.com/kleopatra/jfx/tree/dokeep-edit-api-editstate with an overview of suggested changes https://github.com/kleopatra/swingempire-fx/wiki/CellEditAPI and a example driver as gist https://gist.github.com/kleopatra/447344183e017537c21f7905a062396d Still rough, but working: all current unit tests still passing (a bunch of my own not, and the new api is barely tested) and many of the requested requirements can be implemented (see code in the example and the table of use-cases in the overview) Any feedback - for the good or for the bad - highly welcome :) -- Jeanette From kcr at openjdk.java.net Fri Feb 11 17:24:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 17:24:11 GMT Subject: [jfx17u] RFR: 8278980: Update WebKit to 613.1 Message-ID: Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. ------------- Commit messages: - 8278980: Update WebKit to 613.1 Changes: https://git.openjdk.java.net/jfx17u/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=33&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278980 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod Patch: https://git.openjdk.java.net/jfx17u/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/33/head:pull/33 PR: https://git.openjdk.java.net/jfx17u/pull/33 From kcr at openjdk.java.net Fri Feb 11 17:41:17 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 17:41:17 GMT Subject: [jfx17u] RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 16:48:47 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. Skara didn't mark this one as clean, although it is. See [SKARA-1332](https://bugs.openjdk.java.net/browse/SKARA-1332). I double-checked by doing a diff of this commit, dc2f779c28c0314b033f2b8b897f1c1b4a7d3c79, and the jfx mainline commit, [openjdk/jfx/commit/6f28d91](https://github.com/openjdk/jfx/commit/6f28d912024495278c4c35ab054bc2aab480b3e4). They are identical. ------------- PR: https://git.openjdk.java.net/jfx17u/pull/33 From kcr at openjdk.java.net Fri Feb 11 17:49:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 17:49:16 GMT Subject: [jfx17u] Integrated: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 16:48:20 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. This pull request has now been integrated. Changeset: 0ab83722 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/0ab83722810706fcb58319c7b494da026f5e169f Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Backport-of: 5bd72a7c991d5182f4fd2cff67174cf7fa3fde85 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/30 From kcr at openjdk.java.net Fri Feb 11 17:51:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 17:51:09 GMT Subject: [jfx17u] Integrated: 8278260: JavaFX shared libraries not stripped on Linux or macOS In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 16:48:27 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. This pull request has now been integrated. Changeset: f52ded76 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/f52ded768da5b724677c23ad76dd9436d65ef473 Stats: 68 lines in 3 files changed: 65 ins; 0 del; 3 mod 8278260: JavaFX shared libraries not stripped on Linux or macOS Backport-of: 1ebf7a24144b198e62b9b343821fdb155b9d703e ------------- PR: https://git.openjdk.java.net/jfx17u/pull/31 From kcr at openjdk.java.net Fri Feb 11 17:53:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 17:53:13 GMT Subject: [jfx17u] Integrated: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: <_Yj3f9p-TDzkG6iio2gCHBlPRITMgzgOJmW2xOwRSJk=.1baf6e66-6b2b-4d75-8f34-5e0ed1ef8fc9@github.com> References: <_Yj3f9p-TDzkG6iio2gCHBlPRITMgzgOJmW2xOwRSJk=.1baf6e66-6b2b-4d75-8f34-5e0ed1ef8fc9@github.com> Message-ID: <5Cw1MZdnxb0EoNnyx42S1kmb4X-ituJLpRtQXR5r2jY=.504c5816-c719-407a-84b6-b3e4934c0562@github.com> On Fri, 11 Feb 2022 16:48:35 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. This pull request has now been integrated. Changeset: b0ae8b6b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/b0ae8b6bf3c46dac8bccd3690f99769a5a449969 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8242544: CMD+ENTER key event crashes the application when invoked on dialog Backport-of: a2a0acff66727167bfca879bf908361433e74791 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/32 From kcr at openjdk.java.net Fri Feb 11 18:26:26 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 18:26:26 GMT Subject: [jfx17u] Integrated: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022 16:48:47 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. CI build passed on three platforms. Tested locally on macOS. This pull request has now been integrated. Changeset: 4c944064 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/4c94406435077433185ab92df6612a0802cc35c1 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod 8278980: Update WebKit to 613.1 Backport-of: 6f28d912024495278c4c35ab054bc2aab480b3e4 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/33 From kcr at openjdk.java.net Fri Feb 11 18:44:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 18:44:49 GMT Subject: [jfx17u] Integrated: 8281459: WebKit 613.1 build broken on M1 Message-ID: Clean backport to jfx17u. ------------- Commit messages: - 8281459: WebKit 613.1 build broken on M1 Changes: https://git.openjdk.java.net/jfx17u/pull/34/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=34&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281459 Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod Patch: https://git.openjdk.java.net/jfx17u/pull/34.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/34/head:pull/34 PR: https://git.openjdk.java.net/jfx17u/pull/34 From kcr at openjdk.java.net Fri Feb 11 18:44:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Feb 2022 18:44:49 GMT Subject: [jfx17u] Integrated: 8281459: WebKit 613.1 build broken on M1 In-Reply-To: References: Message-ID: <6iY_m-APgok_8ciE4FKh_G4tnAMccMYUjJF8THi6Gfs=.dd7521a9-cf11-404c-b9d5-76af874c2e1b@github.com> On Fri, 11 Feb 2022 18:35:37 GMT, Kevin Rushforth wrote: > Clean backport to jfx17u. This pull request has now been integrated. Changeset: 9bf1feb0 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/9bf1feb0abf9a4f28c80f655aa1e63325b6383ab Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8281459: WebKit 613.1 build broken on M1 Backport-of: cdebc6cbafb579148b4addee44d307bd9739454b ------------- PR: https://git.openjdk.java.net/jfx17u/pull/34 From steve at weblite.ca Fri Feb 11 22:22:29 2022 From: steve at weblite.ca (Steve Hannah) Date: Fri, 11 Feb 2022 14:22:29 -0800 Subject: JavaFX Launch Failure on Ubuntu from JNI In-Reply-To: References: Message-ID: Just wanted to share that I sorted out all of my issues with this launcher, and I'm proud to present the result: jDeploy https://www.jdeploy.com You can now deploy your JavaFX apps as native bundles to your Mac, Linux, and Windows users without requiring a Mac/Windows/Linux box to produce the native bundle. You don't need to deal with codesigning/notarizing on Mac either. Install bundles are small (3mb compressed). When you publish updates, your users will get them automatically on next launch. Please take it for a spin and let me know what you think. Happy to answer any questions. On Mon, Jan 24, 2022 at 9:48 AM Steve Hannah wrote: > I just wanted to follow up with this in case someone comes across this > thread later. > > After thoroughly exploring the landscape, I found that the issue on Ubuntu > was caused by a conflict between the webkit2gtk-4.0 library (which I was > using to show a progress dialog in the case that the JRE or app needs to > download an update). Additionally it seemed to have a problem with just > the general gtk+-3.0 dependency, if GTK was initialized before JavaFX was > loaded. > I worked around the gtk+-3.0 issue by breaking the GTK stuff into a > separate process (calling itself with different args). This workaround was > not sufficient to resolve the webkit2gtk-4.0 conflict as, even if it wasn't > used at runtime, it would still conflict with JavaFX's webview - resulting > in a segfault. The only solution was to remove the webkit2gtk-4.0 > dependency entirely from my app, and do the progress dialog differently (I > ended up just using basic GTK widgets). > > Best regards > > Steve > > > > On Wed, Jan 19, 2022 at 9:40 AM Steve Hannah wrote: > >> The following issue only seems to occur on Linux (Ubuntu 20.04.1), and >> only when I try to launch the JVM from a custom C launcher using JNI. It >> does not occur when launching the JVM as a separate process using the >> "java" binary. It also does not occur on MacOS when using the same C >> launcher using JNI. >> >> When I call MyApplication.launch(args). (where MyApplication extends the >> JavaFX Application class), I get the following stack trace: >> >> Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup >> Exception in thread "Thread-5" java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Thread-5 >> at com.sun.glass.ui.Application.checkEventThread(Application.java:447) >> at com.sun.glass.ui.Application.setName(Application.java:200) >> at com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) >> at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) >> at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> Exception in Application start method >> Exception in thread "Thread-31" Failed to show docs >> java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-31 >> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) >> at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) >> at com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) >> at com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) >> at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) >> at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) >> at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> java.lang.RuntimeException: Exception in Application start method >> at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) >> at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) >> at java.base/java.lang.Thread.run(Thread.java:829) >> Caused by: java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-6 >> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) >> at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) >> at javafx.stage.Stage.(Stage.java:254) >> at javafx.stage.Stage.(Stage.java:240) >> at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) >> at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) >> at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) >> at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> >> >> I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), >> running on a few different JDK installs (all JDK11). Above stacktrace is >> from 17.0.1. >> >> From the C application that launches the JVM, I have tried running >> directly on the main thread, and also launching it in a fresh thread using >> pthreads - but same issue. I am running this inside an application written >> in Go but the JNI code is all in C. >> >> It appears as though JavaFX is unable to create its application thread >> for some reason. Does anyone have any suggestions on reasons why this >> would be the case? Are there some system properties that need to be there >> which would have been bootstrapped by the "java" binary, but would not when >> the JVM is launched via JNI? >> >> Any suggestions appreciated. I've been banging my head on this for a >> while now. >> >> Best regards >> >> Steve >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > -- Steve Hannah Web Lite Solutions Corp. From kcr at openjdk.java.net Sat Feb 12 01:04:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Feb 2022 01:04:18 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) I don't follow the last point about using the same origin and overlapped lines being wasteful. It seems there are either two or three issues here. 1. Text underline and line-through are drawn slanted as described in this bug, which is a result of incorrectly adjusting the y coord one of the two end points passed into a `drawLine` call by the `thickness`. 2. The text is always drawn as a thin line, possibly because the stroke width doesn't take `thickness` into account (and while this could conceivably be done with `drawRect`, setting the stroke attributes and calling `drawLine` is the right way to do it). 3. MAYBE: there might be problem with drawing dashed line; if this doesn't work, the fix would probably be to set the dash pattern in the stroke. This PR addresses the first problem, which is the problem described in the bug report. The propose change looks correct. We could expand the bug report to cover at least the second case (since that is a somewhat related bug), but it might be better to file and fix that one separately (if it really is as simple as multiplying the existing stroke width by the thickness in the `drawLinesForText` method, then I wouldn't be opposed to fixing it in this PR, since it is somewhat related). In any case, I think the third issue of line pattern should be dealt with separately, if in fact, it is a problem. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Sat Feb 12 01:09:13 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Feb 2022 01:09:13 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: <5tE3p6sKOgNu2cpJBiw6Zulu2EZ6C1U9nZCV02Z9Y50=.eb445c7d-c334-48cd-8a3f-abcfe1eb940c@github.com> On Sat, 12 Feb 2022 01:00:46 GMT, Kevin Rushforth wrote: > 2. The text is always drawn as a thin line... That should be "the text _underline or line-through_ is always drawn as a thin line...". ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sat Feb 12 04:28:11 2022 From: duke at openjdk.java.net (yosbits) Date: Sat, 12 Feb 2022 04:28:11 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) thickness is probably specified in this CSS property * https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration-thickness The fixed code also has a lot of problems, so We can understand how to fix it by comparing it with CoreGraphics. It will be up to the leader to decide when to make the remaining fixes. The source code history looks wrong when trying to correspond to thickness. * https://github.com/openjdk/jfx/blame/8955c2d5fe345d294d8a5ddba09fc23752a07c84/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp Another probably performance issue, ``` Java StrokeStyle savedStrokeStyle = strokeStyle (); setStrokeStyle (stroke); ``` Java setStrokeStyle (savedStrokeStyle); } This looks better outside the loop. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kevin.rushforth at oracle.com Sat Feb 12 14:52:08 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 12 Feb 2022 06:52:08 -0800 Subject: Mention of the CSS properties in JavaDocs In-Reply-To: References: Message-ID: While something like this could be handy, I doubt that adding this much knowledge of JavaFX into the javadoc tool would gain any traction. -- Kevin On 2/9/2022 7:11 AM, Nir Lisker wrote: > Hi, > > When reviewing the docs changes to TabPane, I saw that some properties > mention the CSS that is related to them. I was wondering if we could > standardize it through something like a @css tag that is given the css > string constant, or read automatically through the CssMetaData. > > As an example: > > /** > * Specifies the maximum width of a tab. > * ... > * @css -fx-tab-max-width > * @defaultValue 10 > */ > > If the javadoc tool has access to these during its runtime, it can read the > string by looking in the getCssMetaData() override of the property and then > read the first argument of the CssMetaData constructor. > > Thoughts? From kcr at openjdk.java.net Sat Feb 12 17:09:09 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Feb 2022 17:09:09 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) OK, I get what you are saying now. The dashed line case -- which is the only case we will go through that loop more than once -- has at least two problems: it doesn't adjust the origin point of the segments as it loops through the dash pattern (a functional bug that also is a performance hit), and we set and restore the stroke style inside the loop; probably the right fix is to not loop at all, but rather use the stroke setting for dashed lines and call drawLine once. I will ask Jay to file a follow-up issue for this so we can track it as a separate issue. For the problem with thickness, we either need to also file a new follow-up issue, or address it as part of this PR. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Sat Feb 12 17:45:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Feb 2022 17:45:08 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) The fix for thickness seems to be as easy as saving the current thickness and setting the value to the thickness argument, and then restoring it, similarly to what is done for `StrokeStyle`. I did a quick test of that and the line thickness now matches Safari and Firefox. The positioning is off by what looks like 1/2 thickness, which would make sense if the values passed in were for the upper end of the (thick) line rather than the center, which is what drawLine expects. Adjusting both the start and end points by `thickness/2` makes WebView match the two browsers. So the following might be the fix for both the slanted lines, and the fact that we ignore thickness: StrokeStyle savedStrokeStyle = strokeStyle(); setStrokeStyle(stroke); float savedStrokeThickness = strokeThickness(); setStrokeThickness(thickness); FloatPoint startPoint = origin + FloatPoint(0, thickness / 2); FloatPoint endPoint = startPoint + FloatPoint(width, 0); drawLine( IntPoint(startPoint.x(), startPoint.y()), IntPoint(endPoint.x(), endPoint.y())); setStrokeStyle(savedStrokeStyle); setStrokeThickness(savedStrokeThickness); We would need to confirm my hypothesis that the position of the line should be adjusted like this. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From nlisker at gmail.com Sat Feb 12 18:11:46 2022 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 12 Feb 2022 20:11:46 +0200 Subject: Mention of the CSS properties in JavaDocs In-Reply-To: References: Message-ID: How does it handle JavaFX-specific properties? I thought that JavaFX uses a modified javadoc tool. On Sat, Feb 12, 2022 at 4:52 PM Kevin Rushforth wrote: > While something like this could be handy, I doubt that adding this much > knowledge of JavaFX into the javadoc tool would gain any traction. > > -- Kevin > > > On 2/9/2022 7:11 AM, Nir Lisker wrote: > > Hi, > > > > When reviewing the docs changes to TabPane, I saw that some properties > > mention the CSS that is related to them. I was wondering if we could > > standardize it through something like a @css tag that is given the css > > string constant, or read automatically through the CssMetaData. > > > > As an example: > > > > /** > > * Specifies the maximum width of a tab. > > * ... > > * @css -fx-tab-max-width > > * @defaultValue 10 > > */ > > > > If the javadoc tool has access to these during its runtime, it can read > the > > string by looking in the getCssMetaData() override of the property and > then > > read the first argument of the CssMetaData constructor. > > > > Thoughts? > > From kevin.rushforth at oracle.com Sat Feb 12 22:16:29 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 12 Feb 2022 14:16:29 -0800 Subject: [External] : Re: Mention of the CSS properties in JavaDocs In-Reply-To: References: Message-ID: <72c6948c-9a42-057b-342f-7baaaf51a368@oracle.com> Support for JavaFX properties was folded into the standard doclet in JDK 8, so we haven't used a modified javadoc tool since then. It was initially under a "-javafx" option. That option was eliminated, and the JavaFX property support is enabled and active for classes that implement javafx.beans.Observable interface from the javafx.base module. It has been improved several times recently, but the JavaFX-specific knowledge in the doclet is limited to support for properties. -- Kevin On 2/12/2022 10:11 AM, Nir Lisker wrote: > How does it handle JavaFX-specific properties? I thought that JavaFX > uses a modified javadoc tool. > > On Sat, Feb 12, 2022 at 4:52 PM Kevin Rushforth > wrote: > > While something like this could be handy, I doubt that adding this > much > knowledge of JavaFX into the javadoc tool would gain any traction. > > -- Kevin > > > On 2/9/2022 7:11 AM, Nir Lisker wrote: > > Hi, > > > > When reviewing the docs changes to TabPane, I saw that some > properties > > mention the CSS that is related to them. I was wondering if we could > > standardize it through something like a @css tag that is given > the css > > string constant, or read automatically through the CssMetaData. > > > > As an example: > > > >? ? ? /** > >? ? ? ?* Specifies the maximum width of a tab. > >? ? ? ?* ... > >? ? ? ?* @css -fx-tab-max-width > >? ? ? ?* @defaultValue 10 > >? ? ? ?*/ > > > > If the javadoc tool has access to these during its runtime, it > can read the > > string by looking in the getCssMetaData() override of the > property and then > > read the first argument of the CssMetaData constructor. > > > > Thoughts? > From duke at openjdk.java.net Sun Feb 13 07:27:16 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 13 Feb 2022 07:27:16 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView In-Reply-To: References: Message-ID: <-sW3swBr4A5VOsig3jRfQ5wADDwrV1Jd-FiEZlg7iq0=.ebc43d41-ec2e-4a04-93c3-134118db3fe3@github.com> On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) StrokeStyle savedStrokeStyle = strokeStyle(); setStrokeStyle(stroke); float savedStrokeThickness = strokeThickness(); setStrokeThickness(thickness); FloatPoint startPoint = origin + FloatPoint(0, thickness / 2); FloatPoint endPoint = startPoint + FloatPoint(width, 0); drawLine( IntPoint(startPoint.x(), startPoint.y()), IntPoint(endPoint.x(), endPoint.y())); setStrokeStyle(savedStrokeStyle); setStrokeThickness(savedStrokeThickness); It works , and stroke thickness is effective. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sun Feb 13 07:35:32 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 13 Feb 2022 07:35:32 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v2] In-Reply-To: References: Message-ID: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: adjust thickness ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/94a493ae..c5b6ff76 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=00-01 Stats: 15 lines in 1 file changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sun Feb 13 07:47:04 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 13 Feb 2022 07:47:04 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v2] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 07:35:32 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > adjust thickness The dash case (--) also works without looping Screenshot 2022-02-13 at 1 13 51 PM ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From swpalmer at gmail.com Sat Feb 12 18:25:25 2022 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 12 Feb 2022 13:25:25 -0500 Subject: Mention of the CSS properties in JavaDocs In-Reply-To: References: Message-ID: <77E03BE9-9017-4528-90F3-108DDACBCD91@gmail.com> Would it be a custom doclet that was part of the OpenJFX project and require no changes to the javadoc tool? Scott > On Feb 12, 2022, at 9:52 AM, Kevin Rushforth wrote: > > While something like this could be handy, I doubt that adding this much knowledge of JavaFX into the javadoc tool would gain any traction. > > -- Kevin > > > On 2/9/2022 7:11 AM, Nir Lisker wrote: >> Hi, >> >> When reviewing the docs changes to TabPane, I saw that some properties >> mention the CSS that is related to them. I was wondering if we could >> standardize it through something like a @css tag that is given the css >> string constant, or read automatically through the CssMetaData. >> >> As an example: >> >> /** >> * Specifies the maximum width of a tab. >> * ... >> * @css -fx-tab-max-width >> * @defaultValue 10 >> */ >> >> If the javadoc tool has access to these during its runtime, it can read the >> string by looking in the getCssMetaData() override of the property and then >> read the first argument of the CssMetaData constructor. >> >> Thoughts? > From kcr at openjdk.java.net Mon Feb 14 13:40:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Feb 2022 13:40:21 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v2] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 07:35:32 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > adjust thickness Good. So the only problem with the dashed case was the fact that we were looping and drawing the same dashed line _N_ times. Do you know whether my guess about why we need to add `thickness/2` to `y` (caller is passing in the upper-left corner) is right? In addition to a little more testing, I think we should do the following: 1. Edit the title of the JBS bug and this PR to indicate the somewhat broadened scope of the bug. Something like "WebView text underline and line-through rendered incorrectly" 2. Create a new system test that will render a thick solid line and a thick dashed line, use snapshot to capture the rendered output, and check that the line is drawn in the right place. If the thickness is large enough (at least 6 pixels) you can sample 4 pixels vertically near the center of where the line should be and it should be black. For the dashed line, you can do the same in the middle (horizontally) of both an "on" segment, which should be black, and an "off" segment, which should be white. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From powers.anirvan at gmail.com Wed Feb 16 05:37:33 2022 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Wed, 16 Feb 2022 14:37:33 +0900 Subject: Mention of the CSS properties in JavaDocs In-Reply-To: <77E03BE9-9017-4528-90F3-108DDACBCD91@gmail.com> References: <77E03BE9-9017-4528-90F3-108DDACBCD91@gmail.com> Message-ID: JavaFX 2 provided a custom doclet [1] but this was not required since JavaFX 8 (JDK 8). If a custom doclet is introduced again, we need to modify build scripts / IDE settings, etc. which is not required since JDK 12 [2]. So I suppose going back to a custom doclet again will not be a preferable solution. [1] : https://docs.oracle.com/javafx/2/doclet/jfxpub-doclet.htm [2] : https://bugs.openjdk.java.net/browse/JDK-8208532 On Mon, 14 Feb 2022 at 02:34, Scott Palmer wrote: > Would it be a custom doclet that was part of the OpenJFX project and > require no changes to the javadoc tool? > > Scott > > > On Feb 12, 2022, at 9:52 AM, Kevin Rushforth > wrote: > > > > While something like this could be handy, I doubt that adding this much > knowledge of JavaFX into the javadoc tool would gain any traction. > > > > -- Kevin > > > > > > On 2/9/2022 7:11 AM, Nir Lisker wrote: > >> Hi, > >> > >> When reviewing the docs changes to TabPane, I saw that some properties > >> mention the CSS that is related to them. I was wondering if we could > >> standardize it through something like a @css tag that is given the css > >> string constant, or read automatically through the CssMetaData. > >> > >> As an example: > >> > >> /** > >> * Specifies the maximum width of a tab. > >> * ... > >> * @css -fx-tab-max-width > >> * @defaultValue 10 > >> */ > >> > >> If the javadoc tool has access to these during its runtime, it can read > the > >> string by looking in the getCssMetaData() override of the property and > then > >> read the first argument of the CssMetaData constructor. > >> > >> Thoughts? > > > > -- Anirvan From arapte at openjdk.java.net Wed Feb 16 08:14:43 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Feb 2022 08:14:43 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes Message-ID: Include additional stabilization fixes of WebKit 613.1 Sanity testing did not show any concerns. ------------- Commit messages: - Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx/pull/733/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=733&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1219 lines in 127 files changed: 767 ins; 169 del; 283 mod Patch: https://git.openjdk.java.net/jfx/pull/733.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/733/head:pull/733 PR: https://git.openjdk.java.net/jfx/pull/733 From duke at openjdk.java.net Wed Feb 16 08:52:19 2022 From: duke at openjdk.java.net (danielpeintner) Date: Wed, 16 Feb 2022 08:52:19 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 08:07:35 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSRetainPtr.h line 9: > 7: * > 8: * 1. Redistributions of source code must retain the above copyright > 9: q * notice, this list of conditions and the following disclaimer. seems to be unintentional ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From arapte at openjdk.java.net Wed Feb 16 13:08:04 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Feb 2022 13:08:04 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2] In-Reply-To: References: Message-ID: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: correct unintentional change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/733/files - new: https://git.openjdk.java.net/jfx/pull/733/files/e58b3e38..a725f3dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=733&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=733&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/733.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/733/head:pull/733 PR: https://git.openjdk.java.net/jfx/pull/733 From arapte at openjdk.java.net Wed Feb 16 13:13:17 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 16 Feb 2022 13:13:17 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2] In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 08:49:15 GMT, danielpeintner wrote: >> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: >> >> correct unintentional change > > modules/javafx.web/src/main/native/Source/JavaScriptCore/API/JSRetainPtr.h line 9: > >> 7: * >> 8: * 1. Redistributions of source code must retain the above copyright >> 9: q * notice, this list of conditions and the following disclaimer. > > seems to be unintentional Thank you, It is corrected now. ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From kcr at openjdk.java.net Wed Feb 16 13:44:32 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 13:44:32 GMT Subject: [jfx11u] RFR: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Message-ID: Clean backport to `jfx11u`. ------------- Commit messages: - 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Changes: https://git.openjdk.java.net/jfx11u/pull/70/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=70&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277457 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/70.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/70/head:pull/70 PR: https://git.openjdk.java.net/jfx11u/pull/70 From kcr at openjdk.java.net Wed Feb 16 13:47:44 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 13:47:44 GMT Subject: [jfx11u] RFR: 8278260: JavaFX shared libraries not stripped on Linux or macOS Message-ID: Clean backport to `jfx11u`. ------------- Commit messages: - 8278260: JavaFX shared libraries not stripped on Linux or macOS Changes: https://git.openjdk.java.net/jfx11u/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278260 Stats: 68 lines in 3 files changed: 65 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/71/head:pull/71 PR: https://git.openjdk.java.net/jfx11u/pull/71 From kcr at openjdk.java.net Wed Feb 16 13:48:46 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 13:48:46 GMT Subject: [jfx11u] RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog Message-ID: Clean backport to `jfx11u`. ------------- Commit messages: - 8242544: CMD+ENTER key event crashes the application when invoked on dialog Changes: https://git.openjdk.java.net/jfx11u/pull/72/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=72&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242544 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/72.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/72/head:pull/72 PR: https://git.openjdk.java.net/jfx11u/pull/72 From kcr at openjdk.java.net Wed Feb 16 14:21:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 14:21:16 GMT Subject: [jfx11u] Integrated: 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 13:39:14 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: 6ab043f9 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/6ab043f96699e8c9accf8191cc93854595114742 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod 8277457: AccessControlException: access denied ("java.net.NetPermission" "getCookieHandler") Backport-of: 5bd72a7c991d5182f4fd2cff67174cf7fa3fde85 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/70 From kcr at openjdk.java.net Wed Feb 16 14:23:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 14:23:10 GMT Subject: [jfx11u] Integrated: 8278260: JavaFX shared libraries not stripped on Linux or macOS In-Reply-To: References: Message-ID: <522sk93pycNhyEkT87NCIjYRf6smqNwfpbBmOElSdAs=.067b857d-a6f3-4a99-8ee1-9a6d667970e2@github.com> On Wed, 16 Feb 2022 13:39:59 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: eec13f7f Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/eec13f7fac079e8ed8cfa7b7e9bac0aaaa626b51 Stats: 68 lines in 3 files changed: 65 ins; 0 del; 3 mod 8278260: JavaFX shared libraries not stripped on Linux or macOS Backport-of: 1ebf7a24144b198e62b9b343821fdb155b9d703e ------------- PR: https://git.openjdk.java.net/jfx11u/pull/71 From kcr at openjdk.java.net Wed Feb 16 14:31:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 14:31:18 GMT Subject: [jfx11u] Integrated: 8242544: CMD+ENTER key event crashes the application when invoked on dialog In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 13:40:23 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This pull request has now been integrated. Changeset: fdb50f28 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/fdb50f281732f6192068aa45050ef823c5f11228 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8242544: CMD+ENTER key event crashes the application when invoked on dialog Backport-of: a2a0acff66727167bfca879bf908361433e74791 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/72 From kcr at openjdk.java.net Wed Feb 16 16:53:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 16 Feb 2022 16:53:37 GMT Subject: RFR: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Message-ID: The `javafx.graphics` module has a number of native libraries, including the redistributable Microsoft DLLs on Windows. When running an application using the standalone JavaFX SDK, we load all of the needed DLLs from the SDK `bin` directory and everything works as expected. When creating the jmods, we currently exclude the Microsoft DLLs from `javafx.graphics.jmod` to avoid the problem described in [JDK-8207015](https://bugs.openjdk.java.net/browse/JDK-8207015) where `jlink` complains about two modules (`java.base` and `javafx.graphics`) deliver the same file(s). That works as long as the set of Microsoft DLLs delivered by the JDK is from the same or newer version of Microsoft Visual Studio. This means that you can't take, for example, JDK 11.0.x and run the latest version of JavaFX, since JDK 11.x uses VS 2017 and JavaFX 15 (and later) uses VS 2019. Up until now this has just been a minor bug, but we are now at the point where we need to update to VS 2019 for building JavaFX 11.0.15, which means that a jlinked JDK 11.0.X + JavaFX 11.0.15 will no longer work. This fix is to add the Microsoft DLLs back into `javafx.graphics.jmod` (i.e., stop excluding them at build time), but deliver them in `bin/javafx` so they don't conflict with the ones delivered by the JDK. The changes are: 1. `build.gradle` - When creating the jmods on Windows, copy all of the DLLs to a javafx sub-directory 2. `NativeLibLoader.java` - in the case of JavaFX modules jlinked into the Java runtime, load the libraries first from `${java.home}` rather than always falling back to `System::loadLibrary`. Most of the changes are just simple refactoring. The additional logic is in the new `libDirForJRT` method. When running using the SDK or the modules on maven central, there is no change in behavior. I've tested this on all platforms, including a test of a custom JDK 11.x created with jlink. On a Windows I tested it on a system where a key VS 2019 runtime library was not present in C:\Windows\System32 and it now runs. ------------- Commit messages: - 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Changes: https://git.openjdk.java.net/jfx/pull/734/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=734&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281089 Stats: 125 lines in 2 files changed: 74 ins; 39 del; 12 mod Patch: https://git.openjdk.java.net/jfx/pull/734.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/734/head:pull/734 PR: https://git.openjdk.java.net/jfx/pull/734 From kevin.rushforth at oracle.com Wed Feb 16 21:53:22 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 16 Feb 2022 13:53:22 -0800 Subject: [External] : Re: Mention of the CSS properties in JavaDocs In-Reply-To: References: <77E03BE9-9017-4528-90F3-108DDACBCD91@gmail.com> Message-ID: > So I suppose going back to a custom doclet again will not be a preferable solution. You're right; this would not be a preferred solution. -- Kevin On 2/15/2022 9:37 PM, Anirvan Sarkar wrote: > JavaFX 2 provided a custom doclet [1] but this was not required since > JavaFX 8 (JDK 8). > If a custom doclet is introduced again, we need to modify build > scripts / IDE settings, etc. which is not required since JDK 12 [2]. > So I suppose going back to a custom doclet again will not be a > preferable solution. > > [1] : https://docs.oracle.com/javafx/2/doclet/jfxpub-doclet.htm > [2] : https://bugs.openjdk.java.net/browse/JDK-8208532 > > On Mon, 14 Feb 2022 at 02:34, Scott Palmer wrote: > > Would it be a custom doclet that was part of the OpenJFX project > and require no changes to the javadoc tool? > > Scott > > > On Feb 12, 2022, at 9:52 AM, Kevin Rushforth > wrote: > > > > While something like this could be handy, I doubt that adding > this much knowledge of JavaFX into the javadoc tool would gain any > traction. > > > > -- Kevin > > > > > > On 2/9/2022 7:11 AM, Nir Lisker wrote: > >> Hi, > >> > >> When reviewing the docs changes to TabPane, I saw that some > properties > >> mention the CSS that is related to them. I was wondering if we > could > >> standardize it through something like a @css tag that is given > the css > >> string constant, or read automatically through the CssMetaData. > >> > >> As an example: > >> > >>? ? ?/** > >>? ? ? * Specifies the maximum width of a tab. > >>? ? ? * ... > >>? ? ? * @css -fx-tab-max-width > >>? ? ? * @defaultValue 10 > >>? ? ? */ > >> > >> If the javadoc tool has access to these during its runtime, it > can read the > >> string by looking in the getCssMetaData() override of the > property and then > >> read the first argument of the CssMetaData constructor. > >> > >> Thoughts? > > > > > > -- > Anirvan From kcr at openjdk.java.net Thu Feb 17 00:04:14 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Feb 2022 00:04:14 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2] In-Reply-To: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> References: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> Message-ID: <865iJ0Uprh3bn_XFb17Plu7jfrBM-WK0g3gw6I6twy4=.fe394e4c-0231-4741-8d01-654a418547f0@github.com> On Wed, 16 Feb 2022 13:08:04 GMT, Ambarish Rapte wrote: >> Include additional stabilization fixes of WebKit 613.1 >> Sanity testing did not show any concerns. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct unintentional change So far all my testing looks good, but I'll finish tomorrow. ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From jvos at openjdk.java.net Thu Feb 17 09:06:20 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 17 Feb 2022 09:06:20 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2] In-Reply-To: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> References: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> Message-ID: <3EcwFsEwjYsPtraFC8N80jh4wXlAwDn8FhEEBzQtetA=.9207b1dc-3ad7-4e55-a6e5-3e32e34ceef3@github.com> On Wed, 16 Feb 2022 13:08:04 GMT, Ambarish Rapte wrote: >> Include additional stabilization fixes of WebKit 613.1 >> Sanity testing did not show any concerns. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct unintentional change Looks good on Linux. ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From duke at openjdk.java.net Thu Feb 17 13:03:26 2022 From: duke at openjdk.java.net (eduardsdv) Date: Thu, 17 Feb 2022 13:03:26 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel Message-ID: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> If the InputMethod's node is not in the scene, the default text location point is returned. ------------- Commit messages: - 8281953: NullPointer in InputMethod components in JFXPanel Changes: https://git.openjdk.java.net/jfx/pull/735/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=735&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281953 Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/735.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/735/head:pull/735 PR: https://git.openjdk.java.net/jfx/pull/735 From jvos at openjdk.java.net Thu Feb 17 14:13:17 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Thu, 17 Feb 2022 14:13:17 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2] In-Reply-To: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> References: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> Message-ID: On Wed, 16 Feb 2022 13:08:04 GMT, Ambarish Rapte wrote: >> Include additional stabilization fixes of WebKit 613.1 >> Sanity testing did not show any concerns. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct unintentional change Marked as reviewed by jvos (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From kcr at openjdk.java.net Thu Feb 17 17:47:20 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Feb 2022 17:47:20 GMT Subject: RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes [v2] In-Reply-To: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> References: <87QdsFR1Dz4KD7iWtIkcBQK_Hd3iV6MaCoOTWlqOXmk=.e20c297f-8177-4e39-a047-ddbe045db097@github.com> Message-ID: On Wed, 16 Feb 2022 13:08:04 GMT, Ambarish Rapte wrote: >> Include additional stabilization fixes of WebKit 613.1 >> Sanity testing did not show any concerns. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > correct unintentional change Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From arapte at openjdk.java.net Fri Feb 18 03:44:58 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Fri, 18 Feb 2022 03:44:58 GMT Subject: Integrated: 8281711: Cherry-pick WebKit 613.1 stabilization fixes In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 08:07:35 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. This pull request has now been integrated. Changeset: 418d3437 Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/418d3437923fed0a298c48b54214af069e3bb3bd Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod 8281711: Cherry-pick WebKit 613.1 stabilization fixes Stabilization fixes from WebKitGTK 2.34.5 Reviewed-by: jvos, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/733 From mariushanl at web.de Fri Feb 18 11:14:22 2022 From: mariushanl at web.de (Marius Hanl) Date: Fri, 18 Feb 2022 12:14:22 +0100 Subject: Aw: Sneak preview: cell edit api to support commit-on-focusLost In-Reply-To: <20220211180314.Horde.n4MVwEW-gUC9KEIDCi4XJg3@webmail.df.eu> References: <20220211180314.Horde.n4MVwEW-gUC9KEIDCi4XJg3@webmail.df.eu> Message-ID: Can you may create a branch at the jfx sandbox repo? https://github.com/openjdk/jfx-sandbox Then I can more easily compare and check it out. (and monitor it :)) -- Marius Gesendet: Freitag, 11. Februar 2022 um 18:03 Uhr Von: "Jeanette Winzenburg" An: "openjfx-dev" Betreff: Sneak preview: cell edit api to support commit-on-focusLost Hi folks, after fixing a bunch of edit-related issues, time feels right for nudging elephant out of the room :) Which is the bigger goal of supporting commit-on-focusLost. Working on a PoC (ListView/-Cell only) in a branch of my fork [1]https://github.com/kleopatra/jfx/tree/dokeep-edit-api-editstate with an overview of suggested changes [2]https://github.com/kleopatra/swingempire-fx/wiki/CellEditAPI and a example driver as gist [3]https://gist.github.com/kleopatra/447344183e017537c21f7905a062396d Still rough, but working: all current unit tests still passing (a bunch of my own not, and the new api is barely tested) and many of the requested requirements can be implemented (see code in the example and the table of use-cases in the overview) Any feedback - for the good or for the bad - highly welcome :) -- Jeanette References 1. https://github.com/kleopatra/jfx/tree/dokeep-edit-api-editstate 2. https://github.com/kleopatra/swingempire-fx/wiki/CellEditAPI 3. https://gist.github.com/kleopatra/447344183e017537c21f7905a062396d From alexsch at openjdk.java.net Fri Feb 18 15:28:20 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 18 Feb 2022 15:28:20 GMT Subject: RFR: 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen Message-ID: There is the bouncing when scrolling a node on a ScrollPane to the right/bottom (the node on the scroll pane is scrolled further than its width/height so the background is visible and then automatically is scrolled back to the node bounds) on Raspberry Pi with Touchscreen. There is no bouncing when node is scrolled to the left/top. The fix updates ScrollPaneSkin.updatePosX()/updatePosY() methods to not discard negative minX/Y values in case the touch is supported. ------------- Commit messages: - 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen Changes: https://git.openjdk.java.net/jfx/pull/736/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=736&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282100 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/736.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/736/head:pull/736 PR: https://git.openjdk.java.net/jfx/pull/736 From alexsch at openjdk.java.net Fri Feb 18 17:10:20 2022 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 18 Feb 2022 17:10:20 GMT Subject: RFR: 8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen Message-ID: Zoomed/Rotated with two fingers rectangle flickers (unexpectedly becomes pretty small or large and then returns back to previous size several times during zooming/rotating) on a Raspberry Pi with Touchscreen. The log with traced events shows that it is possible that only one ABS_MT_POSITION_X or ABS_MT_POSITION_Y can be sent for a given slot. In this case the corresponding omitted Y/X value is undefined and is assigned from ABS_Y/X value. This produces incorrect result for slots different from 0. Example of the trace events log, enabled by `-Dmonocle.input.traceEvents.verbose=true -Dmonocle.input.traceEvents=true` flags: traceEvent: Processing EV_ABS ABS_MT_SLOT 1 [index=48] traceEvent: Processing EV_ABS ABS_MT_TRACKING_ID 302 [index=64] traceEvent: Processing EV_ABS ABS_MT_POSITION_X 399 [index=80] traceEvent: Processing EV_ABS ABS_MT_POSITION_Y 272 [index=96] traceEvent: Processing EV_KEY BTN_TOUCH 1 [index=112] traceEvent: Read EV_ABS ABS_MT_SLOT 0 [index=176] traceEvent: Read EV_ABS ABS_MT_POSITION_Y 315 [index=192] traceEvent: Read EV_ABS ABS_Y 315 [index=208] traceEvent: Read EV_SYN SYN_REPORT 0 [index=224] ... traceEvent: Read EV_ABS ABS_MT_SLOT 1 [index=320] traceEvent: Read EV_ABS ABS_MT_POSITION_Y 271 [index=336] traceEvent: Read EV_ABS ABS_X 552 [index=352] traceEvent: Read EV_ABS ABS_Y 322 [index=368] traceEvent: Read EV_SYN SYN_REPORT 0 [index=384] First both ABS_MT_POSITION_X/Y events with values x: 399 and y: 272 are received for the slot 1. Next only ABS_MT_POSITION_Y with y: 271 value is received (which implies that the x value has not been changed) for the slot 1. The x value is undefined in the LinuxStatefulMultiTouchProcessor.processEvents() loop and is unexpectedly assigned to the ABS_X 552 value which belongs to the slot 0. The fix skips setting ABS_X/Y values for slots different from 0. ------------- Commit messages: - 8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen Changes: https://git.openjdk.java.net/jfx/pull/737/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=737&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282104 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/737.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/737/head:pull/737 PR: https://git.openjdk.java.net/jfx/pull/737 From kcr at openjdk.java.net Fri Feb 18 21:07:01 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Feb 2022 21:07:01 GMT Subject: RFR: 8282104: Node zoom/rotate flickers on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:04:08 GMT, Alexander Scherbatiy wrote: > Zoomed/Rotated with two fingers rectangle flickers (unexpectedly becomes pretty small or large and then returns back to previous size several times during zooming/rotating) on a Raspberry Pi with Touchscreen. > > The log with traced events shows that it is possible that only one ABS_MT_POSITION_X or ABS_MT_POSITION_Y can be sent for a given slot. In this case the corresponding omitted Y/X value is undefined and is assigned from ABS_Y/X value. This produces incorrect result for slots different from 0. > > Example of the trace events log, enabled by `-Dmonocle.input.traceEvents.verbose=true -Dmonocle.input.traceEvents=true` flags: > > traceEvent: Processing EV_ABS ABS_MT_SLOT 1 [index=48] > traceEvent: Processing EV_ABS ABS_MT_TRACKING_ID 302 [index=64] > traceEvent: Processing EV_ABS ABS_MT_POSITION_X 399 [index=80] > traceEvent: Processing EV_ABS ABS_MT_POSITION_Y 272 [index=96] > traceEvent: Processing EV_KEY BTN_TOUCH 1 [index=112] > traceEvent: Read EV_ABS ABS_MT_SLOT 0 [index=176] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 315 [index=192] > traceEvent: Read EV_ABS ABS_Y 315 [index=208] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=224] > > ... > > traceEvent: Read EV_ABS ABS_MT_SLOT 1 [index=320] > traceEvent: Read EV_ABS ABS_MT_POSITION_Y 271 [index=336] > traceEvent: Read EV_ABS ABS_X 552 [index=352] > traceEvent: Read EV_ABS ABS_Y 322 [index=368] > traceEvent: Read EV_SYN SYN_REPORT 0 [index=384] > > First both ABS_MT_POSITION_X/Y events with values x: 399 and y: 272 are received for the slot 1. > Next only ABS_MT_POSITION_Y with y: 271 value is received (which implies that the x value has not been changed) for the slot 1. > The x value is undefined in the LinuxStatefulMultiTouchProcessor.processEvents() loop and is unexpectedly assigned to the ABS_X 552 value which belongs to the slot 0. > > The fix skips setting ABS_X/Y values for slots different from 0. I see that this fix is limited to Monocle. Maybe @johanvos can review. ------------- PR: https://git.openjdk.java.net/jfx/pull/737 From kcr at openjdk.java.net Fri Feb 18 21:09:12 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 18 Feb 2022 21:09:12 GMT Subject: RFR: 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 15:21:49 GMT, Alexander Scherbatiy wrote: > There is the bouncing when scrolling a node on a ScrollPane to the right/bottom (the node on the scroll pane is scrolled further than its width/height so the background is visible and then automatically is scrolled back to the node bounds) on Raspberry Pi with Touchscreen. > There is no bouncing when node is scrolled to the left/top. > > The fix updates ScrollPaneSkin.updatePosX()/updatePosY() methods to not discard out of the range top/left minX/Y values in case the touch is supported. This seems like a reasonable fix. Perhaps @johanvos (or @aghaisas ) can review? ------------- PR: https://git.openjdk.java.net/jfx/pull/736 From duke at openjdk.java.net Sat Feb 19 03:52:41 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 19 Feb 2022 03:52:41 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v2] In-Reply-To: References: Message-ID: On Sun, 13 Feb 2022 07:35:32 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > adjust thickness A new system test case for checking line straightness added ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sat Feb 19 03:52:41 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 19 Feb 2022 03:52:41 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Update test case for line straightness check ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/c5b6ff76..135a073b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=01-02 Stats: 238 lines in 2 files changed: 176 ins; 62 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sat Feb 19 11:48:07 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sat, 19 Feb 2022 11:48:07 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView Message-ID: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView ------------- Commit messages: - 8282134: Certain regex can cause a JS trap in WebView Changes: https://git.openjdk.java.net/jfx/pull/739/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=739&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282134 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/739.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/739/head:pull/739 PR: https://git.openjdk.java.net/jfx/pull/739 From kcr at openjdk.java.net Sat Feb 19 14:07:52 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Feb 2022 14:07:52 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView In-Reply-To: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Sat, 19 Feb 2022 11:43:00 GMT, Jay Bhaskar wrote: > Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView The fix looks good. I confirm that the new test fails without the fix and passes with the fix. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/739 From kcr at openjdk.java.net Sat Feb 19 17:03:51 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 19 Feb 2022 17:03:51 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 03:52:41 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Update test case for line straightness check The test is a good start, but I left several comments inline. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 75: > 73: this.primaryStage = primaryStage; > 74: this.primaryStage.setWidth(80); > 75: this.primaryStage.setHeight(60); Minor: Since you set the size of the Scene later on, you don't need to set it here. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 78: > 76: launchLatch.countDown(); > 77: } > 78: } Add a blank after this. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 87: > 85: } > 86: > 87: Minor: the extra blank line is unnecessary. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 105: > 103: Platform.runLater(() -> { > 104: webView = new WebView(); > 105: Scene scene = new Scene(webView,80,60); This test passes on my Windows system even without the fix. Based on what I see on the screen, I think its because the scene size is too small. I would make it larger (at least 150x100). Minor: add a space after the commas to separate the args tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 163: > 161: > 162: // buttom start x position of underline ( startx + font size + thickness -1) > 163: int line_start_x = start_x + height + 20 - 1; The x value shouldn't be affected by thickness or the height. This should be something like `start_x + 3` (the `+3` is so you don't sample anywhere near the edge, to avoid boundary problems). I also recommend sampling near the right edge to catch the problem of a slanted line, so: `int line_end_x = start_x + width - 3;` tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 165: > 163: int line_start_x = start_x + height + 20 - 1; > 164: // buttom start y position of underline ( startx + height) > 165: int line_start_y = start_y + height; As mentioned above, I recommend adding 3 pixels to avoid sampling near the top edge of the thick line, so `start_y + height + 3` tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 167: > 165: int line_start_y = start_y + height; > 166: String line_color = "rgba(0,0,0,255)"; // color of line > 167: for (int i = line_start_y; i < snapshot.getHeight(); i++) { The snapshot height is irrelevant. You should use thickness minus 6 (3 pixels on each of the top and bottom): i < line_start_y + thickness - 6; tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 172: > 170: continue; > 171: else > 172: fail("Each pixel color of line should be" + line_color + " but was:" + expected); The name `expected` is misleading. It isn't the expected value, but rather the "actual" value that you just read. Also, there are two formatting issues: 1. There should be a space after the `if` 2. The target statements of the `if` and `else` must be surrounded by curly braces (unless on the same line as the `if` which would look odd in this case) ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sat Feb 19 17:52:53 2022 From: duke at openjdk.java.net (delvh) Date: Sat, 19 Feb 2022 17:52:53 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel In-Reply-To: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: On Thu, 17 Feb 2022 12:57:27 GMT, eduardsdv wrote: > If the InputMethod's node is not in the scene, the default text location point is returned. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 340: > 338: if (window == null) { > 339: return new Point2D(0, 0); > 340: } As long as each scene needs to be located in a window, the following will simplify the code: Suggestion: if (scene == null) { return new Point2D(0, 0); } Window window = scene.getWindow(); Is it possible to have a scene without an assigned window? ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From duke at openjdk.java.net Mon Feb 21 02:00:57 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 02:00:57 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 14:32:46 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test case for line straightness check > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 78: > >> 76: launchLatch.countDown(); >> 77: } >> 78: } > > Add a blank after this. done > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 87: > >> 85: } >> 86: >> 87: > > Minor: the extra blank line is unnecessary. done > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 105: > >> 103: Platform.runLater(() -> { >> 104: webView = new WebView(); >> 105: Scene scene = new Scene(webView,80,60); > > This test passes on my Windows system even without the fix. Based on what I see on the screen, I think its because the scene size is too small. I would make it larger (at least 150x100). > > Minor: add a space after the commas to separate the args space added, i will look this observation on windows ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 02:28:47 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 02:28:47 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 16:51:52 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test case for line straightness check > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 172: > >> 170: continue; >> 171: else >> 172: fail("Each pixel color of line should be" + line_color + " but was:" + expected); > > The name `expected` is misleading. It isn't the expected value, but rather the "actual" value that you just read. > > Also, there are two formatting issues: > 1. There should be a space after the `if` > 2. The target statements of the `if` and `else` must be surrounded by curly braces (unless on the same line as the `if` which would look odd in this case) done ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 02:43:48 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 02:43:48 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 14:45:53 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test case for line straightness check > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 75: > >> 73: this.primaryStage = primaryStage; >> 74: this.primaryStage.setWidth(80); >> 75: this.primaryStage.setHeight(60); > > Minor: Since you set the size of the Scene later on, you don't need to set it here. This would be remain same , i would not set size later ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 04:22:59 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 04:22:59 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 14:55:30 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test case for line straightness check > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 163: > >> 161: >> 162: // buttom start x position of underline ( startx + font size + thickness -1) >> 163: int line_start_x = start_x + height + 20 - 1; > > The x value shouldn't be affected by thickness or the height. This should be something like `start_x + 3` (the `+3` is so you don't sample anywhere near the edge, to avoid boundary problems). > > I also recommend sampling near the right edge to catch the problem of a slanted line, so: `int line_end_x = start_x + width - 3;` The bounding rect.x rect.y is top left corner, and line is being drawn below the bottom, so height and thickness need to be considered. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 05:34:00 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 05:34:00 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: <-ZQqNXw5_TKpN4ZWIFMSKt_ZM8MQZb2NJyYaxWGcHbQ=.b01b7e3b-af7d-4739-a8fd-fac98b809119@github.com> On Mon, 21 Feb 2022 04:19:29 GMT, Jay Bhaskar wrote: >> tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 163: >> >>> 161: >>> 162: // buttom start x position of underline ( startx + font size + thickness -1) >>> 163: int line_start_x = start_x + height + 20 - 1; >> >> The x value shouldn't be affected by thickness or the height. This should be something like `start_x + 3` (the `+3` is so you don't sample anywhere near the edge, to avoid boundary problems). >> >> I also recommend sampling near the right edge to catch the problem of a slanted line, so: `int line_end_x = start_x + width - 3;` > > The bounding rect.x rect.y is top left corner, and line is being drawn below the bottom, so height and thickness need to be considered. int i = line_start_y; i < (line_start_y - 6); i++ , this meets the condition of sampling near the right edge ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 06:02:32 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 06:02:32 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v4] In-Reply-To: References: Message-ID: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Improve style and width iterartion logic ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/135a073b..3246375d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=02-03 Stats: 13 lines in 1 file changed: 4 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 06:02:34 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 21 Feb 2022 06:02:34 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 15:03:38 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: >> >> Update test case for line straightness check > > tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 167: > >> 165: int line_start_y = start_y + height; >> 166: String line_color = "rgba(0,0,0,255)"; // color of line >> 167: for (int i = line_start_y; i < snapshot.getHeight(); i++) { > > The snapshot height is irrelevant. You should use thickness minus 6 (3 pixels on each of the top and bottom): > > > i < line_start_y + thickness - 6; I think it should be like for (int i = line_start_y; i <= (width - line_start_y -6); i++) , as we need to iterate in x direction ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Mon Feb 21 07:30:53 2022 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 21 Feb 2022 07:30:53 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel In-Reply-To: References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: <5pB7lPLGp0UjHEPzdtDCpprnJTv4T2rhwA9ZY5uup0U=.263da1b7-b96c-4bf7-ba5f-7941e4356244@github.com> On Sat, 19 Feb 2022 17:40:54 GMT, delvh wrote: >> If the InputMethod's node is not in the scene, the default text location point is returned. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 340: > >> 338: if (window == null) { >> 339: return new Point2D(0, 0); >> 340: } > > As long as each scene needs to be located in a window, the following will simplify the code: > Suggestion: > > if (scene == null) { > return new Point2D(0, 0); > } > Window window = scene.getWindow(); > > Is it possible to have a scene without an assigned window? Since the NullPointer occurs here because the synchronization between JavaFx and AWT threads is not really possible in this case, we cannot ensure that this method is only called when the scene is assigned to a window. I would check here for null both the scene and the window. ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From duke at openjdk.java.net Mon Feb 21 09:44:57 2022 From: duke at openjdk.java.net (delvh) Date: Mon, 21 Feb 2022 09:44:57 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel In-Reply-To: <5pB7lPLGp0UjHEPzdtDCpprnJTv4T2rhwA9ZY5uup0U=.263da1b7-b96c-4bf7-ba5f-7941e4356244@github.com> References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> <5pB7lPLGp0UjHEPzdtDCpprnJTv4T2rhwA9ZY5uup0U=.263da1b7-b96c-4bf7-ba5f-7941e4356244@github.com> Message-ID: On Mon, 21 Feb 2022 07:27:46 GMT, eduardsdv wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 340: >> >>> 338: if (window == null) { >>> 339: return new Point2D(0, 0); >>> 340: } >> >> As long as each scene needs to be located in a window, the following will simplify the code: >> Suggestion: >> >> if (scene == null) { >> return new Point2D(0, 0); >> } >> Window window = scene.getWindow(); >> >> Is it possible to have a scene without an assigned window? > > Since the NullPointer occurs here because the synchronization between JavaFx and AWT threads is not really possible in this case, we cannot ensure that this method is only called when the scene is assigned to a window. > I would check here for null both the scene and the window. What a pity. Then ignore this comment. ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From arapte at openjdk.java.net Mon Feb 21 11:36:01 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 21 Feb 2022 11:36:01 GMT Subject: RFR: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 16:46:47 GMT, Kevin Rushforth wrote: > The `javafx.graphics` module has a number of native libraries, including the redistributable Microsoft DLLs on Windows. When running an application using the standalone JavaFX SDK, we load all of the needed DLLs from the SDK `bin` directory and everything works as expected. > > When creating the jmods, we currently exclude the Microsoft DLLs from `javafx.graphics.jmod` to avoid the problem described in [JDK-8207015](https://bugs.openjdk.java.net/browse/JDK-8207015) where `jlink` complains about two modules (`java.base` and `javafx.graphics`) deliver the same file(s). That works as long as the set of Microsoft DLLs delivered by the JDK is from the same or newer version of Microsoft Visual Studio. This means that you can't take, for example, JDK 11.0.x and run the latest version of JavaFX, since JDK 11.x uses VS 2017 and JavaFX 15 (and later) uses VS 2019. > > Up until now this has just been a minor bug, but we are now at the point where we need to update to VS 2019 for building JavaFX 11.0.15, which means that a jlinked JDK 11.0.X + JavaFX 11.0.15 will no longer work. > > This fix is to add the Microsoft DLLs back into `javafx.graphics.jmod` (i.e., stop excluding them at build time), but deliver them in `bin/javafx` so they don't conflict with the ones delivered by the JDK. > > The changes are: > > 1. `build.gradle` - When creating the jmods on Windows, copy all of the DLLs to a javafx sub-directory > 2. `NativeLibLoader.java` - in the case of JavaFX modules jlinked into the Java runtime, load the libraries first from `${java.home}` rather than always falling back to `System::loadLibrary`. Most of the changes are just simple refactoring. The additional logic is in the new `libDirForJRT` method. > > When running using the SDK or the modules on maven central, there is no change in behavior. > > I've tested this on all platforms, including a test of a custom JDK 11.x created with jlink. On a Windows I tested it on a system where a key VS 2019 runtime library was not present in C:\Windows\System32 and it now runs. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/734 From aghaisas at openjdk.java.net Mon Feb 21 11:43:56 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Mon, 21 Feb 2022 11:43:56 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel In-Reply-To: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: On Thu, 17 Feb 2022 12:57:27 GMT, eduardsdv wrote: > If the InputMethod's node is not in the scene, the default text location point is returned. The fix looks good. I thought about returning `null` if either the scene or the window is null. As we need to fix this corner case, whether returning `null` or the default point (as proposed in this PR) does not matter. Both approaches will work. - Have you verified the sample program attached to the JBS runs successfully with your fix? - I have a very minor formatting comment on the test. modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TextInputControlSkinTest.java line 105: > 103: // and that the default point is returned. > 104: Point2D point = textField.getInputMethodRequests().getTextLocation(0); > 105: assertEquals(new Point2D(0,0), point); Very minor : Please add a space between `0,0` ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From duke at openjdk.java.net Mon Feb 21 12:35:34 2022 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 21 Feb 2022 12:35:34 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel [v2] In-Reply-To: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: > If the InputMethod's node is not in the scene, the default text location point is returned. eduardsdv has updated the pull request incrementally with one additional commit since the last revision: 8281953: Format TextInputControlSkinTest ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/735/files - new: https://git.openjdk.java.net/jfx/pull/735/files/c9c66b47..755444da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=735&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=735&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/735.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/735/head:pull/735 PR: https://git.openjdk.java.net/jfx/pull/735 From duke at openjdk.java.net Mon Feb 21 12:54:57 2022 From: duke at openjdk.java.net (eduardsdv) Date: Mon, 21 Feb 2022 12:54:57 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel [v2] In-Reply-To: References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: On Mon, 21 Feb 2022 11:30:17 GMT, Ajit Ghaisas wrote: >> eduardsdv has updated the pull request incrementally with one additional commit since the last revision: >> >> 8281953: Format TextInputControlSkinTest > > modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/TextInputControlSkinTest.java line 105: > >> 103: // and that the default point is returned. >> 104: Point2D point = textField.getInputMethodRequests().getTextLocation(0); >> 105: assertEquals(new Point2D(0,0), point); > > Very minor : Please add a space between `0,0` I added the space and checked the fix again with the sample program. The fix works, the NullPointer does not occur anymore. ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From fastegal at swingempire.de Mon Feb 21 13:21:59 2022 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Mon, 21 Feb 2022 14:21:59 +0100 Subject: Aw: Sneak preview: cell edit api to support commit-on-focusLost In-Reply-To: References: <20220211180314.Horde.n4MVwEW-gUC9KEIDCi4XJg3@webmail.df.eu> Message-ID: <20220221142159.Horde.UuiqZGfBaMDz5j4QHOYvwQ1@webmail.df.eu> hmm .. yeah, will do .. once it's less sneak and less pre ;) Still fighting .. Though not entirely certain how to work with the sandbox: technically, that would be fork the sandbox, create a branch, merge my changes into that branch and push? And not sure how that would be simpler for others (except when actually cooperating) than now looking/monitoring the changes in my jfx fork? -- Jeanette Zitat von Marius Hanl : > Can you may create a branch at the jfx sandbox repo? > https://github.com/openjdk/jfx-sandbox > ? > Then I can more easily compare and check it out. (and monitor it :)) > ? > -- Marius > ? ? GESENDET:?Freitag, 11. Februar 2022 um 18:03 Uhr > VON:?"Jeanette Winzenburg" > AN:?"openjfx-dev" > BETREFF:?Sneak preview: cell edit api to support commit-on-focusLost > > Hi folks, > > after fixing a bunch of edit-related issues, time feels right for > nudging elephant out of the room :) Which is the bigger goal of > supporting commit-on-focusLost. > > Working on a PoC (ListView/-Cell only) in a branch of my fork > https://github.com/kleopatra/jfx/tree/dokeep-edit-api-editstate with > an overview of suggested changes > https://github.com/kleopatra/swingempire-fx/wiki/CellEditAPI and a > example driver as gist > https://gist.github.com/kleopatra/447344183e017537c21f7905a062396d > > Still rough, but working: all current unit tests still passing (a > bunch of my own not, and the new api is barely tested) and many of the > requested requirements can be implemented (see code in the example and > the table of use-cases in the overview) > > Any feedback - for the good or for the bad - highly welcome :) > > -- Jeanette > > ? From mariushanl at web.de Mon Feb 21 14:47:05 2022 From: mariushanl at web.de (Marius Hanl) Date: Mon, 21 Feb 2022 15:47:05 +0100 Subject: Aw: Re: Sneak preview: cell edit api to support commit-on-focusLost In-Reply-To: <20220221142159.Horde.UuiqZGfBaMDz5j4QHOYvwQ1@webmail.df.eu> References: <20220211180314.Horde.n4MVwEW-gUC9KEIDCi4XJg3@webmail.df.eu> <20220221142159.Horde.UuiqZGfBaMDz5j4QHOYvwQ1@webmail.df.eu> Message-ID: Sounds good. :) I think you just can push the branch, but not sure. I think only people with the 'contributor' title can push to it, which I'm not yet. It might not be simpler, but more visible and on a more common location. But yeah, the look and observing part can also be done in your fork. -- Marius Gesendet: Montag, 21. Februar 2022 um 14:21 Uhr Von: "Jeanette Winzenburg" An: "Marius Hanl" Cc: "openjfx-dev" Betreff: Re: Aw: Sneak preview: cell edit api to support commit-on-focusLost hmm .. yeah, will do .. once it's less sneak and less pre ;) Still fighting .. Though not entirely certain how to work with the sandbox: technically, that would be fork the sandbox, create a branch, merge my changes into that branch and push? And not sure how that would be simpler for others (except when actually cooperating) than now looking/monitoring the changes in my jfx fork? -- Jeanette Zitat von Marius Hanl : > Can you may create a branch at the jfx sandbox repo? > [1]https://github.com/openjdk/jfx-sandbox > > Then I can more easily compare and check it out. (and monitor it :)) > > -- Marius > GESENDET: Freitag, 11. Februar 2022 um 18:03 Uhr > VON: "Jeanette Winzenburg" > AN: "openjfx-dev" > BETREFF: Sneak preview: cell edit api to support commit-on-focusLost > > Hi folks, > > after fixing a bunch of edit-related issues, time feels right for > nudging elephant out of the room :) Which is the bigger goal of > supporting commit-on-focusLost. > > Working on a PoC (ListView/-Cell only) in a branch of my fork > [2]https://github.com/kleopatra/jfx/tree/dokeep-edit-api-editstate with > an overview of suggested changes > [3]https://github.com/kleopatra/swingempire-fx/wiki/CellEditAPI and a > example driver as gist > [4]https://gist.github.com/kleopatra/447344183e017537c21f7905a062396d > > Still rough, but working: all current unit tests still passing (a > bunch of my own not, and the new api is barely tested) and many of the > requested requirements can be implemented (see code in the example and > the table of use-cases in the overview) > > Any feedback - for the good or for the bad - highly welcome :) > > -- Jeanette > > References 1. https://github.com/openjdk/jfx-sandbox 2. https://github.com/kleopatra/jfx/tree/dokeep-edit-api-editstate 3. https://github.com/kleopatra/swingempire-fx/wiki/CellEditAPI 4. https://gist.github.com/kleopatra/447344183e017537c21f7905a062396d From aghaisas at openjdk.java.net Tue Feb 22 05:15:52 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 22 Feb 2022 05:15:52 GMT Subject: RFR: 8281953: NullPointer in InputMethod components in JFXPanel [v2] In-Reply-To: References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: On Mon, 21 Feb 2022 12:35:34 GMT, eduardsdv wrote: >> If the InputMethod's node is not in the scene, the default text location point is returned. > > eduardsdv has updated the pull request incrementally with one additional commit since the last revision: > > 8281953: Format TextInputControlSkinTest Marked as reviewed by aghaisas (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From aghaisas at openjdk.java.net Tue Feb 22 05:22:52 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 22 Feb 2022 05:22:52 GMT Subject: RFR: 8279228 Leak in ScrollPaneSkin, related to touch events In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier wrote: > Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running, > and the node is removed from the Scene, then the animation will never stop, causing a memory leak. > A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property. This simple fix looks good to me. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/701 From arapte at openjdk.java.net Tue Feb 22 08:41:56 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Feb 2022 08:41:56 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView In-Reply-To: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Sat, 19 Feb 2022 11:43:00 GMT, Jay Bhaskar wrote: > Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From duke at openjdk.java.net Tue Feb 22 10:03:30 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 22 Feb 2022 10:03:30 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v2] In-Reply-To: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: > Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'public-sec-bug' of https://github.com/jaybhaskar/jfx into public-sec-bug - 8282134: Certain regex can cause a JS trap in WebView ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/739/files - new: https://git.openjdk.java.net/jfx/pull/739/files/6319c639..a041e77e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=739&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=739&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/739.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/739/head:pull/739 PR: https://git.openjdk.java.net/jfx/pull/739 From duke at openjdk.java.net Tue Feb 22 12:02:58 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 22 Feb 2022 12:02:58 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v2] In-Reply-To: References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Tue, 22 Feb 2022 10:03:30 GMT, Jay Bhaskar wrote: >> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView > > Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'public-sec-bug' of https://github.com/jaybhaskar/jfx into public-sec-bug > - 8282134: Certain regex can cause a JS trap in WebView git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name' command error out as below fatal: Option -m cannot be combined with -c/-C/-F. ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From duke at openjdk.java.net Tue Feb 22 12:43:37 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 22 Feb 2022 12:43:37 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v3] In-Reply-To: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: > Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: 8282134: Certain regex can cause a JS trap in WebView ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/739/files - new: https://git.openjdk.java.net/jfx/pull/739/files/a041e77e..3fad1fc9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=739&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=739&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/739.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/739/head:pull/739 PR: https://git.openjdk.java.net/jfx/pull/739 From arapte at openjdk.java.net Tue Feb 22 13:12:00 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Feb 2022 13:12:00 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v3] In-Reply-To: References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Tue, 22 Feb 2022 12:43:37 GMT, Jay Bhaskar wrote: >> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView > > Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8282134: Certain regex can cause a JS trap in WebView Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From arapte at openjdk.java.net Tue Feb 22 13:20:51 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Feb 2022 13:20:51 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v3] In-Reply-To: References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Tue, 22 Feb 2022 12:43:37 GMT, Jay Bhaskar wrote: >> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView > > Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8282134: Certain regex can cause a JS trap in WebView Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From duke at openjdk.java.net Tue Feb 22 13:20:51 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 22 Feb 2022 13:20:51 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v3] In-Reply-To: References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Tue, 22 Feb 2022 12:43:37 GMT, Jay Bhaskar wrote: >> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView > > Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8282134: Certain regex can cause a JS trap in WebView Author name Change , due to bot comment ?? @jaybhaskar the full name on your profile does not match the author name in this pull requests' [HEAD](https://git.openjdk.java.net/jfx/pull/739/commits/6319c639e244f20e9ff6846c9bdcd04fb189d89d) commit. If this pull request gets integrated then the author name from this pull requests' [HEAD](https://git.openjdk.java.net/jfx/pull/739/commits/6319c639e244f20e9ff6846c9bdcd04fb189d89d) commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork: $ git checkout public-sec-bug $ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name' $ git push ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From kcr at openjdk.java.net Tue Feb 22 13:20:51 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Feb 2022 13:20:51 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v3] In-Reply-To: References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Tue, 22 Feb 2022 12:43:37 GMT, Jay Bhaskar wrote: >> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView > > Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8282134: Certain regex can cause a JS trap in WebView In general, we prefer that you not force push your branch once the associated PR is under review. In this case, it seems that an incorrect Skara message led you to amend the existing commit, rather than adding a new empty commit as intended. I'll file a bug against Skara. ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From kcr at openjdk.java.net Tue Feb 22 13:28:53 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Feb 2022 13:28:53 GMT Subject: RFR: 8282134: Certain regex can cause a JS trap in WebView [v3] In-Reply-To: References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Tue, 22 Feb 2022 12:43:37 GMT, Jay Bhaskar wrote: >> Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView > > Jay Bhaskar has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit: > > 8282134: Certain regex can cause a JS trap in WebView Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From duke at openjdk.java.net Tue Feb 22 14:01:58 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Tue, 22 Feb 2022 14:01:58 GMT Subject: Integrated: 8282134: Certain regex can cause a JS trap in WebView In-Reply-To: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> References: <5RaRheoF6uYa5zlTaOOlOarbspkFqqdjevUo6VD3RXw=.7312697b-1f2d-43e8-a599-6305d1ed9249@github.com> Message-ID: On Sat, 19 Feb 2022 11:43:00 GMT, Jay Bhaskar wrote: > Fix YarrJIT backtrackCharacterClassNonGreedy breakpoint() Certain regex can cause a JS trap in WebView This pull request has now been integrated. Changeset: 73963960 Author: Jay Bhaskar Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/73963960dc6e56fe34d7aa5fb4ce6f6d2f07acc5 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod 8282134: Certain regex can cause a JS trap in WebView Reviewed-by: kcr, arapte ------------- PR: https://git.openjdk.java.net/jfx/pull/739 From duke at openjdk.java.net Tue Feb 22 15:08:55 2022 From: duke at openjdk.java.net (eduardsdv) Date: Tue, 22 Feb 2022 15:08:55 GMT Subject: Integrated: 8281953: NullPointer in InputMethod components in JFXPanel In-Reply-To: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> References: <_exgHEeqW4nIhts4Dcl1sNcweVxYXk6085JvQ47VVGw=.d01dd06c-4cd6-4bd7-ad9a-7cd416454400@github.com> Message-ID: On Thu, 17 Feb 2022 12:57:27 GMT, eduardsdv wrote: > If the InputMethod's node is not in the scene, the default text location point is returned. This pull request has now been integrated. Changeset: a0bb545b Author: Eduard Sedov Committer: Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/a0bb545b21d1139dd95d7ee9dea9298e89666d9b Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod 8281953: NullPointer in InputMethod components in JFXPanel Reviewed-by: aghaisas ------------- PR: https://git.openjdk.java.net/jfx/pull/735 From arapte at openjdk.java.net Tue Feb 22 17:37:22 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Tue, 22 Feb 2022 17:37:22 GMT Subject: RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Message-ID: Include additional stabilization fixes of WebKit 613.1 Sanity testing did not show any concerns. ------------- Commit messages: - Cherry-pick WebKit 613.1 stabilization fixes (2) Changes: https://git.openjdk.java.net/jfx/pull/740/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=740&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282099 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod Patch: https://git.openjdk.java.net/jfx/pull/740.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/740/head:pull/740 PR: https://git.openjdk.java.net/jfx/pull/740 From kcr at openjdk.java.net Tue Feb 22 20:12:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Feb 2022 20:12:57 GMT Subject: RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: <5dRvd6WgFTUMz2fUl7u7m5HQXVTgXrlfv8egMuvrYHc=.e782f815-aecf-4f08-8ad9-3b7e0c3c67e7@github.com> On Tue, 22 Feb 2022 17:15:19 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/740 From jvos at openjdk.java.net Tue Feb 22 20:12:57 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Tue, 22 Feb 2022 20:12:57 GMT Subject: RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 17:15:19 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. I notice changes specific to AArch64 and Linux, so I did a testbuild on Linux AArch64 which was successful. Will test the mac/linux/windows regular builds soon. ------------- PR: https://git.openjdk.java.net/jfx/pull/740 From kcr at openjdk.java.net Wed Feb 23 01:28:49 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Feb 2022 01:28:49 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 01:57:29 GMT, Jay Bhaskar wrote: >> tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 105: >> >>> 103: Platform.runLater(() -> { >>> 104: webView = new WebView(); >>> 105: Scene scene = new Scene(webView,80,60); >> >> This test passes on my Windows system even without the fix. Based on what I see on the screen, I think its because the scene size is too small. I would make it larger (at least 150x100). >> >> Minor: add a space after the commas to separate the args > > space added, i will look this observation on windows I can confirm that even on Mac, the only reason that this test passes -- and it does so either with or without the fix -- is because the window size is too small. You need to make the Scene larger. I recommend this: new Scene(webView, 200, 150); It's generally better to set the size of the scene rather than the stage for tests like this -- especially since you are taking a snapshot of the scene. >> tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 167: >> >>> 165: int line_start_y = start_y + height; >>> 166: String line_color = "rgba(0,0,0,255)"; // color of line >>> 167: for (int i = line_start_y; i < snapshot.getHeight(); i++) { >> >> The snapshot height is irrelevant. You should use thickness minus 6 (3 pixels on each of the top and bottom): >> >> >> i < line_start_y + thickness - 6; > > I think it should be like for (int i = line_start_y; i <= (width - line_start_y -6); i++) , as we need to iterate in x direction No, see my earlier comment. it needs to use thickness (which is the height of the line) not width. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Wed Feb 23 01:28:50 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Feb 2022 01:28:50 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v3] In-Reply-To: <-ZQqNXw5_TKpN4ZWIFMSKt_ZM8MQZb2NJyYaxWGcHbQ=.b01b7e3b-af7d-4739-a8fd-fac98b809119@github.com> References: <-ZQqNXw5_TKpN4ZWIFMSKt_ZM8MQZb2NJyYaxWGcHbQ=.b01b7e3b-af7d-4739-a8fd-fac98b809119@github.com> Message-ID: On Mon, 21 Feb 2022 05:30:36 GMT, Jay Bhaskar wrote: >> The bounding rect.x rect.y is top left corner, and line is being drawn below the bottom, so height and thickness need to be considered. > > for (int i = line_start_y; i <= (width - line_start_y -6); i++) { , this meets the condition of sampling near the right edge You are mixing values that should affect `x` (width) with values that should affect `y` (height and thickness). Using height or thickness to adjust the `x` value or using width to adjust the `y` value is wrong. One thing that might help make it clearer is to use `y` as the name of the loop variable rather than `i`. Another thing that might help is to define a `thickness` constant rather than using 20. Then it will be more obvious where you are mixing x and y. ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Wed Feb 23 01:36:58 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Feb 2022 01:36:58 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v4] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 06:02:32 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Improve style and width iterartion logic I added one more minor formatting comment. The important points are listed as replies to your earlier comments above: The size of the window needs to be larger, and the sampling logic isn't quite right. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 172: > 170: continue; > 171: } > 172: else { Minor: this should be on one line, like this: } else { Alternatively, you can replace the entire if-then-else block with: assertEquals("Pixel color does not match", expected_line_color, actual_line_color); ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From jvos at openjdk.java.net Wed Feb 23 07:30:55 2022 From: jvos at openjdk.java.net (Johan Vos) Date: Wed, 23 Feb 2022 07:30:55 GMT Subject: RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 17:15:19 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. Ok on mac/linux/win x86_64 and on linux aarch64 ------------- Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/740 From arapte at openjdk.java.net Wed Feb 23 08:58:54 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Wed, 23 Feb 2022 08:58:54 GMT Subject: Integrated: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 17:15:19 GMT, Ambarish Rapte wrote: > Include additional stabilization fixes of WebKit 613.1 > Sanity testing did not show any concerns. This pull request has now been integrated. Changeset: 6f201f7a Author: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/6f201f7a02dba14328d183e7d0db5dede4416ce4 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Reviewed-by: kcr, jvos ------------- PR: https://git.openjdk.java.net/jfx/pull/740 From aghaisas at openjdk.java.net Wed Feb 23 10:00:53 2022 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Wed, 23 Feb 2022 10:00:53 GMT Subject: RFR: 8282100: Missed top/left bouncing for ScrollPane on Raspberry Pi with Touchscreen In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 15:21:49 GMT, Alexander Scherbatiy wrote: > There is the bouncing when scrolling a node on a ScrollPane to the right/bottom (the node on the scroll pane is scrolled further than its width/height so the background is visible and then automatically is scrolled back to the node bounds) on Raspberry Pi with Touchscreen. > There is no bouncing when node is scrolled to the left/top. > > The fix updates ScrollPaneSkin.updatePosX()/updatePosY() methods to not discard out of the range top/left minX/Y values in case the touch is supported. The change looks correct. I verified that it does not have any side effect on non-touch devices (it is obvious from the code changes as well). I did not test on the platform this PR is intended for. ------------- Marked as reviewed by aghaisas (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/736 From mariushanl at web.de Wed Feb 23 11:35:34 2022 From: mariushanl at web.de (Marius Hanl) Date: Wed, 23 Feb 2022 12:35:34 +0100 Subject: ArrayIndexOutOfBoundsException when disconnecting screen Message-ID: I get an ArrayIndexOutOfBoundsException sometimes when I disconnect my screen(s). Setup: I have a laptop with a docking station attached. The docking station is connected to two screen, so when I disconnect it 2 screen will be 'lost'. The following stacktrace is visible and the application is completely black and unresponsive: java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1 at com.sun.prism.d3d.D3DPipeline.getD3DResourceFactory(D3DPipeline.java:21 7) at com.sun.prism.d3d.D3DPipeline.getResourceFactory(D3DPipeline.java:284) at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.validate(PPSRenderer. java:101) at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP SRenderer.java:221) at com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP SRenderer.java:67) at com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479) at com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(Node EffectInput.java:228) at com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131 ) at com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185) at com.sun.scenario.effect.Offset.filter(Offset.java:160) at com.sun.scenario.effect.Merge.filter(Merge.java:148) at com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70) at com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper .java:166) at com.sun.javafx.sg.prism.EffectFilter.render(EffectFilter.java:61) at com.sun.javafx.sg.prism.NGNode.renderEffect(NGNode.java:2384) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2069) at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) at com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) ... ( a lot of doRender(..), renderContent(..) calls... ) at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java: 92) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors .java:515) at java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureT ask.java:305) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE xecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool Executor.java:628) at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumR enderer.java:126) at java.base/java.lang.Thread.run(Thread.java:829) ----------------------------------------------------------------------- ------------------------------------------------------- Now my question: A naive fix would be an array check here but does someone has more information about the code here? And more interesting: Is there a way to write tests for this? Maybe with simulating/faking screens and then 'faking' a screen disconnect? -- Marius From perini.davide at dpsoftware.org Wed Feb 23 13:03:27 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Wed, 23 Feb 2022 14:03:27 +0100 Subject: Check if a label is ellipsized and then add a tooltip Message-ID: <17f26aded18.2882.3c8a1e3a2388806d058c6e4a23c6ecab@dpsoftware.org> Hi, I have a label inside a gridpane. It is possible to check if the label is ellipsized and if yes, add a tootltip to let the user read the entire label when overing the label with the mouse? Thanks Davide From kcr at openjdk.java.net Wed Feb 23 14:53:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Feb 2022 14:53:59 GMT Subject: RFR: 8279228 Leak in ScrollPaneSkin, related to touch events In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier wrote: > Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running, > and the node is removed from the Scene, then the animation will never stop, causing a memory leak. > A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property. Marked as reviewed by kcr (Lead). ------------- PR: https://git.openjdk.java.net/jfx/pull/701 From fkirmaier at openjdk.java.net Wed Feb 23 16:16:57 2022 From: fkirmaier at openjdk.java.net (Florian Kirmaier) Date: Wed, 23 Feb 2022 16:16:57 GMT Subject: Integrated: 8279228 Leak in ScrollPaneSkin, related to touch events In-Reply-To: References: Message-ID: On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier wrote: > Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or mouseDown is true, the sbTouch animation is running, > and the node is removed from the Scene, then the animation will never stop, causing a memory leak. > A simple fix is to also check, whether the Node is visible, by checking the "isTreeShowing" property. This pull request has now been integrated. Changeset: adf1da42 Author: Florian Kirmaier Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/adf1da42de07aba5af07c67a4e756db52203256d Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8279228: Leak in ScrollPaneSkin, related to touch events Reviewed-by: aghaisas, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/701 From mhanl at openjdk.java.net Wed Feb 23 22:33:44 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 23 Feb 2022 22:33:44 GMT Subject: RFR: 8251483: TableCell: NPE on modifying item's list Message-ID: This PR fixes an issue where the item of the table row is null, although the cell itself is not empty (non null value). The fix is to call `indexChanged(..)` immediately after the index was changed, but before all `indexProperty()` listener are notified. The then notified listener in `TableRowSkinBase` will update the underlying cells, which will eventually result in an call to `updateItem(..)`, where the NPE happened (and now not anymore, since the table row is now correctly setup before). There is one special case: When the index didn't changed at all, we manually call `indexChanged(..)` (basically just like before) since when a property is not changed, `invalidated()` is not called, but we need to notify subclasses that `updateIndex(..)` was called. ------------- Commit messages: - 8251483: indexChanged(..) is now called earlier to update the underlying item first before the listener which reacts to the index change are notified. Changes: https://git.openjdk.java.net/jfx/pull/741/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=741&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251483 Stats: 75 lines in 3 files changed: 67 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/741.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/741/head:pull/741 PR: https://git.openjdk.java.net/jfx/pull/741 From mhanl at openjdk.java.net Wed Feb 23 22:43:58 2022 From: mhanl at openjdk.java.net (Marius Hanl) Date: Wed, 23 Feb 2022 22:43:58 GMT Subject: RFR: 8251483: TableCell: NPE on modifying item's list [v2] In-Reply-To: References: Message-ID: > This PR fixes an issue where the item of the table row is null, although the cell itself is not empty (non null value). > > The fix is to call `indexChanged(..)` immediately after the index was changed, but before all `indexProperty()` listener are notified. > The then notified listener in `TableRowSkinBase` will update the underlying cells, which will eventually result in an call to `updateItem(..)`, where the NPE happened (and now not anymore, since the table row is now correctly setup before). > > There is one special case: When the index didn't changed at all, we manually call `indexChanged(..)` (basically just like before) since when a property is not changed, `invalidated()` is not called, but we need to notify subclasses that `updateIndex(..)` was called. Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: 8251483: Updated copyright year ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/741/files - new: https://git.openjdk.java.net/jfx/pull/741/files/5f65b82c..23921bf2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=741&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=741&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/741.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/741/head:pull/741 PR: https://git.openjdk.java.net/jfx/pull/741 From kevin.rushforth at oracle.com Wed Feb 23 22:54:14 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Feb 2022 14:54:14 -0800 Subject: ArrayIndexOutOfBoundsException when disconnecting screen In-Reply-To: References: Message-ID: <6a09f4fa-3b05-21a3-d14e-66f8a8a0a463@oracle.com> I spent a fair bit of time simulating and testing the D3DERR_DEVICEREMOVED cases for RDP disconnect to fix JDK-8239589 [1], but detaching a screen, which will change the number of active adapters, is a somewhat different case (I'm not sure how easy it would be to simulate it). It's very likely that it isn't handled in a robust manner. Do you know whether you need to disconnect 2 screens to reproduce this, or would disconnecting a single external monitor cause it? Based on the stack trace, it looks like the D3DResourceFactory array has been recreated with the reduced number of adapters (1), but the old screen is still being used by the instance of PPSRenderer. Can you file a bug with the stack trace, and as much information about how to reproduce it as you can. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8239589 On 2/23/2022 3:35 AM, Marius Hanl wrote: > I get an ArrayIndexOutOfBoundsException sometimes when I disconnect my > screen(s). > Setup: I have a laptop with a docking station attached. The docking > station is connected to two screen, so when I disconnect it 2 screen > will be 'lost'. > > The following stacktrace is visible and the application is completely > black and unresponsive: > java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for > length 1 > at > com.sun.prism.d3d.D3DPipeline.getD3DResourceFactory(D3DPipeline.java:21 > 7) > at > com.sun.prism.d3d.D3DPipeline.getResourceFactory(D3DPipeline.java:284) > at > com.sun.scenario.effect.impl.prism.ps.PPSRenderer.validate(PPSRenderer. > java:101) > at > com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP > SRenderer.java:221) > at > com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP > SRenderer.java:67) > at > com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479) > at > com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(Node > EffectInput.java:228) > at > com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131 > ) > at > com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185) > at com.sun.scenario.effect.Offset.filter(Offset.java:160) > at com.sun.scenario.effect.Merge.filter(Merge.java:148) > at > com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70) > at > com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper > .java:166) > at > com.sun.javafx.sg.prism.EffectFilter.render(EffectFilter.java:61) > at com.sun.javafx.sg.prism.NGNode.renderEffect(NGNode.java:2384) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2069) > at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964) > at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270) > at > com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579) > at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072) > ... ( a lot of doRender(..), renderContent(..) calls... ) > at > com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480) > at > com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329) > at > com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java: > 92) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors > .java:515) > at > java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureT > ask.java:305) > at > java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java) > at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE > xecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool > Executor.java:628) > at > com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumR > enderer.java:126) > at java.base/java.lang.Thread.run(Thread.java:829) > > ----------------------------------------------------------------------- > ------------------------------------------------------- > > Now my question: > A naive fix would be an array check here but does someone has more > information about the code here? > And more interesting: Is there a way to write tests for this? Maybe > with simulating/faking screens and then 'faking' a screen disconnect? > > -- Marius From kevin.rushforth at oracle.com Thu Feb 24 00:21:48 2022 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Feb 2022 16:21:48 -0800 Subject: Check if a label is ellipsized and then add a tooltip In-Reply-To: <17f26aded18.2882.3c8a1e3a2388806d058c6e4a23c6ecab@dpsoftware.org> References: <17f26aded18.2882.3c8a1e3a2388806d058c6e4a23c6ecab@dpsoftware.org> Message-ID: <14456fac-d9dc-e602-86d3-8b30ed2a48f5@oracle.com> I don't know of a way to determine whether the text of a labeled is currently being displayed truncated with ellipses. There isn't a (read-only) overrun or displayedText property, either of which would allow an app to know. The only thing I can think of to work around this is to estimate the size that the text would need and compare it to the available size. -- Kevin On 2/23/2022 5:03 AM, Davide Perini wrote: > Hi, > I have a label inside a gridpane. > > It is possible to check if the label is ellipsized and if yes, add a > tootltip to let the user read the entire label when overing the label > with the mouse? > > Thanks > Davide From almatvee at openjdk.java.net Thu Feb 24 02:36:45 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Feb 2022 02:36:45 GMT Subject: RFR: 8280840: Update libFFI to 3.4.2 Message-ID: LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. ------------- Commit messages: - 8280840: Update libFFI to 3.4.2 [v2] - 8280840: Update libFFI to 3.4.2 Changes: https://git.openjdk.java.net/jfx/pull/738/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=738&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280840 Stats: 3463 lines in 34 files changed: 927 ins; 38 del; 2498 mod Patch: https://git.openjdk.java.net/jfx/pull/738.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/738/head:pull/738 PR: https://git.openjdk.java.net/jfx/pull/738 From almatvee at openjdk.java.net Thu Feb 24 03:07:57 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Feb 2022 03:07:57 GMT Subject: RFR: 8280840: Update libFFI to 3.4.2 [v2] In-Reply-To: References: Message-ID: > LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8280840: Update libFFI to 3.4.2 [v3] ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/738/files - new: https://git.openjdk.java.net/jfx/pull/738/files/2ca3a52a..a06a3e65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=738&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=738&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/738.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/738/head:pull/738 PR: https://git.openjdk.java.net/jfx/pull/738 From almatvee at openjdk.java.net Thu Feb 24 03:07:58 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 24 Feb 2022 03:07:58 GMT Subject: RFR: 8280840: Update libFFI to 3.4.2 In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 07:45:43 GMT, Alexander Matveev wrote: > LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. [v2] - Fixed TAB issue. [v3] - Fixed space alignment issue in aarch64/ffitarget.h. ------------- PR: https://git.openjdk.java.net/jfx/pull/738 From arapte at openjdk.java.net Thu Feb 24 13:24:21 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Thu, 24 Feb 2022 13:24:21 GMT Subject: RFR: 8269115: WebView paste event contains old data In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 11:13:20 GMT, Jay Bhaskar wrote: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. The fix itself looks good. Suggested few minor changes. Regarding test: Observed that the test does not fail without this fix. Please recheck. Also, I would recommend to add new tests to test the behavior mentioned in JBS, and modify any pre-existing tests if they now become invalid with fix. modules/javafx.web/src/main/native/Source/WebCore/platform/java/DataObjectJava.h line 133: > 131: Vector types; > 132: types.appendRange(m_availMimeTypes.begin(), m_availMimeTypes.end()); > 133: //returns MIME Types available in clipboard.z Minor: The comment should be the first line in the method, as it was before this. The character z at the end must be unintended. modules/javafx.web/src/main/native/Source/WebCore/platform/java/PasteboardJava.cpp line 240: > 238: // TODO: setURL, setFiles, setData, setHtml (needs URL) > 239: data->setPlainText(jGetPlainText()); > 240: data->setData(DataObjectJava::mimeHTML(),jGetPlainText()); Minor: Please add a space after `,` modules/javafx.web/src/test/java/test/javafx/scene/web/HTMLEditingTest.java line 73: > 71: Clipboard.getSystemClipboard().setContent(content); > 72: > 73: The extra line is not required and would recommend to remove. ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Thu Feb 24 15:37:11 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Thu, 24 Feb 2022 15:37:11 GMT Subject: RFR: 8269115: WebView paste event contains old data In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 12:42:49 GMT, Ambarish Rapte wrote: >> Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. >> Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. > > modules/javafx.web/src/main/native/Source/WebCore/platform/java/DataObjectJava.h line 133: > >> 131: Vector types; >> 132: types.appendRange(m_availMimeTypes.begin(), m_availMimeTypes.end()); >> 133: //returns MIME Types available in clipboard.z > > Minor: The comment should be the first line in the method, as it was before this. > The character z at the end must be unintended. done > modules/javafx.web/src/main/native/Source/WebCore/platform/java/PasteboardJava.cpp line 240: > >> 238: // TODO: setURL, setFiles, setData, setHtml (needs URL) >> 239: data->setPlainText(jGetPlainText()); >> 240: data->setData(DataObjectJava::mimeHTML(),jGetPlainText()); > > Minor: Please add a space after `,` done > modules/javafx.web/src/test/java/test/javafx/scene/web/HTMLEditingTest.java line 73: > >> 71: Clipboard.getSystemClipboard().setContent(content); >> 72: >> 73: > > Minor: The extra line is not required and would recommend to remove. done ------------- PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Thu Feb 24 16:05:41 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Thu, 24 Feb 2022 16:05:41 GMT Subject: RFR: 8269115: WebView paste event contains old data [v2] In-Reply-To: References: Message-ID: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: PR commnets applied ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/729/files - new: https://git.openjdk.java.net/jfx/pull/729/files/62d16a39..129f437b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Thu Feb 24 16:37:12 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Thu, 24 Feb 2022 16:37:12 GMT Subject: RFR: 8269115: WebView paste event contains old data [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 16:05:41 GMT, Jay Bhaskar wrote: >> Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. >> Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > PR commnets applied The commit was before the latest webkit update , yes the test pass without fix, i will investigate and apply the required change ------------- PR: https://git.openjdk.java.net/jfx/pull/729 From kcr at openjdk.java.net Thu Feb 24 19:18:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 19:18:29 GMT Subject: [jfx11u] RFR: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded Message-ID: Clean backport of this test-only fix to `jfx11u`. ------------- Commit messages: - 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded Changes: https://git.openjdk.java.net/jfx11u/pull/73/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=73&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242505 Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/73.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/73/head:pull/73 PR: https://git.openjdk.java.net/jfx11u/pull/73 From kcr at openjdk.java.net Thu Feb 24 19:19:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 19:19:33 GMT Subject: [jfx11u] RFR: 8223377: JavaFX can crash due to loading the wrong native libraries if system libraries are installed Message-ID: Clean backport to `jfx11u`. This will enable [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) to then be backported cleanly, once that fix is integrated into `jfx` mainline. ------------- Commit messages: - 8223377: JavaFX can crash due to loading the wrong native libraries if system libraries are installed Changes: https://git.openjdk.java.net/jfx11u/pull/74/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=74&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223377 Stats: 19 lines in 1 file changed: 12 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jfx11u/pull/74.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/74/head:pull/74 PR: https://git.openjdk.java.net/jfx11u/pull/74 From duke at openjdk.java.net Thu Feb 24 19:34:28 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Thu, 24 Feb 2022 19:34:28 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down Message-ID: Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. The issue happens because the buttons property is not updated in the framework. Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. ------------- Commit messages: - Resolve formatting errors - Enable buttons property for mouse events Changes: https://git.openjdk.java.net/jfx/pull/742/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278759 Stats: 307 lines in 8 files changed: 296 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/742.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/742/head:pull/742 PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Thu Feb 24 19:40:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 19:40:37 GMT Subject: [jfx17u] RFR: 8281711: Cherry-pick WebKit 613.1 stabilization fixes Message-ID: Clean backport to `jfx17u`. I tested the backports of [JDK-8281711](https://bugs.openjdk.java.net/browse/JDK-8281711), [JDK-8282099](https://bugs.openjdk.java.net/browse/JDK-8282099), and [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) together in the `test-kcr-17.0.3` branch. ------------- Commit messages: - 8281711: Cherry-pick WebKit 613.1 stabilization fixes Changes: https://git.openjdk.java.net/jfx17u/pull/35/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=35&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281711 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod Patch: https://git.openjdk.java.net/jfx17u/pull/35.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/35/head:pull/35 PR: https://git.openjdk.java.net/jfx17u/pull/35 From kcr at openjdk.java.net Thu Feb 24 21:42:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 21:42:10 GMT Subject: [jfx11u] Integrated: 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 19:12:09 GMT, Kevin Rushforth wrote: > Clean backport of this test-only fix to `jfx11u`. This pull request has now been integrated. Changeset: 9d0b5f8d Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/9d0b5f8d8b89dc6b58e20f525bfb3b781d1224af Stats: 12 lines in 2 files changed: 12 ins; 0 del; 0 mod 8242505: Some WebKit tests might fail because Microsoft libraries are not loaded Backport-of: e0ffca32c5c6d98be9e43a4c2b7c1fb7f5216e85 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/73 From kcr at openjdk.java.net Thu Feb 24 21:43:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 21:43:11 GMT Subject: [jfx11u] Integrated: 8223377: JavaFX can crash due to loading the wrong native libraries if system libraries are installed In-Reply-To: References: Message-ID: <4TXl0T37cSCmP1VkJoYLwZ2R0QWMgE0OjFBs2AmrGqM=.344d3ebc-27ba-4334-94c6-f02aa96c6dd7@github.com> On Thu, 24 Feb 2022 19:13:36 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. This will enable [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) to then be backported cleanly, once that fix is integrated into `jfx` mainline. This pull request has now been integrated. Changeset: ddda6e1c Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/ddda6e1c78927b38f457b5db178008d0165b4f12 Stats: 19 lines in 1 file changed: 12 ins; 4 del; 3 mod 8223377: JavaFX can crash due to loading the wrong native libraries if system libraries are installed Backport-of: 8e6744d4e6e35eec49ecb93602b1c73b0c63bed7 ------------- PR: https://git.openjdk.java.net/jfx11u/pull/74 From kcr at openjdk.java.net Thu Feb 24 21:43:20 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 21:43:20 GMT Subject: [jfx17u] Integrated: 8281711: Cherry-pick WebKit 613.1 stabilization fixes In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 19:31:18 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. I tested the backports of [JDK-8281711](https://bugs.openjdk.java.net/browse/JDK-8281711), [JDK-8282099](https://bugs.openjdk.java.net/browse/JDK-8282099), and [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) together in the `test-kcr-17.0.3` branch. This pull request has now been integrated. Changeset: f8332b5a Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/f8332b5aa34420c10b99d1123aa83858a8e5ce84 Stats: 1218 lines in 127 files changed: 767 ins; 169 del; 282 mod 8281711: Cherry-pick WebKit 613.1 stabilization fixes Stabilization fixes from WebKitGTK 2.34.5 Backport-of: 418d3437923fed0a298c48b54214af069e3bb3bd ------------- PR: https://git.openjdk.java.net/jfx17u/pull/35 From kcr at openjdk.java.net Thu Feb 24 21:53:24 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 21:53:24 GMT Subject: [jfx17u] RFR: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Message-ID: Clean backport to `jfx17u`. I tested the backports of [JDK-8281711](https://bugs.openjdk.java.net/browse/JDK-8281711), [JDK-8282099](https://bugs.openjdk.java.net/browse/JDK-8282099), and [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) together in the `test-kcr-17.0.3` branch. ------------- Commit messages: - 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Changes: https://git.openjdk.java.net/jfx17u/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282099 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod Patch: https://git.openjdk.java.net/jfx17u/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/36/head:pull/36 PR: https://git.openjdk.java.net/jfx17u/pull/36 From kcr at openjdk.java.net Thu Feb 24 22:16:18 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 22:16:18 GMT Subject: [jfx17u] Integrated: 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 21:46:20 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. I tested the backports of [JDK-8281711](https://bugs.openjdk.java.net/browse/JDK-8281711), [JDK-8282099](https://bugs.openjdk.java.net/browse/JDK-8282099), and [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) together in the `test-kcr-17.0.3` branch. This pull request has now been integrated. Changeset: dd4cfd04 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/dd4cfd049fbefad1a0c281effeacd47661c703d3 Stats: 186 lines in 11 files changed: 116 ins; 33 del; 37 mod 8282099: Cherry-pick WebKit 613.1 stabilization fixes (2) Backport-of: 6f201f7a02dba14328d183e7d0db5dede4416ce4 ------------- PR: https://git.openjdk.java.net/jfx17u/pull/36 From kcr at openjdk.java.net Fri Feb 25 00:30:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 00:30:16 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 18:46:21 GMT, Hima Bindu Meda wrote: > Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. > It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. > The issue happens because the buttons property is not updated in the framework. > Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. > Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. The fix and test both look good. I verified that the new test fails without your fix and passes with the fix. I left a few suggestions and minor formatting issues. modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 844: > 842: //intermediate mouse events that can change text selection. > 843: && twkProcessMouseEvent(getPage(), me.getID(), > 844: me.getButton(), me.getButtons(), me.getClickCount(), I wonder if `buttonMask` would be a better (more descriptive) name on the Java side, and consequently, in the JNI call? Within WebKit, using `buttons` makes sense, since that's what they call it. This is just a suggestion. I don't mind if you leave it as is. modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 1089: > 1087: } > 1088: final int buttonMask = ((ev.isPrimaryButtonDown() ? WCMouseEvent.BUTTON1 : WCMouseEvent.NOBUTTON) | (ev.isMiddleButtonDown() ? WCMouseEvent.BUTTON2 : WCMouseEvent.NOBUTTON) | > 1089: (ev.isSecondaryButtonDown() ? WCMouseEvent.BUTTON3 : WCMouseEvent.NOBUTTON)); Minor: I would wrap this so each of the three bits is on its own line (so the first line isn't so long). Also, the indentation should either be 8 spaces or line up with the RHS expression on the previous line. modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformMouseEvent.h line 48: > 46: enum SyntheticClickType : int8_t { NoTap, OneFingerTap, TwoFingerTap }; > 47: #if PLATFORM(JAVA) > 48: enum MouseButtonPressed : uint8_t { NoButtonPress = 0, LeftButtonPress, RightButtonPress, MiddleButtonPress = 4 }; Do you think `MouseButtonMask`, `LeftButtonMask`, etc., would be better names than `...Pressed`? modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformMouseEvent.h line 76: > 74: PlatformMouseEvent(const IntPoint& position, const IntPoint& globalPosition, MouseButton button, PlatformEvent::Type type, > 75: int clickCount, bool shiftKey, bool ctrlKey, bool altKey, bool metaKey, WallTime timestamp, double force, > 76: SyntheticClickType syntheticClickType, PointerID pointerId = mousePointerID) I recommend reverting this change, since this is in WebKit shared code and the only change you made is in formatting. It will help avoid future merge conflicts. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 89: > 87: > 88: private static CountDownLatch loadLatch; > 89: private static CountDownLatch startupLatch; I would reverse the order here, since startup latch is triggered first. Alternatively, you can use a single latch and initialize it to 2. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 128: > 126: } > 127: > 128: public String mouseButtonDrag(MouseButton... button) { I recommend changing the name of the parameter to `buttonArray` (or `buttonArr` or just `buttons` if you want it shorter), since this varargs parameter is an array of potentially more than one button. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 137: > 135: for (int i = 0; i < DRAG_DISTANCE; i++) { > 136: final int c = i; > 137: Util.runAndWait(() -> { Minor: I think you can move the `runAndWait` outside the list, although that will change the timing slightly. Whether or not you do this, the indentation is a little off (the first several lines are indented too much and the closing paren for the `Util.runAndWait` isn't lined up). tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 140: > 138: // Move the mouse backwards so that the pointer does not stay on the popup,if any. > 139: robot.mouseMove((int)(scene.getWindow().getX() + scene.getX() + DX - c), > 140: (int)(scene.getWindow().getY() + scene.getY() + DY) ); Minor: you don't need the extra space between the last two ')'. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 150: > 148: }); > 149: > 150: return buttonMask; if you move the `Integer.parseInt` from the caller to here (and change the return type to `int`) it will simplify the callers a bit. Just a suggestion. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 156: > 154: public void testLeftButtonDrag() { > 155: int result = Integer.parseInt(mouseButtonDrag(MouseButton.PRIMARY)); > 156: Assert.assertEquals(LEFT_BUTTON_DRAG,result); Minor: there should be a space after the `,`. Also, you might consider using a static import for `assertEquals`. This applies to all of the test methods. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 174: > 172: public void testLeftMiddleButtonDrag() { > 173: int result = Integer.parseInt(mouseButtonDrag(MouseButton.PRIMARY, MouseButton.MIDDLE)); > 174: Assert.assertEquals((LEFT_BUTTON_DRAG|MIDDLE_BUTTON_DRAG),result); Minor: surround the binary `|` operator with a space on either side. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 201: > 199: new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); > 200: waitForLatch(loadLatch, 10, "Timeout waiting for loading webpage()."); > 201: waitForLatch(startupLatch, 15, "Timeout waiting for FX runtime to start"); Since `startupLatch` will trigger first, you should either switch the two calls, or use a single latch (initialized to 2) with a single call to `waitForLatch`. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 215: > 213: public void resetTest() { > 214: Util.runAndWait(() -> { > 215: robot.mouseRelease(MouseButton.PRIMARY,MouseButton.MIDDLE,MouseButton.SECONDARY); Minor: add a space after each `,` ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Fri Feb 25 00:36:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 00:36:10 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 18:46:21 GMT, Hima Bindu Meda wrote: > Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. > It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. > The issue happens because the buttons property is not updated in the framework. > Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. > Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. @arapte @jaybhaskar Can you also review? ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Fri Feb 25 00:36:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 00:36:10 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 23:59:29 GMT, Kevin Rushforth wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformMouseEvent.h line 76: > >> 74: PlatformMouseEvent(const IntPoint& position, const IntPoint& globalPosition, MouseButton button, PlatformEvent::Type type, >> 75: int clickCount, bool shiftKey, bool ctrlKey, bool altKey, bool metaKey, WallTime timestamp, double force, >> 76: SyntheticClickType syntheticClickType, PointerID pointerId = mousePointerID) > > I recommend reverting this change, since this is in WebKit shared code and the only change you made is in formatting. It will help avoid future merge conflicts. GitHub is showing more context than it should have, so my comment might be confusing. I only meant to suggest that you revert the reformatting of the existing constructor. Everything inside the `#if` looks fine. > move the runAndWait outside the list... I meant "loop" ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From duke at openjdk.java.net Fri Feb 25 03:30:41 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 25 Feb 2022 03:30:41 GMT Subject: RFR: 8269115: WebView paste event contains old data [v3] In-Reply-To: References: Message-ID: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Test case chnaged ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/729/files - new: https://git.openjdk.java.net/jfx/pull/729/files/129f437b..d4da4ee5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Fri Feb 25 07:11:49 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 25 Feb 2022 07:11:49 GMT Subject: RFR: 8269115: WebView paste event contains old data [v4] In-Reply-To: References: Message-ID: > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Test regression according to bug ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/729/files - new: https://git.openjdk.java.net/jfx/pull/729/files/d4da4ee5..dded44a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=02-03 Stats: 31 lines in 1 file changed: 13 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Fri Feb 25 07:21:57 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 25 Feb 2022 07:21:57 GMT Subject: RFR: 8269115: WebView paste event contains old data [v5] In-Reply-To: References: Message-ID: <2OuuE6aSGQBETuMZsonB8urqXqReysxR4iRESR0UYz0=.6fcbb5a4-0b25-443d-ba36-a9fd499d3e21@github.com> > Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. > Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: - formating change - formating change ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/729/files - new: https://git.openjdk.java.net/jfx/pull/729/files/dded44a5..aa75ea4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=729&range=03-04 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/729.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/729/head:pull/729 PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Fri Feb 25 07:21:58 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Fri, 25 Feb 2022 07:21:58 GMT Subject: RFR: 8269115: WebView paste event contains old data [v4] In-Reply-To: References: Message-ID: <1D2A-Fb7Y9xGstBgtjianNgSAxaULnB1BFzQkUFiFrs=.1128947c-34cc-4f6a-a227-3998b50b6816@github.com> On Fri, 25 Feb 2022 07:11:49 GMT, Jay Bhaskar wrote: >> Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. >> Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Test regression according to bug All , requested changes applied. ------------- PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Fri Feb 25 11:15:23 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Fri, 25 Feb 2022 11:15:23 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v2] In-Reply-To: References: Message-ID: > Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. > It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. > The issue happens because the buttons property is not updated in the framework. > Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. > Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Refactor variable names and update the formatting ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/742/files - new: https://git.openjdk.java.net/jfx/pull/742/files/ec32ba93..4f88401f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=00-01 Stats: 60 lines in 7 files changed: 4 ins; 7 del; 49 mod Patch: https://git.openjdk.java.net/jfx/pull/742.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/742/head:pull/742 PR: https://git.openjdk.java.net/jfx/pull/742 From duke at openjdk.java.net Fri Feb 25 11:40:53 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Fri, 25 Feb 2022 11:40:53 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v2] In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 23:53:04 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor variable names and update the formatting > > modules/javafx.web/src/main/java/com/sun/webkit/WebPage.java line 844: > >> 842: //intermediate mouse events that can change text selection. >> 843: && twkProcessMouseEvent(getPage(), me.getID(), >> 844: me.getButton(), me.getButtons(), me.getClickCount(), > > I wonder if `buttonMask` would be a better (more descriptive) name on the Java side, and consequently, in the JNI call? Within WebKit, using `buttons` makes sense, since that's what they call it. This is just a suggestion. I don't mind if you leave it as is. Agree.Updated the name to "buttonMask" and refactored accordingly. > modules/javafx.web/src/main/java/javafx/scene/web/WebView.java line 1089: > >> 1087: } >> 1088: final int buttonMask = ((ev.isPrimaryButtonDown() ? WCMouseEvent.BUTTON1 : WCMouseEvent.NOBUTTON) | (ev.isMiddleButtonDown() ? WCMouseEvent.BUTTON2 : WCMouseEvent.NOBUTTON) | >> 1089: (ev.isSecondaryButtonDown() ? WCMouseEvent.BUTTON3 : WCMouseEvent.NOBUTTON)); > > Minor: I would wrap this so each of the three bits is on its own line (so the first line isn't so long). Also, the indentation should either be 8 spaces or line up with the RHS expression on the previous line. Formatted as per comment and aligned. Please review. > modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformMouseEvent.h line 48: > >> 46: enum SyntheticClickType : int8_t { NoTap, OneFingerTap, TwoFingerTap }; >> 47: #if PLATFORM(JAVA) >> 48: enum MouseButtonPressed : uint8_t { NoButtonPress = 0, LeftButtonPress, RightButtonPress, MiddleButtonPress = 4 }; > > Do you think `MouseButtonMask`, `LeftButtonMask`, etc., would be better names than `...Pressed`? As the w3c spec also mentions that buttons gives the current state of the device buttons as a bitmask, MouseButtonMask is more suitable.Made the changes accordingly. > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 89: > >> 87: >> 88: private static CountDownLatch loadLatch; >> 89: private static CountDownLatch startupLatch; > > I would reverse the order here, since startup latch is triggered first. Alternatively, you can use a single latch and initialize it to 2. Used single latch and initialised to 2. > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 128: > >> 126: } >> 127: >> 128: public String mouseButtonDrag(MouseButton... button) { > > I recommend changing the name of the parameter to `buttonArray` (or `buttonArr` or just `buttons` if you want it shorter), since this varargs parameter is an array of potentially more than one button. changed to buttons > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 150: > >> 148: }); >> 149: >> 150: return buttonMask; > > if you move the `Integer.parseInt` from the caller to here (and change the return type to `int`) it will simplify the callers a bit. Just a suggestion. changes done as per the comment. > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 156: > >> 154: public void testLeftButtonDrag() { >> 155: int result = Integer.parseInt(mouseButtonDrag(MouseButton.PRIMARY)); >> 156: Assert.assertEquals(LEFT_BUTTON_DRAG,result); > > Minor: there should be a space after the `,`. Also, you might consider using a static import for `assertEquals`. > > This applies to all of the test methods. done. > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 201: > >> 199: new Thread(() -> Application.launch(TestApp.class, (String[])null)).start(); >> 200: waitForLatch(loadLatch, 10, "Timeout waiting for loading webpage()."); >> 201: waitForLatch(startupLatch, 15, "Timeout waiting for FX runtime to start"); > > Since `startupLatch` will trigger first, you should either switch the two calls, or use a single latch (initialized to 2) with a single call to `waitForLatch`. Added single latch initialised to 2. > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 215: > >> 213: public void resetTest() { >> 214: Util.runAndWait(() -> { >> 215: robot.mouseRelease(MouseButton.PRIMARY,MouseButton.MIDDLE,MouseButton.SECONDARY); > > Minor: add a space after each `,` done. ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From duke at openjdk.java.net Fri Feb 25 11:40:56 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Fri, 25 Feb 2022 11:40:56 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v2] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 00:30:28 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/native/Source/WebCore/platform/PlatformMouseEvent.h line 76: >> >>> 74: PlatformMouseEvent(const IntPoint& position, const IntPoint& globalPosition, MouseButton button, PlatformEvent::Type type, >>> 75: int clickCount, bool shiftKey, bool ctrlKey, bool altKey, bool metaKey, WallTime timestamp, double force, >>> 76: SyntheticClickType syntheticClickType, PointerID pointerId = mousePointerID) >> >> I recommend reverting this change, since this is in WebKit shared code and the only change you made is in formatting. It will help avoid future merge conflicts. > > GitHub is showing more context than it should have, so my comment might be confusing. I only meant to suggest that you revert the reformatting of the existing constructor. Everything inside the `#if` looks fine. Reverted the change from already existing webkit shared code. >> tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 137: >> >>> 135: for (int i = 0; i < DRAG_DISTANCE; i++) { >>> 136: final int c = i; >>> 137: Util.runAndWait(() -> { >> >> Minor: I think you can move the `runAndWait` outside the list, although that will change the timing slightly. >> >> Whether or not you do this, the indentation is a little off (the first several lines are indented too much and the closing paren for the `Util.runAndWait` isn't lined up). > >> move the runAndWait outside the list... > > I meant "loop" updated the indentation ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Fri Feb 25 13:31:59 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 13:31:59 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v2] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 11:15:23 GMT, Hima Bindu Meda wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Refactor variable names and update the formatting All changes look good. While doing final testing, I am seeing test failures on Windows caused by the popup not being dismissed. See below. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 212: > 210: Util.runAndWait(() -> { > 211: robot.mouseRelease(MouseButton.PRIMARY, MouseButton.MIDDLE, MouseButton.SECONDARY); > 212: robot.mouseClick(MouseButton.PRIMARY); I presume clicking the left mouse button is done to dismiss the popup that will happens when dragging with the right mouse button? This doesn't work on Windows, so subsequent tests fail. If you change it to pressing the `ESC` key, then it should work: robot.keyType(KeyCode.ESCAPE); ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Fri Feb 25 13:38:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 13:38:03 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v2] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 13:27:42 GMT, Kevin Rushforth wrote: >> Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor variable names and update the formatting > > tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 212: > >> 210: Util.runAndWait(() -> { >> 211: robot.mouseRelease(MouseButton.PRIMARY, MouseButton.MIDDLE, MouseButton.SECONDARY); >> 212: robot.mouseClick(MouseButton.PRIMARY); > > I presume clicking the left mouse button is done to dismiss the popup that will happens when dragging with the right mouse button? This doesn't work on Windows, so subsequent tests fail. If you change it to pressing the `ESC` key, then it should work: > > > robot.keyType(KeyCode.ESCAPE); Alternatively, moving the mouse up and/or to the left after releasing all the buttons and before clicking the middle button will work (on Windows the popup doesn't display until after you release the middle button, and is displayed at the then-current mouse position). Pressing the ESC seems easier, but it's up to you. ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Fri Feb 25 14:53:02 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 14:53:02 GMT Subject: RFR: 8269115: WebView paste event contains old data [v5] In-Reply-To: <2OuuE6aSGQBETuMZsonB8urqXqReysxR4iRESR0UYz0=.6fcbb5a4-0b25-443d-ba36-a9fd499d3e21@github.com> References: <2OuuE6aSGQBETuMZsonB8urqXqReysxR4iRESR0UYz0=.6fcbb5a4-0b25-443d-ba36-a9fd499d3e21@github.com> Message-ID: On Fri, 25 Feb 2022 07:21:57 GMT, Jay Bhaskar wrote: >> Issue: The DataObject uses m_availMimeTypes as Vector of strings, and appending mime types in pasteboard operation like setPlainText, Hence it will append duplicate mime types in m_availMimeTypes , in this case the length clipboardData.types would be wrong, and duplicates data would be copied to clipboard target. >> Solution: Use ListHashSet data Structure instead of Vector for m_availMimeTypes. > > Jay Bhaskar has updated the pull request incrementally with two additional commits since the last revision: > > - formating change > - formating change The fix looks good to me, but the test still needs additional changes. Then new test should fail without your fix and pass with your fix (as of now it passes either with or without your fix, so it isn't actually testing the fix). Also, I think you might have misunderstood Ambarish's comment about the test. Rather than modifying the existing `clipboardGetDataOnPaste ` test method, I recommend to leave it alone and add a new test method. modules/javafx.web/src/test/java/test/javafx/scene/web/HTMLEditingTest.java line 91: > 89: executeScript("srcInput.defaultValue").toString(), defaultText); > 90: assertEquals("Source clipboard onpaste data", getEngine().executeScript("srcInput.value"). > 91: toString(), clipboardData + defaultText); The expected and actual values are backwards; the first of the two objects being compared should be the expected value. I see that this is a preexisting bug in the test. I recommend fixing this in the new test (while leaving the existing test method as is). modules/javafx.web/src/test/java/test/javafx/scene/web/HTMLEditingTest.java line 96: > 94: assertEquals("Target onpaste data size", getEngine(). > 95: executeScript("document.getElementById(\"clipboardData\").innerText").toString(), > 96: "2"); Same comment as above about expected and actual being backwards. ------------- PR: https://git.openjdk.java.net/jfx/pull/729 From duke at openjdk.java.net Fri Feb 25 17:54:48 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Fri, 25 Feb 2022 17:54:48 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v3] In-Reply-To: References: Message-ID: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> > Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. > It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. > The issue happens because the buttons property is not updated in the framework. > Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. > Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: Use ESC key so that the popup, if any, disappears ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/742/files - new: https://git.openjdk.java.net/jfx/pull/742/files/4f88401f..84b7184f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=742&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/742.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/742/head:pull/742 PR: https://git.openjdk.java.net/jfx/pull/742 From duke at openjdk.java.net Fri Feb 25 18:13:02 2022 From: duke at openjdk.java.net (Hima Bindu Meda) Date: Fri, 25 Feb 2022 18:13:02 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v2] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 13:35:16 GMT, Kevin Rushforth wrote: >> tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 212: >> >>> 210: Util.runAndWait(() -> { >>> 211: robot.mouseRelease(MouseButton.PRIMARY, MouseButton.MIDDLE, MouseButton.SECONDARY); >>> 212: robot.mouseClick(MouseButton.PRIMARY); >> >> I presume clicking the left mouse button is done to dismiss the popup that will happens when dragging with the right mouse button? This doesn't work on Windows, so subsequent tests fail. If you change it to pressing the `ESC` key, then it should work: >> >> >> robot.keyType(KeyCode.ESCAPE); > > Alternatively, moving the mouse up and/or to the left after releasing all the buttons and before clicking the middle button will work (on Windows the popup doesn't display until after you release the middle button, and is displayed at the then-current mouse position). Pressing the ESC seems easier, but it's up to you. Added code to press ESC key.Thanks for the sharing the observation. ------------- PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Fri Feb 25 19:19:58 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 19:19:58 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v3] In-Reply-To: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> References: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> Message-ID: On Fri, 25 Feb 2022 17:54:48 GMT, Hima Bindu Meda wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Use ESC key so that the popup, if any, disappears Looks good. The test now passes for me on all platforms. ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/742 From perini.davide at dpsoftware.org Fri Feb 25 20:45:41 2022 From: perini.davide at dpsoftware.org (Davide Perini) Date: Fri, 25 Feb 2022 21:45:41 +0100 Subject: Check if a label is ellipsized and then add a tooltip In-Reply-To: <14456fac-d9dc-e602-86d3-8b30ed2a48f5@oracle.com> References: <17f26aded18.2882.3c8a1e3a2388806d058c6e4a23c6ecab@dpsoftware.org> <14456fac-d9dc-e602-86d3-8b30ed2a48f5@oracle.com> Message-ID: It's a good workaround even if I would have preferred something built in into the framework... :) Thank you Kevin! Il 24/02/2022 01:21, Kevin Rushforth ha scritto: > I don't know of a way to determine whether the text of a labeled is > currently being displayed truncated with ellipses. There isn't a > (read-only) overrun or displayedText property, either of which would > allow an app to know. > > The only thing I can think of to work around this is to estimate the > size that the text would need and compare it to the available size. > > -- Kevin > > > On 2/23/2022 5:03 AM, Davide Perini wrote: >> Hi, >> I have a label inside a gridpane. >> >> It is possible to check if the label is ellipsized and if yes, add a >> tootltip to let the user read the entire label when overing the label >> with the mouse? >> >> Thanks >> Davide > From kcr at openjdk.java.net Fri Feb 25 23:36:04 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Feb 2022 23:36:04 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: References: Message-ID: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> On Mon, 7 Feb 2022 08:14:50 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with three additional commits since the last revision: > > - Change Dir Path and use local Dir and set data before clearing localstorage test > - Merge branch 'PRLocalstorage' of https://github.com/jaybhaskar/jfx into PRLocalstorage > - Merge branch 'master' into PRLocalstorage You haven't addressed one of my comments on the fix. I'll try to clarify what I meant so we're on the same page. Currently (meaning without your fix), the following check is done right after getting the page: // FIXME: We should consider supporting access/modification to local storage // after calling window.close(). See . if (!page || !page->isClosing()) { if (m_localStorage) return m_localStorage.get(); } There are three cases we might consider: 1. The page is null 2. The page is non-null and is _not_ closing 3. The page is non-null and _is_ closing In the first two cases we currently return the local-storage if it exists. Unless I'm missinsg something, this should also be done for the case of non-null and closing (the third case), which simplifies to unconditionally returning the local-storage if it exists, or: if (m_localStorage) return m_localStorage.get(); If you don't do this, then case 1, the case of a `null` page, will return `nullptr`, which is a change in behavior. The other important part of the change, which you already did, was to remove the `if (page->isClosing() return nullptr;` block. I think those are the only two changes to the existing code that are needed, but it's possible I'm missing something. As for the test, it looks better now. I noted just a few things that could be cleaned up below. modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 861: > 859: // after calling window.close(). See . > 860: if (m_localStorage) > 861: return m_localStorage.get(); This is not needed here if you take my suggestion of doing it above. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 55: > 53: > 54: private static final File LOCAL_STORAGE_DIR = new File("LocalStorageDir"); > 55: private static final File PRE_LOCKED = new File("zoo_local_storage"); This looks like a copy / paste from `UserDataDirectoryTest`, and is unused (and not needed) in this test. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 59: > 57: private static RandomAccessFile preLockedRaf; > 58: private static FileLock preLockedLock; > 59: private static final Random random = new Random(); These are not needed. modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 112: > 110: final WebEngine webEngine = getEngine(); > 111: webEngine.setJavaScriptEnabled(true); > 112: webEngine.setUserDataDirectory(LOCAL_STORAGE_DIR); This should be done for all tests, not just this one. Remember that you shouldn't assume any particular order for the tests (tests are intended to be stateless). modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 126: > 124: //get data > 125: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); > 126: assertEquals(s, "1001"); The arguments should be switched (expected comes first). modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 137: > 135: view.getEngine().executeScript("test_local_storage_set();"); > 136: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); > 137: assertEquals(s, "1001"); Switch arguments. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:24:36 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:24:36 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v4] In-Reply-To: References: Message-ID: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Add Review Changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/a8647839..3f6e815e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=02-03 Stats: 21 lines in 2 files changed: 14 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:28:51 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:28:51 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> References: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> Message-ID: On Fri, 25 Feb 2022 23:09:00 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with three additional commits since the last revision: >> >> - Change Dir Path and use local Dir and set data before clearing localstorage test >> - Merge branch 'PRLocalstorage' of https://github.com/jaybhaskar/jfx into PRLocalstorage >> - Merge branch 'master' into PRLocalstorage > > modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 861: > >> 859: // after calling window.close(). See . >> 860: if (m_localStorage) >> 861: return m_localStorage.get(); > > This is not needed here if you take my suggestion of doing it above. Kindly look code ?? ExceptionOr DOMWindow::localStorage() { if (!isCurrentlyDisplayedInFrame()) return nullptr; RefPtr document = this->document(); if (!document) return nullptr; if (!document->securityOrigin().canAccessLocalStorage(nullptr)) return Exception { SecurityError }; // FIXME: We should consider supporting access/modification to local storage // after calling window.close(). See . if (m_localStorage) return m_localStorage.get(); auto* page = document->page(); if (!page) return nullptr; // Check if localstorage setting is disabled, then return nullptr if (!page->settings().localStorageEnabled()) return nullptr; auto storageArea = page->storageNamespaceProvider().localStorageArea(*document); m_localStorage = Storage::create(*this, WTFMove(storageArea)); return m_localStorage.get(); } is it now ok? > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 55: > >> 53: >> 54: private static final File LOCAL_STORAGE_DIR = new File("LocalStorageDir"); >> 55: private static final File PRE_LOCKED = new File("zoo_local_storage"); > > This looks like a copy / paste from `UserDataDirectoryTest`, and is unused (and not needed) in this test. LOCAL_STORAGE_DIR is used by web engine , to store local data in this case ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:35:29 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:35:29 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: <2WoOqKpi6G7yC_BDv2tQtEwhlELJ3Y7Z_sDEpcMYCQw=.d1ddace5-30e5-458e-98b9-dce2054150e7@github.com> References: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> <2WoOqKpi6G7yC_BDv2tQtEwhlELJ3Y7Z_sDEpcMYCQw=.d1ddace5-30e5-458e-98b9-dce2054150e7@github.com> Message-ID: On Sun, 27 Feb 2022 05:30:44 GMT, Jay Bhaskar wrote: >> Agree > > Agree, done Agree ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:35:23 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:35:23 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v5] In-Reply-To: References: Message-ID: > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Add Review Changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/3f6e815e..ef7587c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=03-04 Stats: 14 lines in 1 file changed: 0 ins; 13 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:43:30 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:43:30 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: References: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> Message-ID: On Sun, 27 Feb 2022 05:25:25 GMT, Jay Bhaskar wrote: >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 55: >> >>> 53: >>> 54: private static final File LOCAL_STORAGE_DIR = new File("LocalStorageDir"); >>> 55: private static final File PRE_LOCKED = new File("zoo_local_storage"); >> >> This looks like a copy / paste from `UserDataDirectoryTest`, and is unused (and not needed) in this test. > > LOCAL_STORAGE_DIR is used by web engine , to store local data in this case private static final File LOCAL_STORAGE_DIR = new File("LocalStorageDir"); is required, and i agree not require for private static final File PRE_LOCKED = new File("zoo_local_storage"); ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:35:28 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:35:28 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: References: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> Message-ID: <2WoOqKpi6G7yC_BDv2tQtEwhlELJ3Y7Z_sDEpcMYCQw=.d1ddace5-30e5-458e-98b9-dce2054150e7@github.com> On Sun, 27 Feb 2022 05:30:34 GMT, Jay Bhaskar wrote: >> modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 59: >> >>> 57: private static RandomAccessFile preLockedRaf; >>> 58: private static FileLock preLockedLock; >>> 59: private static final Random random = new Random(); >> >> These are not needed. > > Agree Agree, done ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:35:28 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:35:28 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v3] In-Reply-To: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> References: <9yqpDS1bMO-Lv_212gflqQzxlsxbV7sYbGpqJGd0igo=.e57b4cf0-061f-40ae-96fd-e123b65c7722@github.com> Message-ID: On Fri, 25 Feb 2022 23:15:54 GMT, Kevin Rushforth wrote: >> Jay Bhaskar has updated the pull request incrementally with three additional commits since the last revision: >> >> - Change Dir Path and use local Dir and set data before clearing localstorage test >> - Merge branch 'PRLocalstorage' of https://github.com/jaybhaskar/jfx into PRLocalstorage >> - Merge branch 'master' into PRLocalstorage > > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 59: > >> 57: private static RandomAccessFile preLockedRaf; >> 58: private static FileLock preLockedLock; >> 59: private static final Random random = new Random(); > > These are not needed. Agree > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 112: > >> 110: final WebEngine webEngine = getEngine(); >> 111: webEngine.setJavaScriptEnabled(true); >> 112: webEngine.setUserDataDirectory(LOCAL_STORAGE_DIR); > > This should be done for all tests, not just this one. Remember that you shouldn't assume any particular order for the tests (tests are intended to be stateless). Agree, done > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 126: > >> 124: //get data >> 125: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); >> 126: assertEquals(s, "1001"); > > The arguments should be switched (expected comes first). Agree , done > modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 137: > >> 135: view.getEngine().executeScript("test_local_storage_set();"); >> 136: String s = (String) view.getEngine().executeScript("document.getElementById('key').innerText;"); >> 137: assertEquals(s, "1001"); > > Switch arguments. Agree, done ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:43:28 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:43:28 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v6] In-Reply-To: References: <-7XS7HeFU_nwxe_ArqWQVUE1Dr5YatZlTKfT_AAF9KA=.6fe9c584-10b6-46d1-9ffa-44af93076526@github.com> Message-ID: On Sat, 5 Feb 2022 14:57:50 GMT, Kevin Rushforth wrote: >> modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 857: >> >>> 855: return m_localStorage.get(); >>> 856: } >>> 857: >> >> This will change the behavior for the case where page is null or where the page is valid, but not closing. I think you should partially revert this part of the fix, restoring it as follows: >> >> >> if (m_localStorage) >> return m_localStorage.get(); > > I still think you need to restore this block, but without the check for `isClosing`. Kindly look code ?? ExceptionOr DOMWindow::localStorage() { if (!isCurrentlyDisplayedInFrame()) return nullptr; RefPtr document = this->document(); if (!document) return nullptr; if (!document->securityOrigin().canAccessLocalStorage(nullptr)) return Exception { SecurityError }; // FIXME: We should consider supporting access/modification to local storage // after calling window.close(). See . if (m_localStorage) return m_localStorage.get(); auto* page = document->page(); if (!page) return nullptr; // Check if localstorage setting is disabled, then return nullptr if (!page->settings().localStorageEnabled()) return nullptr; auto storageArea = page->storageNamespaceProvider().localStorageArea(*document); m_localStorage = Storage::create(*this, WTFMove(storageArea)); return m_localStorage.get(); } is it now ok? ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 05:43:27 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 05:43:27 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v6] In-Reply-To: References: Message-ID: <2UjlkEsmOJ_IiYMWbdQJAbUpknJSQwUA0NBv_JXLhhw=.48437588-79ac-466d-80aa-a641e60dde7d@github.com> > Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: Add Review Changes ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/ef7587c2..f320a013 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=703&range=04-05 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703 From duke at openjdk.java.net Sun Feb 27 07:10:25 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Sun, 27 Feb 2022 07:10:25 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v5] In-Reply-To: References: Message-ID: > Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) ----------End Point(x + width, 0) Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: New chnages for line test ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/731/files - new: https://git.openjdk.java.net/jfx/pull/731/files/3246375d..29916450 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=731&range=03-04 Stats: 30 lines in 1 file changed: 9 ins; 7 del; 14 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731 From duke at openjdk.java.net Sun Feb 27 11:53:10 2022 From: duke at openjdk.java.net (Paul) Date: Sun, 27 Feb 2022 11:53:10 GMT Subject: RFR: 8181084: JavaFX show big icons in system menu on macOS with Retina display Message-ID: I hit on JDK-8181084 while making some changes to Scene Builder, so I decided to investigate. Please note: I have not done any Objective-C or MacOS development before. So I would really like some feedback from someone else who knows this stuff better. Anyway, after some googling, I discovered that MacOS uses points values for measurements and not pixels, so the actual fix for this issue was this block in `GlassMenu.m`:- if ((sx > 1) && (sy > 1) && (width > 1) && (height > 1)) { NSSize imgSize = {width / sx, height / sy}; [image setSize: imgSize]; } The rest of the changes were needed in order to get the `scaleX` and `scaleY` values down from `PixelUtils.java` into `GlassMenu.m`. Before this fix:- Screenshot 2022-02-26 at 22 16 30 After this fix:- Screenshot 2022-02-26 at 22 18 17 ------------- Commit messages: - Removing trailing whitespace. - Correctly scales hi-res icons in MacOS system menu items Changes: https://git.openjdk.java.net/jfx/pull/743/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=743&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8181084 Stats: 86 lines in 14 files changed: 84 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/743.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/743/head:pull/743 PR: https://git.openjdk.java.net/jfx/pull/743 From arapte at openjdk.java.net Mon Feb 28 09:38:52 2022 From: arapte at openjdk.java.net (Ambarish Rapte) Date: Mon, 28 Feb 2022 09:38:52 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v3] In-Reply-To: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> References: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> Message-ID: On Fri, 25 Feb 2022 17:54:48 GMT, Hima Bindu Meda wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Use ESC key so that the popup, if any, disappears Fix itself looks good. Suggesting some changes in the test. tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 112: > 110: webEngine = webView.getEngine(); > 111: String URL = this.getClass().getResource("pointerEvent.html").toString(); > 112: webEngine.load( URL); Minor: `webEngine.load(URL);` While you are at it, please remove the double spaces on line 111, 144 tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 113: > 111: String URL = this.getClass().getResource("pointerEvent.html").toString(); > 112: webEngine.load( URL); > 113: webView.getEngine().getLoadWorker().stateProperty().addListener((ov, o, n) -> { The listener ideally should be added before calling `load()`. (before line 111) tests/system/src/test/java/test/robot/javafx/web/PointerEventTest.java line 123: > 121: stage.setScene(scene); > 122: stage.setAlwaysOnTop(true); > 123: Platform.runLater(startupLatch::countDown); This latch countDown should be done when the stage is shown on the screen. It should be: `stage.setOnShown(e -> { Platform.runLater(() -> startupLatch.countDown()); });` ------------- Changes requested by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/742 From sykora at openjdk.java.net Mon Feb 28 09:56:53 2022 From: sykora at openjdk.java.net (Joeri Sykora) Date: Mon, 28 Feb 2022 09:56:53 GMT Subject: RFR: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 16:46:47 GMT, Kevin Rushforth wrote: > The `javafx.graphics` module has a number of native libraries, including the redistributable Microsoft DLLs on Windows. When running an application using the standalone JavaFX SDK, we load all of the needed DLLs from the SDK `bin` directory and everything works as expected. > > When creating the jmods, we currently exclude the Microsoft DLLs from `javafx.graphics.jmod` to avoid the problem described in [JDK-8207015](https://bugs.openjdk.java.net/browse/JDK-8207015) where `jlink` complains about two modules (`java.base` and `javafx.graphics`) deliver the same file(s). That works as long as the set of Microsoft DLLs delivered by the JDK is from the same or newer version of Microsoft Visual Studio. This means that you can't take, for example, JDK 11.0.x and run the latest version of JavaFX, since JDK 11.x uses VS 2017 and JavaFX 15 (and later) uses VS 2019. > > Up until now this has just been a minor bug, but we are now at the point where we need to update to VS 2019 for building JavaFX 11.0.15, which means that a jlinked JDK 11.0.X + JavaFX 11.0.15 will no longer work. > > This fix is to add the Microsoft DLLs back into `javafx.graphics.jmod` (i.e., stop excluding them at build time), but deliver them in `bin/javafx` so they don't conflict with the ones delivered by the JDK. > > The changes are: > > 1. `build.gradle` - When creating the jmods on Windows, copy all of the DLLs to a javafx sub-directory > 2. `NativeLibLoader.java` - in the case of JavaFX modules jlinked into the Java runtime, load the libraries first from `${java.home}` rather than always falling back to `System::loadLibrary`. Most of the changes are just simple refactoring. The additional logic is in the new `libDirForJRT` method. > > When running using the SDK or the modules on maven central, there is no change in behavior. > > I've tested this on all platforms, including a test of a custom JDK 11.x created with jlink. On a Windows I tested it on a system where a key VS 2019 runtime library was not present in C:\Windows\System32 and it now runs. I've created a sample that generates a jlinked runtime for JDK 11 and OpenJFX 19. I verified that it fails with 19-ea+3 and succeeds with this patch. ------------- Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/734 From duke at openjdk.java.net Mon Feb 28 10:01:52 2022 From: duke at openjdk.java.net (Jay Bhaskar) Date: Mon, 28 Feb 2022 10:01:52 GMT Subject: RFR: 8278759 : PointerEvent: buttons property set to 0 when mouse down [v3] In-Reply-To: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> References: <1VlHBWzNOkmW8mn-aMTlD2QG1ChyY1VnOT45_qZkikE=.98296e33-99d5-4cf2-8698-ec5eb0f5dc17@github.com> Message-ID: On Fri, 25 Feb 2022 17:54:48 GMT, Hima Bindu Meda wrote: >> Basically, buttons property is a mask which represents the button/buttons clicked on the mouse. >> It is observed that event.buttons property is set to 0 when there is mouse press or drag event.This behaviour is observed only with javafx webView.Other browsers set the buttons property to 1, when there is mouse press or drag. >> The issue happens because the buttons property is not updated in the framework. >> Added implementation to update and propagate the buttons property from javafx platform to native webkit.Added a robot test case for the same. >> Performed sanity testing with the added implementation and the buttons property is compliant with the specification mentioned in https://w3c.github.io/pointerevents/#the-buttons-property. > > Hima Bindu Meda has updated the pull request incrementally with one additional commit since the last revision: > > Use ESC key so that the popup, if any, disappears + looks good ------------- Marked as reviewed by jaybhaskar at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jfx/pull/742 From kcr at openjdk.java.net Mon Feb 28 13:40:01 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 13:40:01 GMT Subject: Integrated: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 16:46:47 GMT, Kevin Rushforth wrote: > The `javafx.graphics` module has a number of native libraries, including the redistributable Microsoft DLLs on Windows. When running an application using the standalone JavaFX SDK, we load all of the needed DLLs from the SDK `bin` directory and everything works as expected. > > When creating the jmods, we currently exclude the Microsoft DLLs from `javafx.graphics.jmod` to avoid the problem described in [JDK-8207015](https://bugs.openjdk.java.net/browse/JDK-8207015) where `jlink` complains about two modules (`java.base` and `javafx.graphics`) deliver the same file(s). That works as long as the set of Microsoft DLLs delivered by the JDK is from the same or newer version of Microsoft Visual Studio. This means that you can't take, for example, JDK 11.0.x and run the latest version of JavaFX, since JDK 11.x uses VS 2017 and JavaFX 15 (and later) uses VS 2019. > > Up until now this has just been a minor bug, but we are now at the point where we need to update to VS 2019 for building JavaFX 11.0.15, which means that a jlinked JDK 11.0.X + JavaFX 11.0.15 will no longer work. > > This fix is to add the Microsoft DLLs back into `javafx.graphics.jmod` (i.e., stop excluding them at build time), but deliver them in `bin/javafx` so they don't conflict with the ones delivered by the JDK. > > The changes are: > > 1. `build.gradle` - When creating the jmods on Windows, copy all of the DLLs to a javafx sub-directory > 2. `NativeLibLoader.java` - in the case of JavaFX modules jlinked into the Java runtime, load the libraries first from `${java.home}` rather than always falling back to `System::loadLibrary`. Most of the changes are just simple refactoring. The additional logic is in the new `libDirForJRT` method. > > When running using the SDK or the modules on maven central, there is no change in behavior. > > I've tested this on all platforms, including a test of a custom JDK 11.x created with jlink. On a Windows I tested it on a system where a key VS 2019 runtime library was not present in C:\Windows\System32 and it now runs. This pull request has now been integrated. Changeset: e74cbe8b Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e74cbe8b9563a1ab1a21290aa125579bdaa2f29f Stats: 125 lines in 2 files changed: 74 ins; 39 del; 12 mod 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Reviewed-by: arapte, sykora ------------- PR: https://git.openjdk.java.net/jfx/pull/734 From kcr at openjdk.java.net Mon Feb 28 15:03:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 15:03:57 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v6] In-Reply-To: <2UjlkEsmOJ_IiYMWbdQJAbUpknJSQwUA0NBv_JXLhhw=.48437588-79ac-466d-80aa-a641e60dde7d@github.com> References: <2UjlkEsmOJ_IiYMWbdQJAbUpknJSQwUA0NBv_JXLhhw=.48437588-79ac-466d-80aa-a641e60dde7d@github.com> Message-ID: On Sun, 27 Feb 2022 05:43:27 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Add Review Changes The fix and test look good now. I left a couple cleanup comments. I'll reapprove once you fix them. One other minor suggestion: Since all of the test methods now have the same three init statements at the beginning, you might want to make `webEngine` an instance field (in which case you wouldn't need to pass it to `checkLocalStorageAfterWindowClose`), and do the initialization in a `@Before` method. It's up to you. modules/javafx.web/src/main/native/Source/WebCore/page/DOMWindow.cpp line 851: > 849: > 850: // FIXME: We should consider supporting access/modification to local storage > 851: // after calling window.close(). See . The change of moving this block back here looks good. You can delete the obsolete comment now, right? modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 142: > 140: }); > 141: } > 142: } Minor: can you restore the newline at the end of this file? ------------- Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Mon Feb 28 15:03:57 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 15:03:57 GMT Subject: RFR: 8255940: localStorage is null after window.close() [v5] In-Reply-To: References: Message-ID: On Sun, 27 Feb 2022 05:35:23 GMT, Jay Bhaskar wrote: >> Issue: The current implementation of DOMWindow ::localStorage(..) returns null pointer in case of page is being closed. >> Fix: It should not return nullptr , as per the [w3c web storage spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) >> "User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. User agents should always avoid deleting data while a script that could access that data is running." > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > Add Review Changes modules/javafx.web/src/test/java/test/javafx/scene/web/LocalStorageTest.java line 55: > 53: > 54: private static final File LOCAL_STORAGE_DIR = new File("LocalStorageDir"); > 55: private static final File PRE_LOCKED = new File("zoo_local_storage"); > LOCAL_STORAGE_DIR is used by web engine , to store local data in this case Yes, `LOCAL_STORAGE_DIR` is needed. I only meant that `PRE_LOCKED` was unused. GitHub decided to highlight both lines. ------------- PR: https://git.openjdk.java.net/jfx/pull/703 From kcr at openjdk.java.net Mon Feb 28 15:20:54 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 15:20:54 GMT Subject: RFR: 8280020: Underline and line-through not straight in WebView [v5] In-Reply-To: References: Message-ID: On Sun, 27 Feb 2022 07:10:25 GMT, Jay Bhaskar wrote: >> Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. >> Solution: Do not add thickness to the y position of end point of line. >> Start Point(x,y) ----------End Point(x + width, 0) > > Jay Bhaskar has updated the pull request incrementally with one additional commit since the last revision: > > New chnages for line test The cleaned up test looks much better. I'll test it on Mac and Windows. I left a few additional comments. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 57: > 55: private static final CountDownLatch launchLatch = new CountDownLatch(1); > 56: private static final int LINE_THICKNESS = 20; > 57: private static final int SKIP_TEXT_BOUNDARY = 32; What does this constant represent? tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 166: > 164: int start_y = (int)webView.getEngine().executeScript("document.getElementsByTagName('div')[0].getBoundingClientRect().y"); > 165: int height = (int)webView.getEngine().executeScript("document.getElementsByTagName('div')[0].getBoundingClientRect().height"); > 166: int width = (int)webView.getEngine().executeScript("document.getElementsByTagName('div')[0].getBoundingClientRect().width"); Minor: I recommend switching `width` and `height` to match the order of `x` and `y`. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 168: > 166: int width = (int)webView.getEngine().executeScript("document.getElementsByTagName('div')[0].getBoundingClientRect().width"); > 167: > 168: int line_start_x = start_x; You might want to add a small amount (`DELTA`?) to avoid sampling at the edge. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 173: > 171: String line_color = "rgba(0,0,0,255)"; // color of line > 172: System.out.println(line_end_x); > 173: System.out.println(line_start_y); Once you are done debugging the test, you can remove these print statements. tests/system/src/test/java/test/javafx/scene/web/StraightLineTest.java line 177: > 175: for (int x = line_start_x; x < line_end_x; x++) { > 176: String color = colorToString(pr.getColor(x, line_start_y)); > 177: assertEquals(color, line_color); The arguments are backwards (the expected value goes first). ------------- PR: https://git.openjdk.java.net/jfx/pull/731 From kcr at openjdk.java.net Mon Feb 28 16:12:20 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 16:12:20 GMT Subject: [jfx11u] Integrated: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Message-ID: Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. ------------- Commit messages: - 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Changes: https://git.openjdk.java.net/jfx11u/pull/75/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=75&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281089 Stats: 125 lines in 2 files changed: 74 ins; 39 del; 12 mod Patch: https://git.openjdk.java.net/jfx11u/pull/75.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/75/head:pull/75 PR: https://git.openjdk.java.net/jfx11u/pull/75 From kcr at openjdk.java.net Mon Feb 28 16:12:21 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 16:12:21 GMT Subject: [jfx11u] Integrated: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:02:42 GMT, Kevin Rushforth wrote: > Clean backport to `jfx11u`. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This pull request has now been integrated. Changeset: 2f2a07a9 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/2f2a07a96dc4d739faa63183b4d800e01030b494 Stats: 125 lines in 2 files changed: 74 ins; 39 del; 12 mod 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Backport-of: e74cbe8b9563a1ab1a21290aa125579bdaa2f29f ------------- PR: https://git.openjdk.java.net/jfx11u/pull/75 From kcr at openjdk.java.net Mon Feb 28 16:13:12 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 16:13:12 GMT Subject: [jfx11u] RFR: 8265399: Update to Visual Studio 2019 version 16.9.3 Message-ID: Update `jfx11u` to the same version of VS2019 (16.9.3) that is used in mainline jfx. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. ------------- Commit messages: - 8265399: Update to Visual Studio 2019 version 16.9.3 Changes: https://git.openjdk.java.net/jfx11u/pull/76/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=76&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265399 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx11u/pull/76.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/76/head:pull/76 PR: https://git.openjdk.java.net/jfx11u/pull/76 From kcr at openjdk.java.net Mon Feb 28 16:21:29 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 16:21:29 GMT Subject: [jfx17u] RFR: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Message-ID: Clean backport to `jfx17u`. I tested the backports of [JDK-8281711](https://bugs.openjdk.java.net/browse/JDK-8281711), [JDK-8282099](https://bugs.openjdk.java.net/browse/JDK-8282099), and [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) together in the `test-kcr-17.0.3` branch. ------------- Commit messages: - 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Changes: https://git.openjdk.java.net/jfx17u/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=37&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281089 Stats: 125 lines in 2 files changed: 74 ins; 39 del; 12 mod Patch: https://git.openjdk.java.net/jfx17u/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/37/head:pull/37 PR: https://git.openjdk.java.net/jfx17u/pull/37 From kcr at openjdk.java.net Mon Feb 28 16:21:56 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 16:21:56 GMT Subject: [jfx11u] RFR: 8265399: Update to Visual Studio 2019 version 16.9.3 In-Reply-To: References: Message-ID: <6p17u1NQgxO-IKMyFyVKpIzbXm3DHIKTgE9_JQ3YkPA=.3ad48f22-061d-43d8-bd25-c87a3ad9785d@github.com> On Mon, 28 Feb 2022 16:07:10 GMT, Kevin Rushforth wrote: > Update `jfx11u` to the same version of VS2019 (16.9.3) that is used in mainline jfx. I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. This is a prerequisite for the WebKit 613.1 update. Reviewers: @arapte @tiainen @johanvos ------------- PR: https://git.openjdk.java.net/jfx11u/pull/76 From kcr at openjdk.java.net Mon Feb 28 16:41:02 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 16:41:02 GMT Subject: [jfx17u] Integrated: 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start In-Reply-To: References: Message-ID: <4jZCTxo4qhBdaOQ4w_ReYqGT_4u1S2hAI3KtVly1uQ8=.8f8b9af0-9e49-4f67-ba86-dc665be57918@github.com> On Mon, 28 Feb 2022 16:14:18 GMT, Kevin Rushforth wrote: > Clean backport to `jfx17u`. I tested the backports of [JDK-8281711](https://bugs.openjdk.java.net/browse/JDK-8281711), [JDK-8282099](https://bugs.openjdk.java.net/browse/JDK-8282099), and [JDK-8281089](https://bugs.openjdk.java.net/browse/JDK-8281089) together in the `test-kcr-17.0.3` branch. This pull request has now been integrated. Changeset: e20b9213 Author: Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/e20b92134e46c2918b13272c27308ed3580f0504 Stats: 125 lines in 2 files changed: 74 ins; 39 del; 12 mod 8281089: JavaFX built with VS2019 and jlinked into JDK 11.x fails to start Backport-of: e74cbe8b9563a1ab1a21290aa125579bdaa2f29f ------------- PR: https://git.openjdk.java.net/jfx17u/pull/37 From kcr at openjdk.java.net Mon Feb 28 17:17:23 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 17:17:23 GMT Subject: [jfx11u] RFR: 8278980: Update WebKit to 613.1 Message-ID: Nearly clean backport to `jfx11u` (the only conflict was in the copyright years in one of the unit tests). I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. ------------- Commit messages: - 8278980: Update WebKit to 613.1 Changes: https://git.openjdk.java.net/jfx11u/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=77&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278980 Stats: 412962 lines in 6737 files changed: 231442 ins; 135635 del; 45885 mod Patch: https://git.openjdk.java.net/jfx11u/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/77/head:pull/77 PR: https://git.openjdk.java.net/jfx11u/pull/77 From kcr at openjdk.java.net Mon Feb 28 17:17:24 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 17:17:24 GMT Subject: [jfx11u] RFR: 8278980: Update WebKit to 613.1 In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 16:46:36 GMT, Kevin Rushforth wrote: > Nearly clean backport to `jfx11u` (the only conflict was in the copyright years in one of the unit tests). I tested this along with the other VS 2019 and WebKit 613.1 fixes together in the `test-kcr-11.0.15` branch. @arapte Can you review to confirm that the backport was done cleanly? ------------- PR: https://git.openjdk.java.net/jfx11u/pull/77 From duke at openjdk.java.net Mon Feb 28 20:27:41 2022 From: duke at openjdk.java.net (Abhinay Agarwal) Date: Mon, 28 Feb 2022 20:27:41 GMT Subject: RFR: 8282093: LineChart path incorrect when outside lower bound Message-ID: This regression was caused in PR #667 in which I didn't take into account the lower bounds. I have added more tests and one manual test along with the fix. The manual test can be used to identify any future issues with paths outside lower and upper bounds easily. ------------- Commit messages: - remove extraneous whitespace - 8282093: LineChart path incorrect when outside lower bound Changes: https://git.openjdk.java.net/jfx/pull/744/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=744&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282093 Stats: 509 lines in 4 files changed: 486 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jfx/pull/744.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/744/head:pull/744 PR: https://git.openjdk.java.net/jfx/pull/744