GNOME Bugzilla – Bug 429390
Braille stays on current line after pressing return at end of line in OOo Writer
Last modified: 2009-03-10 00:05:22 UTC
From the Orca list (and confirmed by me): The braillecursor in oo writer does not switch to an emty line. E. G. 1. start oo-writer 2. type hello world 3. press return. The hello world output stays on the brailleterminal with an cursor visible at pos1 (h) of hello world.
Interesting. I'm not seeing this. What I'm seeing is that if you enter (say) "hello" and press return, the braille display is changing to "$l" (correctly) but "hello" is not being spoken. The difference between this and gedit is that with gedit you get an "object:text-changed:insert" event when you press Return and that's what's speaking the last word. With OOo Writer, you don't. With OOo Writer you do get an "object:text-caret-moved" event when you press Return though, so it looks like we are going to have to wedge some more code into the onCaretMoved() routine in StarOffice.py to handle speaking that last word.
(In reply to comment #1) > Interesting. I'm not seeing this. What I'm seeing is that if > you enter (say) "hello" and press return, the braille display > is changing to "$l" (correctly) but "hello" is not being spoken. Just to be sure: 0) Run orca 1) Create a new empty document in OOo 2) Type "hello world" -- don't move the caret anywhere except by merely typing hello world. 3) Press Return I'm seeing "hello world" remain on the braille display and the braille cursor moves to the first cell. Here's the relevant events I'm getting (Orca SVN, Feisty, Feisty's OOo 2.2.0 from 08-Mar). Notice the caret-moved event with a detail1 of -1. That seems to be odd. I think it's OOo's way of telling us the paragraph no longer has focus. vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv OBJECT EVENT: object:text-caret-moved detail=(11,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='' BRAILLE LINE: 'soffice.bin Application Untitled1 - OpenOffice.org Writer Frame Untitled1 - OpenOffice.org Writer RootPane ScrollPane Document view hello world $l' VISIBLE: 'hello world $l', cursor=12 ^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^ KEYEVENT: type=0 hw_code=36 modifiers=0 event_string=(Return) is_text=True time=1176829827.404836 .... vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv OBJECT EVENT: object:text-caret-moved detail=(-1,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO' GENERATOR: _getBrailleRegionsForText obj = role = paragraph BRAILLE LINE: 'hello world $l' VISIBLE: 'hello world $l', cursor=1 ^^^^^ PROCESS OBJECT EVENT object:text-caret-moved ^^^^^ vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(0,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO' ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ vvvvv PROCESS OBJECT EVENT object:children-changed:add vvvvv OBJECT EVENT: object:children-changed:add detail=(1,0) app.name='soffice.bin' name='Document view' role='unknown' state='EDITABLE ENABLED MULTISELECTABLE OPAQUE SHOWING VISIBLE' relations='' ^^^^^ PROCESS OBJECT EVENT object:children-changed:add ^^^^^ vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM' LOCUS OF FOCUS: app='soffice.bin' name='' role='paragraph' event='object:state-changed:focused' ^^^^^ PROCESS OBJECT EVENT object:state-changed:focused ^^^^^ vvvvv PROCESS OBJECT EVENT focus: vvvvv OBJECT EVENT: focus: detail=(0,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM' ^^^^^ PROCESS OBJECT EVENT focus: ^^^^^ KEYEVENT: type=1 hw_code=36 modifiers=0 event_string=(Return) is_text=True time=1176829827.505928
Sorry Will, I'm not seeing this. I'm using latest Feisty, latest Orca from SVN and OOo Writer with a tagline of: openoffice.org 2.2.0-1ubuntu3, Tue Apr 10 21:51:38 UTC 2007 Maybe they've "fixed" something between those two different versions of OOo Writer...
Created attachment 86517 [details] Orca debug whilst testing for the problem. Here's what I'm seeing. I start with OOo Writer running showing a new empty document. I enter "hello world" and then press return. * Key press of Return is at line 1773. * The processing of the "object:text-caret-moved" starts at line 1808 * ' $l' on the braille display is at line 1814. So this is doing the right thing on the braille display. The only difference from the way that gedit works is that it's not speaking the last word (assuming you have enable echo by word on -- which I do). That works for gedit because we get the "object:text-changed:insert" event at the right time and are able to handle it. By the time we get the "object:text-caret-moved" event in OOo Writer, the caret has already moved to the next line. I could try to cons up some code to put in the OnCaretMoved() routine in the StarOffice.py script, but I suspect it's going to be a fair bit of code. If, when you are in OOo are you just type (in other words, let OOo Writer do the formatting for you), then this is only a problem at the end of a paragraph. A quick Up arrow nicely respeaks the last line. Do we want to spend any more time on this? ...
> Do we want to spend any more time on this? ... I just did a dist-upgrade on my machine, and I can still reproduce the problem. So...yes, we need to spend more time on this. Mike, Joanie, Lynn - can you please try to reproduce this problem?
Created attachment 86519 [details] My debug.out that shows the problem Here's the debug.out from my system that shows the problem. You'll see the offending stuff right around line 1000. Just prior to that is where I pressed "Return".
The difference between your and mine appears to be a FOCUSED state. Your's (bad braille line): OBJECT EVENT: object:text-caret-moved detail=(-1,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE FOCUSED MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO' Mine's (good braille line): OBJECT EVENT: object:text-caret-moved detail=(-1,0) app.name='soffice.bin' name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO' I've guessing they are going down different Orca code paths. I'll check that next.
I am seeing what Will is seeing on the two machines I've tried it on thus far. w.r.t. Comment #3: > openoffice.org 2.2.0-1ubuntu3, Tue Apr 10 21:51:38 UTC 2007 > Maybe they've "fixed" something between those two different versions of > OOo Writer... I have the April 10th version.
As another data point, I just tried this on the PPC version of Ubuntu Feisty with OOo Writer 2.2, and I still don't get it to fail.
(In reply to comment #9) > As another data point, I just tried this on the PPC version of > Ubuntu Feisty with OOo Writer 2.2, and I still don't get it to fail. Darn. Well...let's see. We put this bug high on our list because it seemed really bad at first. After playing with it, though, I see the following user experience: 1) The user presses return at the end of the line. 2) Without any other user action, braille displays the previous line and the cursor is put on the first cell. 3) As soon as the user types on the keyboard or arrows around, the braille display is updated appropriately. As such, I think the only time we see this problem is when the user presses return at the end of the line and does nothing else. What do people think? Should we lower the priority and ranking of this problem?
See also bug #434600. They are probably both the same bug.
Rich, I just did a fresh install of the 64-bit version of Feisty. I cannot reproduce this issue in that environment either. Seems limited to the 32-bit version.
(In reply to comment #11) I am Sorry bug #434600 has nothing to do with this one. I can still reproduce this with orca (trunk) and OO writer 2.3.1. Tell my if you need debug output.
ubuntu gutsy, oo writer 2.3.0 openoffice.org-core 1:2.3.0-1ubuntu5.3 tue Nov 27 2007 32 bit version (or at least i didnt specifically select 64 bit anywhere, unless it autodetects and chooses) problem not reproducible, although I could have sworn I have in the past. (I did see a oo update not long ago, maybe that did it).
*** Bug 525151 has been marked as a duplicate of this bug. ***
I can still reproduce this problem with ubuntu hardy live cd from tuesday 15th apr. Maybe people who can't reproduce this error should boot with a hardy live cd too!?
Halim, what version of Orca are you using. The one bundled on the CD, or did you check out trunk from SVN?
problem is still reproducible with orca trunk. A little detail is now different: The problem does not exist at the first two lines. To reproduce start oo writer and type a string and press enter. The text disapears (normal behaviour). If you write a string in line 2, the text is on my brailledisplay after pressing enter.
I can still reproduce the problem in OOo dev 3.0 -- now both for the 32-bit and 64-bit versions. And I can still reproduce it for the first line of text.
Created attachment 115284 [details] [review] revision 1 Will and I took a look at this today. This patch seems to solve the issue. I've also updated the regression tests. Will, for the life of me, I cannot get the test bug_350219.py to work. All the regex stuff looks right to me. What am I missing?
Created attachment 115319 [details] [review] Modified patch to include \$ in bug_350219.py Heh - yeah, this one fooled me, too. The '$' character is treated specially in regular expressions, so it needs to be escaped with a \. This patch is the same as yours, with the exception that this one includes the \.
D'oh! I knew that.... Thanks Will. :-) Mike and others, please test.
Thanks All, above patch solves the problem for me, (openoffice.org 2.3.0, openoffice.org-core 1:2.3.0-1ubuntu5.4, Fri May 2 14:54:38 UTC 2008)
Thanks Jon! Checked into trunk. Moving to pending.
This has been "pending" for a week. It's a safe, targeted change (i.e. looking for a specific accessible hierarchy and event) and hasn't seemed to blow anything up. Therefore, I'm going to close this as FIXED. If there are any objections, feel free to reopen it. :-)