355380 - "text selection changed" event sent out when focus changes

Status: RESOLVED DUPLICATE of bug 368598

(Core :: Disability Access APIs, defect)

Description

[Håkan Waara]

I've made mac listen to the nsIAccessible::EVENT_ATK_TEXT_SELECTION_CHANGE. It is not only fired when a selection is changed, but also when you tab from one link to another.

I think it should only be fired if the _length_ of the selection changes.

So, changing from 3 characters selected to 0 (no selection) fires it, but tabbing from an unselected element (0) to another unselected element (0) wouldn't..

Comment 1

[Aaron Leventhal]

At least, if it goes from collapsed to collapsed but the location has changed, it's really just a caret move event.

Comment 2

[Nian Liu(n/a in a long time)]

we have
text_selection_changed
selection_changed
text_caret_moved

where is the exact def for them?

Comment 3

[Ginn Chen]

http://developer.gnome.org/doc/API/2.0/atk/AtkSelection.html#AtkSelection-selection-changed
http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#AtkText-text-selection-changed
http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#AtkText-text-caret-moved

Comment 4

[parente]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061117 Minefield/3.0a1

Focusable text objects such as text links emit the object:text-selection-changed event immediately after they receive focus. This event fires regardless of whether text is selected anywhere on the page or not.

On Linux, object:text-selection-change events typically fire only when the length of a selection region changes. The only event I would expect to receive when a link receives focus is a focus: event. If text is selected elsewhere on the page and becomes deselected because of this focus change, then I would expect the object:text-selection-change on the accessible for the previously selected text, but definitely not on the newly focused link object.