957332 - atk_text_set_caret_offset() should clear visual selection/highlighting

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Attachment: testcase: text-selection.html

Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal
2. Launch Firefox and enable caret-navigation (F7)
3. (Re)load the attached test case

Expected results: Setting the caret via atk_text_set_caret_offset() would clear the visual selection/highlighting -- just like pressing an arrow key or clicking with the mouse does [*].

Actual results: Setting the caret via atk_text_set_caret_offset() doesn't clear the visual selection/highlighting; the middle of the second paragraph still visually appears to be selected.

Note: As the listener output illustrates, asking for the selected text via ATK results in a zero-length range (which is correct). And pressing Ctrl+C to copy the selected text results in nothing being copied (also correct). But for users with low vision -- and sighted Orca developers trying to implement support for Gecko text selection ;) -- the on-screen rendering is confusing. Hopefully this is a quick fix.

[*] If the attached accessible-event listener were not used. If, after performing steps 1-3 you arrow, click with the mouse, etc., the highlighting remains on screen.

Comment 1

[Joanmarie Diggs]

Attachment: accessible-event listener: text-selection.py

Comment 2

[alexander :surkov (:asurkov)]

Neil, do you have ideas? It seems that visual selection is just an artifact. On accessibility layer we just change the range and then remove/add it from selection (refer to HyperTextAccessible::SetSelectionRange for details).

Comment 3

[Neil Deakin]

Don't know. After loading the testcase and pressing right the selection disappearsand the caret moves to the end of the selection properly. But after pressing right a second time, the caret jumps back to where the beginning was.

Should ask someone who knows more about selection. I think Mats has worked on it in the past.

Comment 4

[Mats Palmgren (inactive)]

Can you try a debug build and let me know if you see any error messages in the console?
I tried the STR - I don't get any messages at all from the attached python script
(using a Nightly on Linux64).
Neil's reported issue might be an unrelated problem.

Comment 5

[Mats Palmgren (inactive)]

Does it work if you move the SetSelectionBoundsAt(0, aStartPos, aEndPos);
after the RemoveRange loop?

Comment 6

[Joanmarie Diggs]

(In reply to Neil Deakin from comment #3)
> Don't know. After loading the testcase and pressing right the selection

Just to be sure.... The test case *and* the accessibility event listener? The event listener needs to be running too as per the steps in the OR.

Comment 7

[Joanmarie Diggs]

Attachment: requested output from running listener and nightly debug build

Here you go.

Comment 8

[Mats Palmgren (inactive)]

Does the workaround suggestion in comment 5 work for now?

Comment 9

[alexander :surkov (:asurkov)]

(In reply to Mats Palmgren (:mats) from comment #8)
> Does the workaround suggestion in comment 5 work for now?

yes it works, I can put an a11y fix but are you interested to have another bug since something strange happens on DOM selection side?

Comment 10

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 11

[Mats Palmgren (inactive)]

Yes, please file a followup bug in Core/Selection and CC me.  Thanks.

Comment 12

[alexander :surkov (:asurkov)]

(In reply to Mats Palmgren (:mats) from comment #11)
> Yes, please file a followup bug in Core/Selection and CC me.  Thanks.

done bug 968430

Comment 13

[alexander :surkov (:asurkov)]

Attachment: patch2

a minimum changes (previous one had editable/test_1.html has failed)

Comment 14

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/72200733e8e7

Comment 15

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/72200733e8e7