Description: 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
Created attachment 134881 [details] Test document
It reads the buggy line just fine for me. Orca version 3.24.0+15+gc2c209c34-1 Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ 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
(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.
If it has been confirmed independently, it should be set to NEW (done). I only used down arrow.
Hello all, another user reports us the issue: https://mail.gnome.org/archives/orca-list/2018-February/msg00061.html @xisco: As It makes LibreOffice really difficult to use on long document due to skipped lines, can I raise the priority of this bug? Best regards.
(In reply to Alex ARNAUD from comment #5) > @xisco: As It makes LibreOffice really difficult to use on long document due > to skipped lines, can I raise the priority of this bug? Yeah I think we can easily nudge a11y issues up a bit.
Nudge up how much? Enough that I don't have to add a hack into Orca? :)
(In reply to Joanmarie Diggs from comment #7) > Nudge up how much? Enough that I don't have to add a hack into Orca? :) It only means that the bug has an better importance. The LibreOffice devs decide on which bugs they want to work on so this bug could stay in this state for a very long time but I hope someone could work on it. Best regards.
Ok, I've added a targeted hack-around in Orca which should only impact LibreOffice document content. Hopefully this will make it possible for Hypra to stop reverting an important Orca-wide fix which impacts all applications.
Is 105487 caused by the same problem? The symptoms of both seem quite similar.
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I would like the help of Joanie for this issue because with have hacked Orca to figure out this but this issue is not fixed yet. @Joanie: Could you write a Python script to help us reproducing this ? Best regards, Alex.
Reverting status change as not relevant (and potentially dangerous).
(In reply to Buovjaga from comment #13) > Reverting status change as not relevant (and potentially dangerous). IMHO, it's relevant because I'm not able to reproduce the issue without a script to reproduce it. Best regards, Alex.
(In reply to Alex ARNAUD from comment #14) > (In reply to Buovjaga from comment #13) > > Reverting status change as not relevant (and potentially dangerous). > > IMHO, it's relevant because I'm not able to reproduce the issue without a > script to reproduce it. But you could reproduce it in 2017 alongside Chrys and Joanmarie, so this should stay NEW. Otherwise we risk this being closed as INSUFFICIENTDATA.
Joanmarie - can you point us to the workaround in Orca?
(In reply to Chris Sherlock from comment #16) > Joanmarie - can you point us to the workaround in Orca? https://gitlab.gnome.org/GNOME/orca/-/commit/055374f8
Joanmarie, can you give us some hints as to what the workaround actually does? What do you think might be causing this? A few of us have tried to reproduce the issue, but we just aren't having much luck.
(In reply to Chris Sherlock from comment #18) > Joanmarie, can you give us some hints as to what the workaround actually > does? What do you think might be causing this? A few of us have tried to > reproduce the issue, but we just aren't having much luck. In default.py, onCaretMoved checks to see if the object firing the caret-moved event exposes STATE_SHOWING. If STATE_SHOWING is absent, then that event is ignored because we only want to (potentially) present the new caret location if the user is in that text object. And if the thing isn't SHOWING, presumably the user is not in that text object. The workaround is the addition of presentEventFromNonShowingObject, which allows scripts to tell the default script that even though something isn't SHOWING, the caret moved event might still be worthy of presentation. The default implementation of presentEventFromNonShowingObject returns False. The LO script's implementation unconditionally returns True. As for what I think might be causing this on the LO side of things, my guess would be either the logic which determines if a paragraph is SHOWING and/or the logic which updates (via a state-changed accessibility event) the SHOWING state (e.g. when something is scrolled into or out of view).