368598 - Text selection events when tabbing through links

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[parente]

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

Tabbing through links in either direction causes a object:text-selection-changed event to fire for each link. This is slightly annoying as it will cause a screen reader (without special scripting) to announce there is now no text selected.

Comment 1

[Aaron Leventhal]

This is happening because of the implementation of nsEventStateManager::MoveCaretToFocus() here:
http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#5112

The offending code is this:
              domSelection->AddRange(newRange);
              domSelection->CollapseToStart();

It's selecting the link and then collapsing the selection, which causes 2 separate notifications. There are probably 2 caret moved events as well.

Two possible solutions:
1) Fix the one place in nsEventStateManager to collapse the range first, and then add it to the selection. I vaguely recall having some problems when I tried that.
2) A more general solution which uses a timeout of length 0 and collects all the selection changes, thus firing fewer caret and selection changes. So anything that messes with the selection with more than 1 operation comes out looking like one thing, if possible. 

#2 sounds better but it's a much harder job, and I wonder if the AT needs to do this for other apps anyway?

Comment 2

[Aaron Leventhal]

Attachment: Multiple fixes, see bug comment

1) Reuse FireDelayedToolkitEvent() so that duplicate caret moves are removed
2) In FlushPendingEvents() also fire selection event if selection changes. 
3) Fix the code that's supposed to return 0 selections when it's just a caret

Behavioral changes -- notes for AT vendors:
A) You won't get as many redundant events. Each user action should result in at most 1 caret and 1 selection event.
B) Caret and selection events will now happen after focus events. Parente says this is a good thing.
C) When selection gets collapsed the user will see a caret move but no selection move event will follow that. 
D) For selection changes where there is still a selection you'll get the caret move and then the selection move event.

Comment 3

[Aaron Leventhal]

Regarding comment 1, I decided to go with the more general solution because I figured out a good way to do it using FireDelayedToolkitEvent()