After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 685098 - Orca not reading changed text in Libreoffice in right way
Orca not reading changed text in Libreoffice in right way
Status: RESOLVED NOTGNOME
Product: orca
Classification: Applications
Component: general
3.5.x
Other Linux
: Normal normal
: ---
Assigned To: Orca Maintainers
Orca Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-09-29 13:09 UTC by Vojtěch Polášek
Modified: 2012-10-16 12:48 UTC
See Also:
GNOME target: ---
GNOME version: 3.3/3.4


Attachments
Larger Libreoffice related debug.out file (107.62 KB, application/zip)
2012-10-07 07:14 UTC, Hammer Attila
Details

Description Vojtěch Polášek 2012-09-29 13:09:14 UTC
When replacing part of the text in libreoffice Orca gets confused and reads wrong characters to you, rendering writing in Libreoffice writer unusable.
I experience this with the latest version buildable on Gnome 3.4 (3.5.92 pre) and latest libreoffice 3.6.
1. Open new libreoffice document.
2. Type some text there.
3. Replace some of its part with other text and try to read the line.
You will get strange result - as if the part was deleted but text hasn't been replaced. Moving by characters will be confused as well. When you delete some character it gets fixed but this is not acceptable.
Please fix this as soon as possible because this is a big problem when using Libreoffice.
Comment 1 Joanmarie Diggs (IRC: joanie) 2012-09-29 15:12:25 UTC
If Orca is "getting confused" it is almost certainly due to the fact that LibreOffice is giving us the wrong information. We don't store some cache of the text. We ask for the text when you ask for the text. And we present to you what we get via AT-SPI2. So I will triage this soon. If the bug is in LibreOffice, I cannot fix it soon.
Comment 2 Vojtěch Polášek 2012-09-29 16:35:41 UTC
I found out that this is happening only for Libreoffice 3.6 and higher. On Libreoffice 3.5 this is not happening.
I haven't tested 3.6 prerelease build. Can I somehow help with this bug? Contacting LO devs?
Comment 3 Joanmarie Diggs (IRC: joanie) 2012-09-29 21:40:53 UTC
LibreOffice has a bugzilla (https://bugs.freedesktop.org) and you are encouraged to file one. My concern is that "Orca doesn't do the right thing in 3.6" is not as clear as a bug stating that "the AtkText interface is broken in this particular way starting in 3.6." I am crazy-busy at the moment, but perhaps you and I can team-triage this thing if you are up for it. If so:

1. Capture a full debug.out when using 3.6. (How to do so is described in https://live.gnome.org/Orca/Debugging).

2. Open the resulting debug.out in a text editor and search for the bogus speech/braille you got from Orca. It will likely be in a line beginning with "SPEECH OUTPUT:" and/or "BRAILLE OUTPUT:". Above each such output line, you will find where the generator (speech generator, braille generator) got the stuff it presented. Once we know the generator method used, we can see what AtspiText methods are getting called to produce that output.

3. Once I have the generator method from you which is responsible, I can create a simple Python test script that will run without Orca (but you can use it with Orca running). If you run the test script and verify the test script gets the same bogus output you get from Orca, you'll be able to file a much more specific bug which the LO devs should be able to reproduce without needing Orca.

Make sense? And thanks for volunteering to help!
Comment 4 Hammer Attila 2012-10-07 07:14:51 UTC
Created attachment 225972 [details]
Larger Libreoffice related debug.out file

I attaching a larger debug.out file with I generated in Ubuntu Quantal, Libreoffice 3.6.1~rc2-1ubuntu5 version.
I experienced drastical performance decreasing when I moved between lines, and confirming the reporter wrote problem too (once I succesfuly reproduced, but very difficult to verify the result because Orca preformance drastical slow in Libreoffice latest release). Search in the debug.out file the "barack" related entryes.
With performance issues related I think following tracebacks producing this issue, but I am not full sure this:
Traceback (most recent call last):
  • File "/usr/lib/python3/dist-packages/orca/event_manager.py", line 208 in _dequeue
    self._processObjectEvent(event)
  • File "/usr/lib/python3/dist-packages/orca/event_manager.py", line 548 in _processObjectEvent
    script.processObjectEvent(event)
  • File "/usr/lib/python3/dist-packages/orca/script.py", line 422 in processObjectEvent
    self.listeners[key](event)
  • File "/usr/lib/python3/dist-packages/orca/scripts/default.py", line 3492 in onTextAttributesChanged
    text.getTextAtOffset(text.caretOffset - 1,
  • File "/usr/lib/python3/dist-packages/pyatspi/text.py", line 515 in get_caretOffset
    return Atspi.Text.get_caret_offset(self.obj)
  • File "/usr/lib/python3/dist-packages/gi/types.py", line 47 in function
    return info.invoke(*args, **kwargs)
gi._glib.GError: The process appears to be hung.

An another possibility to this tracebacks related again with a timing issue of at-spi2 3.6?

Unfortunately in Quantal now Orca braille support not working (missing I think Brltty Python3 bindings), so I not possible to follow up braille the reporter wrote issue to this problem are speech or braille specific only.
Unfortunately when I completing the wrote barack line in the Libreoffice document with ot characters (resulted text is barackot), I unable to listen where am I command the resulted line to Orca right spokening the changed line or not.

Attila
Comment 5 Hammer Attila 2012-10-07 07:17:06 UTC
Forgot to write:
In Ubuntu Quantal awailable Orca 3.7.0.93, at-spi2-core 2.6.0-0ubuntu1 versions.

Attila
Comment 6 Joanmarie Diggs (IRC: joanie) 2012-10-16 12:48:16 UTC
I filed the bug here: https://bugs.freedesktop.org/show_bug.cgi?id=56031.

I cannot fix this in Orca. Sorry.