Description: When I'm moving the cursor inside a Writer text sometimes caret-moved events stop to be emitted. It seems to be a recent regression. It works well on libreoffice-5-2 branch Steps to Reproduce: 1.Launch accerciser: https://wiki.gnome.org/action/show/Apps/Accerciser?action=show&redirect=Accerciser 2. Open attached file 3. Select caret-moved event in accerciser to watch 4. Move cursor with arrows inside the first paragraph -> caret-moved events are there 5. Move cursor to the next paragraph and then back to the first paragraph 6. Move cursor with arrows inside the first paragraph -> caret-moved events are missing Actual Results: The caret-moved events are not always emitted when moving cursor inside a paragraph. Expected Results: The caret-moved events should be emitted always when moving cursor inside a paragraph. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.100 Safari/537.36
Created attachment 129286 [details] Text doxument with two paragraphs
Kohei, Can be this bug related to your recent atk changes?
I tried reproducing this, ran accerciser (this was the first time I used the tool), but it hung on step 4. Not sure if I'm doing something wrong, or there's something wrong with accerciser in Ubuntu 16.04.
(In reply to Aron Budea from comment #3) > I tried reproducing this, ran accerciser (this was the first time I used the > tool), but it hung on step 4. Not sure if I'm doing something wrong, or > there's something wrong with accerciser in Ubuntu 16.04. Yes, it sometimes freezes to me too. You can try the python listener attached to bug 87680. This python code listens this caret moved event.
Repro with Accerciser. The event to be monitored is under object: text-caret-moved. Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ Build ID: 1fce5b024e9f25c3fcef2537a22474ece0dc416f CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on December 10th 2016
*** Bug 105800 has been marked as a duplicate of this bug. ***
Alex kindly bibisected this, the results are in attachment 130976 [details] of bug 105800. The results are narrowed down to 2 commits, both submitted by Kohei Yoshida for bug 71409. Kohei, please take a look: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=e010834dc1a82fcb80dc23025001a752a0fb60a4..87e040fd0f04307534920d0765af6d5878794a98 Raising importance, since it is a serious accessibility issue.
I can't reproduce this, following the steps described in the initial description. I get text-caret-moved events emitted regardless. Actually I get too many emitted per movement (3 or 4 events) instead.
(In reply to Kohei Yoshida from comment #8) > I can't reproduce this, following the steps described in the initial > description. I get text-caret-moved events emitted regardless. Actually I > get too many emitted per movement (3 or 4 events) instead. What is your distribution and test case? Have you read my comment on the related bug? I'm testing it on Debian 8.7 with LibreOffice 5.3/5.4 GTK2 and the bug is also reproduced by user of other distribution. Could you follow the instructions I have provided on the bug 105800 ? I'm available on Freenode (nick: alexarnaud) to discuss about that. It's an important bug that breaks completely the LibreOffice usability by blind persons on GNU/Linux. Best regards.
I can reproduce it now, though the steps are a bit different in my environment. I'm also using a python script for my testing, not that gnome app since it doesn't seem to work well on my machine (Ubuntu 1604 LTS).
Latest Libre Office has become unusable with Orca.
If I revert my fix for bug 71409, I can fix this, but bug 71409 will re-appear. Given how complex the a11y code is and I'm not even an expert at it, for me to come up with a proper solution will likely take months. Let me ask you, which bug is more important? This one, or bug 71409?
(In reply to Kohei Yoshida from comment #12) > If I revert my fix for bug 71409, I can fix this, but bug 71409 will > re-appear. Given how complex the a11y code is and I'm not even an expert at > it, for me to come up with a proper solution will likely take months. > > Let me ask you, which bug is more important? This one, or bug 71409? This bug is more important because LibreOffice 5.3.x is no longer usable for blinds persons on GNU/Linux. I prefer the solution of reverting instead of breaking the 5.3.x branch for the screen reader and screen magnifier users. Best regards.
https://gerrit.libreoffice.org/#/c/34730/ Once this lands, I'll reopen bug 71409, then I'll be done.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=10077a06d8f6d08f276f99024528ee31a57390a9 Revert my fix for tdf#71409, to hopefully fix tdf#104381. It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f36ee01ab3d7934880bfd8b5d337288dcbf62c7&h=libreoffice-5-3 Revert my fix for tdf#71409, to hopefully fix tdf#104381. It will be available in 5.3.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.