1833081 - Text selection markers only visible after scroll

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Peter Brand]

Attachment: textmarker.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/113.0

Steps to reproduce:

After selecting text, there are no start and end markers visible until one performs a page down and back up again.

Actual results:

Selected text. No markers. Press Page Down, page scrolls and selection is out of view, press page up to bring selection back into view, markers are now visible.

Expected results:

Markers should be visible as soon as text is selected.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Selection' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Jan, would you like to take a look at what's up here?

Comment 3

[Jan Jaeschke [:jjaschke]]

Hello Peter,

is this issue related to Firefox itself or rather some AddOns that are enabled? I have never seen these blue markers which allow to extend the Selection with a pointer. Also when installing the AddOn "Textmarker" which you mentioned in the video does not add them. Am I missing something obvious here?

If these markers are indeed added by an AddOn, please reach out to the developers of the AddOn. If not, feel free to ping me again. :)

Comment 4

[Peter Brand]

Hi Jan
Before submitting the bug, I tested to see if it was an add-on by running Firefox in safe mode (shit-click the icon). The markers appeared using the STR. The name of the video is "Textmarker", but there is no audio of me mentioning an add-on by that name.
I have noticed the markers appearing every now and then, whenever some scroll action takes place either manually or in response to activity on the page. They appear to look like the markers I see in the Android version of Firefox.
Behavior does not happen in Edge (haven't tried Chrome as I refuse to install that), or any other application.
I have tested the STR on other PCs with the same version of FF and it does not show the markers. Is this perhaps a configuration setting or a developer option?
I thought it was a feature recently added, and truth be told I rather like it as it makes it easy to adjust the selection.

Comment 5

[Jan Jaeschke [:jjaschke]]

My guess with said AddOn was because there was a search results page in the video that mentioned an AddOn (which from first glance could be doing something in a similar area).

But I think we're getting somewhere. These blue raindrop-shaped bubbles are called accessible caret and are enabled automatically if your device is capable of touch. Is that the case for you?

When I enable the caret via prefs (layout.accessiblecaret.enabled=true && layout.accessiblecaret.hide_carets_for_mouse_input=false) on my non-touch devices I cannot reproduce this though (tested on Ubuntu 23.04, MacOS13 and Win11).

Kagami, I think I remember you have a Windows device that has a touch screen. Can you reproduce this? Thanks!

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Jan Jaeschke [:jjaschke] from comment #5)

Kagami, I think I remember you have a Windows device that has a touch screen. Can you reproduce this? Thanks!

Yup, I've seen this time to time in my machine but didn't have STR. Thank you Peter for getting a simple STR for this. It's weird because scrolling by mouse wheel does not cause the issue.

Just a note, fixing this should still allow showing accessible carets when interacting via touchscreen: selecting text via mouse and scrolling via touchscreen currently shows them, which is good since there's a clear user intent to use touchscreen.

Comment 7

[Jan Jaeschke [:jjaschke]]

:TYLin, may I move this one to you?

Comment 8

[Peter Brand]

I don't have a touch screen. It is a Windows 10 system with dual Philips 234EL monitors. layout.accessiblecaret.enabled was set to false. However, layout.accessiblecaret.enabled_on_touch was set to true by default.I set that to false and the carets disappeared, and now do not appear even when I set it back to true. Perhaps it was in an indeterminate state and has now been set.
For completeness, these are my settings now
layout.accessiblecaret.allow_dragging_across_other_caret true
layout.accessiblecaret.always_tilt false
layout.accessiblecaret.caret_shown_when_long_tapping_on_empty_content false
layout.accessiblecaret.enabled false
layout.accessiblecaret.enabled_on_touch true
layout.accessiblecaret.extend_selection_for_phone_number false
layout.accessiblecaret.hapticfeedback false
layout.accessiblecaret.height 36.0
layout.accessiblecaret.hide_carets_for_mouse_input true
layout.accessiblecaret.magnifier.enabled false
layout.accessiblecaret.margin-left -18.5
layout.accessiblecaret.script_change_update_mode 0
layout.accessiblecaret.transition-duration 250.0
layout.accessiblecaret.use_long_tap_injector false
layout.accessiblecaret.width 34.0
Ah well, I thought they were quite useful, but I can live with it. You can close this ticket if you like. Thanks for your attention.

Comment 9

[Peter Brand]

Wait a bit, I started a new window of Firefox, and the accessible carets are still visible after the STR.
It must have something to do with the settings above.

Comment 10

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Re comment 6:

Just a note, fixing this should still allow showing accessible carets when interacting via touchscreen: selecting text via mouse and scrolling via touchscreen currently shows them, which is good since there's a clear user intent to use touchscreen.

Yes, this is the desired behavior to show the blue caret when using the touchscreen.

Re comment 8:

Those preference in comment 8 are all their default value. Specifically, layout.accessiblecaret.enabled_on_touch is true by default, meaning AccessibleCaret is shown whenever the text selection is triggered by touch events.

I don't have a guess why the blue carets are shown after the scroll events on a system without a touch screen. However, some preference changes might need a restart of Firefox to be effective. Also, I believe Firefox safe mode only disables addons, but still uses the same user profile. Are you able to reproduce this bug with a new profile? https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Comment 11

[Peter Brand]

Good question! Yes, created a new profile, didn't import anything, skipped all the configuration suggestions on first use. Followed STR and Carets were visible. All settings in comment 8 above were the same for the new profile. Setting layout.accessiblecaret.enabled_on_touch to false made the carets disappear. So no difference with new profile.

Comment 12

[Kagami Rosylight [:saschanaz] (they/them)]

What does it say when you open about:support on the address bar? Does it say "touch input enabled" in Graphics / Asynchronous Pan/Zoom ?

Comment 13

[Peter Brand]

Yes, it says wheel input enabled; touch input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled; smooth pinch-zoom enabled

Comment 14

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I think I understand what happens. Peter's system supports touch events, so AccessibleCaret is enabled by default. I can reproduce this issue on my system without touch events support via setting layout.accessiblecaret.enabled=true.

The key to reproduce this is to use Page Up/Down to bring the selected text back into view. (I overlooked this step in comment 0 ...)

The expected behavior should be: the markers (blue carets) should not be visible when the selected text is scrolled back into view, by either using mouse wheel or Page Up/Down. This behavior should be the same as if the system has no touch events support, and the user interacts with the webpage with mouse and keyboard.

The reason the blue carets show after hitting Page Up is that we don't filter key events near the end of AccessibleCaretManager::OnScrollEnd(), but we should.

Comment 15

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1833081 - Don't show AccessibleCaret when selected text is scrolled back into view via keyboard.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d448de86c0d7
Don't show AccessibleCaret when selected text is scrolled back into view via keyboard. r=webdriver-reviewers,emilio,jdescottes

Comment 17

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/d448de86c0d7