Bug Hunting Session
Bug 56031 - Accessible Text Interface not updating until word boundary at caret offset
Summary: Accessible Text Interface not updating until word boundary at caret offset
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.6.3.1 rc
Hardware: Other All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.1.0 target:4.0.2 target:3.6.6
Keywords:
: 50926 (view as bug list)
Depends on:
Blocks: a11y mab4.0
  Show dependency treegraph
 
Reported: 2012-10-16 12:46 UTC by Joanmarie Diggs
Modified: 2016-10-25 19:41 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
accessible event listener (507 bytes, text/x-python)
2012-10-16 12:46 UTC, Joanmarie Diggs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2012-10-16 12:46:48 UTC
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
Comment 1 Jason White 2012-11-22 23:11:17 UTC
This is a regression in LibreOffice 3.6.
Comment 2 chrys87@web.de 2013-01-17 01:54:23 UTC
I can confirm this. this makes the software unusable to me :/. is there a possibility to get it fixed fast?
Comment 3 chrys87@web.de 2013-01-18 17:14:12 UTC
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.
Comment 4 chrys87@web.de 2013-01-25 16:38:32 UTC
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?
Comment 5 V Stuart Foote 2013-02-15 16:05:59 UTC
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
Comment 6 Joanmarie Diggs 2013-02-16 03:03:05 UTC
*** Bug 50926 has been marked as a duplicate of this bug. ***
Comment 7 Caolán McNamara 2013-02-25 16:45:00 UTC
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
Comment 8 prayner 2013-02-25 17:00:26 UTC
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)
Comment 9 Not Assigned 2013-02-25 17:01:12 UTC
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.
Comment 10 Caolán McNamara 2013-02-25 17:03:23 UTC
fixed on master https://gerrit.libreoffice.org/#/c/2401/ for 4-0
Comment 11 Not Assigned 2013-02-25 17:23:31 UTC
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.
Comment 12 V Stuart Foote 2013-02-26 17:05:12 UTC
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
Comment 13 Not Assigned 2013-02-27 15:41:55 UTC
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.
Comment 14 V Stuart Foote 2013-02-28 15:35:00 UTC
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
Comment 15 chrys87@web.de 2013-03-06 18:15:03 UTC
So Caolan McNamara fixed it :).
Where should i send the box of beer to Caolan :)?
Comment 16 Caolán McNamara 2013-03-06 20:08:02 UTC
You can keep your beer :-), anyway looks like it won't make 4.0.1, only >= 4.0.2.