Created attachment 44815 [details]
Accessible tree shows only 24 of the 26 paragraphs in the document.
Some objects at the end of a writer document are not included in the AT-SPI
accessible tree. If a document has n objects, the accessible tree shows only
(n-k) objects. When an assistive tool navigating the document reaches (n-k)th
object, it wrongly concludes that the last object is reached and wraps to the
Steps to reproduce:
1. Create a writer document containing 22 paragraphs, each paragraph consisting
of only one or two words and terminated by a new line. Save and close the
2. Reopen the document. Move the cursor to the first line.
3. Start Accerciser accessibility explorer.
4. Go to the accessible tree view at top left. As shown in attached
screen-shot, select the accessible object corresponding to the Document view,
with role document frame. Make a note of the number of paragraphs shown in
'Children' column. Close Accerciser.
5. Repeat steps 1-4 with more paragraphs (23, 24, 25, 26, ...) till number of
paragraphs in accessible tree (Step 4) are less than the number of paragraphs
in the document (Step 1).
When I carried out the above steps, I got the following results:
Paragraphs in document Paragraphs in accessible tree
Contents of my writer document were as below -
The real problem is that the accessible tree contains only those objects which are visible on the screen at any instant, and ignores those which are above or below. This prevents Assistive Technology tools from accessing the full document. So it needs to be fixed on a priority basis.
This bug is a major hurdle in the way of assistive tools like Orca screen reader trying to access the whole document. How much easy or difficult is it to fix? May we get a tentative target date for fixing it?
See also: https://bugzilla.gnome.org/show_bug.cgi?id=652548
FLOWS_FROM and FLOWS_TO relationships, however, link together all paragraphs and table cells in the document, visible or not.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Today I rechecked my observation with Libre Office dev 3.5.0 beta2 and found
that the bug persists. I suggest that the bug be moved back to NEW status.
Is this Gnome 2? Remains this problem in Gnome 3?
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.
The bug is real. I noticed it in version 3.3.0 and submitted it with a
supporting screenshot. I reconfirmed that the bug exists with version 3.5.0
beta2. It falls in the same category as bugs 35105, 35107, 35110, 35111, 35129
which you have reopened and changed to NEW.
Behavior remains, should have been returned to NEW status.
The corresponding Apache OpenOffice bug is also still open: https://issues.apache.org/ooo/show_bug.cgi?id=117542
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
*Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)
*If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
*If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
*Update the version field
*Reply via email (please reply directly on the bug tracker)
*Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for your help!
-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
This is still reproducible in master.
Build ID: 6c41727484a04ab89005ffb052937dae5d7dc223
Another way to reproduce it: create an empty document, add one paragraph and add a footnote. When you scroll to the bottom of the page, only the footnote will be exposed to the AT; when you scroll to the top, the paragraph is exposed to the AT and the footnote disappears.