https://bugs.documentfoundation.org/show_bug.cgi?id=168278
Bug ID: 168278
Summary: Calc cells report 0 accessible text selections via
ATK/AT-SPI
Product: LibreOffice
Version: 25.2.5.2 release
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
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
--
You are receiving this mail because:
You are the assignee for the bug.
