Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]
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 I did an initial build / test (on macOS) along with a quick look at the changes. This will take a bit more time to complete. As a P3 regression, it is a possible candidate for fixing during RDP1, provided the fix is safe and well-tested. General comments: Why did you need to make a copy of the JDK DualPivotQuicksort class, `DualPivotQuicksort20191112Ext`? This is a maintenance burden that we don't want without a very compelling reason. What additional testing would you recommend? - PR: https://git.openjdk.java.net/jfx/pull/674
Re: RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning
On Thu, 2 Dec 2021 10:12:50 GMT, meghanEmbrace wrote: > With a touch-enabled device, the scrollbar disappears a short while after > it's used. During the layout, updateHbar() checks the hbar visibility and > resets the clip, causing the user to be scrolled fully to the left when > trying to access columns on the right. Using hbar.isVisible() is not feasible > as there are times when the scrollbar is necessary but not visible (such as > on touch-enabled devices where the scrollbar disappears when not in use, or > when hidden by CSS). Hence, it is more reliable to use the variable that > determines whether the hbar is necessary. This seems like the correct fix, but I'll ask @aghaisas to review. What testing have you done to ensure that there are no regressions or unintended side effects of this change? Can you provide an automated test? - PR: https://git.openjdk.java.net/jfx/pull/688
RFR: 8277853: With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning
With a touch-enabled device, the scrollbar disappears a short while after it's used. During the layout, updateHbar() checks the hbar visibility and resets the clip, causing the user to be scrolled fully to the left when trying to access columns on the right. Using hbar.isVisible() is not feasible as there are times when the scrollbar is necessary but not visible (such as on touch-enabled devices where the scrollbar disappears when not in use, or when hidden by CSS). Hence, it is more reliable to use the variable that determines whether the hbar is necessary. - Commit messages: - 8277853 : With Touch enabled devices scrollbar disappears and the table is scrolled to the beginning Changes: https://git.openjdk.java.net/jfx/pull/688/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=688=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277853 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/688.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/688/head:pull/688 PR: https://git.openjdk.java.net/jfx/pull/688
Re: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6]
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
Looks good.
Pending a second reviewer.
-
Marked as reviewed by kcr (Lead).
PR: https://git.openjdk.java.net/jfx/pull/676
Re: RFR: 8278938: [Win] Robot can target wrong key for punctuation and symbols [v2]
> When processing a `WM_CHAR` event on an OEM key (punctuation, symbol, dead > key) the glass code will dynamically query the key's unshifted character to > determine the Java code to assign to it. This is necessary since the > relationship between OEM key codes and the characters they generate varies > from layout to layout. > > The Robot implementation was consulting a table which assumed a fixed > relationship between Java codes and Windows key codes even for the OEM keys. > The table was also missing entries for any Java code not on a US QWERTY > layout, like PLUS. > > In this PR if we don't find the Java code in the table or if it maps to an > OEM key (which may be wrong) we sweep through all the OEM keys looking for > the matching Java code. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: A Robot now correctly handles KeyCodes that aren't in the current layout - Changes: - all: https://git.openjdk.java.net/jfx/pull/702/files - new: https://git.openjdk.java.net/jfx/pull/702/files/dcd4c98c..e9dfaa75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=702=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=702=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/702.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/702/head:pull/702 PR: https://git.openjdk.java.net/jfx/pull/702
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in > dialog fires menuItem in owning > stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the > problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the > performKeyEquivalent method, first. If no view or window handles such a > shortcut key event (indicated by a return value NO in performKeyEquivalent), > the key event is sent a second time via the sendEvent method. Before this > fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be > called twice: first by performKeyEquivalent and then by sendEvent, since no > responder returned YES in performKeyEquivalent. For not handling the same > event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** > in **GlassViewDelegate.m**. It only handled the first call. The second call > checked if the given event was exactly the same like in the last call. In > this case it simply returned and did not forward the event. This means that > all key events with a CMD or CTRL modifier were handled in JFX in the > performKeyEquivalent event loop, even though they actually weren't used by > the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in > **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if > the window was closed and if so, it returned YES. However, nowadays the > window closing check did not work... self->gWindow->isClosed returned NO when > I debugged it, although the window should be closed by the key event. > Returning YES in case of a closed window is not a clean solution, anyway, > because YES should mean that the shortcut key equivalent is handled. Another > point is that Apple writes that overwriting performKeyEquivalent in an > NSWindow subclass is discouraged. So, I completely deleted the method from > **GlassWindow.m**, since it only returned the value of the super function, > except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns > NO, only deleting the method from **GlassWindow.m** did not fix the crash. So > I tried to solve the problem that a shortcut key event is handled in the > performKeyEquivalent loop. The call of **sendJavaKeyEvent** in > **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not > be handled, actually. So, I simply removed this call which is done in > **GlassView3D.m** **performKeyEquivalent** method. By removing the call, > there is also no longer any need to check if the same key event was passed to > **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also > removed. > > I'm curious about your comments and reviews and I wonder if this is a clean > solution. All my tests so far seemed to be fine. Closed in favor of #714, which has now been integrated. - PR: https://git.openjdk.java.net/jfx/pull/704
Integrated: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. This pull request has now been integrated. Changeset: a2a0acff Author:Martin Fox Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a2a0acff66727167bfca879bf908361433e74791 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 Reviewed-by: jpereda, kcr - PR: https://git.openjdk.java.net/jfx/pull/714
Withdrawn: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Wed, 29 Dec 2021 00:44:44 GMT, Andreas Heger wrote: > This also solves [JDK-8205915 [macOS] Accelerator assigned to button in > dialog fires menuItem in owning > stage](https://bugs.openjdk.java.net/browse/JDK-8205915l). > > I must admit that I don't have 100% insight about what actually caused the > problems and how the event flow completely works. > > In MacOS, key events with a command or control modifier are handled via the > performKeyEquivalent method, first. If no view or window handles such a > shortcut key event (indicated by a return value NO in performKeyEquivalent), > the key event is sent a second time via the sendEvent method. Before this > fix, the method **sendJavaKeyEvent** in **GlassViewDelegate.m** seemed to be > called twice: first by performKeyEquivalent and then by sendEvent, since no > responder returned YES in performKeyEquivalent. For not handling the same > event twice in JFX, there seemed to be a workaround in **sendJavaKeyEvent** > in **GlassViewDelegate.m**. It only handled the first call. The second call > checked if the given event was exactly the same like in the last call. In > this case it simply returned and did not forward the event. This means that > all key events with a CMD or CTRL modifier were handled in JFX in the > performKeyEquivalent event loop, even though they actually weren't used by > the MacOS keyEquivale nt functionality and all responders returned NO in performKeyEquivalent. So MacOS sent the event again to all responders in the sendEvent loop. I assume that the window has been destroyed already, when MacOS tried to send the second event to it, because the closing was handled in the first call. Sending an event to a no longer existing window probably caused the crash by an unhandled exception. > > It seems that this problem existed in the past and there was a workaround in > **GlassWindow.m**. In the method **performKeyEquivalent**, it was checked if > the window was closed and if so, it returned YES. However, nowadays the > window closing check did not work... self->gWindow->isClosed returned NO when > I debugged it, although the window should be closed by the key event. > Returning YES in case of a closed window is not a clean solution, anyway, > because YES should mean that the shortcut key equivalent is handled. Another > point is that Apple writes that overwriting performKeyEquivalent in an > NSWindow subclass is discouraged. So, I completely deleted the method from > **GlassWindow.m**, since it only returned the value of the super function, > except for the non working closing check. > > Since the default version of performKeyEquivalent in NSWindow always returns > NO, only deleting the method from **GlassWindow.m** did not fix the crash. So > I tried to solve the problem that a shortcut key event is handled in the > performKeyEquivalent loop. The call of **sendJavaKeyEvent** in > **GlassViewDelegate.m** which is caused by a performKeyEquivalent should not > be handled, actually. So, I simply removed this call which is done in > **GlassView3D.m** **performKeyEquivalent** method. By removing the call, > there is also no longer any need to check if the same key event was passed to > **sendJavaKeyEvent** in **GlassViewDelegate.m**, so this check is also > removed. > > I'm curious about your comments and reviews and I wonder if this is a clean > solution. All my tests so far seemed to be fine. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jfx/pull/704
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling >> processKeyEquivalent. With this PR we just set the contentView to a basic >> do-nothing NSView for the interim. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > Releasing dummy NSView The manual test for this can also cover JDK-8205915 (a Cmd-based shortcut can be processed by two separate windows). This crash was blocking testing on that bug. I'll submit a fix for JDK-8205915 along with the manual test tomorrow. - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 18:34:19 GMT, Martin Fox wrote: >> I don't know. I'm always skeptical of 0 size rectangles. I'd either leave it >> as-is or maybe use a `(0,0,1,1)` rectangle. > > The initial size should not matter since it will be re-sized to the window's > content bounds. But I would rather avoid doing something unusual like > creating a 0-sized NSView even though it almost certainly will work. Okay, no problem then. - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling >> processKeyEquivalent. With this PR we just set the contentView to a basic >> do-nothing NSView for the interim. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > Releasing dummy NSView Marked as reviewed by jpereda (Committer). - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 18:24:36 GMT, Kevin Rushforth wrote: >> Martin Fox has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Releasing dummy NSView > > modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 849: > >> 847: NSView* dummy = [[NSView alloc] initWithFrame: >> NSMakeRect(0, 0, 10, 10)]; >> 848: [window->nsWindow >> performSelectorOnMainThread:@selector(setContentView:) withObject:dummy >> waitUntilDone:YES]; >> 849: [dummy release]; > > This looks fine, given that we wait until the previous call to > `performSelectorOnMainThread` is done. For what it's worth I did complete a full run of robot-based system tests. - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 18:23:20 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847:
>>
>>> 845: {
>>> 846: // If the contentView is set to nil within
>>> performKeyEquivalent: the OS will crash.
>>> 847: NSView* dummy = [[NSView alloc] initWithFrame:
>>> NSMakeRect(0, 0, 10, 10)];
>>
>> The view could be also created with a (0, 0, 0, 0) rect, couldn't it?
>
> I don't know. I'm always skeptical of 0 size rectangles. I'd either leave it
> as-is or maybe use a `(0,0,1,1)` rectangle.
The initial size should not matter since it will be re-sized to the window's
content bounds. But I would rather avoid doing something unusual like creating
a 0-sized NSView even though it almost certainly will work.
-
PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 16:14:16 GMT, Jose Pereda wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Releasing dummy NSView
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847:
>
>> 845: {
>> 846: // If the contentView is set to nil within
>> performKeyEquivalent: the OS will crash.
>> 847: NSView* dummy = [[NSView alloc] initWithFrame:
>> NSMakeRect(0, 0, 10, 10)];
>
> The view could be also created with a (0, 0, 0, 0) rect, couldn't it?
I don't know. I'm always skeptical of 0 size rectangles. I'd either leave it
as-is or maybe use a `(0,0,1,1)` rectangle.
-
PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
On Wed, 12 Jan 2022 16:56:12 GMT, Martin Fox wrote: >> The OS crashes if the contentView of a window is set to nil while handling >> processKeyEquivalent. With this PR we just set the contentView to a basic >> do-nothing NSView for the interim. > > Martin Fox has updated the pull request incrementally with one additional > commit since the last revision: > > Releasing dummy NSView Marked as reviewed by kcr (Lead). modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 849: > 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0, > 0, 10, 10)]; > 848: [window->nsWindow > performSelectorOnMainThread:@selector(setContentView:) withObject:dummy > waitUntilDone:YES]; > 849: [dummy release]; This looks fine, given that we wait until the previous call to `performSelectorOnMainThread` is done. - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog [v2]
> The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Releasing dummy NSView - Changes: - all: https://git.openjdk.java.net/jfx/pull/714/files - new: https://git.openjdk.java.net/jfx/pull/714/files/5674733b..f71d80f8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=714=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=714=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/714.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/714/head:pull/714 PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Wed, 12 Jan 2022 16:24:48 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848: >> >>> 846: // If the contentView is set to nil within >>> performKeyEquivalent: the OS will crash. >>> 847: NSView* dummy = [[NSView alloc] initWithFrame: >>> NSMakeRect(0, 0, 10, 10)]; >>> 848: [window->nsWindow >>> performSelectorOnMainThread:@selector(setContentView:) withObject:dummy >>> waitUntilDone:YES]; >> >> I'm not sure is needed or worth it, but maybe the `dummy` view should be >> released? > > That's a good question. Yes, it should be released. I will update the PR. - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Wed, 12 Jan 2022 16:14:58 GMT, Jose Pereda wrote: >> The OS crashes if the contentView of a window is set to nil while handling >> processKeyEquivalent. With this PR we just set the contentView to a basic >> do-nothing NSView for the interim. > > modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848: > >> 846: // If the contentView is set to nil within >> performKeyEquivalent: the OS will crash. >> 847: NSView* dummy = [[NSView alloc] initWithFrame: >> NSMakeRect(0, 0, 10, 10)]; >> 848: [window->nsWindow >> performSelectorOnMainThread:@selector(setContentView:) withObject:dummy >> waitUntilDone:YES]; > > I'm not sure is needed or worth it, but maybe the `dummy` view should be > released? That's a good question. - PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote:
> The OS crashes if the contentView of a window is set to nil while handling
> processKeyEquivalent. With this PR we just set the contentView to a basic
> do-nothing NSView for the interim.
This PR fixes the JDK-8242544 issue as intended. I've added a couple of minor
comments.
Regarding #704, which also fixed the related issue JDK-8205915 but was
targeting JDK-8242544, maybe it should be just updated to target the former?
modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 847:
> 845: {
> 846: // If the contentView is set to nil within
> performKeyEquivalent: the OS will crash.
> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0,
> 0, 10, 10)];
The view could be also created with a (0, 0, 0, 0) rect, couldn't it?
modules/javafx.graphics/src/main/native-glass/mac/GlassWindow.m line 848:
> 846: // If the contentView is set to nil within
> performKeyEquivalent: the OS will crash.
> 847: NSView* dummy = [[NSView alloc] initWithFrame: NSMakeRect(0,
> 0, 10, 10)];
> 848: [window->nsWindow
> performSelectorOnMainThread:@selector(setContentView:) withObject:dummy
> waitUntilDone:YES];
I'm not sure is needed or worth it, but maybe the `dummy` view should be
released?
-
PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. In the interest of getting as much testing as possible, I'm approving this fix now. If there isn't time to add a manual test, then it can be done in the `jfx18` branch during RDP1. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. This looks good with the current tools/OS behaviour. It is still a bit of a hack, which may result in unexpected behaviour when the macos-specific tools change. But this is a general observation with macos, so I believe this is indeed the best (and least intrusive way) to prevent the crashes. - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/714
Re: RFR: 8242544: CMD+ENTER key event crashes the application when invoked on dialog
On Tue, 11 Jan 2022 22:18:53 GMT, Martin Fox wrote: > The OS crashes if the contentView of a window is set to nil while handling > processKeyEquivalent. With this PR we just set the contentView to a basic > do-nothing NSView for the interim. The fix looks good, and as mentioned above, is minimally intrusive. I also ran a full set of tests with no problems. It would be helpful to add a manual test as part of this PR (maybe based on the test from the bug report). - PR: https://git.openjdk.java.net/jfx/pull/714
