Bug 96492 - Broken accessibility tree when objects are accessed via flows-to/flows-from relation
Summary: Broken accessibility tree when objects are accessed via flows-to/flows-from r...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks: a11y-Linux
  Show dependency tree / graph
 
Reported: 2015-12-14 18:52 UTC by Joanmarie Diggs
Modified: 2024-04-05 07:45 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2015-12-14 18:52:44 UTC 
(Spun off from bug 91739 comment #6)

Steps to reproduce:
1. Create a document with the following structure:

  Page 1 (which is visible)
  * Paragraph 1
  * Paragraph 2
  Page 2 (not currently visible)
  * Paragraph 3
  * Paragraph 4

2. Use Accerciser or an pyatspi script to get the last child of the document. (Result: "Paragraph 2")

3. Get the flows-to target of that child (Result: "Paragraph 3")

So far so good.

4. Get the parent of "Paragraph 3" (Result: The accessible document which contains "Paragraph 1" and "Paragraph 2")

In other words, the parent of "Paragraph 3" does not have "Paragraph 3" as a child. That's a broken tree.

Ideally, the children of the document would be accessible pages. And the children of those accessible pages would be the document's paragraphs (and headings and lists and ...). Failing that, it would be extremely helpful if:

1. As paragraphs are accessed via the flows-to/flows-from accessible relation, they are added to the document's children.

2. As paragraphs are scrolled off-screen, they are NOT removed from the list of the document's children.

Hopefully by doing the above along with emitting the appropriate accessible events (see bug 96490), the accessible tree will be more reliable.
Comment 1 Buovjaga 2016-05-06 10:57:38 UTC 
(In reply to Joanmarie Diggs from comment #0)
> 2. Use Accerciser or an pyatspi script to get the last child of the
> document. (Result: "Paragraph 2")
> 
> 3. Get the flows-to target of that child (Result: "Paragraph 3")
> 
> So far so good.
> 
> 4. Get the parent of "Paragraph 3" (Result: The accessible document which
> contains "Paragraph 1" and "Paragraph 2")

How do we do this in Accerciser?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 2 Joanmarie Diggs 2016-05-06 15:19:47 UTC 
(In reply to Buovjaga from comment #1)
> (In reply to Joanmarie Diggs from comment #0)
> > 2. Use Accerciser or an pyatspi script to get the last child of the
> > document. (Result: "Paragraph 2")
> > 

Quit Accerciser if it is running, create the document first with only page 1 showing, then launch Accerciser. In the pane on the left you should find two children of the document accessible. You can verify which paragraphs they are by expanding Text (Editable) in the Interface Viewer.

> > 3. Get the flows-to target of that child (Result: "Paragraph 3")

You can examine relations in the interface viewer (expand Accessible). But to do the subsequent tasks, iPython console is probably better. So....

Select paragraph 2 in the pane on the left and switch to the iPython console. Type the following:

r = acc.getRelationSet()
flowsToRelations = [x for x in r if x.getRelationType() == RELATION_FLOWS_TO]
target = flowsToRelations[0].getTarget(0)
target.queryText().getText(0,-1)

The result I get is 'Paragraph 3'. So target is the third paragraph. With this in mind....

> > 4. Get the parent of "Paragraph 3" (Result: The accessible document which
> > contains "Paragraph 1" and "Paragraph 2")

Still in the iPython console:

parent = target.parent
children = [x.queryText().getText(0,-1) for x in parent]
children

The result I get is ['Paragraph 1', 'Paragraph 2'].

So the parent of 'Paragraph 3' has two children, neither of which is 'Paragraph 3'.

HTH.
Comment 3 Buovjaga 2016-05-07 10:46:34 UTC 
Ok, now I could reproduce.

Note for testers: when you have launched Accerciser after creating the document, in the node view you should have:
Untitled (frame)
-[no title] (panel)
--Untitled (root pane)

and then a whole bunch of nodes.

Now look at the panel with 3 children. It has a child that is "scroll pane".
This scroll pane has a child of the type "document text".
This document text has children of the type "paragraph".

64-bit, KDE Plasma 5
Build ID: 5.1.2.2 Arch Linux build-1
CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Comment 4 QA Administrators 2017-05-22 13:39:56 UTC Comment hidden (obsolete)
Comment 5 Alex ARNAUD 2017-05-30 15:33:38 UTC 
Dear all,

I can still reproduce this bug on LibreOfficeDev 5.5 from 2017-05-28.

Best regards.
Comment 6 QA Administrators 2018-05-31 02:52:53 UTC Comment hidden (obsolete)
Comment 7 Alex ARNAUD 2018-06-16 16:03:19 UTC 
Hello all,

I can reproduce the issue with LibreOfficeDev 6.2 built the 2018-06-12 on Debian 9 "Stretch". 

Best regards,
Alex.
Comment 8 QA Administrators 2019-06-17 02:46:46 UTC Comment hidden (obsolete)
Comment 9 QA Administrators 2023-01-20 03:25:07 UTC Comment hidden (obsolete)
Comment 10 Michael Weghorn 2024-04-05 07:45:56 UTC 
tdf#35654 comment #19 also mentions the general problem being that off-screen objects are not exposed on the a11y level, which should be looked at in the context of this bug report here as well. (I'll close tdf#35654 to have things in one place, as that one was originally about implementing AtspiCollection).


(Quoting Joanmarie Diggs from tdf#35654 comment #19)
> There is not an AtkCollection interface yet. But, at least now, all
> traditional ATK implementations get their AtspiCollection implementation for
> free. As my previous comment + tool + document show, I can use
> AtspiCollection to get stuff (I used it to get all the tables).
> 
> The problem that remains is that off-screen stuff isn't in the accessibility
> tree. So if the Orca user wants to navigate to the next table, but the next
> table is on page 10 and the user is on page 1, Orca will say "no more
> tables."