440590 - Text selection information is not updated when HTML and XUL entries lose focus

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Steps to reproduce:

1. Navigate to http://delysid.org/orca-firefox-braille-problem.html

2. Tab to one of the two entries which will cause the text in it to be selected.

3. In Accerciser, select the accessible in the tree of accessibles.

4. In the iPython console, type the following:

    acc.queryText().getSelection(0)

5. Tab to move away from that entry which will cause the text in it to no longer be selected.

Repeat step 4.

Expected results:  After step 4: (0, 1).  After step 5: (0, 0) because text is no longer selected.

Actual results: After step 4: (0, 1). After step 5: (0, 1) which indicates text is still selected.

6. Now use the mouse to click on the entry which had the selected text and which is no longer focused.

Repeat step 4.  You get (0, 0) as expected.

Note that this is not limited to HTML.  You can obtain the very same results by performing the very same steps using the Firefox Preferences dialog, Applications page (the Search entry).

Comment 1

[Joanmarie Diggs]

This bug is still present and we're one month shy of a full year without even triage taking place. So.... Ping. :-)

Comment 2

[Ginn Chen]

Joanie,
Even if the selection is invisible, the selection is still there.
e.g. If you enter "123" in the entry, and select "23" with mouse, now click on another window, "23" is no longer highlighted, but if refocus the window, "23" is highlighted again.
However, using tab, or clicking the entry would reset the selection.

Every document / entry has its own selection controller.

So logically acc.queryText().getSelection(0) is returning the "hidden" result.

I can propose 2 options for this bug.
Option 1:
In Orca, ignore selection, if the acc object is focusable but not focused.

Option 2:
In Firefox, do not return the selection if it is "SELECTION_HIDDEN".

What do you think?

Comment 3

[Joanmarie Diggs]

My vote would be for Option 2.

Orca needs to provide access to what's on the screen, and what's on the screen is text which is not selected -- or which appears to be not selected -- so we need a way of knowing that the text is (appears to be) not selected.

While not the case in Firefox/Gecko, other applications do allow the user to select text in multiple objects at the same time. In addition, not all apps clear (hide) the selection when focus is given to another object. For instance, in OOo Writer, you can select bits of different paragraphs, including non-contiguous text. In that case:

1. Giving focus to another window does not clear the selection.

2. Both paragraphs will have STATE_FOCUSABLE, but only one (at most) will have STATE_FOCUSED.

Option 1 requires Orca and other ATs to be familiar with the unique habits and inner workings of each app/toolkit w.r.t. text selection in order to reliably present the contents of the screen. Option 2 means we can trust the apps to report what's being displayed and present it without guessing.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Yeah. So what we (gecko) have to be careful of is what selection(s) are actionable. If we don't expose a selection we better be confident that a copy or paste isn't going to act upon it. In codespeak I'm thinking something like a:

PRBool nsAccUtils::IsSelectionRelevant

Before exposing.

Comment 5

[Ginn Chen]

Attachment: patch

Draft patch.
Is there any unwanted side-effect?

Comment 6

[alexander :surkov (:asurkov)]

What about selection events?

Comment 7

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> Joanie,
> Even if the selection is invisible, the selection is still there.
> e.g. If you enter "123" in the entry, and select "23" with mouse, now click on
> another window, "23" is no longer highlighted, but if refocus the window, "23"
> is highlighted again.
> However, using tab, or clicking the entry would reset the selection.

Ginn, is it valid for linux only. When I do this on windows/mac then selection is visible but it changes the color. I wonder does your patch affects on windows/mac?

Comment 8

[Ginn Chen]

surkov,
If you select some normal text and switch to another window, the color changes.
(I guess it is SELECTION_DISABLED.)
But if you select some text in textbox and switch to another window, the selection will be invisible.
(it is SELECTION_HIDDEN.)

I think it is the same on all platforms.

Comment 9

[alexander :surkov (:asurkov)]

Comment on attachment 383677 [details] [diff] [review]
patch

I think we should ignore hidden selection at all. We don't need to return it and it doesn't make sense to allow to change it.

Comment 10

[alexander :surkov (:asurkov)]

has patch, we should finish it for fx5

Comment 11

[Joanmarie Diggs]

Seeing as how this bug was filed in 2008 and suggested for being finished "for fx5".... Ping?

Comment 12

[alexander :surkov (:asurkov)]

Attachment: patch2

Comment 13

[Trevor Saunders (:tbsaunde)]

Comment on attachment 740156 [details] [diff] [review]
patch2

> HyperTextAccessible::GetSelectionDOMRanges(int16_t aType,
>                                            nsTArray<nsRange*>* aRanges)
> {
>   nsRefPtr<nsFrameSelection> frameSelection = FrameSelection();
>-  if (!frameSelection)
>+  if (!frameSelection || // selection is hidden or off
>+      frameSelection->GetDisplaySelection() <= nsISelectionController::SELECTION_HIDDEN)

nit,  don't put comments in middle of if condition, and maybe make it
// ignore selection if it is not visible.

Comment 14

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/58fa28d2b7bb

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/58fa28d2b7bb