Bug 1714810 Comment 22 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(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. Instead, they put hidden editor 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.
(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.

Back to Bug 1714810 Comment 22