Closed Bug 1653191 Opened 4 years ago Closed 1 year ago

Location bar content not copied to PRIMARY upon clicking in = selecting the URL (Linux/X11)

Categories

(Firefox :: Address Bar, defect, P3)

Product:
Firefox
Component:
Address Bar
Version:
78 Branch
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1633203

People

(Reporter: github.tbart, Unassigned)

References

Details

(Keywords: papercut)

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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Address Bar

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.

Flags: needinfo?(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.

Flags: needinfo?(github.tbart)

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(adw)
Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(adw)
Priority: -- → P3

(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.

Ctrl-A still does not work
works with Ubuntu

Triple-Click works too.

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.

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.

(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.

Keywords: papercut

(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.

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 ?

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

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.

Flags: needinfo?(adw)
Severity: S4 → S3
Flags: needinfo?(adw)

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

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1633203
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.