Issue 48645 - No speech report when pressing <enter> or <tab>
Summary: No speech report when pressing <enter> or <tab>
Status: CLOSED NOT_AN_OOO_ISSUE
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: 680m97
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0.3
Assignee: nospam4obr
QA Contact: issues@framework
URL:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2005-05-03 17:03 UTC by eric.savary
Modified: 2006-01-25 19:43 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description eric.savary 2005-05-03 17:03:16 UTC 
- JDS 34b + OOom97
- start Gnopernicus witch speech
- New text document
-> pressing <Enter> or <Tab> does not output anything.
Comment 1 eric.savary 2005-05-03 17:03:50 UTC 
Set accessibility keyword
Comment 2 eric.savary 2005-05-03 17:38:11 UTC 
ES->OBR: please dispatch to the responsible engineers. Thanx!
Comment 3 nospam4obr 2005-05-18 14:50:27 UTC 
I don't get any feedback on pressing <tab> in gedit either. 

The issue with new paragraphs is that writer adds them _before_ the one that is
currently focused, so there is no focus change in that case. See also #i13025#.

I think we already had a discussion on this topic a while ago, thinking of the
bridge emulating a focus change in this case, but IIRC we decided not to do so.

I am not sure if gnopernicus would state something like "new paragraph" when
retrieving the corresponding child event if we would bridge the accessible role
"paragraph". Bill ?
Comment 4 nospam4obr 2005-05-20 14:48:30 UTC 
re-targetet.
Comment 5 nospam4obr 2006-01-06 14:31:05 UTC 
As written earlier, <tab> is also not read in gedit. I have ensured that the
corresponding key event gets passed into the Java event queue like for all other
keys; the rest is up to gnopernicus.
Comment 6 pavel 2006-01-18 20:30:50 UTC 
What is the status?

obr: will this be fixed in time for 2.0.2?
Comment 7 mdxonefour 2006-01-19 09:33:40 UTC 
MD: As discussed with Oliver, Peter and Michele we re-target this issue to
2.0.3. There we will have the native bridge available which will solve this issue.
Comment 8 billhaneman 2006-01-19 11:09:25 UTC 
I don't think I agree with the last comment - the native bridge only "solves"
this problem because of other gnopernicus logic errors, i.e. by accident.  A
real fix for this problem will be required in either case, as the current
gnopernicus behavior may well have to be patched out.  (gnopernicus is speaking
the word "paragraph" because of a "visible data changed" event, but not for the
reasons one might imagine).

The bug is a gnopernicus bug in any case, why not close this as not-OpenOffice?
Comment 9 nospam4obr 2006-01-19 14:04:35 UTC 
I have logged http://bugzilla.gnome.org/show_bug.cgi?id=327673 for a more
appropriate fix on gnopernicus site, waiting for advice from Sun APO on how to
handle this issue.
Comment 10 nospam4obr 2006-01-19 14:20:27 UTC 
The SUN internal bug id for this is CR6374338.
Comment 11 nospam4obr 2006-01-23 09:42:20 UTC 
As stated above already, the issue is fixed ( "by accident" ) with the "native"
atkbridge (#i47890#), so I close this bug as INVALID in the sense of NOT
OPENOFFICE.ORG.
Comment 12 nospam4obr 2006-01-23 09:42:51 UTC 
.
Comment 13 korn 2006-01-25 19:43:16 UTC 
Please see GNOME bug #328579 at:
http://bugzilla.gnome.org/show_bug.cgi?id=328579 for a fix to the TAB portion of
this bug in Gnopernicus.