On Fri, 12 Jan 2024 00:00:43 GMT, Kevin Rushforth wrote:
> Backport the changes to the README and CONTTRIBUTING guidelines for update
> releases. There are two commits: the first is a clean backport of the fix
> that went into jfx21u. The second is a simple substitution changing 21 to 22
> in
On Thu, 11 Jan 2024 23:11:12 GMT, Kevin Rushforth wrote:
> Updates for the beginning of the 22.0.1 release.
Marked as reviewed by jvos (Reviewer).
-
PR Review: https://git.openjdk.org/jfx22u/pull/1#pullrequestreview-1817553253
On Wed, 10 Jan 2024 21:16:01 GMT, Andy Goryachev wrote:
> I wonder if we should address JDK-8318095 first to be able to test this fix
> fully.
We have another bug [JDK-8319050](https://bugs.openjdk.org/browse/JDK-8319050)
for the issue with `careShape()` and `rangeShape()`. Do you think it is
On Fri, 12 Jan 2024 00:18:38 GMT, Andy Goryachev wrote:
>> I changed 0 to -1 to figure out if the `getHitInfo` in `PrismTextLayout` is
>> invoked by `Text` or `TextFlow`.
>> Added comment regarding this in `com.sun.javafx.scene.tex.TextLayout`.
>
> @karthikpandelu , the more I think about it, th
On Thu, 11 Jan 2024 23:54:13 GMT, Kevin Rushforth wrote:
>> As described in the JBS bug, there is a long-standing deadlock that happens
>> on macOS between the AWT EDT and the JavaFX Application thread (which on
>> macOS is the AppKit thread) when processing Input Method Events (IME) in a
>> W
On Thu, 11 Jan 2024 10:25:44 GMT, Karthik P K wrote:
>> or, would it make more sense to simply pass a boolean flag instead of magic
>> values?
>
> I changed 0 to -1 to figure out if the `getHitInfo` in `PrismTextLayout` is
> invoked by `Text` or `TextFlow`.
> Added comment regarding this in `co
On Thu, 11 Jan 2024 23:54:13 GMT, Kevin Rushforth wrote:
>> As described in the JBS bug, there is a long-standing deadlock that happens
>> on macOS between the AWT EDT and the JavaFX Application thread (which on
>> macOS is the AppKit thread) when processing Input Method Events (IME) in a
>> W
On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote:
> This PR fixes the border glitch/gap as explained in both linked tickets.
>
> I noted that the `ScrollPane` control does not suffer from this problem,
> although the code is mostly the same as in `VirtualFlow`. The `ScrollPane`
> snaps the
Backport the changes to the README and CONTTRIBUTING guidelines for update
releases. There are two commits: the first is a clean backport of the fix that
went into jfx21u. The second is a simple substitution changing 21 to 22 in the
two files.
-
Commit messages:
- Change 21 --> 22
On Fri, 12 Jan 2024 00:00:43 GMT, Kevin Rushforth wrote:
> Backport the changes to the README and CONTTRIBUTING guidelines for update
> releases. There are two commits: the first is a clean backport of the fix
> that went into jfx21u. The second is a simple substitution changing 21 to 22
> in
> As described in the JBS bug, there is a long-standing deadlock that happens
> on macOS between the AWT EDT and the JavaFX Application thread (which on
> macOS is the AppKit thread) when processing Input Method Events (IME) in a
> WebView node in a JFXPanel.
>
> This PR fixes the deadlock by a
On Thu, 11 Jan 2024 23:11:12 GMT, Kevin Rushforth wrote:
> Updates for the beginning of the 22.0.1 release.
Reviewers: @johanvos or @arapte
-
PR Comment: https://git.openjdk.org/jfx22u/pull/1#issuecomment-1888113845
Updates for the beginning of the 22.0.1 release.
-
Commit messages:
- Empty commit to trigger GHA run
- 8323555: Change JavaFX release version to 22.0.1 in jfx22u
Changes: https://git.openjdk.org/jfx22u/pull/1/files
Webrev: https://webrevs.openjdk.org/?repo=jfx22u&pr=1&range=00
On Thu, 11 Jan 2024 22:59:33 GMT, Andy Goryachev wrote:
>> I can undo the rename so they're not touched. My problem with fixing this
>> is that I then also should do it for `CompoundSelector`, which is just
>> completely unrelated to the intent of this PR. I'm pretty sure that within
>> Java
On Thu, 11 Jan 2024 22:50:32 GMT, John Hendrikx wrote:
>> you are right, this code does not affect performance (I could not hit a
>> break point here either).
>> still, since you are touching these lines, why not do it right?
>
> I can undo the rename so they're not touched. My problem with fix
On Mon, 8 Jan 2024 19:24:14 GMT, Andy Goryachev wrote:
>> I am confused, and maybe I am missing something. As far as I know, this
>> method is not called anywhere. I put a breakpoint in it. JavaFX does not use
>> this method anywhere, nor are Selectors ever used as keys in Sets or Maps.
>>
>>
On Thu, 11 Jan 2024 09:33:09 GMT, Marius Hanl wrote:
>> John Hendrikx 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 eight additional
>> commit
On Thu, 11 Jan 2024 20:35:08 GMT, Andy Goryachev wrote:
>> For some reason the `skinProperty` did not allow to set a new skin when it
>> is the same class as the previous one.
>> This leads to multiple issues:
>> 1. When creating a new skin (same class as previous), the skin will likely
>> inst
On Thu, 11 Jan 2024 20:13:09 GMT, Marius Hanl wrote:
> For some reason the `skinProperty` did not allow to set a new skin when it is
> the same class as the previous one.
> This leads to multiple issues:
> 1. When creating a new skin (same class as previous), the skin will likely
> install list
On Wed, 10 Jan 2024 17:53:46 GMT, Hima Bindu Meda wrote:
> This PR updates webkit to v617.1. Verified build on Mac,Windows and linux.
> Sanity testing looks fine. No issues observed in HelloWebView as well
Looks good. Testing is green.
-
Marked as reviewed by kcr (Lead).
PR Review
For some reason the `skinProperty` did not allow to set a new skin when it is
the same class as the previous one.
This leads to multiple issues:
1. When creating a new skin (same class as previous), the skin will likely
install listener but is then rejected when setting it due to the `skinPropert
On Thu, 11 Jan 2024 19:50:49 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: migrate
On Thu, 11 Jan 2024 19:57:21 GMT, Andy Goryachev wrote:
> Would it be possible to separate the migration from the fix?
Another idea could be to use the full qualified path:
`@org.junit.jupiter.api.Test`. But `@Before` and `@After` are still JUnit 4.
Or we can reduce the change by at least rever
On Thu, 11 Jan 2024 19:50:49 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: migrate
> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
> items were null.
Carl Döbbelin has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8323543: migrates tests to junit 5
-
Changes:
- all: https://git.ope
On Thu, 11 Jan 2024 18:56:13 GMT, Kevin Rushforth wrote:
> Although... I just spotted something. The updated tests use JUnit5 assertions
> into what is otherwise a JUnit4 test. We generally avoid doing this.
Should we use the JUnit5 `@Test` annotation, or migrate the class to JUnit5?
The migra
On Thu, 11 Jan 2024 18:56:03 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - JDK-8323543: refac
> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
> items were null.
Carl Döbbelin has updated the pull request incrementally with two additional
commits since the last revision:
- JDK-8323543: refactors tests and adds accessible attribute test for treetable
- JDK-8
On Thu, 11 Jan 2024 18:33:45 GMT, Andy Goryachev wrote:
> This PR has a very narrow focus to be a candidate for a back port to jfx22
> @kevinrushforth
This seems a safe and targeted fix. I have no objection.
-
PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-18877682
On Thu, 11 Jan 2024 16:48:53 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: add tes
On Thu, 11 Jan 2024 18:53:16 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - JDK-8323543: refac
On Thu, 11 Jan 2024 18:49:42 GMT, Andy Goryachev wrote:
> @Maran23 would you like to double check and sponsor?
sure!
-
PR Comment: https://git.openjdk.org/jfx/pull/1329#issuecomment-1887764274
On Thu, 11 Jan 2024 16:48:53 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: add tes
On Thu, 11 Jan 2024 16:48:53 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: add tes
On Thu, 11 Jan 2024 16:48:53 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: add tes
On Thu, 11 Jan 2024 16:48:53 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: add tes
> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
> items were null.
Carl Döbbelin has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8323543: add test and fix for another npe
-
Changes:
- all: https://
On Wed, 10 Jan 2024 19:09:47 GMT, Carl Döbbelin wrote:
>> This PR fixes a nullpointer in TableSkinUtils that occured when the Tables
>> items were null.
>
> Carl Döbbelin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8323543: clean u
JavaFX 22 is now in Rampdown Phase One (RDP1) [1]. We have forked a new
jfx22 branch [2] for stabilizing the JavaFX 22 release.
Here is the short summary of what this means:
- The master branch of the jfx repo is available for integrating bug
fixes or enhancements for jfx23. Almost all fixes w
On Mon, 8 Jan 2024 21:24:43 GMT, Kevin Rushforth wrote:
> Bump the version number of JavaFX to 23. I will integrate this to master as
> part of forking the jfx22 stabilization branch, which is scheduled for
> Thursday, January 11, 2024 at 16:00 UTC.
This pull request has now been integrated.
On Thu, 11 Jan 2024 11:45:02 GMT, Johan Vos wrote:
>> A listener was added but never removed.
>> This patch removes the listener when the menu it links to is cleared. Fix
>> for https://bugs.openjdk.org/browse/JDK-8319779
>
> Johan Vos has updated the pull request incrementally with one addition
On Wed, 10 Jan 2024 17:53:46 GMT, Hima Bindu Meda wrote:
> This PR updates webkit to v617.1. Verified build on Mac,Windows and linux.
> Sanity testing looks fine. No issues observed in HelloWebView as well
All builds and tests went fine.
-
Marked as reviewed by sykora (Author).
PR
Hi Johan,
I can also try this today, since I have an M1 laptop and have access to
an M2 Mac Mini, both running macOS 14.x.
-- Kevin
On 1/11/2024 12:08 AM, Johan Vos wrote:
Hi Martin,
Thanks for testing this. Just to make sure: the fact that the
systemtest pass, is the problem. It shouldn'
I'm also wondering whether we should check and may improve the focus code rather than introducing two new properties.
I did not yet checked the details.
But I was checking if we could remove the hacky focus stuff/css, e.g. ControlUtils.requestFocusOnControlOnlyIfCurrentFocusOwnerIsChild(..) with
On Wed, 10 Jan 2024 12:31:20 GMT, Florian Kirmaier
wrote:
> As seen in the unit test of the PR, when we click on the area above/below the
> scrollbar the position jumps - but the jump is now not always consistent.
> In the current version on the last cell - the UI always jumps to the top. In
>
> A listener was added but never removed.
> This patch removes the listener when the menu it links to is cleared. Fix for
> https://bugs.openjdk.org/browse/JDK-8319779
Johan Vos has updated the pull request incrementally with one additional commit
since the last revision:
Revert some of the c
On Wed, 10 Jan 2024 21:16:01 GMT, Andy Goryachev wrote:
> Preliminary testing looks ok, though it does suffer from effects of
> JDK-8318095 (and I did remove `this.getScene().` in Text:1042)
>
Thanks @andy-goryachev-oracle for testing and reviewing the PR.
Yes, to fully test this fix we need to
On Wed, 10 Jan 2024 20:13:24 GMT, Andy Goryachev wrote:
>> Karthik P K has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code review changes
>
> tests/system/src/test/java/test/robot/javafx/scene/RTLTextCharacterIndexTest.java
> line 48:
On Wed, 10 Jan 2024 20:31:43 GMT, Andy Goryachev wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line
>> 202:
>>
>>> 200: double x = point.getX();
>>> 201: double y = point.getY();
>>> 202: TextLayout.Hit h = layout.getHitInfo(
On Wed, 10 Jan 2024 23:23:14 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1042:
>>
>>> 1040: int runIndex = 0;
>>> 1041: if (runs.length != 0) {
>>> 1042: if (this.getScene().getNodeOrientation() ==
>>> NodeOri
> In the `getHitInfo()` method of PrismTextLayout, RTL node orientation
> conditions were not considered, hence hit test values such as character index
> and insertion index values were incorrect.
>
> Added checks for RTL orientation of nodes and fixed the issue in
> `getHitInfo()` to calculat
I should add that the inconsistency only happens when running the
systemtests using Gradle.
When I isolate the failing systemtest and run it as a Java process, it
correctly fails on both M2 and Mac/Intel.
At this point, I don't have enough information to create a JBS issue
though. I added debug in
On Fri, 5 Jan 2024 01:45:56 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
>>
On Wed, 10 Jan 2024 23:57:24 GMT, Andy Goryachev wrote:
> It might be a dumb question: would it be possible to avoid creating an
> intermediate container and keep the existing .css files?
Not a dumb question, that is what I tried at first. See also my old PR:
https://github.com/openjdk/jfx/pul
Hi Martin,
Thanks for testing this. Just to make sure: the fact that the
systemtest pass, is the problem. It shouldn't pass. The change in PR 1283
caused regression that I didn't notice on the M2, but I heard the test
correctly fails on M1, and I could confirm it correctly fails on Mac/Intel
as we
> A listener was added but never removed.
> This patch removes the listener when the menu it links to is cleared. Fix for
> https://bugs.openjdk.org/browse/JDK-8319779
Johan Vos has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the un
56 matches
Mail list logo
