376013 - [a11y] Incorrect text information sent in "object:text-changed:insert" events.

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Rich Burridge]

See also Orca bug #409736.
http://bugzilla.gnome.org/show_bug.cgi?id=409736

Steps to reproduce:
1. Create a new message in thunderbird.
2. Type "this is a test.", select that line and copy it (Control-V).
3. Move to the end of that line, press Return for a new line, and use Control V
to paste the copied text.

The any_data field of the "object:text-changed:insert" accessibility
event should contain "This is a test". It doesn't. Some times it's
"is a test.
" 
Sometimes it's 
"s a test.
"

This unfortunately means that Orca is unable to correct inform the 
user what has just happened.

Comment 1

[Joanmarie Diggs]

This looks like it should be moved to Core - Disability Access APIs.  However, it seems that I don't have the power to move it. So I've CC'ed Aaron.  :-) Aaron, if you agree, could you also please make this a blocks against the Orca metabug?  Thanks.

Reason for moving it:  The problem exists in Firefox entries as well.  It seems like we're losing three characters at a time.  Try this in a multi-line entry:

1. Type "hello world"
2. Select the line and copy it to the clipboard
3. Move to the end of the line, press Return for a new line, then press V to paste it
4. Keep repeating step 3

The any_data goes from "lo world" to "world" to "ld" to nothing.  See output below from monitoring object:text-changed:insert events in Accerciser.

-----------------------------
object:text-changed:insert(15, 11, lo world
)
	source: [entry | ]
	application: [application | Minefield]
object:text-changed:insert(29, 11,  world
)
	source: [entry | ]
	application: [application | Minefield]
object:text-changed:insert(43, 11, orld
)
	source: [entry | ]
	application: [application | Minefield]
object:text-changed:insert(57, 11, ld
)

Comment 2

[Joanmarie Diggs]

Editing the Summary to remove "Thunderbird" since it effects both Thunderbird and Firefox.

Comment 3

[Aaron Leventhal]

Alexander, could you look at this?

Comment 4

[Evan Yan]

Will the work on bug 371394 affects this bug?

Comment 5

[alexander :surkov (:asurkov)]

(In reply to comment #4)
> Will the work on bug 371394 affects this bug?
> 

Not sure.

Also we do not provide removed/inserted text therefore I guess we return incorect offsets. Right? Also what is order of events, for example, when I insert some text into selection. Should events be fired after changes? Can you point me some documentation?

Comment 6

[Evan Yan]

Attachment: call DOMPointToOffset with parentNode

when insert node, aPosition is child node index, we should call DOMPointToOffset with the parent node.

Comment 7

[Evan Yan]

(In reply to comment #5)
> Also what is order of events, for example, when I
> insert some text into selection. Should events be fired after changes? 

Currently we fire object:text-changed:delete following with object:text-changed:insert. I think it makes sense.

> Can you point me some documentation?
> 
Sorry I don't know there is any such documentation.

Comment 8

[Aaron Leventhal]

Comment on attachment 267262 [details] [diff] [review]
call DOMPointToOffset with parentNode

It's still not probably 100% correct, but Surkov can fix that in the other bug when we remove this method and use nsIDocumentObserver.

Here's the problem:
* If a link or label node is inserted (something with its own accessible object), the length should be 1, because it's represented by an embedded object character.
* If font or some kind of text formatting node is inserted, the length should be the length of the text.

We don't differentiate.