I think this is more like a Chrome FR. pkasting, can you please triage?

To step back a bit, what sorts of use cases lead to commonly want to copy link text?  I want to make sure we understand the problem before we implement or WontFix a solution.

By comparison, we don't have a "copy word" item when right-clicking a word, or the ability to copy a whole textfield by just right-clicking it.  Should we?  What makes links different in how people are trying to interact?  Is it simply that people want to copy all these equally, but since links can be clicked/dragged, selecting them is more difficult?

Also, happy to follow along here, but I shouldn't own this; if anything, this is more an interaction designer question.  +CC hwi.

>> we don't have a "copy word" item when right-clicking a word, or the ability to copy a whole textfield by just right-clicking it.

But you can double click on a word and then right click. You can't do that on a link because it would activate the link. Therefore, you are correct that it is just much more different to fulfill the same use case on a different item type.

Use cases include:

- Copying an email address (many pages would just open up the email client)
- Copying a domain (e.g. enterprise customers who deal with customers in email or CRM)
- Copying a phone number as reference (which, depending on available apps/extensions, may show up as a hyperlink)
- Something as simple as Googling something, getting a suggestion (e.g. due to typo), then wanting to copy the proper resulting term. These show up as hyperlinks too.

Also, to clarify, I believe this is mostly a Chrome OS issue, not browser issue. On a Mac, for example, right clicking things in Chrome already selects the full link text as I described. It is also one of the minor but annoying pain points of migrating to Chrome OS.

I verified that if I highlight a link and right-click, I have both a "Copy" and a "Copy link address" function.  It sounds to me like perhaps we should make win/cros behave more like Mac and auto-select links on context-click, maybe with some caveats (e.g. don't do this if the user is right-clicking on an existing selection).

Hmm...my suggestion is we show "Copy link text" in the context menu of a link text, for the reasoning on c4 (i.e. link text selection is not easy as word selection, and there're use cases).

The menu item, "Copy link text", already exists on Windows touchscreen, on longpress (i.e. selection) of a link text. Screen recording attached.

With the context menu on a link text, it seems unnecessary to copy the mac behavior(i.e. word or link selecting on right-click) since word selecting can be achieved easily with the existing gestures, dragging or double-clicking.

wdyt?

attachment for c7

Deleted: 2017-04-12_13-40-35.GIF 3.1 MB

	2017-04-12_13-40-35.GIF 3.1 MB View Download

Long-press feels like a context-click equivalent.  If we're showing this for long-press, let's just do it for right clicks.

However, this means if you select the link text, and then right click, you'll get both, unless we try to check "is the selection exactly the link text".  So we should be careful there.

BTW, selecting a link is not always easy (or doing that manually might be the solution to this bug) -- I've run into tons of cases recently where it's actually very hard to do this.

For more reasons why this should be implemented, see crbug/268114. Chrome for Android has it on long-click, Chrome for Mac has it on right-click, why doesn't Chrome for Linux have it?

 Issue 268114  has been merged into this issue.

Thinking about this more, I kind of like the "select a link on right-clicking it if there is no existing selection" idea better.  This allows for "Copy link text" transparently with the existing copy mechanism, and we don't need a special "Copy link text" link item.

Reading  bug 268114 , multiple different UX owners throughout the years have WontFixed adding "Copy link text", and when I came back to this bug today after a year my instinct was the same: this is a totally legit use case, it's just not frequent enough to justify the context menu item.  But with autoselection we can solve it while not adding the context menu item.  Then we can remove the special item from Mac/Android and get more platform coherency as well.

Windows, Linux and MacOS all offer "Copy" if you right-click on any selected text.

So if right-click on a link selects the link and also shows the context menu, and that context menu shows a Copy option (because there is selected text), that's already what Chrome/Mac does, and that's exactly what this issue is requesting.


It would be nice from a UX POV if the menu item said "Copy Link Text" (rather than just "Copy") to differentiate it from "Copy Link Address".

+markchang for desktop UI

re: c12 - the suggested change, *automatically* "select a link on right-clicking it if there is no existing selection", seems a usability improvement and a useful consistency across chrome. And the menu will already show 'Copy' along with 'Search Google, Print' (see screenshot) per the existing behavior. 

re: c13 - per the existing behavior, selecing text (including link text case) shows the menu group "Copy, Search Google, Print"(see screenshot), and there's a menu divider above 'Copy' and which helps differentiate between the menu groups. I suggest we keep this as-is without any special change to the menu label.

Deleted: selected link text context menu today 2018-03-02_09-45-25.png 151 KB

	selected link text context menu today 2018-03-02_09-45-25.png 151 KB View Download

re: c12 - if a user has selected text elsewhere, though, we have to make a decision:
1) override the selection and select the hyperlink text
2) do not override, show no "Copy" in the context menu
3) add a context menu item "Copy link text..."

#1 might violate user intention
#2 and #3 add a little inconsistency to this interaction

I, personally, am in favor of just adding "Copy link text..." (WIP) to the context menu on any right-click of a hyperlink to keep it simple.

@15: I think we should do (2).

We definitely can't do (1), that'd be really irritating.  I don't think we should do (3).  This is a rare enough case that I think users wanting to actually copy a link's text won't be impeded by (2).  If we did (3) we'd basically have to add that entry all the time, at which point there's no point in auto-selecting.

Currently, dismissing the context menu doesn't unselect the selection, so right-clicking on two links in succession (e.g. if links are close together, cf this bug report's CC list) would mean that the second link wouldn't get highlighted, and wouldn't have a "Copy" option. That seems likely to add extra frustration to misclicks.

If the auto-selecting idea works at all, then we'd want to do it any time the user doesn't have an explicit manual selection, so "previous selection was an unchanged autoselection" should qualify too.

I would argue against automatically selecting text, particularly if it's going to be inconsistent and unclear to the user why it sometimes works and sometimes not. "Copy Link Text" is very easy to understand.

Can you get usage data from Mac/Android Chrome on how much the link address/text copying is used?

I don't think the proposal will feel inconsistent, but I could be wrong.

I really don't want "Copy link text", though, and am looking for any possible way to avoid that.  There are inconsistencies that route as well, particularly duplication of functionality with "copy" when there is a selection.  This is a less-common case and I'd rather rip the menu item out on any platforms where it currently exists and not solve this, than add that item.  Which is the same thing multiple UX leads have said in the past.

There may be usage data for this menu item as it currently exists; I don't know.

Chrome on Mac platform nails this. Right clicking on a link highlights the link and provides context menu options for both normal "Copy" and "Copy link address". Both are important but I'd argue normal Copy is more important than "Copy link address" which we already show. 

Agree that it might not be completely necessary to highlight the link like is done other platforms, but I do think the highlight is nice to have so the user knows exactly what will be copied. I don't think anyone expects a highlight to be maintained if they click somewhere else- I really don't understand that argument.

I'd also argue "Copy" is better than "Copy link text" because Copy should copy with formatting (pasting it into a rich text editor should maintain the link). "Copy link text" almost implies it'll copy just the text itself (without formatting).

This small issue really hamper power users switching from Mac and I'd guess other platforms. It's my biggest issue with Pixelbook so far- trying to manually highlight link text is very frustrating and error prone.

That would be another option to address the concern in comment 17 (and partly comment 19) -- if auto-selecting text, clear the selection when the context menu closes.

FYI: There's currently something making it hard to Alt-drag from the start of a link, so the main workaround doesn't work well at all. I can alt-drag from inside or outside a link, but not from the very start. This doesn't happen on all links - in the comment header hear, the "Comment NN" link works, but the "user@site" link doesn't. With the Copy Link Text extension no longer working for me, it's getting quite frustrating to copy link text, which is something I do many times a day.

Agree with c21 -- if a user has a previous manual highlight, I don't think preserving that selection is expected upon right-clicking somewhere else.

My proposal is on right-click of a hyperlink, auto-select the text, thus triggering the existing text-copy context menu entries. Dismissing the context menu clears the selection.

Yeah, I think that's good enough.

Any progress on this? Since the CopyLinkText extension stopped working (at least corp-side), the need to manually select link texts is a daily aggravation.

It's not assigned, and it's P3, so no one on the team is likely to pick this up on their own.  If you know someone who'd be willing to contribute a patch, we can review.