Closed Bug 1635578 Opened 5 years ago Closed 5 years ago

click behavior in urlbar broken

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Version:
75 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1621570

People

(Reporter: aeb, Unassigned)

Details

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

Steps to reproduce:

Copying a url from the urlbar to an xterm has become much more difficult.
I click once on the url. The entire urlbar turns blue, but is not copied to the X primary selection. Further clicks make the blue color disappear, but still nothing is copied.
A double click selects a single word and copies that to the X primary selection.
(That is not something one often wants: copying part of a url.) Finally a triple click does what I needed and copies the entire url. Being an old man, triple clicking is not easy for me. The past fifty years I have not needed triple clicks, and today this is the only place in my computer usage where it is needed.

Actual results:

The results are as stated already: single click turns the url blue but does not copy, double click copies a single word, triple click copies the url.
I tried with the four possible combinations true/false of browser.urlbar.clickSelectsAll and browser.urlbar.doubleClickSelectsAll but these do not seem to have any effect.

Expected results:

It should be possible to copy the urlbar to the X primary selection using something simpler than a triple click. The preferences mentioned above should work.
(Then I would set browser.urlbar.doubleClickSelectsAll and double click in order to copy. This is what has worked for many years.)

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

Component: Untriaged → Address Bar
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

(In reply to aeb from comment #0)

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

Steps to reproduce:

Copying a url from the urlbar to an xterm has become much more difficult.
I click once on the url. The entire urlbar turns blue, but is not copied to the X primary selection. Further clicks make the blue color disappear, but still nothing is copied.
A double click selects a single word and copies that to the X primary selection.
(That is not something one often wants: copying part of a url.) Finally a triple click does what I needed and copies the entire url. Being an old man, triple clicking is not easy for me. The past fifty years I have not needed triple clicks, and today this is the only place in my computer usage where it is needed.

Actual results:

The results are as stated already: single click turns the url blue but does not copy, double click copies a single word, triple click copies the url.
I tried with the four possible combinations true/false of browser.urlbar.clickSelectsAll and browser.urlbar.doubleClickSelectsAll but these do not seem to have any effect.

Expected results:

It should be possible to copy the urlbar to the X primary selection using something simpler than a triple click. The preferences mentioned above should work.
(Then I would set browser.urlbar.doubleClickSelectsAll and double click in order to copy. This is what has worked for many years.)

Tripple clicking is easy, if you have a proper mouse probably. Furthermore, the preferred method to select a whole line is by using the keyboard shutcut ctrl+l. Even an old man should be able to remember that.

(In reply to w_m0zart@mozilla from comment #3)

Tripple clicking is easy, if you have a proper mouse probably. Furthermore, the preferred method to select a whole line is by using the keyboard shutcut ctrl+l. Even an old man should be able to remember that.

Friendly reminder to keep a civil tone
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

(In reply to w_m0zart@mozilla from comment #3)

About the ease of triple clicking: you will understand in due time, maybe fifty or sixty years from now.
About ctrl+L: that does not work. It turns the urlbar blue, a nice color, just like single clicking does.
But it does not copy the url to the X primary selection, so ctrl+L does not help me.

Yes, it is pretty much impossible to efficiently copy the url to the primary selection clipboard using the keyboard. What works, is putting the cursor on one side, hold shift and go the the other side (using home/end) to select the URL.

Bug 1633203 covers the case of selecting an already selected address bar to populate primary clipboard.

I am not quite sure what you want to tell me. That there is a different regression, somewhat similar, where clipboard.autocopy does not work?

X is a messy beast, and selection under X is a messy topic. My understanding today:

  1. There are eight cut buffers named CUT_BUFFER0 .. CUT_BUFFER7.
    The contents is shown by the program xcb.
    These cut buffers belong to the root window and are long-lived.
  2. There are two or more selections named PRIMARY, SECONDARY, ...
    The contents is shown by the program xsel.
    The selections are short-lived, overwritten as soon as something else is selected.
    The selection disappears as soon as the owner of the window with the selected text exits.
  3. There is a selection named CLIPBOARD.
    The contents is shown by the program xsel.
    The clipboard is long-lived.

Old fashioned command-line work is done in an xterm window. What one selects in an xterm window goes both to CUT_BUFFER0 and to the primary selection. What one pastes is taken from the primary selection if there was something there, and from CUT_BUFFER0 otherwise.

You knew all this, I suppose. I hope it is precisely correct. In this usual X terminology there is no "primary clipboard",
there is a primary selection, and there is a clipboard, and these have different properties.
The preference clipboard.autocopy is documented to act on the clipboard. The present regression report is about the fact that double click no longer copies to the primary selection, and, more importantly, that there seems to be no convenient way at all to do this very common operation.

I'm sorry I meant primary selection clipboard

OK, so you agree that Bug 1633203 is unrelated.

nope, that is what eventually will be fixed if someone provides a patch. with that fixed CTRL+L or CTRL+A will put the text in the primary selection clipboard.

Then I must reiterate. There is no "primary selection clipboard". There is a "primary selection" and there is a "clipboard" and they are not the same.

name it as you wish, according to https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt:
"X has a thing called "selections" which are just clipboards,
essentially (implemented with an asynchronous protocol so you don't
actually copy data to them). There are three standard selections
defined in the ICCCM: PRIMARY, SECONDARY, and CLIPBOARD."

Now I'd prefer to stop the bikeshed coloring, and back to the topic, when the user selects explicitely we set primary selection, when Firefox sets the selection programmatically we don't.
CTRL+L makes Firefox set the selection programmatically, a further CTRL+A or CTRL+L could set the primary selection, but that doesn't work, and that's what Bug 1633203 may fix.
Triple click is still the best option for now.

The discussion is not about the name but about the fact that there are two distinct things (and life is least confusing if one uses the traditional names). Bug 1633203 is about the clipboard, but the present bug is not about the clipboard, it is about the primary selection. The link you provide talks the truth, and shows PRIMARY and CLIPBOARD as separate selections. If you copy something to the primary selection it is not yet in the clipboard. If you copy something to the clipboard it is not yet in the primary selection.
That is why I said that Bug 1633203 is unrelated.

Bug 1633203 is only about primary selection.

Aha. It is about the preference clipboard.autocopy. The documentation says "Automatically copy contents of selections to the clipboard", and that suggests XA_CLIPBOARD, but maybe it really is XA_PRIMARY. OK.

You need to log in before you can comment on or make changes to this bug.