Page MenuHomePhabricator

VisualEditor warning about blocked external link can be skipped too easily (even accidentally)
Open, Needs TriagePublic

Description

VisualEditor warning about blocked external link ("People at this wiki decided to block links to this site. Please try another link.") can be skipped too easily (even accidentally), in at least two ways.

Steps to reproduce:

  1. Edit any page, e.g. https://en.wikipedia.org/w/index.php?title=The_Fighting_Temeraire&veaction=edit
  2. Click the link icon or press Ctrl+K
  3. Paste an external link that is blocked, for example: https://youtu.be/dQw4w9WgXcQ

Issue 1: The server-side check takes a good fraction of a second. You can click "Insert" before the check completes and disables it. On second thought, this behavior is better than waiting for the response.

Issue 2: Even when the "Insert" button is disabled, you can still press Enter on your keyboard to insert the link.

Please note, I understand that the feature isn't meant to be "secure" and prevent those links from being added, it's just intended to helpfully show the warning early before you go through the whole edit. But due to these issues it's easy to miss the warning by accident.

Story

@ppelberg to populate

Proposed UX

In cases when people manage to insert a URL that's blocked into the document, the following will happen:

  1. As soon as visual editor receives a response from the API indicating that the link someone has added is present on a community-maintained block list, said link will be highlighted using the component we defined in T365660.
    • Purpose: inspire people to revisit the link they just added.
  2. Upon tapping the now-highlighted link, show people an Edit Check card the using the component we also defined in T365660.
    • Said card would offer people two options Remove or Replace the link that the project they're contributing to has deemed spam.
  3. If someone does not choose to engage with the link that will have become highlighted in "2." before advancing "onward" to the publishing flow, we'll present them with the Edit Check card step "2." above refers to. Although, this version of the card will contain a single option Remove.

Meta: the Editing Team recognizes that the above amounts to a non-trivial investment to improve, what we assume to be, an edge case. However, the Editing Team is viewing the above as an opportunity to quickly learn the extent to which the design patterns it depends on will scale in the ways we've intended it to.//

Event Timeline

For issue 1, my logic here is that blocked links are (probably) going to be a very uncommon case, so it's better to not have a mandatory second-ish pause every time you edit a link, and the case where someone misses noticing it because they're acting quickly is the same reject-on-save behavior we've been happy enough with for years. That said, perhaps a sensible fallback would be to hook it into the context for the link, since that'll still be showing once you leave the inspector...

For issue 2, interesting that the submit-on-enter behavior isn't checking whether the action is disabled. I'll look into whether that's widespread, or whether I'm disabling the action in the wrong way somehow.

  1. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

Change #1048831 had a related patch set uploaded (by Esanders; author: Esanders):

[oojs/ui@master] Dialog: Check if an action is disabled in the UI before executing

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

(executeAction is called directly quite rarely, so I doubt we would have a problem with the above breaking change: https://codesearch.wmcloud.org/search/?q=executeAction%5C%28&files=&excludeFiles=&repos=#Extension:VisualEditor)

Change #1048831 merged by jenkins-bot:

[oojs/ui@master] Dialog: Check if an action is disabled in the UI before executing

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

For issue 1, my logic here is that blocked links are (probably) going to be a very uncommon case, so it's better to not have a mandatory second-ish pause every time you edit a link, and the case where someone misses noticing it because they're acting quickly is the same reject-on-save behavior we've been happy enough with for years. That said, perhaps a sensible fallback would be to hook it into the context for the link, since that'll still be showing once you leave the inspector...

Yeah, on second thought, you're right. And I agree it'd be nice to show it in the context too. That would also help in the case when an external link is pasted directly into the editing surface.


  1. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

There is at least one place in VE where we actually allowed executing an action while its button is disabled, and it's in the same inspector:

After the patch, there remains one case where "Enter" will have an effect while the "Done" button is disabled: if the textfield is empty, pressing Enter will remove the link. This is intentional.

Maybe it's okay to change it though. It fails in a weird way with this OOUI patch:

image.png (445×881 px, 42 KB)

... perhaps a sensible fallback would be to hook it into the context for the link, since that'll still be showing once you leave the inspector...

Building on the idea David shared above, during today's team meeting we converged on exploring the user experience documented below, as well is in the task description...

Proposed UX

In cases when people manage to insert a URL that's blocked into the document, the following will happen:

  1. As soon as visual editor receives a response from the API indicating that the link someone has added is present on a community-maintained block list, said link will be highlighted using the component we defined in T365660.
    • Purpose: inspire people to revisit the link they just added.
  2. Upon tapping the now-highlighted link, show people an Edit Check card the using the component we also defined in T365660.
    • Said card would offer people two options Remove or Replace the link that the project they're contributing to has deemed spam.
  3. If someone does not choose to engage with the link that will have become highlighted in "2." before advancing "onward" to the publishing flow, we'll present them with the Edit Check card step "2." above refers to. Although, this version of the card will contain a single option Remove.

Meta: the Editing Team recognizes that the above amounts to a non-trivial investment to improve, what we assume to be, an edge case. However, the Editing Team is viewing the above as an opportunity to quickly learn the extent to which the design patterns it depends on will scale in the ways we've intended it to.//

  1. We could fix this at the OOUI level, checking if there are visible actions, and if those actions are disabled. It would technically be a breaking change, although I don't know how likely it is that someone has deliberately programmatically triggered an action that is disabled in the UI. One could add an override to allow it to go through, or have it skip the UI check by default.

It would technically be a breaking change

(Well it was one, Convenient-Discussions's screenshot upload functionality built upon mw.Upload.Dialog executes the save action right after upload action if all input fields are autofilled. The primary action stays disabled so that the user doesn't decide an action is required from them.)

image.png (749×566 px, 59 KB)
image.png (749×564 px, 70 KB)