I’m currently looking into why the native debug build is crashing. This same
assert fails while running FileReaderTest using the native debug build. For the
time being, you can try building by removing this particular assert statement
for debugging.
— Arun Joseph
> On 12-Mar-2021, at 11:47
On Fri, 12 Mar 2021 14:18:59 GMT, Florian Kirmaier
wrote:
>> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXLaunchTest.java
>> line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2012, 2021, Oracle and/or its affiliates. All rights
>>> reserved.
>>
>> Minor year
On Fri, 12 Mar 2021 21:12:41 GMT, Martin Fox
wrote:
>> I see that the Windows pre-submit test build failed. It's clearly not
>> related to anything in this PR, so it can be ignored.
>>
>> I'll review this PR later (hopefully next week some time), but I have a
>> couple general comments:
>>
On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote:
>> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as
>> expected by more accurately mapping from a Mac key code to a Java key code
>> based on the user’s active keyboard layout (the existing code assumes a US
>>
On Fri, 12 Mar 2021 16:27:27 GMT, Martin Fox
wrote:
> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as
> expected by more accurately mapping from a Mac key code to a Java key code
> based on the user’s active keyboard layout (the existing code assumes a US
> QWERTY
> Fixing a memory leak.
> A node hard references its old parent after CSS layout and getting removed.
> This shouldn't be the case, this is very counterintuitive.
>
> The fix uses a WeakReference in CSSStyleHelper for firstStyleableAncestor.
> This should be fine because the CSS should only
On Fri, 12 Mar 2021 14:27:44 GMT, Florian Kirmaier
wrote:
>> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
>> line 96:
>>
>>> 94: } catch (Exception e) {
>>> 95: throw e;
>>> 96: }
>>
>> line 91: is non reachable code and
This PR adds code to ensure that KeyCodeCombinations match KeyEvents as
expected by more accurately mapping from a Mac key code to a Java key code
based on the user’s active keyboard layout (the existing code assumes a US
QWERTY layout). The new code first identifies a set of Mac keys which can
Hi Kevin,
Unfortunately I don't have a test case. We are using various WebViews in
our production application hence we don't know where/why exactly the
application freezes.
We were hoping that we will be able to identify it using the native debug
build (& attached debugged) but it is now
On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote:
>> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as
>> expected by more accurately mapping from a Mac key code to a Java key code
>> based on the user’s active keyboard layout (the existing code assumes a US
>>
Arun should be able to help you with the crash you are seeing in debug mode.
Regarding the hang, do you have a test case that will reproduce it? A
few different developers have reported similar hangs. We ended up
closing a recently-filed bug, JDK-8260238 [1], because were (and still
are)
On Fri, 12 Mar 2021 07:55:54 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8263402
>> Added new verison of the unit-test
>
>
On Wed, 10 Mar 2021 23:02:07 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
>
On Fri, 12 Mar 2021 14:31:17 GMT, Florian Kirmaier
wrote:
>> tests/system/src/test/java/test/com/sun/javafx/application/InitializeJavaFXBase.java
>> line 80:
>>
>>> 78: System.out.println("Finished launch!");
>>> 79: Assert.fail("Error: No Exception was thrown
On Fri, 12 Mar 2021 11:52:24 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
> Suggested minor changes.
I've seperated the
On Fri, 12 Mar 2021 14:49:41 GMT, Florian Kirmaier
wrote:
>> Fixing deadlock when calling Application.launch in the FXThread after
>> Platform.startup
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8263322
>
> Fixing deadlock when calling Application.launch in the FXThread after
> Platform.startup
Florian Kirmaier has updated the pull request incrementally with two additional
commits since the last revision:
- JDK-8263322
Small changes based on codereview
- JDK-8263322
Some small cleanups
On Thu, 11 Mar 2021 21:58:40 GMT, Kevin Rushforth wrote:
>> Since this touches CSS, it needs a second reviewer.
>
> I think others can review this. I do have a couple questions:
> 1. In general, I don't like the idea of just making everything a weak
> reference, since it often masks a design
On Fri, 12 Mar 2021 09:01:49 GMT, Ambarish Rapte wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
>
On Wed, 10 Mar 2021 23:10:06 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8263322
>> updated the javadoc to mention the new case.
>
>
> Fixing deadlock when calling Application.launch in the FXThread after
> Platform.startup
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8263322
Seperated the unit-tests into seperate files
-
Changes:
-
> Fixing deadlock when calling Application.launch in the FXThread after
> Platform.startup
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8263322
fixed the copyright headers, based on codereview
-
Changes:
On Fri, 12 Mar 2021 10:03:53 GMT, Ajit Ghaisas wrote:
>> Reverting to the old way of showing the context menu but with application
>> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct
>> size measurement of the menu.
>
> Marked as reviewed by aghaisas (Reviewer).
This
On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier
wrote:
>> Fixing deadlock when calling Application.launch in the FXThread after
>> Platform.startup
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8263322
>
On Wed, 10 Mar 2021 22:25:32 GMT, Florian Kirmaier
wrote:
> Fixing a memory leak.
> A node hard references its old parent after CSS layout and getting removed.
> This shouldn't be the case, this is very counterintuitive.
>
> The fix uses a WeakReference in CSSStyleHelper for
On Tue, 23 Feb 2021 15:32:17 GMT, Robert Lichtenberger
wrote:
> Reverting to the old way of showing the context menu but with application
> of CSS prior to calling prefHeight(-1) / prefWidth(-1) to ensure correct
> size measurement of the menu.
Marked as reviewed by aghaisas (Reviewer).
Hi everyone,
I would need some help related to OpenJFX build.
I was able to successfully prepare a build following this procedure (from
pull/417 request):
https://github.com/openjdk/jfx/pull/417#issuecomment-795178731
We wanted to use it in our existing application (Java 11.0.10) to debug an
On Wed, 10 Mar 2021 22:35:31 GMT, Florian Kirmaier
wrote:
>> Fixing deadlock when calling Application.launch in the FXThread after
>> Platform.startup
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8263322
>
28 matches
Mail list logo
