Michael: I noticed that Orca was sometimes interrupting speech of the spelling error and context in order to present a name change. Orca has logic to try to prevent incorrect interruptions, and I could add more. But in this particular case one of the events seems wrong, and the other will be redundant if the first event is addressed. From my debug.out (trimmed for clarity): ------ object:property-change:accessible-name for [dialog: 'Spelling: English (USA)'] in soffice (gtk 3.24.43) (detail1: 0, detail2: 0, any_data: 'Spelling: $LANGUAGE ($LOCATION)') ------ This means that the dialog with the name of 'Spelling: English (USA)' is changing its name to 'Spelling: $LANGUAGE ($LOCATION)' Presumably it doesn't want to do that. Then another event comes in to put things back to what they should be: ------ object:property-change:accessible-name for [dialog: 'Spelling: English (USA)'] in soffice (gtk 3.24.43) (detail1: 0, detail2: 0, any_data: 'Spelling: English (USA)') ------ (Note that there may be Orca debugging side effects that's causing the name after "dialog:" to be corrected/updated. But the any_data is what Orca gets from LO. And it's the any_data that demonstrates the problem.) Orca's skips processing the first of those two events because, at processing time, Orca knows about the second one having been queued. But Orca does present the second one, interrupting speech for the error presentation. At the time the dialog was shown, it already had the right name. So I'm hoping if you stop the first event (as being wrong) and have code that checks if the name really changed (to stop the second event), Orca will stop interrupting itself.
I can reproduce. Corresponding events seeing in Accerciser's event monitor: 99.6 object:property-change:accessible-name(0, 0, Spelling: $LANGUAGE ($LOCATION)) source: [dialog | Spelling: $LANGUAGE ($LOCATION)] application: [application | soffice] 99.6 object:property-change:accessible-name(0, 0, Spelling: ) source: [dialog | Spelling: ] application: [application | soffice] Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aae76f4df1d4a554fa16c05a28d2e1d10ea558af CPU threads: 32; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
Created attachment 197490 [details] pyatspi script to print events
Created attachment 197491 [details] Sample doc with spelling errors
On further analysis, it seems to me like most of the events I see are triggered by setting the title on the dialog before it gets shown, and I don't see "Spelling: $LANGUAGE ($LOCATION)" being set any more once the correct title has been set, so I'm not not sure whether I actually see the exact same behavior as you do. Steps: 1) run the attached pyatspi script attachment 197490 [details] 2) open the attached document attachment 197491 [details] (with LO using the gtk3 VCL plugin, version from comment 1) 3 while the cursor is still at the beginning of the document: Press F7 to open the spellcheck dialog 4) check the script output generated in step 3 I see these events: event source: Spelling: $LANGUAGE ($LOCATION), showing: False object:property-change:accessible-name(0, 0, Spelling: $LANGUAGE ($LOCATION)) source: [dialog | Spelling: $LANGUAGE ($LOCATION)] host_application: [application | soffice] sender: [application | soffice] event source: Spelling: , showing: False object:property-change:accessible-name(0, 0, Spelling: ) source: [dialog | Spelling: ] host_application: [application | soffice] sender: [application | soffice] event source: Spelling: English (USA), showing: False object:property-change:accessible-name(0, 0, Spelling: English (USA)) source: [dialog | Spelling: English (USA)] host_application: [application | soffice] sender: [application | soffice] , all of which are triggered while the dialog is not yet reporting itself as showing on the a11y level (notice the "showing: False" output from the script above). With a breakpoint on `gtk_window_set_title`, it seems the first one is triggered when GtkBuilder (from the GTK library) processes the .ui file, the second one is in SpellDialog::SpellDialog, the third one is in SpellDialog::UpdateBoxes_Impl. In particular the first one is likely not easy to avoid. If I manually switch the text language in the dialog, I see an additional event, this time with the showing state set as expected: event source: Spelling: English (UK), showing: True object:property-change:accessible-name(0, 0, Spelling: English (UK)) source: [dialog | Spelling: English (UK)] host_application: [application | soffice] sender: [application | soffice] Does this match what you're seeing? If so, could/should Orca maybe ignore these events for objects that don't have the AT-SPI showing state set? Or do you see different events being emitted, maybe when taking different steps? I've submitted https://gerrit.libreoffice.org/c/core/+/176256 to avoid one unnecessary case where a title might be set, but that doesn't seem to play a role for my scenario described above at least.
Created attachment 197494 [details] Alternative listener I modified your listener because getting the states as a property of the source seems to be failing. Here's the output I get from my version of your listener. The showing state is present. event type: object:property-change:accessible-name, event source: Spelling: $LANGUAGE ($LOCATION), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE'] object:property-change:accessible-name(0, 0, Spelling: $LANGUAGE ($LOCATION)) source: [dialog | Spelling: $LANGUAGE ($LOCATION)] host_application: [application | soffice] sender: [application | soffice] event type: object:property-change:accessible-name, event source: Spelling: , states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE'] object:property-change:accessible-name(0, 0, Spelling: ) source: [dialog | Spelling: ] host_application: [application | soffice] sender: [application | soffice] event type: object:state-changed:showing, event source: Spelling: , states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE'] object:state-changed:showing(1, 0, 0) source: [dialog | Spelling: ] host_application: [application | soffice] sender: [application | soffice] event type: object:property-change:accessible-name, event source: Spelling: English (USA), states: ['ENABLED', 'SENSITIVE', 'SHOWING', 'VISIBLE'] object:property-change:accessible-name(0, 0, Spelling: English (USA)) source: [dialog | Spelling: English (USA)] host_application: [application | soffice] sender: [application | soffice]
Michael: In answer to your suggestion to ignore name changes on non-showing objects, that makes sense in general so I just landed that change: https://gitlab.gnome.org/GNOME/orca/-/commit/db1a26161 I'm still seeing the problem because, again, the showing state is actually present.
(In reply to Joanmarie Diggs from comment #5) > Created attachment 197494 [details] > Alternative listener > > I modified your listener because getting the states as a property of the > source seems to be failing. Thanks! > Here's the output I get from my version of your listener. The showing state > is present. The SHOWING state being present already before the object:state-changed:showing event is emitted seems odd to me. Since this is a GTK dialog/widget, I'd generally expect that GTK would take care of accessible states here, but that needs further investigation.
(In reply to Michael Weghorn from comment #7) > (In reply to Joanmarie Diggs from comment #5) > > Created attachment 197494 [details] > > Alternative listener > > > > I modified your listener because getting the states as a property of the > > source seems to be failing. > > Thanks! > > > Here's the output I get from my version of your listener. The showing state > > is present. > > The SHOWING state being present already before the > object:state-changed:showing event is emitted seems odd to me. > Since this is a GTK dialog/widget, I'd generally expect that GTK would take > care of accessible states here, but that needs further investigation. Assuming that got fixed, that would only help get rid of the first two object:property-change:accessible-name events. The one for the final title would remain. Would getting rid of the first two be of any help or wouldn't that make much of a difference anyway as long as the final one is still there?
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e44f566a2c901d9c761759a20bbd767f18795d5b tdf#163802 cui: Don't set temporary title for spelling dialog It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Michael Weghorn from comment #8) > Would getting rid of the first two be of any help or wouldn't that make much > of a difference anyway as long as the final one is still there? Avoiding the last title/name change or making it also happen before the dialog shows seems non-trivial from what I've seen this far, as the logic to retrieve the language/dictionary (that's part of the dialog title) is currently only available later. (Might need a more fundamental rework, but I'm not too familiar with the involved code to give a more definitive answer at the moment.)