double clicking on a URL drops the protocol from the URL

The double click behavior doesn't care about URLs at all. It considers certain characters as part of a word, certain others are not. There were many debates specifically around whether ':' should be a word character or not by default.

Unfortunately the setting is not available on the UI; see https://bugzilla.gnome.org/show_bug.cgi?id=730632#c33 for how to set this hidden value.

Status changed to 'Confirmed' because the bug affects multiple users.

This is a quite annoying bug for gnome-terminal users. I strongly suggest Ubuntu distro patches so that highlighting URLs works again. If this can't be done in time, we should have a release note with instructions on how users can fix it themselves.

FYI, here is the workaround that I am using:
$ dconf list /org/gnome/terminal/legacy/profiles:/
list
:b1dcc9dd-5262-4d8d-a863-c897e6d979b9/
:23d982d2-b22d-4b6d-8e60-ccebbc4e9afe/
:43f0a757-4fdc-4ea4-b5e4-28fa01733089/

I happen to know by looking at dconf-editor that ':b1dcc9dd-5262-4d8d-a863-c897e6d979b9/' is the one I care about, so:

$ dconf write /org/gnome/terminal/legacy/profiles:/:b1dcc9dd-5262-4d8d-a863-c897e6d979b9/word-char-exceptions '@ms "-,.;:/?%&#_=+@~·"'

To remove this key and get back to current Ubuntu defaults:
$ dconf reset /org/gnome/terminal/legacy/profiles:/:b1dcc9dd-5262-4d8d-a863-c897e6d979b9/word-char-exceptions

Double click is not meant to select a URL (there's an option in the right click menu for that), and adding colon to the list of word-chars won't fix it either. E.g. if you have a URL with a trailing dot (which strictly speaking could be a part of the URL, but usually denotes the end of a sentence) then double click will select that, whereas Ctrl+click or Right click -> copy URL won't consider that to be part of the URL.

Quite ugly "bug" :( I had the habit "since ages" (ehhh) to work in terminal windows, and copy&paste URLs etc. It worked nicely with a quick double click on the URL which does not work anymore after upgrade to Wily :( I understand that it was not meant to select URLs anyway (and not a perfect solution either), but in practice it worked reasonably well. I've just wanted to write a bug report about this, however launchpad was intelligent enough to find me a similar already existing bug report, this one ;)

This bug is annoying since it make the whole process of copy/paste an url to a specific browser heavier. Futhermore, by default URL without specified scheme will be opened as file:/// on most browser.

Not sure whether this is a bug, but I liked the previous behavior.

Though I didn't know that there was a "Copy Link Address" feature in the right-click menu, will just get used to that, thanks Egmont.

Dupe of bug 1463072.

FYI, this is still an issue on 16.04. The technique in comment #4 continues to work.

I "love" how much people still complain and fail to understand the previous comments...

So let me try it once again...

Double clicking, by design, is _not_ meant to select URLs.

Double clicking selects a continuous sequence of certain (configurable) characters, and it has do be able to do this even when you double click outside of a URL.

At one point this configurability was removed, but due to popular demand (that is: plenty of complaints) it was brought back in the very next version (alas as a hidden setting, without a UI).

There were many debates around what the default set of such characters should be, and the reason it is configurable is because there's no single right answer, it's a matter of taste, or rather, a matter of use cases. The only clear conclusion was that generally it's better to have fewer characters in the set rather than more, that is, double clicking should rather select shorter segments than long ones. This is because if it selects a shorter section than desired, it is still easy to double-click and then drag the mouse to extend it by other sections, whereas the other way around this cannot be done.

This was the reason behind the removal of ":" from the default set, and continuing this trend if we were to change anything, it would much rather be the removal of "/" too rather than adding ":" back.

If we removed "/" too, it would mean that double clicking on a URL would highlight even much shorter parts of it: either the hostname only, or one path component only. Would you still complain then that it's broken, or would it be more obvious to you and easier for you to accept that double clicking is not designed for selecting a URL?

As stated above, if you add ":" to the set (which you can do easily), it would still not perfectly select URLs, there would be differences ("bugs" if you will). Double clicking behavior is very simple: certain characters are selected, while the rest are not, without looking at the larger picture. URLs, on the other hand, are waaaay more complex to detect. See https://git.gnome.org/browse/gnome-terminal/tree/src/terminal-regex.h?h=gnome-3-22 to get an idea how crazily heavily complex the regular expressions are, and it's still not perfect (it's not even possible to get it perfect since it's not defined anywhere how to detect the boundaries of a URL in a text flow), but is quite good.

Theoretically the code could be changed to select based on characters when double clicking outside a URL, and the entire URL when clicking inside. But this dual behavior would be even more confusing (i.e. broken). Then the currently available and luckily configurable set of word characters would be ignored within URLs (and what if let's say you actually wanted to easily highlight parts of the URL and hence you removed "/" from wordchars? you'd find that it doesn't work) whereas you'd get another way of copying the URL for which you already have one method.

Also, beginning with Yakkety gnome-terminal recognizes numbers, and even though (as opposed to URLs) it doesn't highlight them on mouseover, it provides useful information on a right click. So then should this one also modify the double click behavior to s...

Egmont Koblinger <email address hidden> writes:

> Double clicking, by design, is _not_ meant to select URLs.

Really? Which design is that?

And regardless of whether or not double click is meant to select URLs,
it's a literal fact that it did in fact (largely) select URLs for many
years.

> So, guys, there's nothing to see here. Please move on.

You're obviously welcome to your opinion, but it's a little strange to
end 77 lines and 705 words with the claim that there is "nothing to
see here" and a request to "move on".

> This bug should be closed as invalid.

That's your opinion; in my opinion this is a regression in Ubuntu.

--
James

If you want an apple, as for an apple. If you want a pear, ask for a pear. What you do is you want a pear, yet you ask for an apple and expect to receive the kind of apple that tastes as close to pear as possible. And even though you can configure the kind of the apple you'll receive, it's still not good enough for you, you wish that Ubuntu by default configures to deliver your favorite kind of apple, the one that tastes the closest to pears. You keep ignoring that you could actually ask for a pear if that's what you want, or that the default kind of apple was decided by those who actually want an apple apple, not a pear-ish apple.

(In case it's not clear: apple = select a word; kind of apple = the configured characters that should be considered part of a word; pear = select a URL.)

> > Double clicking, by design, is _not_ meant to select URLs.

> Really? Which design is that?

I've checked the behavior of the following apps for you: Terminal emulators: Linux console + gpm, xterm, urxvt, konsole, st, pterm, terminology, mlterm; browsers: Firefox, Chrome and Opera, and in each of them a non-hyperlinked URL as part of a rendered page, a simple textarea, as well as Gmail's compose window; other apps: LibreOffice Writer (hyperlink removed), gedit.

Guess what: Out of these urxvt is the only one that selects URLs on double click. Plus xterm and konsole are the ones that work as gnome-terminal used to work (including the bugs you're aware of: due to only looking at the characters individually, quite often they don't correctly recognize URLs because they simply don't care about URLs when you double click). All the other apps select a shorter segment of the URL.

So you ask what design it is... well, it is the design of most of the apps out there.

You're perfectly aware that what gnome-terminal used to do was far from perfect, it made mistakes many times. Example: Let's take a URL with a trailing dot, such as this sentence: "For details see http://example.com/whatever.html." Hover underlining does exclude the trailing dot, and similarly the right-click menu's Open/Copy Link actions exclude it too. It was never possible to do the same with double clicking. Either the dot character is included in the set of word characters, in which case the trailing dot is included, or it is excluded from the set, in which case double clicking also stops the selection at the middle of the domain name, or before the extension.

Apart from urxvt, I don't think any terminal emulators implement a more sophisticated algorithm for double clicking, and with their current approach (looking at characters individually) it is just not possible to make it right.

gnome-terminal/vte has never implemented anything more sophisticated either, and has no such bug entry and I can't recall any TODO about it either. If it was ever agreed that double clicking should recognize and highlight URLs, I'm absolutely certain there would be a bug entry about it, or it would already be implemented. This is a clear proof that double clicking was never meant to select URLs. This is not my personal opinion, this is a fact. Double clicking is meant to aid conveniently select logical parts of any re...

For me selecting a link using double click is faster than using the right-click context menu (overall don't like menus as I can't use them quickly). To me that's a regression (I can't select URLs as fast as I used to), but that doesn't mean that bringing back the old double-click behavior is the right fix.

Is it feasible that a single-click shortcut that could be used for this context-menu option? For me something like ctrl+click or shift+click on a URL instead of using the right-click menu would be acceptable (and probably preferrable to my original double-click + ctrl+shift+c workflow as it's fewer actions / faster).

Ctrl+click opens the URL in your preferred browser.

Do you often need to copy the URL into your clipboard instead? I guess Ctrl+Shift+click could be made to do that, sounds reasonable to me (although will be a hard to discover feature).

Could you please file a feature request at bugzilla.gnome.org to keep track of this (and also hear the main maintainer's opinion)?

Thanks, filed: https://bugzilla.gnome.org/show_bug.cgi?id=786935

Must say that like many others I had the habit of double clicking a URL in order to copy it - a task which I repeatedly do in my work as to paste the URL in a text editor in order to track report URLs which I'm spawning via the terminal.
It seems to me that the fact that many users relied on this "accidental" feature, should cause a change in mind and make it an actual feature.