Closed Bug 1267576 Opened 4 years ago Closed 4 months ago

AccessibleCaret in cursor mode hides immediately in Etherpad


(Core :: DOM: Selection, defect)

Not set





(Reporter: capella, Unassigned)


(Blocks 1 open bug, )


Followup on to bug bug 1266322 comment #5 ...
... It looks like |AccessibleCaretManager::IsCaretDisplayableInCursorMode| is returning false ...
See Also: → 1266322
Step to reproduce on Firefox desktop browser.
1. Set "layout.accessiblecaret.allow_script_change_updates" to true to simulate Firefox Android.
2. Open
3. Single tap on an arbitrary text in the etherpad.

Expected result:
The caret will show.

Actual results:
The caret will show and then disappear immediately.
What I had observed is that when the cursor is in the pad, some javascript will keep changing the selection range once per second. In the change operation, gecko will perform two removeSelection() and one addRange(), which should correspond to the 'else' branch in the js code in [1].

The removeSelection() js call will hide the caret since the selection don't have any range. Even if we allow script to update the caret on Android, there's no way to show the caret later in the addRange() js call because we only update caret when there's a visible caret in [2].

I'm wondering if we can remove [2] and allow the carets always update whenever script changes.

Change the bug title because carets should work as expected in simple designMode pages without any js scripts.
Summary: AccessibleCaret hides in Etherpad / designMode documents → AccessibleCaret hides in Etherpad
We avoid updates in those cases to prevent IME/keyboard events and styling-selection changes to expose (make visible) the carets and the Selection UI (ActionBar / FloatingToolbar) if they aren't already in that state.

Watch for regressions like:
Bug 1230617 - Editing text in an input field causes the actionbar to appear and disappear on each keystroke
I think we need to add reason to nsISelectionListener.idl to distinguish removeAllRange() and addRange() calls. Currently, these two operations are both reason 0.
Assignee: nobody → tlin
Bug 1240286 is another related issue we should not regress.
I'm not working on this bug this moment.
Assignee: tlin → nobody

This bug still happens in, but the eitherpad is currently not publicly accessible. Per analysis in comment 2, I don't feel there's a good way to fix this, so I'd like to call this WONTFIX

Closed: 4 months ago
Resolution: --- → WONTFIX
Summary: AccessibleCaret hides in Etherpad → AccessibleCaret in cursor mode hides immediately in Etherpad
You need to log in before you can comment on or make changes to this bug.