GNOME Bugzilla – Bug 572555
Character being erased with backspace not announced in Eclipse
Last modified: 2010-04-08 12:56:55 UTC
This is from an e-mail message from mjsotn at GMAIL dot COM on JAVA-ACCESS at JAVA dot SUN dot COM: "If you prefer to stick with the *nix type platform, then Orca and Eclipse on either Linux or Solaris should work perfectly well for you. The only querk I found when running Orca with Eclipse is it didn't announce the character being erased with backspace, I found this to be a rather trivial annoyance, but it may be a bigger issue for some."
This is a bit different in eclipse 3.5 but is still incorrect. For instance if I have the word public and put the cursor before the "b", like pu*blic (where the * symbol is the cursor position) and press backspace to delete the u character,, like p*blic orca anounces the "b" character, not the "u" character that was deleted, like we'd expect. It announces the next character, not the one we've deleted. It must be something related with text_changed events or such, I'll try generating a log file and post it here.
Created attachment 157933 [details] Debug.out with deleting of some characters in eclipse editor I deleted two or three chars in the word "public" and observed that for one deletion orca receives one text-changed-deleted event and two text-caret-moved events. Is this suposed? I guess there is a dupplicated event causing the described behaviour here but just only a guess... Orca announces the next char not the one deleted. I commented bit the log to yself so I don't get lost, maybe it is some help though for someone.
My guess is that we're getting the wrong any_data for the event which begins at line 99 of your debug.out. If you haven't already seen, I just now committed a change in Orca which will cause Orca to include an event's any_data (what we look to for object:text-changed:delete events to know what to speak). So if you want to know for certain if Orca is speaking the 'l' when you got rid of the 'b', please pull Orca from git master and capture another debug.out. And my apologies. I tried to get that change committed and comment here before you dug too deeply into this bug, but you were faster than I was.... :-)
Created attachment 157937 [details] Debug.out with any_data information Deleted the first three characters of the word public, and eclipse returned "l" in any_data for the three....
(In reply to comment #3) > My guess is that we're getting the wrong any_data for the event which begins at > line 99 of your debug.out. > It seems your guess are right... The 2nd debug.out I posted (comment 4) has "l" for any_data deleting the first three characters of the word public... Orca is reporting "right", at least is reporting the information it receives... I'm suposing that in text:changed:delete events any_data is the deleted data (is that right). > If you haven't already seen, I just now committed a change in Orca which will > cause Orca to include an event's any_data (what we look to for > object:text-changed:delete events to know what to speak). So if you want to > know for certain if Orca is speaking the 'l' when you got rid of the 'b', > please pull Orca from git master and capture another debug.out. > > And my apologies. I tried to get that change committed and comment here before > you dug too deeply into this bug, but you were faster than I was.... :-) No problem.
That doesn't appear to be the debug.out. (It's a file called nvda_last.)
Regardless.... Given what you describe in comment 5, sounds like the bug is the following: The any_data field of an object:text-changed:delete event should contain the string which was just removed. (Currently it would seem to contain the character at the caret.) Is there an Eclipse issue tracker that is publicly available? If so, could you please file a bug describing both the issue *and* its impact on you, the user? Then we'll block this bug against that one. Once the Eclipse guys fix this issue, Orca should start doing the right thing automatically. I'm assigning this bug to you because that should (I hope) allow you to do things like change the summary (put a '[blocked]' at the beginning of the bug summary once you have filed the Eclipse bug). Also, please add the URL of the bug you file to the 'See Also: Add Bug URLs:' entry of this bug. Finally, once they fix the bug, you can close it out as RESOLVED/NOTGNOME. Thanks for digging into this bug, Rui!
Created attachment 157938 [details] Debug.out with any_data (this time is it!)
(In reply to comment #6) > That doesn't appear to be the debug.out. (It's a file called nvda_last.) So sorry... Reposted it in comment 8.
(In reply to comment #9) > (In reply to comment #6) > > That doesn't appear to be the debug.out. (It's a file called nvda_last.) > So sorry... Reposted it in comment 8. No worries. What you've attached matches both your description as well as my interpretation of your description. And it supports what I cite as the bug in comment 7. We're getting the wrong (or perhaps I should put that in quotes: "wrong") any_data. If the Eclipse guys can cause us to get the right (or "right") any_data, we'll be all set. The reason I put the quotes around wrong and right is because the last time I checked, the documentation of what was expected for an event's detail1, detail2 and any_data was poorly documented. We (the a11y community) should add evaluating this documentation to our to-do list. After all, we can't expect the rest of the world to do the right thing if they have no idea what the right thing might be. Nonetheless.... If you could file a bug wherever the Eclipse issue tracker is, explaining what is expected for an event's any_data when text is removed, hopefully we can get this resolved. Thanks again for all your work on this issue!
(In reply to comment #10) > What you've attached matches both your description as well as my interpretation > of your description. And it supports what I cite as the bug in comment 7. We're > getting the wrong (or perhaps I should put that in quotes: "wrong") any_data. > If the Eclipse guys can cause us to get the right (or "right") any_data, we'll > be all set. > It just happens in java editor so far (at least from what I found). In normal text edit controls it provides the right information. They use native gtk controls under swt, java editor may be an customized I suppose... > The reason I put the quotes around wrong and right is because the last time I > checked, the documentation of what was expected for an event's detail1, detail2 > and any_data was poorly documented. We (the a11y community) should add > evaluating this documentation to our to-do list. After all, we can't expect the > rest of the world to do the right thing if they have no idea what the right > thing might be. > > Nonetheless.... If you could file a bug wherever the Eclipse issue tracker is, > explaining what is expected for an event's any_data when text is removed, > hopefully we can get this resolved. Eclipse bugzilla it at http://bugz.eclipse.org and I reported the following with this issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=308057 Lets see what they do... Searching for accessibility there reports almost 500 bugs, it might mean something! > > Thanks again for all your work on this issue!
The bug report was fixed on their part... Didn't test yet so changing the summary to reflect this. When someone test eclipse version newer then today (2010-04-07) please report the results so we can close this issue. I'll try doing that when eclipse folks provide binaries for their trunk but don't know when they'll do that.
I tested using eclipse N20100407-2000 and it seemed ok. If for example I put the cursor on the letter b of the public word and press the backspace key, orca announces u. Rui, it seems that you can celebrate the victory.
(In reply to comment #13) > I tested using eclipse N20100407-2000 and it seemed ok. > If for example I put the cursor on the letter b of the public word and press > the backspace key, orca announces u. > Rui, it seems that you can celebrate the victory. Ok, closing as fixed.