Description: Using AT-SPI2 to remove/clear the selection in a paragraph results in the caret being moved to the start of the paragraph. It should instead leave the caret where it was, but unselect the text. Steps to Reproduce: 1. Create a new document and type at least 10 characters. 2. Select some characters in the middle. 3. Use AT-SPI2 to remove the selection. Here's an example of doing 3 via Accerciser's iPython console: In: text = acc.queryText() In: text.caretOffset Out: 8 << End of selection. Good. In: text.getNSelections() Out: 1 In: selection = text.getSelection(0) In: selection[0] Out: 4 << Start offset of selection. Good. In: selection[1] Out: 8 << End offset of selection, caret offset. Good. In: text.removeSelection(0) Out: True In: text.caretOffset Out: 0 << Why?? Actual Results: Removing the selection resets the caret to the beginning of the paragraph. Expected Results: Removing the selection would leave the caret in place (in the above steps, offset 8). Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.5.2 (X86_64) Build ID: 520(Build:2) CPU threads: 48; OS: Linux 6.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Michael: Please take a look. I'm working on global caret navigation in Orca because it's the next step in global browse mode. This bug has the following impact: Steps to reproduce (using my local WIP code): 1. Select some text using native navigation. 2. Toggle Orca's caret navigation on. 3. Press Right Arrow. Expected results: The text selection would be cleared (because Shift wasn't being used) and the caret would be moved one character to the right of the previous selection end. Actual results: The text selection is cleared and you're back at the beginning of the paragraph. I suspect I can work around this without much difficulty, but as you know, I hate adding workarounds in Orca because it's just more technical debt. Thanks in advance!
Thanks for the detailed report. I can reproduce this with gtk3, and looking at the implementation makes clear why it currently behaves the way it does: static gboolean text_wrapper_remove_selection (AtkText *text, gint selection_num) { g_return_val_if_fail( selection_num == 0, FALSE ); try { css::uno::Reference<css::accessibility::XAccessibleText> pText = getText( text ); if( pText.is() ) return pText->setSelection( 0, 0 ); // ? } catch(const uno::Exception&) { g_warning( "Exception in setSelection()" ); } return FALSE; } In addition, the selection doesn't get cleared at all when using the qt6 VCL plugin. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ccd12a015b8ce69776614754dfca16d28113cb1f CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Pending change series to make the scenario described here work for both, gtk3 and qt6: https://gerrit.libreoffice.org/c/core/+/189580 Note: Managing multiple selections via AT-SPI is currently not implemented for both, the gtk3 and qt6 VCL plugins. (There is an internal interface, but it didn't actually work in a quick test, so I didn't adjust code to use that one, but for now focused on making the single-selection scenario work.)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/315c94c91adc6a9e79a78b304e8d2b95e2f45b80 tdf#167930 gtk3 a11y: Keep caret pos when removing selection It will be available in 26.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 "master": https://git.libreoffice.org/core/commit/d540577625ab140930f8467822aec70ede817ed5 tdf#167930 qt a11y: Implement QtAccessibleWidget::{add,remove}Selection It will be available in 26.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 "master": https://git.libreoffice.org/core/commit/cf118143d6fd74ecce76fda74bb3c899d08f7ed1 tdf#167930 wina11y: Keep caret pos when removing selection It will be available in 26.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-25-8": https://git.libreoffice.org/core/commit/76db1af13b394c944876adddd8ddd6bc61a7557f tdf#167930 gtk3 a11y: Keep caret pos when removing selection It will be available in 25.8.1. 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.