Created attachment 118423 [details] Test case: laggy.odt Steps to reproduce: 1. Launch the (to-be) attached accessible-event listener in a terminal 2. Open the attached test case (you may wish to do so via CLI and --norestore) 3. Do not interact with your system, the document or anything just wait Expected results: The act of merely opening the document would not result in 3000-4000 accessible events logged in the terminal. Actual results: 3000-4000 accessible events are emitted and logged. In addition, it takes multiple seconds (for this doc, it averages 10. The doc it's based on* averages 15). *The original document was shared privately by an Orca user to me. At this time he does not have permission to make the document public. However, there is *something* about that document that makes the flood and delay significantly worse compared to documents of similar size and formatting. In order to file this bug, I took the original document and replaced all the characters, the URLs, the image, the bookmarks, etc., etc., etc. In doing so, I created something that demonstrates the problem well enough. If we can get permission to share the original, we'll attach it here.
Created attachment 118424 [details] accessible-event listener: soffice-events.py As you'll see, all this event listener does is print the received "object" events emitted by LibreOffice. It does no other processing -- a screen reader, on the other hand, does more processing. Thus the 10-15 second delay and associated app and system lag reported here is actually much worse for end users of assistive technologies like Orca.
Created attachment 118425 [details] Log output from performing the steps in the opening report Note that there around 4000 accessible events from LibreOffice just from opening the document. Some things worth noting: 1. The first event is for the window (frame) becoming active (21:01:36) 2. The event that indicates the frame has the name of the document is 11 seconds later (see line 1433) 3. Most of the events are emitted for objects whose accessible role is paragraph. 4. There are quite a lot of (by which I mean excessive) events for: a. object:state-changed:showing b. object:visible-data-changed c. object:text-changed:insert d. object:text-changed:delete e. object:text-attributes-changed It might be worth considering (by which I mean please DO consider) NOT emitting signals for text changes that result from the loading of the document. From the point of view of the user (and his/her screen reader), no text was inserted or removed from those paragraphs. Similarly, the text in those paragraphs didn't change attributes. All the user did was open the document which already had the text and attributes in question. 5. There are a number of "[DEAD]" accessibles. It's not clear to me if those objects are still in the process of being created or went defunct as a result of a timeout. But there's only 177 of them (out of the ~4000 total).
Adding Jamie to the CC list. Do you get bombarded with event floods from the attached document, or is this some weird platform issue? (Thanks in advance for trying!)
(In reply to Joanmarie Diggs from comment #0) > Created attachment 118423 [details] > Test case: laggy.odt > > Steps to reproduce: > 1. Launch the (to-be) attached accessible-event listener in a terminal > 2. Open the attached test case (you may wish to do so via CLI and > --norestore) > 3. Do not interact with your system, the document or anything just wait Should it attach automatically to soffice? It didn't print any events at all for me. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 334599030e7b45153107a3075f9049a7463aac80 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 22nd 2016 On Arch the dependency package is: python-atspi
(In reply to Buovjaga from comment #4) > (In reply to Joanmarie Diggs from comment #0) > > Created attachment 118423 [details] > > Test case: laggy.odt > > > > Steps to reproduce: > > 1. Launch the (to-be) attached accessible-event listener in a terminal > > 2. Open the attached test case (you may wish to do so via CLI and > > --norestore) > > 3. Do not interact with your system, the document or anything just wait > > Should it attach automatically to soffice? It didn't print any events at all > for me. Dear Buovjaga, on Debian 8.4 with LibreOffice 5.1.2 I can reproduce the issue. Are you using LibreOffice GTK version ? Best regards.
Yep, it was my ignorance about GTK requirement. Launched with SAL_USE_VCLPLUGIN=gtk3 and could reproduce. Arch Linux 64-bit, KDE Plasma 5 Version: 5.2.0.0.alpha1+ Build ID: 540fee2dc7553152914f7f1d8a41921e765087ef CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on April 30th 2016
** 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 (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Dear all, I can't reproduce this issue with LibreOfficeDev 6.0 of 2017-09-27. @Joanie: are you able to reproduce this issue ? Best regards.
No reply, so I think we should just set to WFM.