1905508 - Feature request: Provide “Copy link” option in context menu of HTML heading elements with ID attributes

Status: REOPENED

(Firefox :: Menus, enhancement)

Description

[Šime Vidas]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

When a heading element on a web page has an ID attribute

<h2 id="Community">Community</h2>

then it is possible to link to that heading

https://example.com/some-page#Community

It would be useful if Firefox allowed users to copy that link. Imagine if the user right-clicked such a heading, and Firefox provided a “Copy link” or “Copy link to heading” option in the context menu.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[atjn]

Attachment: Bug 1905508 - Provide "copy link" option in context menu for HTML headings

Comment 3

[atjn]

I have made a prototype for it. I think it works well, would love to get your feedback on it :)

I plan on writing some tests for it soon.

Comment 4

[Šime Vidas]

this.contentWindow.HTMLHeadingElement.isInstance(elem)

In this code, is elem the event target of the click event, right? In that case, it’s possible that the user right-clicks a heading but elem does not refer to that heading. This can happen when the heading contains another element:

<h1 id=Community>
  <span>Community</span>
</h1>

The feature needs to work for such cases too. So there needs to be a check that looks for a heading element among the click event target’s ancestors.

Comment 5

[atjn]

(In reply to Šime Vidas from comment #4)

The feature needs to work for such cases too. So there needs to be a check that looks for a heading element among the click event target’s ancestors.

I agree, which is why it works exactly as you are describing. The check runs on the target of the click event, then recursively on all ancestors of the target.

See the while loop that encloses it:

while (elem) {

And the last command in that loop:

  elem = elem.flattenedTreeParentNode;
}

You can test it by going to https://lea.verou.me/blog/2024/css-conditionals-now/ and seeing that you can still copy a link to each subheading, even though you are right clicking on a link that is enclosed by a header.

Comment 6

[Šime Vidas]

You can test it

Sorry for my ignorance, but how can I test your draft? I only have Firefox Nightly.

Comment 7

[atjn]

Attachment: Menu showcase

Comment 8

[atjn]

(In reply to Šime Vidas from comment #6)

Sorry for my ignorance, but how can I test your draft? I only have Firefox Nightly.

You have to compile Firefox locally with my changes to test it. I just assumed you could do that, but no worries if not. I have attached a video called "Menu showcase" that shows how it works.

Comment 9

[atjn]

I have added some tests now and I believe the feature is ready to land. I am not sure who to tag for review, I hope someone will be assigned to this bug. If the feature is too big to "just land", maybe we could add it behind a preference, and turn it on by default in Nightly to get some user feedback?

One thing I would like to mention is that the feature theoretically could be extended to cover other elements with ID's. For example, the Firefox source docs does not add the ID to the heading, but instead a <section> element that wraps the heading and any content under the heading. In that case, it might be useful to provide a "Copy link to Section" option, and there could be a more generic "Copy link to Element" for things like <div>. But this opens up a million questions, e.g. what if a website author changes the ID on a div, expecting that this is an internal change only, but for some reason many users have copied links to that specific div ID.
I think that limiting this feature to headings is much safer and is easier for both website authors and users to understand. Then we could open a second bug to explore what other link methods would be good/bad to support.

Comment 10

[Mathew Hodson]

(In reply to atjn from comment #9)

I have added some tests now and I believe the feature is ready to land. I am not sure who to tag for review, I hope someone will be assigned to this bug.

I added a reviewers group for you on your patch so that they will see it in their queues.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The following patch is waiting for review from an inactive reviewer:

ID	Title	Author	Reviewer Status
D215730	Bug 1905508 - Provide "copy link" option in context menu for HTML headings	dev	cmkm: Back Sep 7, 2024

:dev, could you please find another reviewer?

For more information, please visit BugBot documentation.

Comment 12

[atjn]

@flod is there someone else that can review this, or should I just ignore the BugBot and wait for @cmkm to review?

Comment 13

[Francesco Lodolo [:flod]]

You need to wait for the designed reviewer.

Comment 14

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

#c0

[e-mail], why restrict it to heading elements? Why not any visible tag with an archor?

Comment 15

[atjn]

:zn7esutb I addressed this in #c9.

Comment 16

[Chris Peterson [:cpeterson]]

This feature is a good idea, but I'm going to close this bug as a duplicate of bug 1779688 because that bug is implementing a more flexible approach ("Copy link to Highlight").

Comment 17

[atjn]

I strongly disagree with that evaluation. The "Copy link to Highlight" feature is very different. As you mentioned, it is more flexible, but that comes at the cost of being less reliable. These two features complement each other, they are not duplicates of each other.

Here are some examples to explain why I would always choose "Copy link to Heading" rather than "Copy link to Highlight" when possible:

1:
You want to link to a headline on a multilingual website. You send it to your friend who uses a different language in their browser:
"Copy link to Highlight": Fails because the text is in a different language.
"Copy link to Heading": Works because the ID is the same no matter what language is served.

2:
A website owner wants to update a heading to fix a spelling mistake or otherwise make it more accurate. The owner knows that ID's are used as links, so they do not change the ID. They also know that some people link directly to the text, but there is nothing to do about that, the mistake needs to be fixed.
"Copy link to Highlight": Fails because the text was changed.
"Copy link to Heading": Works because the ID is not changed.

3:
A user has copied a link to a heading. Unfortunately, the article uses the exact same phrase earlier in the text.
"Copy link to Highlight": Fails because it finds the first occurrence of the phrase.
"Copy link to Heading": Works because it is linking to the unique heading ID.

I can keep going if you want more examples.

If you ask me, these two features should be available alongside each other in the same option group. And as I have explained earlier, I also think that we could add even more similar features that have their own strengths and weaknesses.

I hope you will reopen this issue :)

Comment 18

[Chris Peterson [:cpeterson]]

I hadn't considered the multilingual website scenario. I see that "Copy link to Heading" is not a duplicate of "Copy link to Highlight". I will ask the UX designer. That said, if we implement "Copy link to Highlight", having both "Copy link to Highlight" and "Copy link to Heading" might overwhelm the context menu with:

• Copy Link
• Copy Link Without Site Tracking
• Copy Link to Highlight
• Copy Link to Highlight Without Site Tracking
• Copy Link to Heading
• Copy Link to Heading Without Site Tracking

Perhaps the "Copy link" menu item could try to be smart: if the highlighted text is an HTML element with an id, copy a URL with #anchor. Otherwise copy a #:~:text= fragment URL to the highlighted text. Though users might be confused if one menu item had two behaviors based on the HTML invisible to the user.

https://developer.mozilla.org/en-US/docs/Web/URI/Fragment/Text_fragments

Comment 19

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

having both "Copy link to Highlight" and "Copy link to Heading"

[e-mail], irrespective, that would be incorrect phrasal, for IDs can be attached to any element, not merely <h*> tags. It would need to be named "Copy link to ID" or something similar which communicates that the user is copying a link to a permanent identifier.

Comment 20

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

#c19

Additionally, I certainly wouldn't want the behaviour to change bases upon context (although I can predict that being useful for the technically incompetent).

The reason is that, frequently, a fragment directive shall be more stable if the content of the page is not expected to change, whilst the underlying generator is (because it may reassign IDs).

Comment 21

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

That said, if we implement "Copy link to Highlight", having both "Copy link to Highlight" and "Copy link to Heading" might overwhelm the context menu with:

• Copy Link
• Copy Link Without Site Tracking
• Copy Link to Highlight
• Copy Link to Highlight Without Site Tracking
• Copy Link to Heading
• Copy Link to Heading Without Site Tracking

Why is a "Copy Link" category submenu not acceptable for this – I estimate you've considered that? I ask because I already find how disorganised the current menu is to be rather unusual.

Comment 22

[atjn]

(In reply to Chris Peterson [:cpeterson] from comment #18)

That said, if we implement "Copy link to Highlight", having both "Copy link to Highlight" and "Copy link to Heading" might overwhelm the context menu with:

Sorry, I forgot to respond to this. I can understand your concern, I think there is a simple solution:

If the "Copy Link" and "Copy Link to Heading" links are identical, we remove the "Copy Link" option. It is confusing for the user to see both options at the same time, since that suggests that the options provide different links. We keep the most descriptive option (Copy Link to Heading), since it is useful for the user to know that the link they are copying is not just any link but actually a link to the specific header they right-clicked on.

If we do that, we can at most be showing two separate options*, which is the same amount as if you had highlighted something in any other link on the page. I think that is fine, and I don't think it is a good idea to try to merge the two options as they are very different and can't reliably replace each other.

*tiny note: You could still see all three options if the heading is wrapped in a link that does not link to the heading. This seems like such a niche case that we can just ignore it.