GNOME Bugzilla – Bug 434600
cursor routing keys cannot be used to position caret at end of line
Last modified: 2009-11-09 21:35:40 UTC
Please describe the problem: open gedit with braille enabled and write hello The cursor is placed after the o character. Now press routing over h e l l o that works fine. The problem is that you can't place the cursor after tthe o sign by pressing the regarding routing key Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
See also bug #429390. They are both probably the same bug. And yet again, I can't reproduce this one.
The bug #429390 you mentioned has nothing to do with cursor routing. Why do you think they are comparable?
Bug #429390 is: Braille stays on current line after pressing return at end of line in OOo Writer.
I can reproduce this with my Alva.
> The bug #429390 you mentioned has nothing to do with cursor routing. > Why do you think they are comparable? I did a quick test with this, and they *seem* to be different problems. This one seems to be generalizable to a special flat review mode case: when the last line is empty, flat review skips it. When entering flat review mode while the caret is on this last blank line, the flat review context will find the nearest thing it can in the text area, which happens to be the previous line. I'm guessing the "if foundZoneWithCaret" block around line 455 in flat_review.py needs to be adjusted somehow. Bug 429390, seems as though it may be something related to events we may (or may not) be getting from OOo.
Attention: I can reproduze this in several edit areas. Not only in OO or gedit. Simply press alt+f2 type something and try to use cursor routing in this textfield. It isn't possible to bring the cursor back to the (writecursor)
Whoa! Sorry. I think I replied to the wrong problem. I was responding to the other problem Halim mentioned on the Orca list, which was that flat review ended up going to the wrong spot: http://mail.gnome.org/archives/orca-list/2007-April/msg00525.html
For this problem, I believe the code in question is in braille.py:processCursorKey. It seems to be doing the right thing, so maybe there's a bug in the AT-SPI that will not let us position the caret at the end of the text? Before jumping to conclusions, though, one should experiment a little bit by putting some debug statements around the call to setCaretOffset to see if we are attempting to set the caret properly.
You're right. They aren't related. Last week, Halim sent me private email that stated: "3. Gedit-problem 1. write hello and press return 2. write world and press return. 3. press braille-lineup and you are getting hello on the braille display and not world." I thought that this was that problem, which would be related to bug #429390. Halim, are you still seeing that problem? Are you going to file a separate bug report on that?
I filled a separate bug for this #434654 I can reproduce these problems under feisty.
Created attachment 88241 [details] [review] Patch to make the eol text part of the Text area The problem was that the text was being handled in a braille.Text object, but the " $l" for the eol was being handled in a separate label region. As a result, any presses on the " $l" portion were being ignored. This patch makes the " $l" part of the Text object, and relies upon the good nature of the AT-SPI to position the caret at the end of the line.
Created attachment 88247 [details] [review] Revised patch that doesn't depend upon the good nature of the AT-SPI This revised patch limits the effect of the cursor routing keys to the line being shown on the braille display. It works well in gedit and gnome-terminal's preferences dialog as far as I can tell. Looks like it kind of sort of works in Gecko: the caret will move in Gecko, but we don't seem to update the cursor position on the braille display. I'm not sure if it's because we're not getting an event or not.
Will Thanks it works now. Tested in OO and gedit under ubuntu feisty. Great work.
Mario has reported that the cursor is positioned incorrectly when in gedit and you're at the end of a file and the last line is blank. The cursor gets positioned under the $ in the " $l" instead of under the empty cell. Investigating.
Created attachment 88306 [details] [review] Handle case where the last line of a file in gedit is blank
this patch with orca from trunk seems to be working correctly.
Closing. Thanks!
Sorry this bug is still there in orca 2.27.x.
(In reply to comment #18) > Sorry this bug is still there in orca 2.27.x. Halim - do you know if it was there *before* the big braille refactor that happened this week, or was it reintroduced with the big braille refactor?
This is a longstanding issue and I'm sure not related to the refactor.
OK - so, I'm confused, especially since both of you signed off on this bug and said it was fixed. Following the steps in teh bug opener, I cannot seem to reproduce it with Orca from the git master branch on my Baum Vario 40. :-(
I really should have been more clear in my last comment. The problem I see is that I can't click on the end of line character that I think exists. Perhaps it can't be focused though. I can click on the last character.
Ok this bug was fixed in orca 2.20 (if checked this this evening). I don't know wich orca version has re reintroduced it again but it seems that is was not the refactor stuff! I can click on the last char in gedit (using orca 2.20).
I think I have found the bug but I don't know how to fix this: The bug happens only if line end sign is switched of or the string for it is empty.
(In reply to comment #24) > I think I have found the bug but I don't know how to fix this: The bug happens > only if line end sign is switched of or the string for it is empty. Aha. Thanks for the extra info -- definitely helps. For how to fix this, I'm not quite exactly sure. I believe the EOL indicator helps us because it gives us something you can click on the Text Region portion of the braille line. Getting rid of the EOL gets rid of the clickable target. If this is the case, a potential solution might be to adjust the braille code to say "Hey, if the user clicks on any blank cell to the right of the text area, we'll position the caret at the end." This would also be somewhat consistent with how clicking the mouse works in a text area.
Created attachment 138380 [details] this should fix these problems if user has eol string is empty or the user has disabled it completely
(In reply to comment #26) > Created an attachment (id=138380) [edit] > this should fix these problems if user has eol string is empty or the user has > disabled it completely This is fine by me if you don't think anyone would have the expectation of pressing any other routing keys to the right of the text to position the caret at the end of the text. What do you think?
No I don't think so. It's a normal behaviour that a user can route to current cursorpossition. BTW. This bug isn't related only to gedit. It affects all edit fields! So please apply.
Created attachment 138445 [details] [review] Revised patch Please try this patch. It catches some more cases with respect to various combinations of contracted braille, the disabling of the EOL indicator, and the contents of the EOL indicator.
Ok I have tested your patch, it works great (for me). Unfortunately i couldn't test contracted braille. Please apply this patch to git.
Created attachment 138532 [details] [review] Simplified patch After running the regression tests, the previous patch was causing some issues. This patch is a simplified patch that works well. The only thing is that it doesn't prevent you from shooting yourself in the head. That is, if you set the eol indicator string to nothing, you get what you asked for: nothing. Since setting this string is not something you can do via the preferences UI (you can only specify whether you want the string used or not), I think this is OK. Halim - if you could test with this patch, it would be great. Thanks for your testing so far.
Ok it works as expected on my Machine. Nice Work (thanks).
Thanks! Committed to git master for Orca v2.27.5.