Thanks for filing this! I think that, especially on mobile, having this menu item in the overflow menu will be more intuitive than tapping on a timestamp. (If we're curious about it, we could also emit an event in Prometheus for taps to the timestamp vs taps to the menu item in the overflow menu to understand this better.)

Adding this to next sprint with the assumption that adding this is relatively lightweight/straightforward.

Change #1278593 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Add "copy link" to the overflow menu

https://gerrit.wikimedia.org/r/1278593

Note that since this is an unconditional item added to the overflow menu it will now be present on all comments. It was already present on all comments that weren't your own comment because of Thanks.

In T418197#11868701, @DLynch wrote:

Note that since this is an unconditional item added to the overflow menu it will now be present on all comments. It was already present on all comments that weren't your own comment because of Thanks.

@DLynch: to confirm the "it" bolded above refers to the overflow menu? Something else?

Yes, the overflow menu ellipsis button.

In T418197#11868730, @DLynch wrote:

Yes, the overflow menu ellipsis button.

Got it. So, as a result of this change, the ellipsis/overflow menu will now appear on all talk page comments. Previously, it had only been shown on comment you did NOT write.

Assuming that's accurate. Sounds great to me. Thank you for naming this explicitly.

Yup!

It's way less of a change than us releasing Thanks was.

In T18691 folks are working on adding a similar feature as another link next to the [edit] link, but – notably – using the browser's "Share" API instead of only copying the link to clipboard. Thoughts on that? Should DiscussionTools's option do the same, or be different?

In T418197#11886303, @matmarex wrote:

Should DiscussionTools's option do the same, or be different?

The other parts of DT copying don’t use share API so probably best not to use it here, either. Especially since right now it allows to quickly copy something while share API is a bit more intrusive to editor experience (at least I found it so while testing in Firefox), and doesn’t actually allow to copy Unicode as Unicode in all contexts (definitely not on Windows 10 where I tested).

Honestly, it would’ve been better if there was some centralised MW JS share module that showed a small extendable dialog window with two options, one for wikitext and one for URL, with web share only being a secondary option available via a button. Then both that feature and DT could use it consistently. Personally I find that Convenient-Discussions has too many options for linking (there’s 5 there: wiki link, wiki link from the same page, permanent wiki link, normal URL, permanent URL) but DT has too little, whereas editors would definitely benefit from having easier access to copying wikitext link syntax.

editors would definitely benefit from having easier access to copying wikitext link syntax.

honestly I think that all MediaWiki inputs that deal with wikilinks (WikiEditor, title inputs) should just auto-convert inserted URLs to wikilinks the way CD does (here, https://en.wiktionary.org/wiki/cause is pasted): (It's Ctrl+Z'able)

Yeah, just tested share API at https://6e9260483c.catalyst.wmcloud.org/wiki/Алан_Тьюринг with Firefox for Android and it also only copies URLs encoded. I think that’s a definite ‘no’ for anything aimed at the editors (and honestly why I might end up switching experimental flag off on desktop once T18691 hits the production).

In T418197#11886303, @matmarex wrote:

using the browser's "Share" API instead of only copying the link to clipboard

Definitely not instead of. Share API support varies a lot across OSs, with no support at all on Linux, and according to the table, no support in browsers other than Safari (and maybe Firefox?) on macOS. These users should have a fallback, and hopefully not the one T18691: RFC: Section header "share" link does, which simply overwrites the cupboard content without asking. (As a user jumping across devices, I find this automated fallback pretty annoying.)

no support in browsers other than Safari (and maybe Firefox?) on macOS

It's supported fine in Chrome on macOS. I think Chrome+Safari on macOS gets us to something like 95% of requests from that OS, as I recall. There should absolutely be a fallback for Firefox, of course.

which simply overwrites the cupboard content without asking

I find the combination of "navigate the page to the permalink-anchor" plus "dump it into the clipboard" to be pretty good, honestly. If you know about the clipboard, it's already there for you (and clipboard managers are now standard -- built in to macOS and Windows -- so concerns about overwriting the existing contents are reduced, though not eliminated). If you don't, sharing the page normally will work. And it's a standard link, so right-click copy will work as well.

Change #1278593 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Add "copy link" to the overflow menu

https://gerrit.wikimedia.org/r/1278593

Looks good to me. It's worth noting that the mobile experience has a scroll to view and expanded accordion flow.

Non-blocking comment: Did we decide to go with a plain toast? The comment action toast commes with a ✅ icon, some green to show success. However, I wanted alignment on looks and feel.

Context: this is the same toast that's triggered by clicking the timestamp, so this was a long-ago behavioral decision. It could be revisited if we want.