marked url in firefox by using one click isn't copied to clipboard, only with a triple mouse-click

[Matthias Sprau]

Hi, if I click in an url in firefox, the whole url ist marked, i.e. highlighted.

If I now use a click on the mousewheel to paste the content of the clipboard into another software, I discover that the url wasn't copied into the clipboard - the previous content ist filled in.
That's confusing to me.

I would expect: If I can mark an url in Firefox with a single mouse-click, which looks like a marking with a triple click, then it should be copied also in the clipboard.
That would be a consisting behavior.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: firefox 78.0.2+build2-0ubuntu0.20.04.1
ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
Uname: Linux 5.4.0-40-generic x86_64
AddonCompatCheckDisabled: False
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: matthias 1453 F.... pulseaudio
 /dev/snd/controlC1: matthias 1453 F.... pulseaudio
 /dev/snd/pcmC1D0c: matthias 1453 F...m pulseaudio
 /dev/snd/pcmC1D0p: matthias 1453 F...m pulseaudio
BuildID: 20200708170202
CasperMD5CheckResult: skip
Channel: Unavailable
CurrentDesktop: ubuntu:GNOME
Date: Sat Jul 25 16:44:27 2020
DefaultProfileExtensions: extensions.sqlite corrupt or missing
DefaultProfileIncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
DefaultProfileLocales: extensions.sqlite corrupt or missing
DefaultProfilePrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/firefox/omni.ja:greprefs.js:730
DefaultProfilePrefSources: prefs.js
DefaultProfileThemes: extensions.sqlite corrupt or missing
ExecutablePath: /usr/lib/firefox/firefox
ForcedLayersAccel: False
InstallationDate: Installed on 2020-04-24 (92 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
IpRoute:
 default via 192.168.11.1 dev wlp4s0 proto dhcp metric 600
 169.254.0.0/16 dev wlp4s0 scope link metric 1000
 192.168.11.0/24 dev wlp4s0 proto kernel scope link src 192.168.11.66 metric 600
Profile1Extensions: extensions.sqlite corrupt or missing
Profile1IncompatibleExtensions: Unavailable (corrupt or non-existant compatibility.ini or extensions.sqlite)
Profile1Locales: extensions.sqlite corrupt or missing
Profile1PrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/firefox/omni.ja:greprefs.js:730
Profile1PrefSources: prefs.js
Profile1Themes: extensions.sqlite corrupt or missing
Profiles:
 Profile1 - LastVersion=74.0.1/20200403064753 (Out of date)
 Profile0 (Default) - LastVersion=78.0.2/20200708170202 (In use)
RunningIncompatibleAddons: False
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/12/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N14ET53W (1.31 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20BTS06G0J
dmi.board.vendor: LENOVO
dmi.board.version: SDK0E50510 WIN
dmi.chassis.asset.tag: R90GJVAH
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN14ET53W(1.31):bd11/12/2019:svnLENOVO:pn20BTS06G0J:pvrThinkPadX1Carbon3rd:rvnLENOVO:rn20BTS06G0J:rvrSDK0E50510WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X1 Carbon 3rd
dmi.product.name: 20BTS06G0J
dmi.product.sku: LENOVO_MT_20BT_BU_Think_FM_ThinkPad X1 Carbon 3rd
dmi.product.version: ThinkPad X1 Carbon 3rd
dmi.sys.vendor: LENOVO

[Github-tbart (github-tbart)]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Using Firefox 78.0.2 on Linux/X11:
1. Visit a URL by entering it into the location bar and pressing return
2. Click into the location bar once or press Ctrl+L; the URL gets highlighted
3. Middle click into any text area (inside firefox or some other window/application)

Actual results:

URL does not get pasted.

Expected results:

URL should be in PRIMARY as soon as it gets highlighted and be able to be pasted somewhere else.

This bug has been introduced only shortly before my current 78.0.2 as I regularly use this procedure to paste URLs into mails and constantly end up not pasting what I want.

I don't know how others feel, but I miss the triple-click to select which is the standard in any other application (or even within text areas inside firefox)! This is a real break in usability standards.
With the current way of automatic full selection of the URL by the first click, I also cannot select parts of the URL (which I have to do all the time because of unnecessary sessionid, tracking and whatnot parameters in today's urls) without clicking a second time, which is also completely uncommon to any selectable text.

clipboard.autocopy is set (untouched).
The description of http://kb.mozillazine.org/Clipboard.autocopy is also wrong now with the current behavior.

If this is a feature and not a bug, please make it configurable (and I'd suggest to make the standard of a whole desktop environment the standard and not this way that breaks the standard). If you do not agree please at least make it configurable and leave the "feature" the standard.

[Release-mgmt-account-bot (release-mgmt-account-bot)]

[Bugbug](https://github.com/mozilla/bugbug/) thinks this bug should belong to this component, but please revert this change in case of error.

[Mak-g (mak-g)]

For how much it may look confusing (it is definitely a shift in behavior and habits), this is the expected behavior currently. Clicking on the urlbar focuses and selects its contents, but because the selection is programmatic we don't override the primary selection, that is because maybe you are selecting the urlbar to paste something, and we don't want to overwrite that.

triple-click should work correctly if you start from an unfocused urlbar (please let us know otherwise), or it's bug 1633203 (allow to re-select). Would fixing that bug help?
You can also drag select starting from the unfocused urlbar.

[Olivier Tilloy (osomon)]

This behaviour looks intentional to me. Can you please file an upstream bug report at https://bugzilla.mozilla.org/enter_bug.cgi#h=dupes%7CFirefox, and share the link to it here? Thanks!

[Matthias Sprau (sprau)]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

 Hi, if I click in an url in firefox, the whole url ist marked, i.e.
  highlighted.

  If I now use a click on the mousewheel to paste the content of the clipboard into another software, I discover that the url wasn't copied into the clipboard - the previous content ist filled in.
  That's confusing to me.

  I would expect: If I can mark an url in Firefox with a single mouse-click, which looks like a marking with a triple click, then it should be copied also in the clipboard.
  That would be a consisting behavior.

Expected results:

  I would expect: If I can mark an url in Firefox with a single mouse-click, which looks like a marking with a triple click, then it should be copied also in the clipboard.
  That would be a consisting behavior.

[Matthias Sprau (sprau)]

https://bugzilla.mozilla.org/show_bug.cgi?id=1656045

Am 29.07.20 um 17:25 schrieb Olivier Tilloy:
> This behaviour looks intentional to me. Can you please file an upstream
> bug report at
> https://bugzilla.mozilla.org/enter_bug.cgi#h=dupes%7CFirefox, and share
> the link to it here? Thanks!
>
> ** Changed in: firefox (Ubuntu)
> Status: New => Incomplete
>

[Github-tbart (github-tbart)]

Using 79.0 now things have improved a lot.
Triple clicking works again, partial selection of URLs also works again.

Ctrl-A still does not work, Ctrl-L also does not work.

Still, (and the linked bug also shows other people feel like this) I think breaking a well established behavior that is common across thousands of other applications is a regression.

The intended functionality (at least I think that has been the motivation behind this change) of only having to click once into the location bar and being able to type a new URL would not be hindered by adhering to the established standard of copying selected text into PRIMARY.

You mention you don't want to override possibly existing clipboard contents.
I don't think anyone uses the PRIMARY to paste URLs into address bars (or has done so before) as it involves/involved selecting (parts of) the URL anyway. That's what CLIPBOARD is for. (And no, I am not asking for overwriting the CLIPBOARD contents upon selection!)

Apart from that, I'd rather introduce a new button/shortcut/etc for a new functionality (clear and focus) instead of breaking standards

Input from a few other users would help, I think.

[Release-mgmt-account-bot (release-mgmt-account-bot)]

The severity field is not set for this bug.
:adw, could you have a look please?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#workflow.2Fno_severity.py).

[Marcela-calderon (marcela-calderon)]

Hi, this sounds like an enhancement, I will set a component to have a starting point for this.
Widget: Gtk team, if this is not the right component please feel free to route this ticket to the corresponding team, thanks!

[Stransky (stransky)]

This is an address bar issue, the text is highlighted but not copied to clipboard.

[Adw-mozilla (adw-mozilla)]

*** This bug has been marked as a duplicate of bug 1653191 ***

[Adw-mozilla (adw-mozilla)]

*** Bug 1656045 has been marked as a duplicate of this bug. ***

[Adw-mozilla (adw-mozilla)]

*** Bug 1659347 has been marked as a duplicate of this bug. ***

[Crxssi (crxssi)]

(In reply to Marco Bonardo [:mak] (OoO 09-23 Aug) from comment #2)
> For how much it may look confusing (it is definitely a shift in behavior and habits), this is the expected behavior currently. Clicking on the urlbar focuses and selects its contents, but because the selection is programmatic we don't override the primary selection, that is because maybe you are selecting the urlbar to paste something, and we don't want to overwrite that.

That is a good point that I had not considered, primarily because I don't typically do that. I usually open a new (blank) tab, then paste into an empty Firefox URL bar, or I paste by middle-clicking in the main Firefox window to paste the X11 buffer. Interestingly, now it seems that pasting a URL into the main Firefox window (the display area of the website) doesn't work anymore, it is just ignored- is this yet another behavior change or bug? (If so, is there already a bug report on that?)

Of course, my entire copy/paste/select workflow has been greatly disrupted by both this new "1 click selects all" and "auto select all doesn't copy to X11 buffer" in the URL bar (and search bar), because nothing else works like that in Linux. Nothing else does that in Firefox, either (except maybe "save as" dialogs where the entire proposed filename is pre-selected). I am trying to keep an open mind, but I really do hate these changes and the fact that there is no preference/setting to revert it to act like it did before.

> triple-click should work correctly if you start from an unfocused urlbar (please let us know otherwise), or it's bug 1633203 (allow to re-select).

Currently I am using 78.0.1 and when I triple-click the unfocused URL bar, it is, indeed, copying the URL into the X11 buffer (which I can then middle-click into another program to paste). It also works if I focus the URL bar first and then triple-click. Note, I do have browser.urlbar.disableExtendForTests set to True because I dislike all the changes in the URL bar, and that reverts some of it (the "zoom" thing and the forced drop-down) but I tested the above with it set to False and the behavior was the same.

[Matthias Sprau (sprau)]

>Ctrl-A still does not work
works with Ubuntu

Triple-Click works too.

[Covex (covex)]

But this tripple click is crazy, all year the single click and selected text was in the buffer, this is the most common thing to do, this tripple click need drives me crazy.

[Philippe-gras (philippe-gras)]

Hello,

The automatic copy into the primary selection has been preventing pasting url with a middle-click in the address bar for many years and it is wonderful that is has been fixed.

For me, the current behaviour is the correct one and I would be sad if the change is reverted.

Nevertheless, I believe CTRL-A should copy the url to the primary selection in order to be consistent with its behaviour on web pages and with the behaviour of the shift-arrow selection.

If some users are confused by text highlighted as selected but not copied into the primary selection, then using a different look in such a case, like text in grey, would avoid any confusion.

Cheers,
Philippe.

[Matthias Sprau (sprau)]

I accept the new behaviour, now it makes sense to me like described above.

[Mozbugs-a (mozbugs-a)]

(In reply to Marco Bonardo [:mak] from comment #2)
> For how much it may look confusing (it is definitely a shift in behavior and habits), this is the expected behavior currently. Clicking on the urlbar focuses and selects its contents, but because the selection is programmatic we don't override the primary selection, that is because maybe you are selecting the urlbar to paste something, and we don't want to overwrite that.
>
> triple-click should work correctly if you start from an unfocused urlbar (please let us know otherwise), or it's bug 1633203 (allow to re-select). Would fixing that bug help?
> You can also drag select starting from the unfocused urlbar.

I appreciate your explanations. I see that you have had to re-explain this across a suite of bug reports, over several years. Maybe there's a middle ground here.

In X11, highlight == primary selection. I understand that the current behavior is an auto-selection, and I think I agree that automatic actions should not have side-effects.

The middle ground would be to allow the user to control that auto-selection. In X11, the auto-select is giving a false view of the state of the system. Make the default to work as it currently does, but give X11 users the opportunity to set Firefox up to conform to X11 (ICCM, Freedesktop.org) standards.

Handling the urlbar selection should be done in only one place (I'd guess), so adding an 'if' in that one place doesn't seem too extreme a solution, and would give you a rest from re-explaining the current behavior.

[Adw-mozilla (adw-mozilla)]

*** Bug 1706572 has been marked as a duplicate of this bug. ***

[Adw-mozilla (adw-mozilla)]

*** Bug 1707568 has been marked as a duplicate of this bug. ***

[Lruzicka (lruzicka)]

(In reply to github.tbart from comment #3)

> Still, (and the linked bug also shows other people feel like this) I think breaking a well established behavior that is common across thousands of other applications is a regression.

I could not agree more.

> You mention you don't want to override possibly existing clipboard contents.
> I don't think anyone uses the PRIMARY to paste URLs into address bars (or has done so before) as it involves/involved selecting (parts of) the URL anyway. That's what CLIPBOARD is for. (And no, I am not asking for overwriting the CLIPBOARD contents upon selection!)
>

Yes, totally. Whenever a text is highlighted, it is expected that it is copied into the primary buffer on Linux and accessible from the mouse buttons. Not doing this is not only not providing the expected behaviour, but also confusing users who might think that something else is broken.

> Apart from that, I'd rather introduce a new button/shortcut/etc for a new functionality (clear and focus) instead of breaking standards
>

Also agree, or at least you could make the behaviour editable using the `about:config` and anyone could choose the behaviour according to their needs and likings.

[Maxime Accadia (maxacc)]

How can we move forward on this issue ?

Would it be possible to workaround this with an addon ? a patch ? some JS somewhere ?

What is the position of the UX designers ?

[Maxime Accadia (maxacc)]

I found a (not very clean) workaround based on https://github.com/SebastianSimon/firefox-selection-fix.

See https://github.com/MAccadia/firefox-selection-fix/tree/primary_select_fix

[Htwyford (htwyford)]

*** Bug 1741158 has been marked as a duplicate of this bug. ***

[Massimo (massimo-b)]

As of 91.7.0esr the issue is still there. Focussing the address bar which has the URL selected doesn't copy the content to primary selection.
Using the triple click workaround is different from all other Linux and Gtk applications. It is also different from browsers like Palemoon.
Any selection is going to be copied to primary selection according to ICCCM and freedesktop.org:
https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt

[Release-mgmt-account-bot (release-mgmt-account-bot)]

The severity field for this bug is relatively low, S4. However, the bug has 5 duplicates.
:adw, could you consider increasing the bug severity?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#severity_underestimated.py).

[Dharvey-d (dharvey-d)]

Fixing the dep here should allow selection which will handle the use cases here

*** This bug has been marked as a duplicate of bug 1633203 ***