[Resetting QA Contact to newly introduced "at-spi-maint@gnome.bugs". 
Reason: So far it was impossible to watch changes in at-spi bug reports without following all the specific persons (Li Yuan, Bill Haneman, Jeff Wai, ...) and also their activity outside of at-spi reports.

IMPORTANT: Anyone interested in following all bug activity (including all maintainers) must watch the "at-spi-maint@gnome.bugs" dummy user by adding it to the 'Users to watch' list under Preferences->Email preferences. This is also the default procedure nowadays in GNOME when setting up new products.]

Atk has atk_get_focus_object (atk installs a focus tracker to store a reference to the focus object). This is currently not used by AT-SPI. Using it may be helpful but would not be a complete solution since the atk function is specific to an individual application, and I'm not sure if it takes into account whether the window is active.

AT-SPI could have a function that does the following, however:
* Look at all children of the desktop.
* Look at the children of these top-level applications. If a child contains ATK_STATE_ACTIVE, then call atk_get_focus_object (using a D-Bus interface that we would need to add) and return that object.

Do people think that this makes sense?

(In reply to comment #2)
> Atk has atk_get_focus_object (atk installs a focus tracker to store a reference
> to the focus object). 

FWIW, focus trackers are planned to be deprecated (see bug 649575 comment 4). An although right now they are not deprecated, on gtk the current implementation is broken (AFAIK) and in clutter those methods are not used at all. In general, those methods are, imho, were an overkill, and would be easier to implement from the toolkit itself.

> This is currently not used by AT-SPI. Using it may be
> helpful but would not be a complete solution since the atk function is specific
> to an individual application, and I'm not sure if it takes into account whether
> the window is active.

I think that was taking into account all the windows.

> AT-SPI could have a function that does the following, however:
> * Look at all children of the desktop.
> * Look at the children of these top-level applications. If a child contains
> ATK_STATE_ACTIVE, then call atk_get_focus_object (using a D-Bus interface that
> we would need to add) and return that object.

A DBUS interface or a new method on ATK? or both?

(In reply to comment #3)
> (In reply to comment #2)
> > Atk has atk_get_focus_object (atk installs a focus tracker to store a reference
> > to the focus object). 
> 
> FWIW, focus trackers are planned to be deprecated (see bug 649575 comment 4).
> An although right now they are not deprecated, on gtk the current
> implementation is broken (AFAIK) and in clutter those methods are not used at
> all. In general, those methods are, imho, were an overkill, and would be easier
> to implement from the toolkit itself.
> 
> > This is currently not used by AT-SPI. Using it may be
> > helpful but would not be a complete solution since the atk function is specific
> > to an individual application, and I'm not sure if it takes into account whether
> > the window is active.
> 
> I think that was taking into account all the windows.

Or at least is should. Looking at the documentation:

 * Returns: (transfer none): the currently focused object for the current
 * application


> > AT-SPI could have a function that does the following, however:
> > * Look at all children of the desktop.
> > * Look at the children of these top-level applications. If a child contains
> > ATK_STATE_ACTIVE, then call atk_get_focus_object (using a D-Bus interface that
> > we would need to add) and return that object.
> 
> A DBUS interface or a new method on ATK? or both?

Sorry, I didn't realize that you were talking about the existing ATK method. So yes it would be required to implement the DBUS interface to access this.

But as I said, right now the implementation of atk_get_focus_object at the toolkit side is broken. Although it is true that this would mean a first step.

[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]

*** Bug 719470 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
 
> AT-SPI could have a function that does the following, however:
> * Look at all children of the desktop.
> * Look at the children of these top-level applications. If a child contains
> ATK_STATE_ACTIVE, then call atk_get_focus_object (using a D-Bus interface that
> we would need to add) and return that object.
> 
> Do people think that this makes sense?

Well, that strikes me as being the tree diving that Orca already does -- when Orca is forced to do it. So unless AT-SPI has some clever and performant way not available to ATs to accomplish this, I'm not convinced this addresses the issue/need.

Instead, I think what we need is something along the following:

1. A means by which a toolkit can provide the innermost focused child from that toolkit given a root object.

For instance, given an Epiphany window, Epiphany's Gtk+ implementation could be used to immediately retrieve the focused GtkNotebook tab (or whatever widget) embedding the current/active page. Then a second query on that WebKitGtk root object (document frame) could be used to get the link which is focused. This would be way more efficient than Orca (or AT-SPI2) doing a tree dive.

2. The emission of an object:state-changed:focused event when a window becomes active. Using the example above, Alt+Tabbing back into Epiphany would cause Gtk+ to emit object:state-changed:focused for the GtkNotebook tab (or whatever widget) embedding the WebKitGtk content. WebKitGtk would emit its own object:state-changed:focused event for the link which has focus within the document.

If we all can agree that this is at least conceptually* reasonable to ask of implementors, we should document it** and then request it. I think the timing is good given the focus-related changes and deprecations. Let's just do it all and get it over with. :)

Thoughts?

* I suspect it is also technically reasonable: Gecko already does it in at least some instances. And, as Matthias pointed out during our discussion of the above: "The toolkit certainly keeps track of (the focused widget) as evidenced by us rendering the focus on the right widget (or not, if the window loses focus)."

** One of Matthias's very valid complaints/observations during our discussion of the above is the fact that we currently lack any specification describing when ATK implementors should emit focus-related signals.

ping?

I agree with Joanmarie that tree diving from AT-SPI is not a good thing. We had to do this in brltty's atspi2 driver to determine what to output when it starts, but we kept ending up in issues: some applications have loops in their tree, some applications have whole sets of nodes which are both parent and child of each other, etc. leading to exponential loops... while toolkits surely know which widget has focus.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/

Thank you for your understanding and your help.