GNOME Bugzilla – Bug 619180
[blocked] When I read a composed or replyed message with Up or Down arrow keys, Orca some time not the right line spoken
Last modified: 2018-02-08 12:49:40 UTC
Dear developers, In Orca Mailing List I wroted a difficulter diagnosable problem when I use Thunderbird 3.0.4 version with Orca. When I write a new longer message or reply a message and the message is longer, if I read the message body text with Up and Down arrow key, Orca some time not always the right caret positioned line spoken, but spoken the actual+1 line. Only help if I move the caret with right arrow key with few character and go to prewious line and press home key. In Orca List some user confirmed this problem with Thunderbird use. Now, I am lucky because when the problem is happened when I edited a letter, I have possibility to mage a debug.out file. I will be attaching the debug.out file with next comment, I very hope you helpful this debug.out file to determine why happening this problem. Unfortunately I not known an always working reproducation test to reproduce this problem, very sorry. This problem is present with Orca 2.30.1 and Orca git master version. Attila
Created attachment 161532 [details] This is the debug.out file with possible show why happening the described problem
Michael Whapples wroted following letter with this related Thunderbird problem, possible help: "I sort of think I observe this from time to time. I'm not fully sure what is happening but I am slightly swayed to the thought it may be related to the caret position on the line (I think there may be times when the caret appears to be on the previous line although left and right indicates it may be on the first character of the next line). A quick play around just now in this message seems to show me something interesting. Go to a line while composing which wraps to the next line and press end. Now press right, I get nothing spoken, press right again and I get the second character of the next line. Press left, I get the first character, press left again nothing spoken, press left again and I get the last character. Now press end again and cursor up and down, observe what happens around a line where you did press enter to finish the line, I get the line spoken twice (once when the caret is on the line wrap join and once when its on my actual newline character. Does this seem to show your bug? Now is this a mozilla bug or a orca bug?" I verifyed he wroted example. The problem is happening if the Thunderbird wraps automaticaly a line and if I press for example the End key. When I press end key, Orca spokening next line first character. If I after end keypress press right arrow key, Orca not spoken the real next line first character. If you copyed for example the top of this comment copyed Michael wroted letter, possible you easy to see what happening. So, possible not only one problems present in Thunderbird caret navigation handling with Orca, I am not full sure this is an Orca or Mozilla Thunderbird related issue. If you want, I welcome make another debug.out file with concentrating only first the Michael wroted problems, because he wroted problem is easyest to reproduce and always sure reproduceable with automatic indented lines in Thunderbird message body. Attila
Thanks for the report Attila! I'll take a look tonight or tomorrow.
Ah yeah, this..... This is a Mozilla issue. It's been around forever. I have vague recollections of discussing it at a face-to-face meeting ... I think three or so years ago... and being told by Mozilla guys that it was a tough problem for them to fix. (Read: A fix ain't gonna happen). If memory serves me, the explanation went something like: At the end of the line when text wraps you're at a particular offset, x. There's no actual newline character there. As a result, offset x really refers to two different on screen positions: 1) the end of the line you were on when you pressed End, 2) the first character of wrapped text on the next line. Since this is a Mozilla bug that they won't fix, I can try to hack around it, but the solution will be a hack.
In order to even hack around it, I need to get actual caret-moved events to trigger the hack. These are missing at the end of the line. Therefore, this is not one, but two Mozilla bugs. I've opened a new bug against Mozilla for the caret-moved events. Once that's fixed I can attempt to hack around the other bug. https://bugzilla.mozilla.org/show_bug.cgi?id=567571
Closing blocked bugs because we need the issue fixed in the blocker.