Followup on to bug bug 1266322 comment #5 ... ... It looks like |AccessibleCaretManager::IsCaretDisplayableInCursorMode| is returning false ...

Step to reproduce on Firefox desktop browser. 1. Set "layout.accessiblecaret.allow_script_change_updates" to true to simulate Firefox Android. 2. Open https://public.etherpad-mozilla.org/p/testforclipboard 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. [1] https://github.com/ether/etherpad-lite/blob/97b971747f19c427e40e1fa64b431324da80238d/src/static/js/ace2_inner.js#L4724-L4748 [2] https://dxr.mozilla.org/mozilla-central/rev/fc15477ce628599519cb0055f52cc195d640dc94/layout/base/AccessibleCaretManager.cpp#159

Change the bug title because carets should work as expected in simple designMode pages without any js scripts.

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.

Bug 1240286 is another related issue we should not regress.

I'm not working on this bug this moment.