GNOME Bugzilla – Bug 639466
Document the use of the ":system" suffix for signals
Last modified: 2021-06-10 11:26:36 UTC
This request is to formally include something Gecko already does, namely append a ":system" suffix to events which lets us know if they are user-generated/trigged or not. The main use case for Gecko seems to be the handling of live regions for which many object:text-changed and many object:children-changed events are generated. The reason the suffix is needed (imho) is because much of what an AT like Orca does is use heuristic means to determine the nature of an event for the purpose of figuring out what, if anything, should be presented to the user as a result. The more we know about an event, the less we have to guess.
Hackfests conclusions: * It is hard to know what triggered an event: the user or the system. BUT: * If it is known, it would be good for ATK implementors to implement this. * We need to document it well (including a variety of examples) and add it to the to-be-written best practices guide. * (No API breakage)
Li, I noticed on the hackfest agenda page that you signed up as the "responsible person" for Gail. Thanks!! :-) In addition to it needing to be done in Gtk/Gail (and other toolkits), I think it will be helpful to have this documented in the ATK docs so that when we open bugs against those other toolkits we can point to the docs. Is this something you can tackle as well?
Sorry for the spam. This (ATK) bug is now one of documentation. A new bug should be opened for each toolkit where an implementation is requested.
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add atk-maint@gnome.bugs to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla. Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
I wonder if there is any code change (other than doc) needed. We need G_SIGNAL_DETAILED flag enabled when new a signal if we want the signal support detail. Many signals in atk doesn't support now. While it is not hard to add this flag, I just wonder how Firefox does this without signal details?
(In reply to comment #5) > I wonder if there is any code change (other than doc) needed. I mean in atk, of course.
Hi Joanie, I wonder what happened with Firefox emits the children-changed::add with system suffix. Is it children-changed:add:system?
The reason Orca isn't reading text-changed notifications from Firefox right now when a user edits an edit field seems to be that they include the "system" suffix, and so Orca's event listener doesn't see them. I'm not sure if it's a bug that the "system" suffix is being added in the first place, but, anyhow, it brings up the question of how event listeners should work. Should an event listener for an event receive the event, regardless of the presence or lack thereof of a ":system" suffix? Currently, for instance, a listener for "object:text-changed:insert" would not catch a "object:text-changed:insert:system" event, and a few changes to AT-SPI would be needed to make it so. Or do we want several possible syntaxes for specifying an event listener: one to catch events with the system suffix, one to catch events without the system suffix, and one to catch both types of events?
(In reply to comment #8) > The reason Orca isn't reading text-changed notifications from Firefox right now > when a user edits an edit field seems to be that they include the "system" > suffix, and so Orca's event listener doesn't see them. I'm not sure if it's a > bug that the "system" suffix is being added in the first place, I would argue that it is. ;) The system suffix says "The user is not changing this text; the system/app/something else is." > Should an event listener for an event receive the event, regardless of the > presence or lack thereof of a ":system" suffix? If we register for object:text-changed:insert, I would think we would also get object:text-changed:insert:system; if we register for object:text-changed:insert:system I would not expect to get object:text-changed:insert which lacked the :system suffix. > Currently, for instance, a > listener for "object:text-changed:insert" would not catch a > "object:text-changed:insert:system" event, That is a change that I do not recall being documented. We did not change Orca's code w.r.t. what events were being listened to, but we no longer receive these events. > and a few changes to AT-SPI would be > needed to make it so. Really? > Or do we want several possible syntaxes for specifying an event listener: one > to catch events with the system suffix, one to catch events without the system > suffix, and one to catch both types of events? Hmmm. This is an interesting question that perhaps should be discussed. Dunno... I suppose I could go either way as long as it's clearly documented.
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 of atk, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.