Page MenuHomePhabricator

Paste Check not showing in pre-save
Open, Needs TriagePublic

Description

Meta

  • Platform: desktop and mobile
  • Browser: Chrome
  • OS: Mac / iOS

Behavior

  1. Visit https://en.wikipedia.beta.wmcloud.org/w/index.php?veaction=edit&ecenable=2&title=Fox
  2. Paste ≥50 characters of text from an "unknown" source
  3. Notice Paste Check appears
  4. Tap Publish Changes
✅ Expected
  1. Paste Check appears again in the "Pre-save" moment
❗️Actual
  1. Paste Check does NOT appear in the "Pre-save" moment

Event Timeline

I thought we'd deliberately decided not to do this? I recall the logic being that because we're forcing you to see the paste check as soon as it happens, someone who had chosen to ignore it at that point shouldn't be bothered with it again.

I thought we'd deliberately decided not to do this?

I don't recall this. If there is a link/place where you can recall such a choice, please let me know.

I recall the logic being that because we're forcing you to see the paste check as soon as it happens, someone who had chosen to ignore it at that point shouldn't be bothered with it again.

This logic doesn't accord with what I've understood us as coming to think is the best outcome for the wikis and the person making the edit (see "outcomes below").

Outcomes
We think that Paste Check will decrease the likelihood of the following:

  1. Newcomers acting in good faith seeing the edits they made reverted because they've unknowingly/mistakenly published an edit which contains content they do not have the necessary license to publish on-wiki
  2. Wiki containing content that does not accord with the content license required

I don't recall this. If there is a link/place where you can recall such a choice, please let me know.

Sorry, no, it's a general recollection of discussion in meetings.

This logic doesn't accord with what I've understood us as coming to think is the best outcome for the wikis and the person making the edit (see "outcomes below").

Similar logic to what we're employing with Tone, though, where once someone has interacted with it mid-edit we stop it from showing up in pre-save.

I don't recall this. If there is a link/place where you can recall such a choice, please let me know.

Sorry, no, it's a general recollection of discussion in meetings.

Gotcha. Makes sense.

This logic doesn't accord with what I've understood us as coming to think is the best outcome for the wikis and the person making the edit (see "outcomes below").

Similar logic to what we're employing with Tone, though, where once someone has interacted with it mid-edit we stop it from showing up in pre-save.

What do you mean by "...someone has interacted with it mid-edit..." in this context?

Reason I ask: at present, Paste Check seems to behaving in a way that is inconsistent with how Tone Check behaves...

  1. Paste Check: If you paste text into the editor that causes Paste Check to activate and proceed to tapping Publish without having interacted with the Paste Check card at all (read: you do NOT tap Yes, keep it or No, remove it) Paste Check is NOT shown in the Pre-Save moment. This is the behavior/case reflected in the task description, as currently written.
  2. Tone Check: If you enter text into the editor that causes Tone Check activate and proceed to tapping Publish without having interacted with the Tone Check card at all (read: you do NOT tap Revise or Decline) Tone Check is re-shown in the Pre-Save moment.

Can we please make it so Paste Check behaves as Tone Check currently behaves (described in "2." above)? [i]


i. Of course, if there is some context/nuance I'm misunderstanding/missing here that you think gives you pause about doing the above, I hope you will say as much!

What do you mean by "...someone has interacted with it mid-edit..." in this context?

I was thinking specifically of the mobile experience, where the user will have had Paste forcibly opened up and shown to them unlike other checks. It’s admittedly more similar to the normal experience on desktop.

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

[mediawiki/extensions/VisualEditor@master] Paste check: show in pre-save as well

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

Change #1200115 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Paste check: show in pre-save as well

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

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

[mediawiki/extensions/VisualEditor@master] Edit check: use takesFocus as a factor in check-sorting

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

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

[mediawiki/extensions/VisualEditor@master] Paste check: behave better in pre-save by not selecting text

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

Change #1200164 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Edit check: use takesFocus as a factor in check-sorting

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

Change #1200172 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Paste check: behave better in pre-save by exiting pre-save when deleting

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

Ryasmeen subscribed.

The behavior has been now changed, testing notes has been updated to reflect the change that Paste Check will now appear in Pre-Save mode.

However, it seems the behavior of tone check has also been changed. Unlike before when once someone has interacted with the tone check mid-edit, it was not showing up in pre-save mode, now it does. (note: "user interaction" was defined by David Lynch as "even just clicking on the check dialog", to avoid repeated activation, per my previous conversation with him on slack). @DLynch : Please confirm if this change with Tone Check is intentional.

Both the checks are now behaving similarly regardless of user interaction in mid-edit.

@Ryasmeen Sorry, I must have misspoken there -- you need to have clicked a button in the check dialog to make it be considered "interacted". That said, there's also a bug where that's not being respected, and I'll get that fixed in a second.

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

[mediawiki/extensions/VisualEditor@master] Paste check: don't show pre-save after all

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

This is getting kicked back for more work after issues turned up.

To summarize: paste check lets you choose to remove content, but it only removes the actual pasted content. This will often only be a part of what the user added, and will leave behind whitespace or other surrounding content that'd make for a messy edit. As such, we need to either work out a way to clean up that content (difficult!) or send the user back to normal edit mode (like Tone).

The patch to send the user back has already been merged, but might require more work before we can turn on paste-check pre-save -- as-is it's potentially confusing, since it deletes the pasted content and silently drops the user back where it was, with the "now fix all this so you're comfortable publishing it" being heavily implied but unstated...

(Think about the case where the user has written Shakespeare said "The fault, dear Brutus, is not in our stars, but in ourselves". The only bit that would be removed by the paste check would be the contents of the quotation marks that they copied in, and suggesting that they publish with just Shakespeare said "" seems unwise.)

Change #1200195 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Paste check: don't show pre-save after all

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

The patch to send the user back has already been merged, but might require more work before we can turn on paste-check pre-save -- as-is it's potentially confusing, since it deletes the pasted content and silently drops the user back where it was, with the "now fix all this so you're comfortable publishing it" being heavily implied but unstated...

Per what @DLynch and I converged on offline, as currently implemented, when someone taps No, remove it from within the pre-save moment, they will arrive back into mid-edit moment with the content they pasted removed and without insufficient context about where they are and what they're meant to do next.

As such, we're going to pause any further work on this task for now. We'll revisit the priority of this task by way of T400098#11330285.

@Ryasmeen Sorry, I must have misspoken there -- you need to have clicked a button in the check dialog to make it be considered "interacted".

@DLynch : Ah Understood, I updated that as well as expected behavior for tone check that clicking on Revise button on both the mid edit tone check dialog and the pre-save tone check dialog will be considered as a "user interaction" and therefore the tone check won't be shown again in pre-save.

That said, there's also a bug where that's not being respected, and I'll get that fixed in a second.

Yeah, for me when I was testing this fix, I saw that clicking on Revise on mid-edit was not enough and the tone check was still appearing on pre-save. It is fixed now. Thanks!