I'd recommend dialog-prevent-table-template-show. If we wanted to simplify, something like dialog-prevent-both-show would also work but that might cause confusion if there are ever any additional events beyond template and table that might cause this dialog to show.

Let me know if you have any questions or concerns.

cc @ppelberg @DLynch

In T259673#6373574, @MNeisler wrote:

I'd recommend dialog-prevent-table-template-show. If we wanted to simplify, something like dialog-prevent-both-show would also work but that might cause confusion if there are ever any additional events beyond template and table that might cause this dialog to show.

Let me know if you have any questions or concerns.

cc @ppelberg @DLynch

Thank you, Megan.

As discussed during today's standup, I'm going to assign this over to @Esanders to share any input on the event's name as David is OoO this week.

There are three syntax types we block on:

• Templates
• Tables
• Extensions (including references)

This makes the logging and messaging more complex. Currently we just fail on the first one we find. Displaying/reporting all the various combinations would be more complex, and it seems like it would be relatively rare.

In T259673#6375785, @Esanders wrote:

This makes the logging and messaging more complex. Currently we just fail on the first one we find. Displaying/reporting all the various combinations would be more complex, and it seems like it would be relatively rare.

...in light of what Ed shard above and the subsequent conversation @Mayakp.wiki, @MNeisler and I had, we're going to make the changes described below.

Changes

1. Log 1 event, regardless of the syntax type that causes a switch from being blocked
2. Call this "event" dialog-prevent-show
3. This event should be logged in the following schema: VisualEditorFeatureUse

Side effects
In implementing the "Changes" above, we will be "undoing" the events [i] implemented in T257501.

Rationale
We are okay with not knowing which specific syntax (table, template or extension) is causing people to be blocked from switching text input modes because we are primarily interested in knowing WHEN someone is blocked from switching because the new syntax will effect tables, templates and extensions equally.

Note: the task title and description has been updated to reflected the new scope defined in this comment.

i.

Open question

• @Esanders is it possible to implement the dialog message described in "Step 4." of the task description's "Implementation details" section [i] without logging/firing separate events for each syntax type?

i.

4. They should see a dialog that says:

Dialog title	Dialog body
Visual mode disabled	Sorry, switching to visual mode is disabled because the syntax below was detected in the comment you have written. [Learn more](mw:Extension:DiscussionTools/Reply_tool_visual_mode_limitations). <ul> <li>Extension</li> <li>Table</li> <li>Template</li> </ul>

In T259673#6384547, @ppelberg wrote:

Open question

• @Esanders is it possible to implement the dialog message described in "Step 4." of the task description's "Implementation details" section [i] without logging/firing separate events for each syntax type?

@Esanders confirmed during today's standup that it is possible to implement the dialog message described in "Step 4." of the task description's "Implementation details" section] without logging/firing separate events for each syntax type?

The task description's "Open questions" section has been updated to reflect the above.

Change 628204 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/DiscussionTools@master] When preventing switching modes, don't log a type-specific action

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

Change 628204 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] When preventing switching modes, don't log a type-specific action

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

The above patch unifies the logging to one type. I think changing the message is lower priority as it will be quite rare for more than one disallowed syntax type to be present.

Filed message change as T263261

In T259673#6474526, @Esanders wrote:

The above patch unifies the logging to one type. I think changing the message is lower priority as it will be quite rare for more than one disallowed syntax type to be present.

Roger that.

Meta: is there something about the revisions to the error message implementation that contributed to you thinking it was best handled in a separate task? E.g. did it prompt questions we do not yet have answers for that you thought would get in the way of consolidating the two events?

(I've updated the task description to reflect what copy is shown in the resulting dialog.)

Quick update re post-deployment data QA: I'm currently only seeing two dialog-prevent-show events recorded in VisualEditorFeatureUse since the beginning of September through yesterday. Both events were recorded on Dutch Wikipedia on October 13th. Based on the sample event from @Ryasmeen, I'm guessing both of these might be testing events. See below:

It might be possible that no users have performed the action required to cause this event since deployment but it is difficult to confirm or complete QA until some more events are fired. I tried creating a few more events on a few different wikis (frwiki, cswiki, and kowiki) and will confirm if they are logged correctly tomorrow once they are stored in eventlogging.

For the two events recorded, everything looks as expected except for the editor interface. The editor_interface for these events are recorded as visual editor - @DLynch Is that expected? I had assumed that the editing interface should be wikitext given that this action is supposed to record when an editor is prevented from switching to visual mode from source?

In T259673#6543659, @MNeisler wrote:

Quick update re post-deployment data QA: I'm currently only seeing two dialog-prevent-show events recorded in VisualEditorFeatureUse since the beginning of September through yesterday. Both events were recorded on Dutch Wikipedia on October 13th. Based on the sample event from @Ryasmeen, I'm guessing both of these might be testing events. See below:

It might be possible that no users have performed the action required to cause this event since deployment but it is difficult to confirm or complete QA until some more events are fired. I tried creating a few more events on a few different wikis (frwiki, cswiki, and kowiki) and will confirm if they are logged correctly tomorrow once they are stored in eventlogging.

Update: I've rechecked the data to see if any additional events have come in. I see one event for frwiki, which is likely from my test instance and one for arwiki that occurred on October 16th. See updated numbers below.

Change 637110 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/DiscussionTools@master] Switching editor modes would switch editor_interface before success/fail

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

I took a look. There was a sequencing issue with the events -- the editor-switch.visual-desktop event fired as soon as the switch was requested, so if it later failed because of a template the dialog-prevent-show would believe the switch had already happened and log itself as happening in visual mode.

The patch adjusts it so that the editor-switch.[visual/source]-desktop event won't fire until the switch has succeeded, and so the dialog event won't be confused.

Everything else about the event seems to be correct -- it fires whenever the dialog shows, and is easily reproducible by adding e.g. {{done}} to whatever source one is editing.

Change 637110 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Switching editor modes would switch editor_interface before success/fail

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

@DLynch - I checked today. There have only been a few events logged since the patch was deployed but the editor_interface for these events appears to still be recorded as visual editor in the VEFU schema.

Data via:

SELECT
    date_format(dt, 'yyyy-MM-dd') AS date,
    wiki AS wiki,
    event.editor_interface AS editor_interface,
    event.platform AS platform,
    event.feature As feature,
    event.integration AS integration,
    event.action AS action,
    COUNT(*) AS events
FROM event.visualeditorfeatureuse
WHERE 
    year = 2020 
    AND month >= 10
    AND wiki <> 'testwiki'
    AND event.action = 'dialog-prevent-show'
GROUP BY
    date_format(dt, 'yyyy-MM-dd'),
    wiki,
    event.editor_interface,
    event.feature,
    event.integration,
    event.platform,
    event.action

@MNeisler Sorry, I didn't realize when I was kicking it over to you -- the general tumult of last week meant we had a disruption to our normal deployment schedule. 1.36.0-wmf.16 only made it to Group 2 wikis in the noon PST deploy today, so your testing was unfortunately not including the fix. (I had foolishly assumed that it'd already be on its way out when I was making that last comment.)