399158 - Caret browsing doesn't send accessibility events from generated XUL texts

Status: RESOLVED WONTFIX

(Firefox :: Disability Access, defect)

Description

[Milan Zamazal]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a9pre) Gecko/2007100814 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a9pre) Gecko/2007100814 Minefield/3.0a9pre

Caret browsing sends object:text-caret-moved events when moving over <description> element contents in XUL applications only when the given <description> element is put directly in a .xul file.  When the <description> element is added dynamically by a script, caret browsing doesn't send the object:text-caret-moved events from it.

Reproducible: Always

Steps to Reproduce:
1. Go to the URL given above.
2. Press the "Add text" button one or more times.
3. Run Orca or Accerciser.
4. Move the caret using left/right arrow keys over characters in both "Static text." and "Generated text." lines and listen to Orca output and/or watch Accerciser events.
Actual Results:  
Orca reads characters in "Static text." but doesn't read characters in "Generated text.".  Accerciser reports the object:text-caret-moved event for each caret movement in "Static text." and for none or only some of the caret movements in "Generated text.".

Expected Results:  
Characters in both "Static text." and "Generated text." lines should be handled the same way.

Comment 1

[Marco Zehe (:MarcoZ)]

I can confirm different behaviour of this bug in Windows, too. With JAWS, and Virtual Cursor turned off, I can navigate the Static Text. element using the Arrow Keys Left and Right. If I add the text via the button, I cannot navigate that text reliably, except for the G and the e of the first word.

Question: Is it at all wanted to be able to navigate XUL:description elements using the caret? If yes, then this is definitely a bug. If not, the fact that it works in the XUL:description element in the first place is by accident, and this is not a bug.
Aaron, any thoughts/pointers?

Comment 2

[Aaron Leventhal]

Closing for same reason as in bug 399059.

It's the screen readers job to allow review by character within UI/dialogs. Support of caret navigation should not be necessary within UI, and would be inconsistent with other apps, confusing and prohibitively difficult as well.

Comment 3

[Aaron Leventhal]

Orca bug for handling descriptions: http://bugzilla.gnome.org/show_bug.cgi?id=487189

JAWS/Window-Eyes already handle them.