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 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:
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.
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...
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
Change #1200115 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Paste check: show in pre-save as well
Test wiki created on Patch demo by PPelberg (WMF) using patch(es) linked to this task:
https://dbdd4b87f3.catalyst.wmcloud.org/wiki/Douglas Adams
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
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
Change #1200164 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Edit check: use takesFocus as a factor in check-sorting
Test wiki created on Patch demo by DLynch (WMF) using patch(es) linked to this task:
https://40935f0e13.catalyst.wmcloud.org/wiki/Douglas Adams
Change #1200172 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Paste check: behave better in pre-save by exiting pre-save when deleting
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
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
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.
@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!