Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException

2020-03-05 Thread Robert Lichtenberger
On Thu, 5 Mar 2020 18:00:25 GMT, Kevin Rushforth wrote: >> why a second pr for the same issue (see >> https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do >> much more/else/better (than clamping, which isn't good enough)? > > I have exactly the same question. > > In

Re: ComboBox keypress discrepancy

2020-03-05 Thread Abhinay Agarwal
Hi Dirk, Thanks for reaching out. As stated earlier, I want to know what exactly is causing this change in behaviour. I also want to know what is the expected behaviour in this case: should TAB key press trigger when the popupwindow is showing? -- Abhinay

Re: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator

2020-03-05 Thread Kevin Rushforth
On Mon, 2 Mar 2020 10:09:57 GMT, Florian Kirmaier wrote: >> Hi everyone, >> >> ticket: https://bugs.openjdk.java.net/browse/JDK-8236259 >> >> The fix itself is quite straight forward. >> It basically just removed the listener which causes the leak. >> >> The unit-test for the fix is a bit

Re: [Rev 03] RFR: 8236259: MemoryLeak in ProgressIndicator

2020-03-05 Thread Kevin Rushforth
On Thu, 19 Dec 2019 14:43:29 GMT, Jeanette Winzenburg wrote: >> I don't see an API in the discussion, on how to remove a specific listener. >> Did i miss something? It seems to me, that the API is written to support >> only a single listener per property. > > the api is in a related issue

Re: [Integrated] RFR: 8240451: JavaFX javadoc build fails with JDK 14

2020-03-05 Thread Kevin Rushforth
Changeset: b2ac76a9 Author:Kevin Rushforth Date: 2020-03-05 20:58:03 + URL: https://git.openjdk.java.net/jfx/commit/b2ac76a9 8240451: JavaFX javadoc build fails with JDK 14 Reviewed-by: nlisker, jvos !

Re: RFR: 8240451: JavaFX javadoc build fails with JDK 14

2020-03-05 Thread Johan Vos
On Tue, 3 Mar 2020 16:12:23 GMT, Kevin Rushforth wrote: > The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic > parameter if not surrounded by `<` and `>`. This will in turn fail the build, > since we treat warnings as errors. There are 5 classes in JavaFX with this >

Re: RFR: 8240451: JavaFX javadoc build fails with JDK 14

2020-03-05 Thread Kevin Rushforth
On Thu, 5 Mar 2020 17:17:57 GMT, Nir Lisker wrote: >> The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic >> parameter if not surrounded by `<` and `>`. This will in turn fail the >> build, since we treat warnings as errors. There are 5 classes in JavaFX with >> this error.

Re: [Integrated] RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Kevin Rushforth
Changeset: cf0bba62 Author:Arun Joseph Committer: Kevin Rushforth Date: 2020-03-05 19:28:25 + URL: https://git.openjdk.java.net/jfx/commit/cf0bba62 8240211: Stack overflow on Windows 32-bit can lead to crash Reviewed-by: ghb, kcr, jvos !

Re: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Johan Vos
On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last > iteration of calling frameLoaded() and then, grows beyond the thread's stack > range causing a stack overflow and crashes. This occurs as the stack grows by >

Re: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Kevin Rushforth
On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last > iteration of calling frameLoaded() and then, grows beyond the thread's stack > range causing a stack overflow and crashes. This occurs as the stack grows by >

Re: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Kevin Rushforth
On Thu, 5 Mar 2020 17:46:17 GMT, Johan Vos wrote: >> Looks good to me. >> I believe you have executed DRT on both 64 & 32 bit build. > > This looks correct and very valuable to me. Would be great if there was a > test that results in a crash before? Here is a pointer to the

Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException

2020-03-05 Thread Kevin Rushforth
On Thu, 5 Mar 2020 17:01:25 GMT, Jeanette Winzenburg wrote: >> This PR fixes JDK-8176270 by clamping the end index of the selected text to >> the length of the text. > > why a second pr for the same issue (see > https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do > much

Re: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Johan Vos
On Thu, 5 Mar 2020 16:50:55 GMT, Guru Hb wrote: >> Issue: The stack pointer is checked close to the stack limit during the last >> iteration of calling frameLoaded() and then, grows beyond the thread's stack >> range causing a stack overflow and crashes. This occurs as the stack grows >> by

Re: RFR: 8240451: JavaFX javadoc build fails with JDK 14

2020-03-05 Thread Nir Lisker
On Tue, 3 Mar 2020 16:12:23 GMT, Kevin Rushforth wrote: > The JDK 14 javadoc will emit a warning for an `@pram` tag of a generic > parameter if not surrounded by `<` and `>`. This will in turn fail the build, > since we treat warnings as errors. There are 5 classes in JavaFX with this >

Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException

2020-03-05 Thread Jeanette Winzenburg
On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger wrote: > This PR fixes JDK-8176270 by clamping the end index of the selected text to > the length of the text. why a second pr for the same issue (see https://github.com/openjdk/jfx/pull/73)? particularly one that doesn't do much

Re: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Guru Hb
On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last > iteration of calling frameLoaded() and then, grows beyond the thread's stack > range causing a stack overflow and crashes. This occurs as the stack grows by >

Re: RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Kevin Rushforth
On Thu, 5 Mar 2020 14:51:03 GMT, Arun Joseph wrote: > Issue: The stack pointer is checked close to the stack limit during the last > iteration of calling frameLoaded() and then, grows beyond the thread's stack > range causing a stack overflow and crashes. This occurs as the stack grows by >

RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException

2020-03-05 Thread Robert Lichtenberger
This PR fixes JDK-8176270 by clamping the end index of the selected text to the length of the text. - Commits: - e78e8793: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException - d849c67c: Merge remote-tracking branch 'upstream/master'

RFR: 8240211: Stack overflow on Windows 32-bit can lead to crash

2020-03-05 Thread Arun Joseph
Issue: The stack pointer is checked close to the stack limit during the last iteration of calling frameLoaded() and then, grows beyond the thread's stack range causing a stack overflow and crashes. This occurs as the stack grows by an amount larger than the reserved zone at the end of the

Re: ComboBox keypress discrepancy

2020-03-05 Thread Dirk Lemmermann
So what info do you need? What test do you want us to run? I ran it on MacOS X with Java 14ea and I DO NOT see the „TAB“ output. Dirk > Am 05.03.2020 um 11:43 schrieb Abhinay Agarwal : > > import javafx.application.Application; > import javafx.scene.Scene; > import

ComboBox keypress discrepancy

2020-03-05 Thread Abhinay Agarwal
Hi, We have come across a behavioural change in ComboBox b/w JavaFX 8 and 9+. We are not sure if its a regression or a bug fix which is causing it. Therefore, I am reaching out to the community for insight. If you run the following example, open the popup window in ComboBox and press TAB:

Re: [Rev 02] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case

2020-03-05 Thread Johan Vos
On Mon, 10 Feb 2020 13:27:27 GMT, Ambarish Rapte wrote: >> Memory allocated in initDecompressor() and decompressIndirect() is not freed >> in error case. >> In error case, >> 1. Allocated memory should be freed. >> 2. Appropriate de-initialization jpeg library calls should be added. >> >>