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

[mediawiki/extensions/VisualEditor@master] Edit check: don't focus new checks automatically

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

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

[mediawiki/extensions/VisualEditor@master] Tone check: surface wasn't being focused on revise

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

Change #1178072 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Tone check: surface wasn't being focused on revise

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

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

[mediawiki/extensions/VisualEditor@master] Tone check: stop "revise" from undoing itself immediately

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

Change #1178607 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Tone check: stop "revise" from undoing itself immediately

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

Change #1178052 abandoned by DLynch:

[mediawiki/extensions/VisualEditor@master] Edit check: don't focus new checks automatically

Reason:

We're going with the stack ending in Iaf3a52babf639d3f9bc47f3c1c958df374b15fb7 instead.

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

Tested this here: https://en.wikipedia.beta.wmcloud.org/wiki/Polar_bear?ecenable=2&veaction=edit

Here is what I am seeing:

1. I wrote something tone-violating.
2. I moved the caret out of the paragraph, which triggered the tone check.
3. The tone check pops up in the side bar, my cursor is still outside of its paragraph.
4. I click on Revise.

Observed Behaviour: The cursor moves back to the check-range, the blue outlines appear.

@DLynch: Could you confirm what do we refer to by "the stale rendering" and "the staleness flag". Thanks!

The observed behavior sounds correct to me.

Sorry about the internal implementation jargon in the description. Technically, the blue outline rendering is attached to any check which is "stale" -- meaning that its contents have changed and the check's validity hasn't been updated yet. Practically, this can only ever happen to tone, because it's the only one that doesn't update immediately when you change the document. So, just read any reference to "staleness" as "whether the blue outline is used". 😅

In T401727#11102980, @DLynch wrote:

The observed behavior sounds correct to me.

Sorry about the internal implementation jargon in the description. Technically, the blue outline rendering is attached to any check which is "stale" -- meaning that its contents have changed and the check's validity hasn't been updated yet. Practically, this can only ever happen to tone, because it's the only one that doesn't update immediately when you change the document. So, just read any reference to "staleness" as "whether the blue outline is used". 😅

@DLynch: No worries! Thanks for explaining it. I do have few more points to confirm:

1. The stale rendering can be applied when I revise the tone without actually clicking the "Revise" button. It's not necessarily tied to the "Revise" button?

However, I see we are not thanking the users when we revise the tone in this way without actually being in the "Revise" workflow. Is that expected?

2. I see that when we revise the tone and don't click the "Recheck" , it still re-checks and removes the check when it's updated, so why do we have the "Recheck" button for?

3. I also noticed when there are multiple tone violations, and we correct only one, it removes the check, is that expected?

The stale rendering can be applied when I revise the tone without actually clicking the "Revise" button. It's not necessarily tied to the "Revise" button?

Yes. It should either apply immediately when you press revise, or after you start changing the text without pressing anything.

However, I see we are not thanking the users when we revise the tone in this way without actually being in the "Revise" workflow. Is that expected?

That's expected. We decided that if someone hadn't engaged with the check directly, we should keep things popping up and flashing at them to a minimum. (On desktop it's subtle, but the equivalent on mobile pops up fairly blatantly at the bottom of your phone screen.)

I see that when we revise the tone and don't click the "Recheck" , it still re-checks and removes the check when it's updated, so why do we have the "Recheck" button for?

Recheck is supposed to make it more obvious to the editor how to ask for that update. Otherwise, they'd need to realize that moving their caret outside of the paragraph is what triggers it, and that's fairly unintuitive.

I also noticed when there are multiple tone violations, and we correct only one, it removes the check, is that expected?

Within the same paragraph? The check should keep on showing up until the model's confidence in a tone violation being present drops below 0.8. Depending on how blatant your tone violations are, that might not be the same as them all having been removed.

If it removed a check for a different paragraph, that'd be a bug.

In T401727#11104483, @DLynch wrote:

The stale rendering can be applied when I revise the tone without actually clicking the "Revise" button. It's not necessarily tied to the "Revise" button?

Yes. It should either apply immediately when you press revise, or after you start changing the text without pressing anything.

However, I see we are not thanking the users when we revise the tone in this way without actually being in the "Revise" workflow. Is that expected?

That's expected. We decided that if someone hadn't engaged with the check directly, we should keep things popping up and flashing at them to a minimum. (On desktop it's subtle, but the equivalent on mobile pops up fairly blatantly at the bottom of your phone screen.)

I see that when we revise the tone and don't click the "Recheck" , it still re-checks and removes the check when it's updated, so why do we have the "Recheck" button for?

Recheck is supposed to make it more obvious to the editor how to ask for that update. Otherwise, they'd need to realize that moving their caret outside of the paragraph is what triggers it, and that's fairly unintuitive.

I also noticed when there are multiple tone violations, and we correct only one, it removes the check, is that expected?

Within the same paragraph? The check should keep on showing up until the model's confidence in a tone violation being present drops below 0.8. Depending on how blatant your tone violations are, that might not be the same as them all having been removed.

If it removed a check for a different paragraph, that'd be a bug.

Thanks again David, for answering my questions!

For multiple tone violations it is indeed happening within the same paragraph, and for the same sentence for which the check was presented.

If, this is an expected behavior according to the model's confidence score, we can close this.