1714810 - Middle-click to scroll resets text selection (regression)

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Description

[Johannes]

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

Steps to reproduce:

Draw a text selection with the mouse and then middle-click to start scrolling the website

Actual results:

The text selection was undone.

Expected results:

The text selection should stay like in Firefox 88 and earlier.

Like many other people, I use text selections for orientation. In this particular case, it helps me focussing on where I started scrolling so that I can keep reading there after scrolling. This change in Firefox 89 breaks this usage pattern, and it is inconsistent with how other applications such as word processors handle middle-clicking to scroll with an active selection.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2032f2b926ddf13702d5720983d226273a4290a6&tochange=889132330748b03914570e29abbb56950816da30

Comment 3

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Masayuki, can you, please, set severity as appropriate?

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

Hmm, this is a difficult issue. If I enable middlemouse.paste in ESR 78, I reproduce this too. So, this must be a traditional behavior on Linux in the default settings. And the new behavior is same as Chrome. So, fixing this bug may cause new web-compat issue (or there may be some web-compat issues but just we don't have the reports). So, even if we fix this, it might better to keep current behavior in the default settings, but if so, most users won't realize the fix of this issue with a hidden pref. So, I can say, it's not worthwhile to fix this in such approach.

On the other hand, I really understand the inconvenience for some users because I'm also a big fun of using text selection to read long text (although I don't use autoscrolling, I use mouse wheel instead).

Comment 5

[Johannes]

I often prefer middle-click since I can scroll in much finer steps than with the scroll wheel. For users of middlemouse.paste I guess the behaviour is expected, but here we're talking about the standard behaviour on Windows for the last 20+ years.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Masayuki, this is picking up a lot of dupes. Can we revisit the priority & severity here? It would be nice if we could get this fixed in an upcoming release.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10)

Masayuki, this is picking up a lot of dupes. Can we revisit the priority & severity here? It would be nice if we could get this fixed in an upcoming release.

Well, but the difficult thing is, the new behavior is exactly same as Chrome. So, fixing this may cause restoring a web-compat issue which there was.

Comment 12

[Laurențiu Nicola]

How did you test? While Chromium doesn't have auto-scrolling by default, you can enable it using this extension: https://chrome.google.com/webstore/detail/autoscroll/occjjkgifpmdgodlplnacmkejpdionan/related.

After that, if you select some text on a web page and scroll with the wheel button, the selection is persisted.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

(In reply to Laurențiu Nicola from comment #12)

How did you test?

I just test it with Chrome for Windows. Looks like that it's enabled only on Windows (and cannot disable it):
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/exported/web_view_impl.cc;l=1799-1801;drc=f78c2191a92342c75a4a2877a2789299f9a14a15

While Chromium doesn't have auto-scrolling by default, you can enable it using this extension: https://chrome.google.com/webstore/detail/autoscroll/occjjkgifpmdgodlplnacmkejpdionan/related.

After that, if you select some text on a web page and scroll with the wheel button, the selection is persisted.

I don't think that we should follow an extension's behavior.

Comment 14

[Leo_sk]

Its not following the behaviour of extension. Its just that there is no precedent to this behaviour even on chrome. Middle click in chrome does not bring autoscroll at all. In firefox, appearance of autoscroll on middle clicking is separate behaviour from chrome anyways, so it makes no sense to imitate chrome's behaviour in unselecting text too.

Also, the previous behaviour where autoscroll did not unselect text allowed much flexibility in behaviour. Current behaviour provides none, and there is even no current concrete reason to have it. If there are issues in with websites in future, we can always follow chrome and disable autoscroll completely.

Comment 15

[Laurențiu Nicola]

It's not behaving like Chromium, even on Windows: in Chromium if you middle-click on the selection to scroll, the selection is preserved. The selection is also preserved in Edge, regardless of where you're clicking.

We should also keep in mind that a (supposedly) Linux bug fix caused a regression in auto-scrolling not only on Linux, but also Windows.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

I checked on Edge on Windows, Chrome on Linux/macOS, Chromium on Linux and Safari on macOS again. All of them collapse selection if I middle button down outside selected text or if I middle mouse button up in selected text. So, at least the former case, current behavior is exactly matches with the other browsers. This consistent behavior may be useful for web developers if they want to apply a function to middle mouse button. So, I feel it's better to take the traditional behavior with a hidden pref even if we fix this regression.

Comment 17

[Laurențiu Nicola]

So, at least the former case, current behavior is exactly matches with the other browsers.

That is, if you press the button outside the selection. If not, Firefox behaves differently. I can't reproduce your Edge behavior, but maybe I have an older version.

This consistent behavior may be useful for web developers if they want to apply a function to middle mouse button.

It's "consistently bad" in Firefox, though. But I think the browser should behave in a useful way for the user, not for the web developers.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

If not, Firefox behaves differently.

Yes, but fixing it requires a big change, so, I don't think that we should fix it immediately.

I think the browser should behave in a useful way for the user, not for the web developers.

Without big market share, this kind of difference may cause only Firefox users facing problems. Such problems inconvenience the users too. So, the balance is really difficult issue.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

Attachment: Bug 1714810 - Add a hidden pref to prevent to collapse selection at trying to start autoscroll r=Edgar!

Collapsing selection with middle click is compatible behavior with Chrome.
However, some Firefox users don't like this behavior, and we have not done it
before. Therefore, this patch adds a hidden pref to prevent the new Chrome
compatible behavior.

Keeping compatible behavior is important and middle click is mainly used for
autoscroll. Therefore, if auto scroll is disabled, we should ignore the new
pref for better compatibility.

Unfortunately, we collapse selection before AutoScrollChild handles
mousedown event with the listener in the system group (
nsIFrame::HandleEvent() is called before that). Therefore, we cannot prevent
the selection change from AutoScrollChild only when it starts scroll.
For solving this issue, we need a lot of big changes. Therefore, for now,
this patch just checks whether the pref is enabled or not.

And also the new pref is ignored when middle click paste is enabled because
it may be followed by "paste" event even when user clicks non-editable nodes.
Then, if web apps handle "paste" event, the new selection range may be
important. Therefore, we should ignore the new pref in this case.

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

I considered that we should keep the new behavior by default. However, for the users who don't like the new behavior, I'll put a new pref, general.autoscroll.prevent_to_collapse_selection_by_middle_mouse_down. If it's set to true and autoscroll is enabled and middle mouse paste is disabled, you can get the traditional behavior back, i.e., you won't reset selection with a click of the middle mouse button on non-editable content.

Comment 21

[Laurențiu Nicola]

That's a lot of opt-ins to make selection work well:

1. why does the preference have to be hidden? (the general.autoscroll preferences aren't hidden, why do you hate this one so much?)
2. why the awkward name? (okay, the other preferences have awkward names, too)
3. why gate it on two apparently unrelated preferences? I don't use middle-click pasting often, but it doesn't make sense to link pasting in a text area to scrolling around the page (see below).
4. why do you insist that this is for Chrome compatibility, when you acknowledge in bug 1528289 that there are still some differences, including what happens when you middle click the selection?

But these are mostly rhetorical questions. I admit I didn't fully understand bug 1528289 and I might be wrong, but it seems to be about the fact that scrolling on the messages triggers pasting in the editing area. Clearing the selection seems to be a bad workaround: the problem is that clicking on one element pastes text into another one.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

(In reply to Laurențiu Nicola from comment #21)

1. why does the preference have to be hidden? (the general.autoscroll preferences aren't hidden, why do you hate this one so much?)

I don't think that breaking web-compat things shouldn't be introduced in front. Such options have caused invalid bug reports a lot.

2. why the awkward name? (okay, the other preferences have awkward names, too)

How do you make it shorter with explaining what it changes?

3. why gate it on two apparently unrelated preferences? I don't use middle-click pasting often, but it doesn't make sense to link pasting in a text area to scrolling around the page (see below).

It's explained at the definition of the preference. They are really related to the new pref.

4. why do you insist that this is for Chrome compatibility, when you acknowledge in bug 1528289 that there are still some differences, including what happens when you middle click the selection?

I'd love to write or review patches to make the behavior more similar to Chrome. However, it's not realistic scenario unless we get some web-compat issues since it requires (probably) big changes.

But these are mostly rhetorical questions. I admit I didn't fully understand bug 1528289 and I might be wrong, but it seems to be about the fact that scrolling on the messages triggers pasting in the editing area. Clearing the selection seems to be a bad workaround: the problem is that clicking on one element pastes text into another one.

In these days, some richtext editor (a.k.a html editor) do not use built-in editor simply. Instead, they put hidden editor, and showing colored text and handling pointing device events with non-editable (visible) content. Therefore, web browsers started to fire all clipboard events when user tries to do cut/copy/paste even if selection is not in editable content for making such web apps can handle the users' intention better. So, when a middle mouse click causes a "paste" or web apps wants to apply a function to middle mouse click, the selection behavior becomes really important for mousedown, mouseup and auxclick event listeners.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3a1818384ecc
Add a hidden pref to prevent to collapse selection at trying to start autoscroll r=edgar

Comment 24

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/3a1818384ecc

Comment 25

[ololuki]

I have done some comparisons between Firefox 90.0.2 and Chrome 92.0.4515.159 / Edge 92.0.902.62 on Windows and

• middle click on link - selection is kept on Chrome/Edge no matter if clicked inside or outside selection. In Firefox 90 selection was collapsed after click on link. Is seems to be fixed already in Firefox nightly
• middle button down on selection and move mouse - selection is kept on Chrome/Edge. Firefox always collapses selection
• middle button click on selection (without move) - selection is lost on all browsers
• middle button down outside selection - all browsers collapses selection
• click middle button or press middle and move mouse on scrollbar - selection is kept on all browsers

If middlemouse.paste is enabled - it always deselects selected text even in Firefox 78.13.0 ESR, but this deselection is after middle up event.
Selection is only prevented when link is clicked with middle button in Firefox 78.13.0 ESR.

I prepared Extension to fix selection collapsing on middle button events. You can download it here:
https://github.com/ololuki/AutoScroll
https://github.com/ololuki/AutoScroll/releases/tag/v0.0.1
It is not perfect, but it is good enough to have autoscroll and keep selection. It should works on Windows and on Linux Firefox 90 and 91. If middlemouse.paste is enabled then middle mouse paste could not work properly - moving focus with left button is needed, but sometimes it does not work at all. But selection is not collapsed.
I hope it will be helpful, at least until official fix will be available on Firefox.

Comment 26

[Kestrel]

In latest Nightly, the new pref is listed in about:config and not hidden despite the patch description and previous discussion. Normally prefs are only considered hidden if they aren't listed by default and the user needs to create them manually.

Comment 27

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

The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 28

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(away until 10/14)]

Comment on attachment 9236768 [details]
Bug 1714810 - Add a hidden pref to prevent to collapse selection at trying to start autoscroll r=Edgar!

Beta/Release Uplift Approval Request

• User impact if declined: Some users really hate the new (other browsers' compat) behavior, that is resetting selection at middle click when they try to start auto scroll.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds a hidden pref to take the traditional behavior back by users. So, this does not affect to most users.
• String changes made/needed: none

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9236768 [details]
Bug 1714810 - Add a hidden pref to prevent to collapse selection at trying to start autoscroll r=Edgar!

Approved for 92.0b8.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/be406fd0b928