Steps to reproduce: 1. Launch Orca 2. Launch Calc and create a second sheet 3. Use Ctrl+PageUp/Ctrl+PageDown to switch sheets Expected results: Orca would announce the name of the sheet before announcing the selected cell. Actual results: Orca just announces the selected cell. From debugging things on the Orca side, it looks like the following is taking place when moving from Sheet 1 to Sheet 2: 1. The document fires object:children-changed:remove for Sheet 1 2. The document fires object:children-changed:add for Sheet 2 3. Sheet 2 fires object:active-descendant-changed for the selected cell When Orca goes to present the new focus/object of interest, it always looks for the new ancestors so that it can give context to the user about their new location. In the case described in this issue, Orca checks for the common ancestors between the old focus (cell selected on Sheet 1) and the new focus (cell selected on sheet 2). This fails because Sheet 1 is being (has been?) destroyed. Orca doesn't want to be too chatty and speak the sheet, and the document, and the root pane, and the window, so it doesn't speak any ancestors in this case. Instead it just announces the new active descendant. I potentially could handle this situation in Orca. HOWEVER, Orca already has similar code in its web support for recovery from destroyed object. And those heuristics have a tendency to get things wrong, which leads to more heuristics, which leads to new things being wrong, .... :( I really don't want to add more fragile heuristics to Orca if it can be avoided. ALSO: What is functionally taking place is that Sheet 2 gains focus. So I don't think it would be a hack for Sheet 2 to fire object:state-changed:focused prior to firing active-descendant change. Related aside: I've noticed that Orca recently only announces the root pane when Calc is initially launched. I've not yet debugged to see whether that's an Orca change or a Calc change. But, if the active sheet fired object:state-changed:focused upon launch of Calc, I believe it would also solve that issue. Michael: Thoughts?
Confirmed, Ubuntu 24.04 with Orca main, Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: nl-NL (nl_NL.UTF-8); UI: nl-NL Ubuntu package version: 4:24.2.3-0ubuntu0.24.04.2 Calc: threaded
Michael: Could you please take a look at this? Thanks in advance!
In the meantime.... https://gitlab.gnome.org/GNOME/orca/-/commit/4ead75fda > Hack around https://bugs.documentfoundation.org/show_bug.cgi?id=161444 > Because removing workarounds is regressing the end user experience, > add the following hack: When we receive an active descendant event > from LO, and the event source is not an ancestor of the current focus: > > 1. Silently set the locus of focus to the parent of the event source. > Otherwise we'll be super chatty in response to the next item. > 2. Non-silently set the locus of focus to the event source. This will > cause us to present the sheet name. > 3. Allow the default script to do its thing which will set the locus > of focus to the cell with the common ancestor being the table and > thus it will not be double-spoken.
(In reply to Joanmarie Diggs from comment #2) > Michael: Could you please take a look at this? Thanks in advance! Yes, and sorry for not getting to it earlier. > From debugging things on the Orca side, it looks like the following is > taking place when moving from Sheet 1 to Sheet 2: > > 1. The document fires object:children-changed:remove for Sheet 1 > 2. The document fires object:children-changed:add for Sheet 2 > 3. Sheet 2 fires object:active-descendant-changed for the selected cell Thanks for the detailed analysis, this is exactly what happens. Sending a state-changed:focused event for the sheet totally makes sense to me. Pending Gerrit change implementing it: https://gerrit.libreoffice.org/c/core/+/173331 With that in place, the events are as I understand your suggestion. From Accerciser's event monitor: 86.3 object:children-changed:remove(0, 0, [table | Sheet Sheet2]) source: [document spreadsheet | Untitled 1 - LibreOfficeDev Spreadsheets] application: [application | soffice] 86.3 object:children-changed:add(0, 0, [table | Sheet Sheet3]) source: [document spreadsheet | Untitled 1 - LibreOfficeDev Spreadsheets] application: [application | soffice] 86.3 object:state-changed:focused(1, 0, 0) source: [table | Sheet Sheet3] application: [application | soffice] 86.3 object:active-descendant-changed(212998, 0, [table cell | G14]) source: [table | Sheet Sheet3] application: [application | soffice] However, when testing this with Orca as of 6f6e0f79ff5d8669591c7c19ecdaca5ec45ab67d, i.e. without your workaround in place, Orca's behavior remains unchanged for me: > Expected results: Orca would announce the name of the sheet before > announcing the selected cell. > > Actual results: Orca just announces the selected cell. Any thoughts?
(In reply to Michael Weghorn from comment #4) > Thanks for the detailed analysis, this is exactly what happens. > Sending a state-changed:focused event for the sheet totally makes sense to > me. Pending Gerrit change implementing it: > https://gerrit.libreoffice.org/c/core/+/173331 Thanks! > With that in place, the events are as I understand your suggestion. From > Accerciser's event monitor: > > > 86.3 object:children-changed:remove(0, 0, [table | Sheet Sheet2]) > source: [document spreadsheet | Untitled 1 - LibreOfficeDev > Spreadsheets] > application: [application | soffice] > 86.3 object:children-changed:add(0, 0, [table | Sheet Sheet3]) > source: [document spreadsheet | Untitled 1 - LibreOfficeDev > Spreadsheets] > application: [application | soffice] > 86.3 object:state-changed:focused(1, 0, 0) > source: [table | Sheet Sheet3] > application: [application | soffice] > 86.3 object:active-descendant-changed(212998, 0, [table cell | G14]) > source: [table | Sheet Sheet3] > application: [application | soffice] That looks right to me. > However, when testing this with Orca as of > 6f6e0f79ff5d8669591c7c19ecdaca5ec45ab67d, i.e. without your workaround in > place, Orca's behavior remains unchanged for me: > > > Expected results: Orca would announce the name of the sheet before > > announcing the selected cell. > > > > Actual results: Orca just announces the selected cell. Bummer. Are you familiar with Orca's debugging output? If not, please see https://orca.gnome.org/debugging.html If you capture a full debug.out performing the steps to reproduce the problem, you should find the events being fired along with what Orca decided to do (or not do) in response. See if there's any insight there. And thanks again!
Created attachment 196424 [details] orca debug output with https://gerrit.libreoffice.org/c/core/+/173331/1 (In reply to Joanmarie Diggs from comment #5) > Bummer. Are you familiar with Orca's debugging output? If not, please see > https://orca.gnome.org/debugging.html > > If you capture a full debug.out performing the steps to reproduce the > problem, you should find the events being fired along with what Orca decided > to do (or not do) in response. See if there's any insight there. Thanks, that's really helpful. Attached is Orca's debug output. The relevant sheet switch is from "Sheet3", cell "E11" to "Sheet1", cell "A1". This here (lines 10256) looks related: > ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ > > > 12:54:46.132474 - EVENT MANAGER: object:property-change:accessible-value for [split pane] in [application: 'accerciser'] (0, 0, 0) > 12:54:46.132714 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > 12:54:46.132766 - EVENT_MANAGER: Ignoring due to multiple events of this type in short time > > 12:54:46.132836 - EVENT MANAGER: object:property-change:accessible-value for [split pane] in [application: 'accerciser'] (0, 0, 0) > 12:54:46.133068 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > 12:54:46.133113 - EVENT_MANAGER: Ignoring due to multiple events of this type in short time > > 12:54:46.133177 - EVENT MANAGER: object:property-change:accessible-value for [split pane] in [application: 'accerciser'] (0, 0, 0) > 12:54:46.133409 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > 12:54:46.133453 - EVENT_MANAGER: Ignoring due to multiple events of this type in short time > 12:54:46.133775 - EVENT MANAGER: Dequeued object:active-descendant-changed for [table: 'Sheet Sheet1'] in [application: 'soffice'] (0, 0, [table cell: 'A1']) > > vvvvv PROCESS OBJECT EVENT object:active-descendant-changed (queue size: 40) vvvvv It seems Orca is ignoring the event intentionally to avoid event flooding. (?) Any ideas how to prevent that?
(In reply to Michael Weghorn from comment #6) > It seems Orca is ignoring the event intentionally to avoid event flooding. > (?) > Any ideas how to prevent that? Looking again, the actually relevant are more likely the ones above these: > 12:54:46.127822 - FOCUS MANAGER: Locus of focus is [table cell: 'E11'] > 12:54:46.128029 - SOFFICE: Event believed to be post-editing focus claim based on role. > 12:54:46.128086 - FOCUS MANAGER: Request to set locus of focus to [table: 'Sheet Sheet1'] event_manager._dequeue_object_event > event_manager._process_object_event > script.on_focused_changed > focus_manager.set_locus_of_focus > 12:54:46.129079 - AXObject: Clearing AT-SPI cache on [table: 'Sheet Sheet1'] Recursive: False. Reason: Setting locus of focus. > 12:54:46.129106 - SCRIPT MANAGER: Active script is: soffice (module=orca.scripts.apps.soffice.script) event_manager._process_object_event > script.on_focused_changed > focus_manager.set_locus_of_focus > script_manager.get_active_script > 12:54:46.131507 - FOCUS MANAGER: Changing locus of focus from [table cell: 'E11'] to [table: 'Sheet Sheet1']. Notify: False > 12:54:46.131786 - FOCUS MANAGER: Region of interest: [table: 'Sheet Sheet1'] (0, 0) > 12:54:46.132177 - FOCUS MANAGER: Switching object of interest from [table cell: 'E11'] to [table: 'Sheet Sheet1'] In particular: > 12:54:46.131507 - FOCUS MANAGER: Changing locus of focus from [table cell: 'E11'] to [table: 'Sheet Sheet1']. Notify: False but just from the log, it's not clear to me why the decision is: "Notify: False"
(In reply to Michael Weghorn from comment #7) > but just from the log, it's not clear to me why the decision is: "Notify: > False" But that's mostly due to myself not being familiar with reading those logs... Looking into Orca code, the > 12:54:46.128029 - SOFFICE: Event believed to be post-editing focus claim based on role. turns out to show the cause. Dropping the following lines in Orca for testing makes Orca announce the sheet, but it doesn't just say "Sheet 1, ...", but starts at the very top of the hierarchy, with the top-level frame: "Untitled 1,..." https://gitlab.gnome.org/GNOME/orca/-/blob/4ead75fdaebdde60535cfbadca108ccaeeeb9401/src/orca/scripts/apps/soffice/script.py#L471-476
(In reply to Michael Weghorn from comment #8) > Dropping the following lines in Orca for testing makes Orca announce the > sheet, but it doesn't just say "Sheet 1, ...", but starts at the very top of > the hierarchy, with the top-level frame: "Untitled 1,..." > [...] IIUC, the cause for announcing the whole hierarchy might be that Orca is unable to identify that the spreadsheet document is the ancestor of both, the previously selected cell in the other sheet, and the newly selected sheet. From a new debug log with the local Orca modification for testing in place: > 14:02:53.845023 - SCRIPT UTILITIES: Looking for common ancestor of [table: 'Sheet Sheet1'] and [table cell: 'G21'] > 14:02:53.845352 - AXObject: Exception in get_child_count: object no longer exists > 14:02:53.845356 - AXObject: Adding to known dead objects ax_object.get_parent_checked > ax_object.get_child_count > ax_object.handle_error > ax_object._set_known_dead_status > 14:02:53.847103 - AXObject: [table cell: 'G21'] has index 327686 ; parent [DEAD] has 0 children > 14:02:53.847185 - SCRIPT UTILITIES: Common ancestor of [table: 'Sheet Sheet1'] and [table cell: 'G21'] is None > 14:02:53.847192 - DEFAULT: Not in SayAll > 14:02:53.847396 - AXObject: [table cell: 'G21'] has index 327686 ; parent [DEAD] has 0 children > 14:02:53.847423 - GENERATOR: _get_functional_role: invalid > 14:02:53.847436 - SPEECH GENERATOR: _generate_old_ancestors: [] > 14:02:53.847444 - SOFFICE SPEECH GENERATOR: _generate_old_ancestors: [] > 14:02:53.847461 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > 14:02:53.847639 - SCRIPT UTILITIES: Looking for common ancestor of [table cell: 'G21'] and [table: 'Sheet Sheet1'] > 14:02:53.847829 - AXObject: [table cell: 'G21'] has index 327686 ; parent [DEAD] has 0 children > 14:02:53.848070 - SCRIPT UTILITIES: Common ancestor of [table cell: 'G21'] and [table: 'Sheet Sheet1'] is None No easy way to solve that comes to my mind right now, as it looks like Calc currently only has a single spreadsheet in its a11y tree at a time, i.e. at the point in time where it switches to the new sheet, the a11y representation of the old one is deleted and thus walking up the a11y path of the previous cell no longer works and it's considered dead by Orca, IIUC.
> Thanks, that's really helpful. Attached is Orca's debug output. Yeah, Orca's logs are like novels. :D As you alluded to in a later comment, reading them takes some getting used to. For example: > > 12:54:46.132474 - EVENT MANAGER: object:property-change:accessible-value for [split pane] in [application: 'accerciser'] (0, 0, 0) > > 12:54:46.132714 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > > 12:54:46.132766 - EVENT_MANAGER: Ignoring due to multiple events of this type in short time > > > > 12:54:46.132836 - EVENT MANAGER: object:property-change:accessible-value for [split pane] in [application: 'accerciser'] (0, 0, 0) > > 12:54:46.133068 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > > 12:54:46.133113 - EVENT_MANAGER: Ignoring due to multiple events of this type in short time > > > > 12:54:46.133177 - EVENT MANAGER: object:property-change:accessible-value for [split pane] in [application: 'accerciser'] (0, 0, 0) > > 12:54:46.133409 - FOCUS MANAGER: Locus of focus is [table: 'Sheet Sheet1'] > > 12:54:46.133453 - EVENT_MANAGER: Ignoring due to multiple events of this type in short time Should be read as "Accerciser fired a value-change event. Focus happens to be on Sheet 1. I'm ignoring Accerciser's value event because they just keep coming." Hopefully https://gitlab.gnome.org/GNOME/orca/-/commit/1165e426e helps. But Orca never ignores an event if it comes from an object which is focused, is selected, or is the current object ("locus of focus") in Orca. In order to determine if the object is the current object, it has to retrieve that object which generates a log line. Sorry for the confusion!
(In reply to Michael Weghorn from comment #7) > but just from the log, it's not clear to me why the decision is: "Notify: > False" Notify means set it in the focus manager but don't tell the scripts otherwise they'll update their state and likely speak and braille the change. If you look at the workaround I committed it's a similar situation: 1. Set the locus of focus to the parent of the table without notification. 2. Set the locus of focus to the table with notification. Since the script believes focus changed from the parent of the table to the table, present just the table. 3. Do normal processing for the active descendant change. Focus went from the table to a child cell, so just present the cell.
(In reply to Michael Weghorn from comment #9) > No easy way to solve that comes to my mind right now, as it looks like Calc > currently only has a single spreadsheet in its a11y tree at a time, i.e. at > the point in time where it switches to the new sheet, the a11y > representation of the old one is deleted and thus walking up the a11y path > of the previous cell no longer works and it's considered dead by Orca, IIUC. So maybe a different, less hacky workaround for Orca? Here's a quick and dirty diff that might solve it, or might need changes: diff --git a/src/orca/scripts/apps/soffice/script_utilities.py b/src/orca/scripts/apps/soffice/script_utilities.py index 8ba34be4e..a903fda2c 100644 --- a/src/orca/scripts/apps/soffice/script_utilities.py +++ b/src/orca/scripts/apps/soffice/script_utilities.py @@ -107,6 +107,18 @@ class Utilities(script_utilities.Utilities): return results + def commonAncestor(self, a, b): + result = super().commonAncestor(a, b) + if result is not None: + return result + + # https://bugs.documentfoundation.org/show_bug.cgi?id=161444 + focus = focus_manager.get_manager().get_locus_of_focus() + ancestor = AXObject.find_ancestor(focus, AXUtilities.is_document_spreadsheet) + tokens = ["SOFFICE: Returning", ancestor, "as common ancestor. LO BUG: 161444"] + debug.print_tokens(debug.LEVEL_INFO, tokens, True) + return ancestor + Could you please see if that solves it?
(In reply to Joanmarie Diggs from comment #10) > As you alluded to in a later comment, reading them takes some getting used > to. For example: > > [...] > Should be read as "Accerciser fired a value-change event. Focus happens to > be on Sheet 1. I'm ignoring Accerciser's value event because they just keep > coming." > > Hopefully https://gitlab.gnome.org/GNOME/orca/-/commit/1165e426e helps. Thanks! My main mistake was to look for something that looked relevant starting at the bottom of the log and then continuing below the > ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ instead of above it (and ignoring too much of the context in general, as it felt a bit overwhelming at first). The "^^^^" pointing to above is actually quite clear in hindsight...
Created attachment 196428 [details] local orca diff on top of git main as of 4ead75fdaebdde60535cfbadca108ccaeeeb9401 (In reply to Joanmarie Diggs from comment #12) > So maybe a different, less hacky workaround for Orca? Sounds good to me for now. > Here's a quick and dirty diff that might solve it, or might need changes: > > diff --git a/src/orca/scripts/apps/soffice/script_utilities.py > b/src/orca/scripts/apps/soffice/script_utilities.py > index 8ba34be4e..a903fda2c 100644 > --- a/src/orca/scripts/apps/soffice/script_utilities.py > +++ b/src/orca/scripts/apps/soffice/script_utilities.py > @@ -107,6 +107,18 @@ class Utilities(script_utilities.Utilities): > > return results > > + def commonAncestor(self, a, b): > + result = super().commonAncestor(a, b) > + if result is not None: > + return result > + > + # https://bugs.documentfoundation.org/show_bug.cgi?id=161444 > + focus = focus_manager.get_manager().get_locus_of_focus() > + ancestor = AXObject.find_ancestor(focus, > AXUtilities.is_document_spreadsheet) > + tokens = ["SOFFICE: Returning", ancestor, "as common ancestor. LO > BUG: 161444"] > + debug.print_tokens(debug.LEVEL_INFO, tokens, True) > + return ancestor > + > > Could you please see if that solves it? Thanks! That indeed makes announcement work if used on top of 6f6e0f79ff5d8669591c7c19ecdaca5ec45ab67d with the other lines mentioned in comment 8 removed as well. Looking at my previously removed lines, I'm aware of this scenario where they are relevant: Edit a cell, then press Tab key to move to the next cell. With the lines removed, Orca will announce "Sheet Sheet 1, <next cell>" instead of just the new cell. IIRC, the reason is that there are 2 separate/different objects for the cell being edited (which is using EditEngine, has paragraph children,... and is not a child of the sheet) and the "simple" cell object as exposed as a child of the table (which doesn't have paragraph children, but exposes the text directly via the Text interface). To not have more chatty output for that scenario, leaving the suppression for the paragraph role should be enough. That makes it work as expected in my tests. Attached is my orca diff against git main as of 4ead75fdaebdde60535cfbadca108ccaeeeb9401 for reference. Does that make sense?
(In reply to Michael Weghorn from comment #14) > Attached is my orca diff against git main as of > 4ead75fdaebdde60535cfbadca108ccaeeeb9401 for reference. Does that make sense? From a quick read, it does. But does it depend on your firing the focus event on the table? (I'm working on non-Orca day-job stuff today and not at a point to try your proposed change. Sorry!)
(In reply to Joanmarie Diggs from comment #15) > From a quick read, it does. But does it depend on your firing the focus > event on the table? Yes, it does. Without https://gerrit.libreoffice.org/c/core/+/173331 , the new sheet is not announced when switching sheets, but only the cell.
(In reply to Michael Weghorn from comment #16) > (In reply to Joanmarie Diggs from comment #15) > > From a quick read, it does. But does it depend on your firing the focus > > event on the table? > > Yes, it does. Without https://gerrit.libreoffice.org/c/core/+/173331 , the > new sheet is not announced when switching sheets, but only the cell. Ok, then how about the following plan: 1. We leave my hack in the gnome-47 branch. I'm assuming that my hack won't break anything after your fix. If I'm wrong about that, please let me know. 2. Once your fix lands in a stable release, we apply your change to Orca in the main branch. ?
(In reply to Joanmarie Diggs from comment #17) > Ok, then how about the following plan: > [...] Sounds good to me! > 1. We leave my hack in the gnome-47 branch. I'm assuming that my hack won't > break anything after your fix. If I'm wrong about that, please let me know. That's correct, your hack in current orca main works fine with pending LO change https://gerrit.libreoffice.org/c/core/+/173331 in place as well. > 2. Once your fix lands in a stable release, we apply your change to Orca in > the main branch. Just to mention it, I wouldn't claim the Orca change is "mine" as it mostly consists of your suggested changes. :-)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/366dec115e3805e50071c39da2cf847b99aa8f7a tdf#161444 sc a11y: Send focused event when switching sheets 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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/246d126e6a2e183e16c3a67c6026580436051c30 tdf#161444 sc a11y: Send focused event when switching sheets It will be available in 24.8.2. 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.
I hadn't realized I had a version with the fix until I started ignoring a focus event from the root pane which comes *after* the focus event for the document object. See https://gitlab.gnome.org/GNOME/orca/-/commit/5e573ec9c2. If you are surprised by the root pane event, could you please fix it? :) I'm not sure I can call it a bug. But if it's not happening on purpose, and it's news to you, might as well stop firing the event. Anyhoo, once Orca stopped saying "Root pane", it started saying the sheet name twice. So I had to tweak the workaround. See https://gitlab.gnome.org/GNOME/orca/-/commit/153b255300e Thanks again for fixing this bug!
Oops one more change was needed in Orca: https://gitlab.gnome.org/GNOME/orca/-/commit/ab02e9caae4b Now everything seems right as best as I can tell. Thanks again!
(In reply to Joanmarie Diggs from comment #21) > I hadn't realized I had a version with the fix until I started ignoring a > focus event from the root pane which comes *after* the focus event for the > document object. See https://gitlab.gnome.org/GNOME/orca/-/commit/5e573ec9c2. > > If you are surprised by the root pane event, could you please fix it? :) I'm > not sure I can call it a bug. But if it's not happening on purpose, and it's > news to you, might as well stop firing the event. I can see that happening as well. From Accerciser's event monitor: 32.8 object:state-changed:focused(1, 0, 0) source: [table | Sheet Sheet1] application: [application | soffice] 32.8 object:active-descendant-changed(163845, 0, [table cell | F11]) source: [table | Sheet Sheet1] application: [application | soffice] 32.8 object:state-changed:focused(1, 0, 0) source: [root pane | Untitled 1 — LibreOfficeDev Calc 25.2 [ff8e1b98529b0b278730035a37412a5cc0f58c0d]] application: [application | soffice] From what I can see so far, that `object:state-changed:focused` event on the root pane is from GTK 3's internal widget a11y handling for the `OOoFixed` LO widget which is a GtkFixed (see vcl/unx/gtk3/gtkframe.cxx). Backtrace for how the focused event gets sent: >~"#0 atk_object_notify_state_change (accessible=0x55e13d3c82f0, state=11, value=1) at ../atk/atkobject.c:1211\n" >~"#1 0x00007f92b0d84a2d in gail_focus_notify (widget=0x55e13bb84e20) at ../gtk/a11y/gtkaccessibility.c:530\n" >~"#2 0x00007f92b0d848bf in gail_focus_idle_handler (data=0x55e13bb84e20) at ../gtk/a11y/gtkaccessibility.c:483\n" >~"#3 0x00007f92b1c38561 in gdk_threads_dispatch (data=0x55e13e189b80) at ../gdk/gdk.c:769\n" >~"#4 0x00007f92b710c7df in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0\n" >~"#5 0x00007f92b710ea17 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0\n" >~"#6 0x00007f92b710f180 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0\n" >~"#7 0x00007f92b1476a0c in GtkSalData::Yield (this=0x55e139b7cfa0, bWait=true, bHandleAllCurrentEvents=false) at vcl/unx/gtk3/gtkdata.cxx:405\n" >~"#8 0x00007f92b147b7a3 in GtkInstance::DoYield (this=0x55e139b7ce50, bWait=true, bHandleAllCurrentEvents=false) at vcl/unx/gtk3/gtkinst.cxx:425\n" >~"#9 0x00007f92bbb1d356 in ImplYield (i_bWait=true, i_bAllEvents=false) at vcl/source/app/svapp.cxx:385\n" >~"#10 0x00007f92bbb1ccef in Application::Yield () at vcl/source/app/svapp.cxx:473\n" >~"#11 0x00007f92bbb1cad0 in Application::Execute () at vcl/source/app/svapp.cxx:360\n" >~"#12 0x00007f92c4926a94 in desktop::Desktop::Main (this=0x7ffde349d668) at desktop/source/app/app.cxx:1683\n" >~"#13 0x00007f92bbb3dc5a in ImplSVMain () at vcl/source/app/svmain.cxx:228\n" >~"#14 0x00007f92bbb3f879 in SVMain () at vcl/source/app/svmain.cxx:246\n" >~"#15 0x00007f92c49a0baa in soffice_main () at desktop/source/app/sofficemain.cxx:121\n" >~"#16 0x000055e117737a6d in sal_main () at /home/michi/development/git/libreoffice/desktop/source/app/main.c:51\n" >~"#17 0x000055e117737a47 in main (argc=2, argv=0x7ffde349d878) at /home/michi/development/git/libreoffice/desktop/source/app/main.c:49\n" Looking into gtk3 source code, seeing the `gail_focus_idle_handler` (and the related `gail_focus_notify_when_idle`), I think what may be happening here is that GTK doesn't send the focused event right away, but does so via an idle (i.e. it's delayed), which may be the reason it happens only *after* the focused event that LO sends for the document (sheet + table cell). However, since this is GTK-internal handling, I currently can't come up with a good idea to prevent that from happening on LO side. (I don't see this when using the qt6 VCL plugin instead of gtk3.)
(In reply to Joanmarie Diggs from comment #22) > Oops one more change was needed in Orca: > https://gitlab.gnome.org/GNOME/orca/-/commit/ab02e9caae4b > > Now everything seems right as best as I can tell. Thanks again! Thanks for handling the Orca side! Do your recent commits update/replace the original plan from comment 17 (i.e. obsolete attachment 196428 [details] )? In any case, I'm closing this ticket now, since the original LO bug reported here is fixed.