In T257501#6295041, @JTannerWMF wrote:

Hey @Mayakp.wiki sometime next week, we need you to drive getting the answers to these questions in collaboration with @DLynch

Next steps

• Moving this to Blocked/Needs more work as @MNeisler and @DLynch need to come to a decision about what the event should be called

Timing
Ideally, we can decide on the event name, implement the event and test the event within the next 2-3 weeks.

The above is now reflected in the task description.

1. What should this event be called?
I'm currently thinking the following might work based on the event naming conventions in the VEFU schema. See the VEFU data dictionary.
Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Follow-up Question:
Do we want separate events to track if the dialog was caused by a table or a template in the source comment? (cc @ppelberg)

2. What schema should this event be stored in?

This event should be stored in the VisualEditorFeatureUse schema.

@DLynch - Any thoughts on the above? Happy to discuss other recommendations.

In T257501#6323332, @MNeisler wrote:

Follow-up Question:
Do we want separate events to track if the dialog was caused by a table or a template in the source comment? (cc @ppelberg)

Good call, @MNeisler; I'm glad you thought of this.

Yes, we would like to instrument separate events to know what content (table or template) caused the dialog to be shown (read: the person to be prevented from switching between source and visual).

Two notes:

1. During today's standup, @DLynch and @Esanders confirmed the above should be possible considering code paths exist for the explicit scenarios we would like to instrument/detect.
2. I've updated the task description's "Requirements" section to reflect the need to instrument what caused the dialog to be presented

Now T256150 has the relevant patch merged, we can do whatever logging we'd like.

Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Presumably we'd want variants on the action based on the type, so we'd wind up with dialog-prevent-{type}-show or similar.

In T257501#6327158, @DLynch wrote:

Now T256150 has the relevant patch merged, we can do whatever logging we'd like.

Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Presumably we'd want variants on the action based on the type, so we'd wind up with dialog-prevent-{type}-show or similar.

Yes, agreed. dialog-prevent-template-show and dialog-prevent-table-show would work for me.

In T257501#6327431, @MNeisler wrote:

In T257501#6327158, @DLynch wrote:

Now T256150 has the relevant patch merged, we can do whatever logging we'd like.

Action: dialog-disable-show or dialog-prevent-show
Feature: editor-switch

Presumably we'd want variants on the action based on the type, so we'd wind up with dialog-prevent-{type}-show or similar.

Yes, agreed. dialog-prevent-template-show and dialog-prevent-table-show would work for me.

Next steps
@MNeisler + @DLynch, based on the above, I am assuming y'all have agreed on answers to the task description's "Open questions." [i] As such, I am moving this to "Ready for development" so the events below [i] can be implemented by Editing Engineering.

⚠️If y'all have NOT agreed on answers to the "Open questions" in the task description, please comment as much.

Open questions

• 1. What should this event be called?
• 2. What schema should this event be stored in?

Change 616874 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/DiscussionTools@master] Log when editor switching is prevented

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

Task description update

• ADDED pre-deployment QA to "Done"

Note to Editing Engineering: please move this task to the Editing QA "High Priority" column once code review is complete.

Change 616874 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Log when editor switching is prevented

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

Checked the two events on Beta. They seem to be firing as expected.

Screenshots for the dialog and the event for scenario 1, where a person tries to switch to the Reply Tool's visual mode after writing a template in its source mode:

Screenshots for the dialog and the event for scenario 2, where a person tries to switch to the Reply Tool's visual mode after writing a table in its source mode:

@DLynch/@ppelberg: I have a question though about a scenario which I tried :

When I write both a template and a table in Reply Tool's source mode and then switch to visual mode. I only get the event and dialog for one event, the one for the table, shouldn't I get these for both?

In T257501#6361341, @Ryasmeen wrote:

Checked the two events on Beta. They seem to be firing as expected.

Thank you for the update, Rummana.

When I write both a template and a table in Reply Tool's source mode and then switch to visual mode. I only get the event and dialog for one event, the one for the table, shouldn't I get these for both?

Good spot which I think has two consequences:

• 1. We need to add a third dialog for the case in which people write table and template syntax in the Reply Tool's source mode and attempt to switch to its visual mode
• 2. We need to add a third event that fires in cases where people write table and template syntax in the Reply Tool's source mode and attempt to switch to its visual mode

Considering the new case you identified was NOT scoped as part of this task and the cases that were scoped as part of this task have been verified, I've created a task for "1." and "2." above: T259673.

Resulting actions
As for the remaining items in the task's description's "Done" section:

• "Open questions" are answered
• Pre-deployment QA is completed

This is now done per T257501#6361341

• "Requirements" are implemented

This is now done per T257501#6350423

• New events are added to the VisualEditor/Feature use data dictionary

This will instead happen in T252930 per T252930#6347000

I am resolving this task; the task description's "Done" section has been updated to reflect the above.