Last Comment Bug 440590 - Text selection information is not updated when HTML and XUL entries lose focus
: Text selection information is not updated when HTML and XUL entries lose focus
Status: RESOLVED FIXED
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: mozilla23
Assigned To: alexander :surkov
:
Mentors:
Depends on:
Blocks: orca a11ynext
  Show dependency treegraph
 
Reported: 2008-06-19 16:46 PDT by Joanmarie Diggs
Modified: 2013-04-22 19:21 PDT (History)
5 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (4.47 KB, patch)
2009-06-17 02:52 PDT, Ginn Chen
no flags Details | Diff | Splinter Review
patch2 (4.34 KB, patch)
2013-04-21 20:17 PDT, alexander :surkov
tbsaunde+mozbugs: review+
Details | Diff | Splinter Review

Description Joanmarie Diggs 2008-06-19 16:46:50 PDT
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 2009-05-21 14:10:41 PDT
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 2009-06-09 01:51:17 PDT
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 2009-06-09 07:36:08 PDT
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] 2009-06-09 07:54:12 PDT
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 2009-06-17 02:52:45 PDT
Created attachment 383677 [details] [diff] [review]
patch

Draft patch.
Is there any unwanted side-effect?
Comment 6 alexander :surkov 2009-06-17 06:18:31 PDT
What about selection events?
Comment 7 alexander :surkov 2009-06-17 19:11:57 PDT
(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 2010-06-08 05:14:40 PDT
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 2010-06-28 23:34:50 PDT
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 2011-03-10 06:23:14 PST
has patch, we should finish it for fx5
Comment 11 Joanmarie Diggs 2013-01-02 10:52:56 PST
Seeing as how this bug was filed in 2008 and suggested for being finished "for fx5".... Ping?
Comment 12 alexander :surkov 2013-04-21 20:17:41 PDT
Created attachment 740156 [details] [diff] [review]
patch2
Comment 13 Trevor Saunders (:tbsaunde) 2013-04-21 23:15:57 PDT
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 15 Wes Kocher (:KWierso) 2013-04-22 19:21:51 PDT
https://hg.mozilla.org/mozilla-central/rev/58fa28d2b7bb

Note You need to log in before you can comment on or make changes to this bug.