Description: It is possible to ascend the accessibility tree all the way to the desktop frame from outside the Calc spreadsheet (e.g. from within a menu). This also used to work reliably from within the spreadsheet; it no longer does. N.B. I'm putting "sometimes" as the reproducibility. HOWEVER, right now it's happening all the time for me. In the past this sometimes happened and sometimes did not. Steps to Reproduce: 1. Launch Calc 2. Launch the attached accessible-event listener in a terminal 3. Arrow within the file menu 4. Arrow within the spreadsheet Actual Results: ----- object:selection-changed in [menu | File]: child 0. ancestors of source: menu bar, viewport, scroll pane, panel, panel, frame, application, desktop frame object:active-descendant-changed in [table | Sheet Sheet1]: child [table cell | G7]. ancestors of source: document spreadsheet, panel, panel, root pane, frame ----- Note that in the second case the final object is "frame" whereas in the first case, after frame, there is "application, desktop frame" Expected Results: In both cases, after frame, there would be "application, desktop frame" Reproducible: Sometimes User Profile Reset: Yes Additional Info: Version: 24.2.2.1 (X86_64) Build ID: 420(Build:1) CPU threads: 48; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 193836 [details] accessible-event listener
Michael: Can you please take a look? I still need to debug exactly why, but this issue is making Orca extremely chatty when arrowing around in a Calc spreadsheet. Thanks!
I'm now working around this in Orca's main and gnome-46 branches, but it would be best to have it fixed, especially for users of older versions of Orca.
Created attachment 193851 [details] accessible-event listener (fixed listener, original one fails for me like this: $ python3 /tmp/broken_listener.py File "/tmp/broken_listener.py", line 18 print(f"ancestors of source: {", ".join(ancestors)}") ^ SyntaxError: f-string: expecting '}' )
(In reply to Joanmarie Diggs from comment #0) > N.B. I'm putting "sometimes" as the reproducibility. HOWEVER, right now it's > happening all the time for me. In the past this sometimes happened and > sometimes did not. It doesn't happen reliably for me, but I could finally reproduce. Interestingly, I can currently reliably reproduce when starting LO as SAL_USE_VCLPLUGIN=gtk3 ./instdir/program/soffice.bin --calc > object:active-descendant-changed in [table | Sheet Sheet1]: child [table cell | B1]. > ancestors of source: document spreadsheet, panel, panel, root pane, frame > > object:selection-changed in [table | Sheet Sheet1]: child 0. > ancestors of source: document spreadsheet, panel, panel, root pane, frame while everything is fine when starting using the shell wrapper: SAL_USE_VCLPLUGIN=gtk3 ./instdir/program/soffice --calc > object:active-descendant-changed in [table | Sheet Sheet1]: child [table cell | B1]. > ancestors of source: document spreadsheet, panel, panel, root pane, frame, application, desktop frame > > object:selection-changed in [table | Sheet Sheet1]: child 0. > ancestors of source: document spreadsheet, panel, panel, root pane, frame, application, desktop frame Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 93b986e93de32a4cf62571a5cba354ba49f8a983 CPU threads: 32; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
(In reply to Michael Weghorn from comment #5) > while everything is fine when starting using the shell wrapper: > > SAL_USE_VCLPLUGIN=gtk3 ./instdir/program/soffice --calc The wrapper runs oosplash, and when doing that directly: SAL_USE_VCLPLUGIN=gtk3 instdir/program/oosplash --calc All of these tests were on KDE Plasma Wayland on Debian testing. Forcing the X11 GDK backend makes it misbehave for me again: GDK_BACKEND=x11 SAL_USE_VCLPLUGIN=gtk3 instdir/program/oosplash --calc I don't see anything obvious yet, maybe it's some race condition and the different ways to start LO just influence the timing... (?) (In reply to Joanmarie Diggs from comment #3) > I'm now working around this in Orca's main and gnome-46 branches, but it > would be best to have it fixed, especially for users of older versions of > Orca. For reference: https://gitlab.gnome.org/GNOME/orca/-/commit/509bdc401fd123623fb16fceaa6d7b906521d703
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/252b1591d5e4e3adbf7063b56c2b578fe046ad3d tdf#159369 tdf#160806 tdf#160837 gtk3 a11y: Don't skip parents one way It will be available in 24.8.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 "master": https://git.libreoffice.org/core/commit/be543e321552d4331e7dddca954a2b57f4c7f379 tdf#159369 tdf#160806 gtk3 a11y: Drop fallback dummy a11y obj It will be available in 24.8.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 Joanmarie Diggs from comment #0) > Steps to Reproduce: > 1. Launch Calc > 2. Launch the attached accessible-event listener in a terminal The order is actually relevant: The issue is (more) reproducible when starting Calc before starting running the script. The commit from comment 7 makes the case when AT is started before LO more reliable, but further analysis + fixing is needed in particular for the case where LO is started first. (I have an approach in mind now.)
Michael: I'm seeing similar weirdness but this time with what visually look like editable comboboxes on the formatting toolbar, e.g. paragraph style, font name, font size. When I arrow up and down with the widget collapsed, we get a focused event (and an active descendant changed event) for a table cell. In the former case, Orca is ignoring the event and the debug log indicates it's for a similar issue namely the top level object (with role window; not role frame) claims to have no parent. (In the latter case, it's presenting the event but doing so incorrectly for reasons I have yet to debug.) I haven't yet tried a build with the changes mentioned in comment 7 and comment 8. So apologies if you already fixed this. Possibly related aside: Can you get at the options (e.g. "Default Paragraph Style", "Title", etc.) via Accercsier? I cannot. I find the associated panels, but when I drill down the table in question is not present. It's like the reverse of the bug in the opening report. Semi-related aside: Why are these drop-downs tables? Orca's table-related logic is kicking in for what functionally (IMHO) is not a table. :-/
(In reply to Joanmarie Diggs from comment #10) > Michael: I'm seeing similar weirdness but this time with what visually look > like editable comboboxes on the formatting toolbar, e.g. paragraph style, > font name, font size. > > When I arrow up and down with the widget collapsed, we get a focused event > (and an active descendant changed event) for a table cell. In the former > case, Orca is ignoring the event and the debug log indicates it's for a > similar issue namely the top level object (with role window; not role frame) > claims to have no parent. (In the latter case, it's presenting the event but > doing so incorrectly for reasons I have yet to debug.) I can reproduce that with Writer. I noticed however that the object:state-changed:focused event for the collapsed combobox only gets sent once the combobox has been expanded once, then collapsed again. Before doing that, no such event is sent when switching entries in the collapsed combobox. As in comment 9, the hierarchy is fine when when starting the listener script before starting Writer, but the hierarchy is broken when starting LO first. > I haven't yet tried a build with the changes mentioned in comment 7 and > comment 8. So apologies if you already fixed this. For testing, I don't see any need to rush before I got into looking into the remaining known issues mentioned in comment 9 as well (in particular the scenario where LO is started first). > Possibly related aside: Can you get at the options (e.g. "Default Paragraph > Style", "Title", etc.) via Accercsier? I cannot. I find the associated > panels, but when I drill down the table in question is not present. It's > like the reverse of the bug in the opening report. I can reproduce that here, s.a. explanation below. > Semi-related aside: Why are these drop-downs tables? Orca's table-related > logic is kicking in for what functionally (IMHO) is not a table. :-/ Due to shortcomings in the native GTK 3 combobox, LO cannot use that one, but as a workaround, it has its own implementation of a combobox when using the gtk3 VCL plugin, see this commit and the referenced GTK issues: commit bc0e0f633b05c4f91b6695488fc9e5c127507ba5 Author: Caolán McNamara Date: Thu Apr 9 11:41:00 2020 +0100 tdf#131120 use a replacement for GtkComboBox For that reason, it also behaves differently on the a11y layer than the stock GtkComboBox. From a quick look at the related .ui file (vcl/uiconfig/ui/combobox.ui), this one is using a GtkTreeView. I didn't look into it more closely yet, but IIUC, the table cell a11y role is used for entries in the GtkTreeView, i.e. comes from the GTK library rather than being explicitly set by LO. Seeing that the GTK issues are not resolved yet (e.g. performance issue https://gitlab.gnome.org/GNOME/gtk/-/issues/1910 ), switching to the stock GTK combobox still doesn't look like an option at this point. Whether the reported role can reasonably be tweaked with the custom combobox implementation would need some further analysis as I'm not that experienced with GTK.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c1a7de292c3f1d1ec52dbda4c027dc91a9718777 tdf#160806 tdf#160837 gtk3 a11y: Don't use idle It will be available in 24.8.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 "master": https://git.libreoffice.org/core/commit/1b9041a7c97c31a12afe7b69f0e1e4005a819509 tdf#160806 tdf#160837 gtk3 a11y: Port from deprecated atk_focus_tracker_notify It will be available in 24.8.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 "master": https://git.libreoffice.org/core/commit/c45c64aeb57dce91965d7be54601128946455c90 tdf#160806 tdf#160837 gtk3 a11y: Drop handling of some VclEventIds It will be available in 24.8.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 "master": https://git.libreoffice.org/core/commit/593923ee108b01c03ee3b14295fedfb8d07e7ea0 tdf#160806 tdf#160837 gtk3 a11y: Drop VclEventId::ToolboxButtonStateChanged It will be available in 24.8.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 #11) > > I haven't yet tried a build with the changes mentioned in comment 7 and > > comment 8. So apologies if you already fixed this. > > For testing, I don't see any need to rush before I got into looking into the > remaining known issues mentioned in comment 9 as well (in particular the > scenario where LO is started first). I cannot reproduce the issue of a broken a11y hierarchy any more with the additional commits from comment 12 to comment 15 in place - neither for the initially reported Calc case nor for editable comboboxes as reported in comment 10. @Joanie: Could you please retest with a daily build of tomorrow or later whether this works fine for you as well now? I also did some more cleanup of the gtk3/ATK a11y bridge - please let me know if you notice anything suspicious. Closing as fixed for now, please reopen if you still see this issue.
@Joanie: Related to your previous comment regarding editable comboboxes, I've created tdf#160971 for tracking further work on improving announcement of these by Orca.