Interesting, that exception does not happen on my macOS 15.3 system. The
reproducer somehow also doesn't seem to trigger the
IndexOutOfBoundsExceptions on macOS for me, only on Windows so far. On
Windows, the large alert is shown as a broken stage with no content and
controls for me, which I gu
On Sat, 22 Mar 2025 12:20:17 GMT, John Hendrikx wrote:
> This PR will forward more Label calculations to LabeledSkinBase, as they are
> quite complex, especially when a Graphic is involved which is a full-fledged
> `Node`. More specifically, this solves issues with TitledPane when the
> graphi
On Wed, 26 Mar 2025 20:13:25 GMT, Andy Goryachev wrote:
>> Yeah, the reason I was hesitant to change this is that currently you can set
>> the alignment from CSS in two ways:
>>
>> .titled-pane {
>> -fx-alignment: RIGHT;
>> }
>>
>> Or:
>>
>> .titled-pane > .title
On Wed, 26 Mar 2025 21:36:22 GMT, John Hendrikx wrote:
>> the original code had some logic around `(pos == null)`, I wonder if we need
>> to do the same here, that is, derive the effective alignment from both
>> values?
>
> That was just for deriving the `hpos` and `vpos` fields, which are no l
On Wed, 26 Mar 2025 14:36:39 GMT, Andy Goryachev wrote:
>> Fixed several issues found in importing RTF text:
>>
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>>
>> Also, HTML copy suffered from the following issues:
>
On Wed, 26 Mar 2025 19:20:54 GMT, Andy Goryachev wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java
>> line 514:
>>
>>> 512: */
>>> 513:
>>> 514: double labelPrefWidth =
>>> TitledPaneSkin.super.computePrefWidth(height, 0, 0,
> Windows programs may reuse a clipboard buffer that is larger than the new
> content. In this case de NUL terminator is not at the end of the buffer, but
> within it.
> The current implementation copys the whole buffer into a text field,
> including the NUL terminator and the remaining chars.
On Wed, 26 Mar 2025 19:57:59 GMT, John Hendrikx wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java
>> line 160:
>>
>>> 158: registerChangeListener(titleRegion.alignmentProperty(), e ->
>>> pos = titleRegion.getAlignment());
>>> 159:
>>> 160:
On Tue, 25 Mar 2025 17:59:41 GMT, Andy Goryachev wrote:
>> This PR will forward more Label calculations to LabeledSkinBase, as they are
>> quite complex, especially when a Graphic is involved which is a full-fledged
>> `Node`. More specifically, this solves issues with TitledPane when the
>> g
On Wed, 26 Mar 2025 18:45:49 GMT, Martin Fox wrote:
>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line
>> 279:
>>
>>> 277: * @since 25
>>> 278: */
>>> 279: public static final int MAX_NESTED_EVENT_LOOPS = 200;
>>
>> I would rather not make this constan
On Wed, 26 Mar 2025 18:22:50 GMT, Andy Goryachev wrote:
>> Martin Fox has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Set limit on nested event loop count to 200 which seems less arbitrary
>> - The max nested event loop limit is now p
On Wed, 26 Mar 2025 14:11:34 GMT, Michael Strauß wrote:
>> The tests show that only LF "\n" is rendered as a new line, there is no need
>> to add more restrictions that is not needed
>> and the same was tested by @andy-goryachev-oracle previously in the comments
>> and it confirms the same.
>
>
On Wed, 26 Mar 2025 17:37:39 GMT, Martin Fox wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates too
>> many nested ev
On Wed, 26 Mar 2025 17:37:39 GMT, Martin Fox wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates too
>> many nested ev
Hey Martin,
thank you for looking into this. The initial StackOverflow is a result
of me forcing to reproduce the bounds IndexOutOfBoundsException. The
StackOverflow can be ignored, it was merely the best method I found to
transition the scene graph into a state where the
IndexOutOfBoundsExce
> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
> terminates the Java app. The situation arises when a JavaFX app creates too
> many nested event loops from within Platform.runLater runnables.
>
> T
Yes, thank you Christopher for providing a reproducible test case!
I was able to trigger the problem on my Mac on the first try. Since I’m using a
modified version of JavaFX the system didn’t crash but instead hit a Java stack
overflow error and produced a very long stack trace.
At least on the
On Wed, 26 Mar 2025 08:30:08 GMT, Michael Strauß wrote:
> Why would an application need to be tested against a specific limit?
If you knew that your app could hit a limit and the limit could vary by
platform you would want to focus your testing on the platform with the lowest
limit. In any cas
> Additional RichTextArea API tests.
Andy Goryachev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 23 commits:
- Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
- Merge remote-tracking branch 'origin/master'
> Please refer to
>
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>
> The RichTextArea control
> ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom
> control that needs non-trivial navigation within complex or wrapped text
> needs a p
> Fixed several issues found in importing RTF text:
>
> - charset translation (brought back removed code)
> - missing font size attribute
> - missing strike-through attribute
>
> Also, HTML copy suffered from the following issues:
>
> - incorrect font size
> - incorrect handling of boolean chara
On Tue, 25 Mar 2025 21:55:54 GMT, Andy Goryachev wrote:
>> Changed the StubTextLayout to use product PrismTextLayout with much
>> simplified glyph layout (via stubbed fonts). The new layout assumes all the
>> glyphs are squares of font size, while the bold type face produces wider
>> glyphs (
On Fri, 20 Dec 2024 22:23:11 GMT, Andy Goryachev wrote:
> Changed the StubTextLayout to use product PrismTextLayout with much
> simplified glyph layout (via stubbed fonts). The new layout assumes all the
> glyphs are squares of font size, while the bold type face produces wider
> glyphs (by 1
On Wed, 26 Mar 2025 13:30:48 GMT, Ziad El Midaoui
wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java
>> line 735:
>>
>>> 733: promptNode.fontProperty().bind(getSkinnable().fontProperty());
>>> 734:
>>> 735:
>>> promptNode.textProperty
On Wed, 26 Mar 2025 08:44:28 GMT, Michael Strauß wrote:
>> Ziad El Midaoui has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unused imports and code
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.
On Tue, 25 Mar 2025 21:55:54 GMT, Andy Goryachev wrote:
>> Changed the StubTextLayout to use product PrismTextLayout with much
>> simplified glyph layout (via stubbed fonts). The new layout assumes all the
>> glyphs are squares of font size, while the bold type face produces wider
>> glyphs (
On Tue, 25 Mar 2025 22:53:55 GMT, Ziad El Midaoui
wrote:
>> Added multi line prompt support for TextArea this will provide the ability
>> to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally wi
On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox wrote:
>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the
>> equivalent wrapper NSRunLoop methods). When the limit is hit the OS
>> terminates the Java app. The situation arises when a JavaFX app creates too
>> many nested ev
On Tue, 25 Mar 2025 20:47:21 GMT, Martin Fox wrote:
> For customers creating cross-platform apps having the limit be the same on
> all platforms would simplify testing. If this was per-platform we would need
> to publish the limits since developers would want to test on the most
> restrictive
On Tue, 25 Mar 2025 18:39:08 GMT, Oliver Schmidtmer
wrote:
>> Windows programs may reuse a clipboard buffer that is larger than the new
>> content. In this case de NUL terminator is not at the end of the buffer, but
>> within it.
>> The current implementation copys the whole buffer into a tex
30 matches
Mail list logo
