Description: Because Calc reports 0 accessible text selections, Orca assumes no text is selected and thus doesn't report it. Steps to Reproduce: 1. Write "this is a test" in cell A1 2. In editing mode, use shift+left to select from the end of "test" to the beginning of this. 3. While still in editing mode, use Accerciser's iPython console to call getNSelections()/get_n_selections() on the accessible paragraph. Actual Results: 0 is returned Expected Results: 1 is returned because there is selected text. Reproducible: Always User Profile Reset: No Additional Info: Notes: 1. If you ignore the fact that 0 is returned and call getSelection(0)/get_selection(0), you actually do get a range. But Orca currently uses get_n_selections() to see if there's anything selected, and I don't think it's unreasonable for Orca to do that. Thus it would be great to have the correct value returned. 2. The range returned appears to reflect the start and end offsets with respect to what the user did (14, 0) rather than with respect to the text itself (0, 14). I'm pretty sure Orca isn't handling that currently. Maybe Orca should be.... But if LO could return (0, 14) instead of (14, 0), I'd appreciate it. 3. When I perform the equivalent steps in Writer, I get the expected results (get_n_selections() returns 1, and get_selection(0) returns (0, 14) even though I selected from right to left). 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
Thanks for the detailed report! Pending fix: https://gerrit.libreoffice.org/c/core/+/190716 (In reply to Joanmarie Diggs from comment #0) > 2. The range returned appears to reflect the start and end offsets with > respect to what the user did (14, 0) rather than with respect to the text > itself (0, 14). I'm pretty sure Orca isn't handling that currently. Maybe > Orca should be.... But if LO could return (0, 14) instead of (14, 0), I'd > appreciate it. This was adjusted to be (0, 14) for Calc/EditEngine as well now. Reporting it the other way around was actually the underlying issue for no selection being reported at all, as the LO gtk3 a11y bridge only reports a selection if the end index is larger than the start index. The AT-SPI doc isn't very explicit, but in a quick test, other applications also always use the smaller index for the start index, so doing so seems reasonable.
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/be739cff91a9ee31a8055061f97e6de802f3da3d tdf#168278 editeng a11y: Normalize selection start/end index 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.