Bug 109398 - Some lines of text are not visible for assistive technologies
Summary: Some lines of text are not visible for assistive technologies
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium major
Assignee: Not Assigned
Keywords: accessibility
Depends on:
Blocks: a11y-Linux
  Show dependency treegraph
Reported: 2017-07-26 20:38 UTC by Alex ARNAUD
Modified: 2017-10-01 01:36 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:

Test document (15.93 KB, application/vnd.oasis.opendocument.text)
2017-07-26 20:38 UTC, Alex ARNAUD

Note You need to log in before you can comment on or make changes to this bug.
Description Alex ARNAUD 2017-07-26 20:38:03 UTC
Dear all,

since version 3.24, Orca stops to do ugly work-around to figure out wrong LibreOffice events and to solve issue related to work-around (see the thread on the Orca list : https://mail.gnome.org/archives/orca-list/2017-July/msg00023.html)

I've tested on Debian 8.8 with Orca 3.24, LibreOfficeDev 6 or LibreOffice 4.2, on Debian Sid with LibreOffice 5.3 and orca master and on Windows 7 with LibreOffice 5.3 and NVDA. 
I can't reproduce the issue on Windows.

Steps to Reproduce:
1. Launch the Orca screen reader with version 3.24 or master
2. Open the attached document with LibreOffice GTK2 or GTK2
3. Press down arrow until you find you go to the line "buguy line"

Actual Results:  
Incorrect events are emitted so Orca or other assitive tools can't see the line

Expected Results:
LibreOffice should emit the same events as the other lines

Reproducible: Always

User Profile Reset: No

Additional Info:
I raise the severity to critical because reading document on LibreOffice Writer wouldn't be possible efficiently on GNU/Linux when people will be migrated to Orca 3.24+.

I observe the same issue with the focus tracking feature of the EZoom screen magnifier so it's not an orca related issue.

Please, let me know if you need more details or information. I'm available on Freenode (IRC) with the nickname "alexarnaud" on the #libreoffice-design chan.

Best regards.

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Comment 1 Alex ARNAUD 2017-07-26 20:38:52 UTC
Created attachment 134881 [details]
Test document
Comment 2 Buovjaga 2017-08-20 16:18:11 UTC
It reads the buggy line just fine for me.

Orca version 3.24.0+15+gc2c209c34-1

Arch Linux 64-bit, KDE Plasma 5
Build ID: 668ab2e739397e6b095372a1a468bd4f515927b6
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 20th 2017
Comment 3 Alex ARNAUD 2017-08-22 10:19:56 UTC
(In reply to Buovjaga from comment #2)
> It reads the buggy line just fine for me.
> Orca version 3.24.0+15+gc2c209c34-1

Are you using only down arrow to move to the buggy line? Sometimes, LibreOffice reads the buggy line but it's another line that is not read.

To be sure to reproduce the issue you need to know that Orca should speak on all the line with the text content or "blank" on empty lines.

If you don't reproduce the issue the first time move to beginning of the document and press down arrow again until to find a unread line.

I've reproduced on Debian 8.9, Sid and Ubuntu 17.10 daily build.

The bug has been confirmed by one user and the Orca developper :
- https://mail.gnome.org/archives/orca-list/2017-July/msg00025.html
- https://mail.gnome.org/archives/orca-list/2017-July/msg00034.html

Best regards.
Comment 4 Buovjaga 2017-08-22 10:49:16 UTC
If it has been confirmed independently, it should be set to NEW (done).

I only used down arrow.