JDK-8033249 : Focus Event Delivery spec needs a clarification
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,8,9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-01-30
  • Updated: 2021-07-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Description
The section "Event Delivery" of "The AWT Focus Subsystem" specification needs a clarification.

Current spec (http://docs.oracle.com/javase/7/docs/api/java/awt/doc-files/FocusSpec.html#EventDelivery) says:

"If the focus is not in java application and the user clicks on a focusable child Component a of an inactive Frame b, the following events will be dispatched and handled in order:

b will receive a WINDOW_ACTIVATED event.
Next, b will receive a WINDOW_GAINED_FOCUS event.
Finally, a will receive a FOCUS_GAINED event.

If the user later clicks on a focusable child Component c of another Frame d, the following events will be dispatched and handled in order:

a will receive a FOCUS_LOST event.
b will receive a WINDOW_LOST_FOCUS event.
b will receive a WINDOW_DEACTIVATED event.
d will receive a WINDOW_ACTIVATED event.
d will receive a WINDOW_GAINED_FOCUS event.
c will receive a FOCUS_GAINED event."

It's necessary to specify explicitly that the observable event sequence can contain not only events described above, but also other events. For example, pairs of temporary focus events.

Test code:

        Frame f = new Frame("f");
        f.setLayout(new FlowLayout());
        Button b1 = new Button("b1");
        Button b2 = new Button("b2");
        f.add(b1);
        f.add(b2);
        f.pack();
        f.setVisible(true);

How to reproduce:

1. After showing a window, click outside the window 
2. Click on b2.

Observed event list order:

1) WINDOW_ACTIVATED on "f"
2) WINDOW_GAINED_FOCUS on "f"
3) FOCUS_GAINED on "b1"
4) FOCUS_LOST on "b1"
5) FOCUS_GAINED on "b2"

Here we see a pair of temporary focus events (FOCUS_GAINED on "b1", FOCUS_LOST on "b1"), that are not described in the spec.
Comments
Sergey, Since you've reopened the bug without a clarification I would recommend you to clarify its target and update the summary before you assign it to somebody else. You could think about the next: 1. The focus transfer event sequence is different for various scenarios and the current bug summary mentions one particular case only. 2. The proposed event order is taken from another scenario than one described by the mentioned document section. 3. Description of all possible scenarios on this level of details is hard (if we aren't going to write a book). It's better to neglect the exact event order specification at least.
10-09-2015

Sorry but I cannot spent more time on that. I just can repeat the the observed events and the test in the summary are taken from another scenario.
09-09-2015

No, This is specification as mentioned at the beginning: "This document is a formal specification both of the new APIs and of existing APIs ". And it should be read literally. The first sentence describe the situation when the java window became focused after some other non-java window was active. The current behavior contradicts it, so we should clarify the specification or implementation should be changed.
09-09-2015

This doc section describes very generally focus transfer between two different top level windows. Both paragraphs describes the same scenario connected to the activation of another window in the the second both windows are java. Focus transfer between two components of the same window, between parent and child modal window component, between parent and child non-modal window component, ... - will be absolutely different.
09-09-2015

Please clarify. You mention "Actually the provided test is wrong because it contains only one frame and this documentation section descries focus transfer to a component in _another_ frame. " But the first sentence describe the situation when the current window is not java. " If the focus is not in java application and the user clicks on a focusable child Component a of an inactive Frame b, the following events will be dispatched and handled in order: b will receive a WINDOW_ACTIVATED event. Next, b will receive a WINDOW_GAINED_FOCUS event. Finally, a will receive a FOCUS_GAINED event. " And provided testcase shows that this sequence of events is not complete if the frame b has some other components.
09-09-2015

Sergey, please, read my first comment once more.
09-09-2015

Yes the provided testcase generate: f.windowActivated b1.focusGained b1.focusLost b2.focusGained Which is not the same as described in the doc? f.windowActivated f.WINDOW_GAINED_FOCUS b2.focusGained
09-09-2015

b receives the same events as d in the 2nd section
09-09-2015

The frame b is inactive, because current active window is not a java window. If you click on child a of Frame b, will the "temporary focus events" generated?
08-09-2015

How do you deduce that? The first sentence states "clicks on a focusable child Component a of an _inactive_ Frame b".
08-09-2015

It contains the one frame, because it cover the first sentence in documentation: "If the focus is not in java application and the user clicks on a focusable child Component of an inactive Frame b, the following events will be dispatched and handled in order" Does the temporary focus events will be generated in this case?
07-09-2015

Actually the provided test is wrong because it contains only one frame and this documentation section descries focus transfer to a component in _another_ frame. When the parent frame is lost focus the pair of temporary events are not generated and the current inner focused component receives the focus lost event only exactly as it is mentioned in the document section.
07-09-2015

Release team: Approved for deferral.
31-01-2014

Yes, the spec should not strictly specify the order (and the number) of focus events in the scenario in question. Requires clarification.
31-01-2014

As JCK is ok to defer it, and this is not a regression, not a customer reported issue, not a blocker for dev process, I'm adding 8-defer-request.
31-01-2014

JDK8: SQE OK to defer
31-01-2014

JCK team is ok to move this issue to 9, because this issue is NOT tck-red.
30-01-2014