GNOME Bugzilla – Bug 426684
[Pending] Orca does not speak entry text in Firefox when the caret is at the end of line
Last modified: 2007-04-13 16:58:38 UTC
Steps to reproduce: 1. Enter a new bug in bugzilla 2. In the "Description" textarea, type several short lines such as: This is a test. <return> So is this. <return> A third line of text.<return> 3. Be sure that the caret is positioned at the end of the "text." 4. Use Up/Down Arrow to review the lines. Expected results: Orca would speak and display in braille each line arrowed to. Actual results: Orca displays each line in braille but fails to speak the text. This only occurs when the caret is at the end of the line.
Created attachment 85866 [details] [review] proposed patch If we're on a newline char and in an entry, adjust the characterOffset to the left one character before calling getLineContentsAtOffset().
Joanie: is this the result of a Firefox bug or is it the same problem that we're trying to capture in the same YIKES! block? The YIKES! block was just a way of me saying "This could be a problem, I'm not sure I've run into it, and I don't really know quite what to do here. I'll try to handle it for when I think it might happen, but I'll make the script be noisy to let me know when it really happens so we can poke at it some more when we have a real use case." BTW, now that I look at the YIKES block, it probably should be doing a len comparison on the unicode string length and not the byte length of the UTF-8 string. Finally, Mike/Joanie, what should be spoken when the user moves the caret to the end of the line (and also to the end of all the text in an entry)? Is the behavior with the patch the desired behavior?
> Joanie: is this the result of a Firefox bug or is it the same problem that > we're trying to capture in the same YIKES! block? Is there a third possibility? :-) When we navigate to a line, we seem to be calling getLineContentsAtOffset() twice. Presumably once for braille and once for speech -- the latter taking place in sayLine(). In the circumstances described in the bug, the first call is fine, but the call done by sayLine() results in empty contents. I saw your comment: # [[[TODO: WDW - the caret might be at the end of the text. # Not quite sure what to do in this case. What we'll do here # is just speak the current line. and the corresponding adjustment to characterOffset. The circumstances seemed to be the same; however, we weren't catching it because len(foo) is the entire entry; not just the line. > Is the behavior with the patch the desired behavior? I *believe* that the behavior with or without the patch is the same. I changed sayLine(). sayLine() only gets called when we're navigating by line and we're not controlling the caret(right?). The code that dictates what should be spoken when the caret moves to the end of the line is elsewhere (right?). If I'm missing something, please let me know. That said, I think it would be nice if Orca said "new line" or "end of line" or something to that effect when the user navigated by character (or by word?) or pressed End and landed on a newline char. And I would be happy to revise my patch accordingly to do that. Let me know. Thanks!!
With regard to speaking newline in an entry I think we should follow what we are doing in applications such as gedit, evolution and writer. IE speak newline when we move over the line boundry.
Created attachment 86028 [details] [review] K.I.S.S. principle patch :-) It turns out that the patch does impact the behavior w.r.t. speaking blank lines. My bad! (As a related aside, the navigation by word and character in entries already seems to be consistent with what we're doing in other applications) I've been giving this some thought and have concluded that I was thinking too hard before. :-) If we are in an entry, we're not going to have embedded object characters, are we? And the default script doesn't have the problem with not speaking text when the caret is at the end of the line. And, for that matter, the default script is not going to speak "text" over and over and over in an entry (see bug #423198). And, while we're on the subject, the default script is not going to grab extraneous/peripheral text that is surrounding the entry when we're Up/Down arrowing in it. So.... Drum roll please.... Why don't we just let the default script handle entries? :-) I tried this and it seems to work. Will, is there a scenario I'm overlooking?
Created attachment 86039 [details] [review] K.I.S.S. principle patch take 2
> I tried this and it seems to work. Will, is there a scenario I'm overlooking? The latest patch looks pretty good, and I definitely like the KISS approach. :-)
this one seems to work for me. I think we should go with it.
We already are going with it. <smile> I guess that means it's safe to close this one out as FIXED.