GNOME Bugzilla – Bug 558546
Eclipse editor window doesn't always correctly update Braille display
Last modified: 2010-07-05 21:38:22 UTC
Please describe the problem: Eclipse has a few automagic editing features such as inserting matching closing parenthesis and suchlike. When such an action is triggered during editing text, the automatically inserted text is not "inserted" in braille, but the caret position changes on my braille display. This can lead to absurd situations like the caret being displayed *after* the line end symbol (46 123). When I move the caret backwards again, speech outputs the newly inserted characters, but they are not visible in braille. Steps to reproduce: 1. Open a new class file in the eclipse code editor 2. Go to a location that allows for statements. 3. Type "javax.sound.midi.MidiSystem.getSyn" followed by Ctrl+SPACE Actual results: Eclipse completes the method name to "getSynthesizer()". i.e., it inserts "thesizer()" when Ctrl+SPACE is pressed. The braille display does not show this new text, but the caret is displayed 8 cells beyond the line end symbol. Expected results: The newly inserted text should be displayed on my braille display! :-) Does this happen every time? Yes, it is 100% reproducible with eclipse (SWT 3.2 and 3.4). Other information: I haven't looked into the event being sent in detail but I am suspecting some insertion events goes missing somewhere, either inside of SWT itself or in the Orca handling of things. It seems unlikely that SWT is at fault since speech review can speak the newly inserted characters. But it looks fixable since the caret position changes to a theoretically impossible value, maybe we just need to explicitly request the text content of a widget if such a thing happens?
Created attachment 121785 [details] A orca log excerpt The log starts with the insertion of the letter "n" from step 3 in the problem description. We see the object:text-changed:insert event come in with a length of 1 which results in an updated braille display with the newly inserted "n" at the end of the line. After the obvious key release of "n" we see the key presses for Ctrl+L. Here, autocompletion takes place. We immediately see a object:text-caret-moved event advancing the caret by 10 and the braille display update the old text but new caret position.
So the root cause of the problem is that we do not see a object:text-changed:insert event when eclipse does automagic things in its editor window. This is probably a bug in SWT or in its bindings to GTK. However, I wonder if it is possible to re-request the text content of an object if onCaretMoved fires and sees a offset which is out of bounds. In this particular case, its obvious that the caret can't be 10 characters beyond the line end position, so we could just update our idea of how thatline looks like. I'd like to test this in a local script, but how do I refresh a text object in Orca?
(In reply to comment #2) > I'd like to test this in a local script, but how do I > refresh a text object in Orca? > To get the accessible text interface for obj (assuming you don't have it; I'm assuming you do, but being thorough): obj.queryText() Given an accessible text interface, iText, you can get the text via: iText.getText(startOffset, endOffset). There are other potentially applicable methods (e.g. getTextAtOffset). Take a look at the AT-SPI IDL. Hope this helps. And thanks for investigating it!!
I suspect that this bug is fixed too. I found https://bugs.eclipse.org/bugs/show_bug.cgi?id=253075 that seems to be related with this bug.
(In reply to comment #4) > I suspect that this bug is fixed too. > I found https://bugs.eclipse.org/bugs/show_bug.cgi?id=253075 that seems to be > related with this bug. Thanks for the update José! When you get a chance, could you please test to see if it has indeed been fixed. And if so, close out this bug?
(In reply to comment #5) > Thanks for the update José! When you get a chance, could you please test to see > if it has indeed been fixed. And if so, close out this bug? I do not have a display braille to confirm. However I can confirm that I have no problems using with speech. Can I close? Thanks.
> Can I close? If you can confirm that in your debug.out you have a BRAILLE LINE that also shows the autocompleted information, yes please. I want to be sure there's not a braille-specific bug in Orca that still needs to be addressed.
As stated in comment #4, the bug was fixed in eclipse. Looking in orca debug out, I found the following output: BRAILLE LINE: ' javax.sound.midi.MidiSystem.getSynthesizer() $l' VISIBLE: 'idi.MidiSystem.getSynthesizer() ', cursor=32 Bug closed. Thanks.