Update: Edits made in source mode without the toolbar accounted for only 0.36% of source mode replies in November[1] (about 0.28% of all replies).

1. https://superset.wikimedia.org/superset/dashboard/152/

Now that the reply tool has been deployed at almost all wikis, it might be a good time to revisit this and clear up this maintenance debt. Very few users are using and it is not tested as part of our regular QA.

Remove sub-tasks which have not yet been identified as blockers to this happening.

I'd like us to remove this technical/maintenance/testing debt.

From superset, in the last month still only 0.4% of source mode replies were made with the toolbar disabled.

It may not be entirely rational of me, but I'd prefer to keep the two modes forever. As a technology purist I wish that DiscussionTools wouldn't depend on VisualEditor at all. (We currently rely on various other bits and pieces of it that would be better placed in MediaWiki core along with Parsoid.)

On a slightly more rational note: users continue to occasionally report issues with input to the VE surface on various devices (e.g. T292538), and we're not very good at fixing them, so I want to have a fallback mode that works for these users.

In T276607#8040762, @matmarex wrote:

On a slightly more rational note: users continue to occasionally report issues with input to the VE surface on various devices (e.g. T292538), and we're not very good at fixing them, so I want to have a fallback mode that works for these users.

In practice this is completely undiscoverable:

1. Full preferences are not available on mobile
2. A user having problems with the reply tool would have no idea that turning off the "source mode toolbar" might fix their input issue

The bug you linked to is basically a unsupported workflow (desktop site on mobile), but if there are genuine input issues we should prioritise fixing them, and not pretend that maintaining this rarely used code path is helping.

Example of maintenance burden of maintaining this mode: T348834

I’m happy to report breakages and live with them for a few days if this means that I can continue to use the interface that better integrates with OS features (like primary selection on Linux); works without JavaScript (once loaded), making it more reliable in case of CPU spikes; and doesn’t try to be smarter than me (e.g. I can input literal non-breaking spaces).

In T276607#8582334, @Esanders wrote:

1. Full preferences are not available on mobile

They may not have been back in February, but they have been for quite some time by now.

2. A user having problems with the reply tool would have no idea that turning off the "source mode toolbar" might fix their input issue

People helping on technical village pumps can advise them to do so, leading a much faster unblock of their workflows than the code fix (take the current situation: learning that I have to toggle my preferences unblocked my workflow in minutes, others’ workflows probably in hours; the code fix will unblock it in days).

In T276607#9251736, @Tacsipacsi wrote:

better integrates with OS features (like primary selection on Linux);

Does this not work with our surface?

works without JavaScript (once loaded), making it more reliable in case of CPU spikes

Especially with the small documents involved with replies, CPU is unlikely to be a bottle neck

(e.g. I can input literal non-breaking spaces).

There's NBSP in the special chracters menu, and a keyboard shortcut (ctrl+shift+space). NBSP is a special case because most of the time it is inserted it is accidental, so we would get more complaints if we didn't remove them, but our IME support is pretty solid at this point.

In T276607#8582334, @Esanders wrote:

1. Full preferences are not available on mobile

They may not have been back in February, but they have been for quite some time by now.

They are, but finding DiscussionTools options are still several menus deep on mobile

2. A user having problems with the reply tool would have no idea that turning off the "source mode toolbar" might fix their input issue

People helping on technical village pumps can advise them to do so, leading a much faster unblock of their workflows than the code fix (take the current situation: learning that I have to toggle my preferences unblocked my workflow in minutes, others’ workflows probably in hours; the code fix will unblock it in days).

Having fewer edit modes means these regressions will be less likely, and fixes will be prioritised for the supported modes. A tiny proportion of users on read technical village pumps, and on smaller wikis such support is just not available.

Generally though - users who are advanced enough that they need a <textarea> input will still be able to do so in the full page editor.

In T276607#9258593, @Esanders wrote:

In T276607#9251736, @Tacsipacsi wrote:

better integrates with OS features (like primary selection on Linux);

Does this not work with our surface?

Not reliably. T338285 is definitely yet to be fixed, maybe there are other issues as well.

works without JavaScript (once loaded), making it more reliable in case of CPU spikes

Especially with the small documents involved with replies, CPU is unlikely to be a bottle neck

CPU spikes caused by other things (e.g. other tabs) can make DiscussionTools not work either.

(e.g. I can input literal non-breaking spaces).

There's NBSP in the special chracters menu, and a keyboard shortcut (ctrl+shift+space). NBSP is a special case because most of the time it is inserted it is accidental, so we would get more complaints if we didn't remove them, but our IME support is pretty solid at this point.

I don’t think inserting literal non-breaking spaces in discussions is problematic; no one will want to edit them later on anyway. Articles, for which VisualEditor was originally designed, are a different topic.

In T276607#8582334, @Esanders wrote:

1. Full preferences are not available on mobile

They may not have been back in February, but they have been for quite some time by now.

They are, but finding DiscussionTools options are still several menus deep on mobile

They’re linked from the reply/new topic tool, just like on desktop. I don’t think they’re hard to discover; and definitely not harder than on desktop.

Generally though - users who are advanced enough that they need a <textarea> input will still be able to do so in the full page editor.

I know, and I probably will if you remove this mode, but especially the reply tool is much more convenient to use even as an advanced editor: using the full page editor, when I decide to reply to a comment, I have to scroll back to top of the section, click the edit section link, find the comment I’m replying to in the sea of wikitext, then click preview and find my reply draft in the sea of parsed content every time I refined the text. And if I fail to sign the reply properly (e.g. one tilde too few or much, or no tildes at all), I make DiscussionTools unusable to others as well. If I use the reply tool, I have to click the reply button right where I want to see my reply without scrolling and searching, the preview also appears there, and if I decide not to, or forget to, add a proper signature, the tools does it for me.