UX: pasting links on a selection will apply a link format (PR #15010)

One handy way of adding a link is by copying a link url and pasting it into a text selection. This has been in use as a way of adding links in WordPress for quite some time.

If there isn’t a text selection, or the copied item is not a link we should see default paste behavior.

Changes in this PR implement the idea in Discourse as discussed in Idea: Paste links in the editor - ux - Discourse Meta

Testing Instructions

  • No regressions for paste behavior in d-editor
  • Verify that the new qunit tests make sense. In order to fully test paste events, we may need to switch these to integration tests, but let me know if folks have preferences.

GitHub

Let me know if folks have a preferred way of testing for links in Discourse. Generally it’s link-like enough if the URL constructor is able to parse the string.

https://url.spec.whatwg.org/#valid-url-string

This pull request has been mentioned on Discourse Meta. There might be relevant details there:

This seems good to me, but I do wonder if we will end up linking things that are not links, and if that will be more of a nuissance than the thing the auto linking solves?

I do wonder if we will end up linking things that are not links

In practice, I haven’t seen a major report like this yet for folks using the block or classic editor in WordPress. We do get small issues from time to time, but they tend to be minor inconveniences.

That said, I browsed around the codebase some more and it does look like discourse-markdown uses GitHub - markdown-it/linkify-it: Links recognition library with full unicode support to test links. If we’d like this pasting behavior, ideally we can match the rules here. I’ll take a look to see if it’s accessible to d-editor.

Example of a cooked link in preview:

Another option might be to limit this to a site or user setting to toggle the behavior.

I sketched out an approach in 5a9cf8d where we reuse the linkify rules. Not sure if I like using library implementation details in this way, but I do feel like the overall behavior is much improved. One alternative might be using linkify directly versus off of the PrettyText instance.

I’ll add some example tests/videos tomorrow, but let me know if you had feedback/questions ahead of time.

This is looking better. Strangely there is a test failure now for Ember CLI. Any ideas?

This is looking better. Strangely there is a test failure now for Ember CLI. Any ideas?

Thanks for taking another look. If this isn’t a flakey test, the new init in the mixin could have affected timing for some tests. I’ll try a few things.

So far this is green locally for me, but it’s not uncommon to have CI be a bit more sensitive to timing issues.

For future me I verified this locally by:

  1. Running the full suite from the app/assets/javascripts folder can check results via ~/checkouts/discourse/app/assets/javascripts/node_modules/.bin/ember test --launch Chrome.
  2. Running a single test: ~/checkouts/discourse/app/assets/javascripts/node_modules/.bin/ember test --launch Chrome --filter "Integration | Component | d-editor: bold with a multiline selection"
  3. Also via ./bin/rake qunit:test from the root checkout directory.

@eviltrout I think the multiline test is flakey, if we visit Actions · discourse/discourse · GitHub and spot check a few items, it’s also failing in other branches. For example:

Thanks! I’ve merged it. Let’s give it a try.

Nice! Thanks for the review @eviltrout!