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

RESOLVED FIXED in mozilla23

Status

()

Core
Disability Access APIs
RESOLVED FIXED
9 years ago
4 years ago

People

(Reporter: Joanmarie Diggs, Assigned: surkov)

Tracking

(Blocks: 2 bugs, {access})

Trunk
mozilla23
x86
Linux
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

4.34 KB, patch
tbsaunde
: review+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
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).
(Reporter)

Comment 1

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

Comment 2

8 years ago
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?
(Reporter)

Comment 3

8 years ago
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.
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

8 years ago
Created attachment 383677 [details] [diff] [review]
patch

Draft patch.
Is there any unwanted side-effect?
Assignee: nobody → ginn.chen
Status: NEW → ASSIGNED
Attachment #383677 - Flags: review?(surkov.alexander)
(Assignee)

Comment 6

8 years ago
What about selection events?
(Assignee)

Comment 7

8 years ago
(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

7 years ago
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.
(Assignee)

Comment 9

7 years ago
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.
Attachment #383677 - Flags: review?(surkov.alexander)
(Assignee)

Comment 10

6 years ago
has patch, we should finish it for fx5
Blocks: 632301
(Reporter)

Comment 11

4 years ago
Seeing as how this bug was filed in 2008 and suggested for being finished "for fx5".... Ping?
(Assignee)

Comment 12

4 years ago
Created attachment 740156 [details] [diff] [review]
patch2
Assignee: ginn.chen → surkov.alexander
Attachment #383677 - Attachment is obsolete: true
Attachment #740156 - Flags: review?(trev.saunders)
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.
Attachment #740156 - Flags: review?(trev.saunders) → review+
(Assignee)

Comment 14

4 years ago
http://hg.mozilla.org/integration/mozilla-inbound/rev/58fa28d2b7bb
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/58fa28d2b7bb
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
You need to log in before you can comment on or make changes to this bug.