Created attachment 68620 [details] accessible event listener Steps to reproduce (without the mouse and exactly as follows): 1. Launch the attached accessible event listener in a terminal. 2. Launch writer. 3. Type the string "This is a test." and press Return. 4. Press Up Arrow. 5. Press Right Arrow to move the cursor to the word "is". 6. Press Delete once (leaving "This s a test.") 7. Type the string "wa" (resulting in "This was a test.") 8. Press Down Arrow then Up Arrow. Expected results (short version): After step 8: current line: This was a test. Actual results (short version): After step 8: current line: This s a test. Expected results (long version): Every time the caret moved on screen, the event listener would print out the current line and the current line's contents would be accurate. Actual results: The current line is only printed out when the character at the caret offset is at a word boundary (space, period, etc.). And the line contents are incorrect until a word boundary (space, period, etc.) is typed. At that point the line text is correct. Apparently this is a regression introduced at some point in the 3.6 cycle as per this Orca user's report: https://bugzilla.gnome.org/show_bug.cgi?id=685098#c2
This is a regression in LibreOffice 3.6.
I can confirm this. this makes the software unusable to me :/. is there a possibility to get it fixed fast?
i also can confirm this in the new libeoffice 4.0. I think this is a real critical bug, because the visually impaired linux users cant use libreoffice overall. i hope its possible to fix this bug soon.
I will spend a box of beer to the developer who get this fixed to the next version :) of lo :). is this an deal :D?
Response to discussion of this on the Accessibility ML -- http://nabble.documentfoundation.org/libreoffice-accessibility-what-does-it-cost-to-fix-a-bug-td4037638.html So, looks to be that problems with the Xaccessible instrumentation of caret and cursor movement events is not limited to the ATK <-> UNO AAPI bridge. Omission is also present in Java JAB <-> UNO AAPI, so Windows screen readers are also degraded and problem is lower in the UNO AAPI. Observed in a 4.0.0.3 Windows build with JAB v2.0.2 and JRE 1.6u39; still need to verify against a > 3.6.4 build, and 3.5.7 build to help pin down where introduced. Have annotated this bug to be all platforms. And nominating as a 4.0 MAB @Roman, could you check against VoiceOver and comment
*** Bug 50926 has been marked as a duplicate of this bug. ***
I believe this is a regression triggered by http://cgit.freedesktop.org/libreoffice/core/commit/?id=062eaeffe7cb986255063bb9b0a5f3fb3fc8e34c The change of content causes the new RSID attribute to be emitted which causes an a11y attributes change event to be added to the queue, then the removal of content arrives and the SwAccessibleMap::AppendEvent decides to throw away the REMOVE event and keep the attributes changed event. (sufficient to put a breakpoint in SwAccessibleMap::AppendEvent and delete a letter) This SwAccessibleMap::AppendEvent is a bit odd, bAppendEvent of false means throw away the event, while bAppendEvent of true means move an old event for the source from the queue to the end after optionally updating some of its members
I am on travel and will respond to email when possible. If urgent please call 0402 752 379 noting that I am in China (3 hours behind Melbourne)
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d08ccd5b84c121867d7b3102f9d10b26005c682 Resolves: fdo#56031 RSID attr changes drop content change events 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.
fixed on master https://gerrit.libreoffice.org/#/c/2401/ for 4-0
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=791a060bd1031c844a9a1b283689dee6a8a7ef77&h=libreoffice-4-0 Resolves: fdo#56031 RSID attr changes drop content change events It will be available in LibreOffice 4.0.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.
Confirming now correct accessible text behavior on Windows 7 OS as patched in Tinderbox build of 4.0.2 (libreoffice-4-0~2013-02-26_09.45.35_LibO-Dev_4.0.2.0_Win_x86.msi -- core:01f8d0a1dffce854a66c0f957e81e6df6d361a86). With NVDA 2012.3.1 with JRE 1.6u41
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8aff15241b34fca1ae4a4e0698510f9014026297&h=libreoffice-3-6 Resolves: fdo#56031 RSID attr changes drop content change events It will be available in LibreOffice 3.6.6. 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.
Also, confirming now correct accessible text behavior on Linux OS with Orca as patched in Tinderbox build of 4.0.2 (core:311497d245e67d90aa2630e0c168a03adcddfd41) Fedora 18, with a libpng12 work around for bug 61571
So Caolan McNamara fixed it :). Where should i send the box of beer to Caolan :)?
You can keep your beer :-), anyway looks like it won't make 4.0.1, only >= 4.0.2.