Found another case where the object:state-changed:focused event is missing, though I'm not sure if it's the same bug.

Steps to reproduce:
1. Launch the attached listener in a terminal
2. Launch gedit
3. Press Ctrl+N to create a new document

Only the focus: event is emitted.

You do get object:state-changed:active for the toplevel windows involved (the menu and the application main window).

But that doesn't tell ATs what widget within the active window has focus. And doing a tree dive to locate the focused descendant is potentially an expensive call.

Regardless, since the deprecated focus: is currently being emitted and since object:state-changed:focused is desired, would it be too much trouble to stop emitting the former and start emitting the latter?

(In reply to comment #3)
> But that doesn't tell ATs what widget within the active window has focus. And
> doing a tree dive to locate the focused descendant is potentially an expensive
> call.

GtkWindow has gtk_window_get_focus for that. I didn't invent the atk api...

> Regardless, since the deprecated focus: is currently being emitted and since
> object:state-changed:focused is desired, would it be too much trouble to stop
> emitting the former and start emitting the latter?

The focus: signal is emitted via the deprecated focus tracker infrastructure that you guys are still using in at-spi2-atk.

I think what we need here is a *spec* fow how focus notification is actually supposed to work on the atk level. There's a bunch of overlapping states here that are involved:

active (for windows)
focused
selected (mainly for menuitems)

According to existing documentation [1]:

    The "state-change" signal is emitted when an object's state
    changes. The detail value identifies the state type which
    has changed.

According to existing documentation [2]:

    ATK_STATE_FOCUSED Indicates this object currently has the
    keyboard focus

From the text above, my conclusion would be that implementors are expected to emit object:state-changed:focused each and every time the item with keyboard focus changes.

The only thing I can think of that accounts for what appears to be our difference in opinion of when this event should be emitted is the definition of "keyboard focus." My working definition is "the widget where the user's next keystroke will take effect."

Example 1: If "keyboard focus" is in a TextView, arrowing should cause the caret to move around within the text in that TextView. Similarly, pressing a printable character would cause that character to be added to that TextView at the insertion point.

Example 2: If "keyboard focus" is in a Menu, arrowing should cause the selected menu item to change. Similarly, pressing a printable character would cause the menu item with that character underlined to be activated.

If we were to add the above clarification about "keyboard focus" along with the examples to the ATK documentation, would that be sufficient to move forward with emitting object:state-changed:focused accessibility events for the issues identified in the opening report and comment 1? If not, what additional specification or text would you suggest we add to be more clear?

[1] https://developer.gnome.org/atk/unstable/AtkObject.html#AtkObject-state-change
[2] https://developer.gnome.org/atk/unstable/atk-AtkState.html

(In reply to comment #5)
> According to existing documentation [1]:
> 
>     The "state-change" signal is emitted when an object's state
>     changes. The detail value identifies the state type which
>     has changed.
> 
> According to existing documentation [2]:
> 
>     ATK_STATE_FOCUSED Indicates this object currently has the
>     keyboard focus
> 
> From the text above, my conclusion would be that implementors are expected to
> emit object:state-changed:focused each and every time the item with keyboard
> focus changes.
> 
> The only thing I can think of that accounts for what appears to be our
> difference in opinion of when this event should be emitted is the definition of
> "keyboard focus." My working definition is "the widget where the user's next
> keystroke will take effect."
> 
> Example 1: If "keyboard focus" is in a TextView, arrowing should cause the
> caret to move around within the text in that TextView. Similarly, pressing a
> printable character would cause that character to be added to that TextView at
> the insertion point.
> 
> Example 2: If "keyboard focus" is in a Menu, arrowing should cause the selected
> menu item to change. Similarly, pressing a printable character would cause the
> menu item with that character underlined to be activated.
> 
> If we were to add the above clarification about "keyboard focus" along with the
> examples to the ATK documentation, would that be sufficient to move forward
> with emitting object:state-changed:focused accessibility events for the issues
> identified in the opening report and comment 1? If not, what additional
> specification or text would you suggest we add to be more clear?
> 
> [1]
> https://developer.gnome.org/atk/unstable/AtkObject.html#AtkObject-state-change
> [2] https://developer.gnome.org/atk/unstable/atk-AtkState.html

Not really. 'Explanation by example' does not make a spec. 

First issue: GTK+ does not really maintain a single focus location. Each window has its 'focus widget'. This is where the 'active' status comes in. The 'current focus' is a combined state, it is the 'focus widget' in the 'active window'. Currently, you get a state-changed:active if the active window changes, and a state-changed:focused if the focus widget changes.

Second issue: The concept of focus does not really apply in menus at all - there's usually no keyboard input to individual locations in a menu hierarchy, and keynav is interpreted by the menu system, holistically.


To make substantive progress on this, I suggest we need a few things:

- Write up explicitly the expected state-change sequences for the two issues I mentioned above

- Write a test that can verify such sequences

- Disable the focus tracker stuff entirely, so we can get a clear picture of what is currently working

(In reply to comment #6)
 
> To make substantive progress on this, I suggest we need a few things:
> 
> - Write up explicitly the expected state-change sequences for the two issues I
> mentioned above

First issue

For the window which is no longer active:
1. object:state-changed:focused (false) for the focus widget in that window
2. object:state-changed:active (false) for the window

For the window which just became active:
1. object:state-changed:active (true) for the window
2. object:state-changed:focused (true) for the focus widget in that window

---------

Second issue

For whatever was the focus widget before the menu became active:
1. object:state-changed:focused (false)

For the menu which just became active:
1. object:state-changed:focused (true)
2. object:state-changed:selected (true) for the selected menu item (if one exists)

As items in the above menu become selected:
1. object:state-changed:selected (false) for the menu item which just became unselected
2. object:state-changed:selected (true) for the menu item which just became selected

Matthias: Ping. (This is the bug and conversation we were chatting about at GUADEC.)

I've pushed a framework that will let us write tests for event sequences and state changes.

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

Yet another case where the desired event is missing, but the deprecated focus: event is present. Dup of bug 711397.

*** This bug has been marked as a duplicate of bug 711397 ***