https://bugs.documentfoundation.org/show_bug.cgi?id=150064

            Bug ID: 150064
           Summary: Accessible tree order is unstable
           Product: LibreOffice
           Version: unspecified
          Hardware: All
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Impress
          Assignee: [email protected]
          Reporter: [email protected]

Created attachment 181334
  --> https://bugs.documentfoundation.org/attachment.cgi?id=181334&action=edit
CppUnit test for default Impress document a11y layout

In at least the default document created by Impress (one page with title +
subtitle), the accessible tree layout is not entirely predictable, and its
order changes from a run to the next.

The (more or less) expected tree looks like this:
- document_presentation
  - shape (page)
  - shape (title)
    - paragraph
  - shape (subtitle)
    - paragraph

It is what I get about 80% of the times, but the other 20% the "title" and
"subtitle" nodes are swapped.  The internal representation (SdrObjects) is
always in the right order though.  Note that this happens both with the "new"
document (private:factory/simpress) and a saved version of it.

Impact on end users is not yet known as it'd depend on how often and how
widespread the issue is in "real" scenarii, but it's awkward, unexpected and
makes it terribly hard to write a test for Impress's layout.  It also makes me
worry a little about trustworthiness of that a11y tree.

As said, I am not sure if all documents are affected and it's a global order
issue, or if there's a specific at play, but it's very reproducible in a test
scenario (see attached test case).  I've actually discovered this while writing
test infrastructure for a11y and trying to exercise it a bit against the
different components; but I checked in regular running situation inspecting the
a11y tree from outside LO and it is reproducible as well -- so it's not a test
glitch.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to