8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed

[hjohn]

This is a proof of concept fix for the linked issue.

We'll need to discuss if using an event filter in the Behavior is the appropriate fix and how much impact this may have on current applications.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8337246: SpinnerSkin does not consume ENTER KeyEvent when editor ActionEvent is consumed (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1629/head:pull/1629
$ git checkout pull/1629

Update a local copy of the PR:
$ git checkout pull/1629
$ git pull https://git.openjdk.org/jfx.git pull/1629/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1629

View PR using the GUI difftool:
$ git pr show -t 1629

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1629.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jhendrikx! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 01: Full - Incremental (4e6dafca)
• 00: Full (afef5153)

[hjohn]

The failing SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons test is a bit odd; it expects that Enter in an editable Spinner should result in activating the Default Button. However, a normal TextField doesn't do this either...

In a non-editable Spinner, the default button logic works as expected.

As it is, we can't have both; the bug wants to not have Enter bubbling up, but then the default button logic is not going to work.

IMHO, Spinner's text field should work like regular text fields, so if Enter in those fields can't activate the default button, then neither should Spinner's editable field.

[beldenfox]

The failing SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons test is a bit odd; it expects that Enter in an editable Spinner should result in activating the Default Button. However, a normal TextField doesn't do this either...

Maybe I'm misunderstanding this comment but in my testing pressing Enter in an editable TextField can activate the default button as long as the TextField doesn't have an OnAction handler set. It should not be so easy to block Enter from activating the default button.

It might be helpful to write up a single test that verifies that Enter is handled correctly for TextField, ComboBox, DatePicker, and Spinner. I'm working on a PR to clean up ESC handling and it was useful to write up a single test covering all of these controls. (I want to ensure that the user can always uses ESC to close a modal dialog even if the TextField has a formatter assigned to it. This isn't working currently.)

Why doesn't Spinner work the same as ComboBox? For a ComboBox the client registers the action handler directly on the ComboBox instead of the combo box's editor.

[beldenfox]

It would be cleaner to use the exiting EventUtil.fireEvent() routine.

[hjohn]

The purpose of doing it this way is to prevent a full dispatch chain (starting from Window/Scene) to be built. EventUtil.fireEvent does something else. Perhaps a utility method is warranted if this pattern becomes commonplace to solve these kinds of issues.

[beldenfox]

Got it. I should have looked at that code more closely.

Your code assumes that it's sufficient to send the event to the single dispatcher associated with the node. That seems like a substantial change since it bypasses any handlers or filters installed further up the node hierarchy. But there are plenty of other instances where this happens. Anyone who tries to install a filter that tries to monitor events going to all TextFields at a global level will already see some anomalies. For example, you will never see an Escape or Enter key event that's targeted at the TextField inside a ComboBox.

[hjohn]

The failing SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons test is a bit odd; it expects that Enter in an editable Spinner should result in activating the Default Button. However, a normal TextField doesn't do this either...

Maybe I'm misunderstanding this comment but in my testing pressing Enter in an editable TextField can activate the default button as long as the TextField doesn't have an OnAction handler set. It should not be so easy to block Enter from activating the default button.

Ah, perhaps that's the problem, I did have an action handler, although it did't consume the event (which normally should mean it's a no-op). Hm...

It might be helpful to write up a single test that verifies that Enter is handled correctly for TextField, ComboBox, DatePicker, and Spinner. I'm working on a PR to clean up ESC handling and it was useful to write up a single test covering all of these controls. (I want to ensure that the user can always uses ESC to close a modal dialog even if the TextField has a formatter assigned to it. This isn't working currently.)

Yeah, I guess I didn't look deep enough.

Why doesn't Spinner work the same as ComboBox? For a ComboBox the client registers the action handler directly on the ComboBox instead of the combo box's editor.

Very good point; when I was looking at the code I was quite confused with the way the editor property works -- it being read only seemed quite useless, except if that's the only way to register an action handler. It looks suspiciously like a poor design.

[hjohn]

So I took a look in TextFieldBehavior how it could possibly be that installing an empty Action handler could lead to the Enter event being consumed, and I found this:

    // fix of JDK-8207759: reverted logic
    // mapping not auto-consume and consume if handled by action
    if (onAction != null || actionEvent.isConsumed()) {
        event.consume();
    }

So, that if will consume the event if there is an action handler or the action event was consumed... I'm pretty sure that should be an and.

In fact, I'm unsure why the code even bothers to check if there is an action handler... just check if the Action event was consumed.

[andy-goryachev-oracle]

I am not sold on this solution.

The issue, as I see it, stems from the fact that copies of events are being sent and their isConsumed() is not checked. So even though the secondary event is consumed, the code that fires the copy does not check the flag, and as a result this information is lost.

This is currently being discussed in the mailing list, me advocating fixing maybe by removing Event.copyFor() and/or linking the isConsumed() flags for events created via Event.copyFor().

The alternative is illustrated here - adding what I think are band-aids in the form of custom event dispatchers, which I think is wrong (I think there should not be a public EventDispatcher interface and no need for Event.copyFor()).

The other alternative, using only internal hacks can be seen in #1523

[beldenfox]

Currently the system treats events as immutable objects. In order to update either the target or source of an event the system needs to make a copy with the new target or source. This means a copy might be made when an event is fired at a target OR when an event is handed off to a filter or handler. To get rid of all copies would require the target and source fields in the event to become mutable which is a very big and problematic change.

There are other reasons why an event dispatcher might not send along the original event to a handler. See EnteredExitHandler.java to see how new mouse events are created during dispatch to satisfy the demands of the documented MouseEvent API.

There's an existing protocol for determining whether an event was consumed or not, namely checking to see if dispatchEvent returns null. It is not well documented but part of the external API. And it works fine even in the face of events being copied or modified during dispatch which happens all over the place.

[andy-goryachev-oracle]

Mailing list might be a better place for this discussion, but for some reason a lot of discussion happens in the PRs.

I agree events should be immutable. What I am saying there should be no 'target' field - then one does not need to do copyFor(). One can still fire a new event if so desired.

The current FX event mechanism is just not a good one, causes more problem than it solves (I presume it solves some problems, though I can't see how - in Swing, neither EventDispatcher is public, nor the Events have target fields and the need for copyFor). Yes, FX is not Swing, this is just an example of a better design (from the event handling point of view).