Page MenuHomePhabricator

Prevent page corruption in DiscussionTools caused by broken and incomplete table syntax
Closed, ResolvedPublic

Description

Steps to reproduce:

  1. Put a broken table on the talk page. (It is not necessary for this table to look right.) Starting the table with ::{| even though https://en.wikipedia.org/wiki/Help:Table#Basic_table_markup_summary tells you that "The above marks must start on a new line" is a reliable way to break the table.
  2. Use the reply tool.
  3. Get what you deserve (two examples).

Event Timeline

:::| One || 1 was turned into :::| One (i.e., actual loss of content). That seems bigger than just removing newlines.

This is the same as T240280, that task just has a poor description. (I'll fix it.)

But I think it'll be useful to have two tasks.

  • That that is about the Parsoid issue, which affects DT, VE, and anything else that uses Parsoid to edit.
  • This task can be only about DiscussionTools and how we're going to work around the Parsoid issue, assuming it's not getting fixed soon.
matmarex renamed this task from Broken and incomplete table syntax screws up the rest of the page to Prevent Parsoid page corruption caused by broken and incomplete table syntax in DiscussionTools.Mar 2 2020, 10:49 PM
matmarex added a parent task: T233443: [Epic] Reply Tool.

This is the same as T240280, that task just has a poor description. (I'll fix it.)

But I think it'll be useful to have two tasks.

  • That that is about the Parsoid issue, which affects DT, VE, and anything else that uses Parsoid to edit.
  • This task can be only about DiscussionTools and how we're going to work around the Parsoid issue, assuming it's not getting fixed soon.

Thanks @matmarex. That distinction is helpful. For the first point, T240280#5818529 summarizes the issue. I don't see any obvious fix that is actually going to be useful for editors. If anyone can think of useful approaches, please respond there.

For DiscussionTools, I think the best we can do is to just disable replying on affected pages until their wikitext is fixed. We could detect this using Parsoid's lint output, which has "type":"fostered" errors. (I previously described this idea in our internal chat in December: https://chat.google.com/u/1/room/AAAAVBWD7Zg/JZmMcLRHP50.)

matmarex renamed this task from Prevent Parsoid page corruption caused by broken and incomplete table syntax in DiscussionTools to Prevent page corruption in DiscussionTools caused by broken and incomplete table syntax.Mar 2 2020, 11:05 PM

There are >35,000 pages with that lint error on en.wiki https://en.wikipedia.org/wiki/Special:LintErrors, probably with a significant proportion in talk namespaces. Clicking on a few they all appear to roundtrip correctly in VE, so it would appear that this bug is just a small subset of fostered content issues, and most wouldn't prevent DT working correctly.

There are >35,000 pages with that lint error on en.wiki https://en.wikipedia.org/wiki/Special:LintErrors, probably with a significant proportion in talk namespaces. Clicking on a few they all appear to roundtrip correctly in VE, so it would appear that this bug is just a small subset of fostered content issues, and most wouldn't prevent DT working correctly.

They only roundtrip correctly if the affected part is not touched, thanks to selser.

Possible interface for this (as discussed in Engineering meeting yesterday):

  1. Display "Reply" links as normal, but greyed-out, struck-out, or otherwise marked
  2. When a reply link is clicked, display an error message instead of the textfield.

I think approach #2 provides the people who are landing on these pages a better experience (clear feedback about the issue preventing them from being able to do what they are intending to do with actionable steps to correct the issue and accomplish what they originally set out to).

With this said, I assume implementing approach #2 would require significantly more effort in which case approach #1 seems like a good intermediate fix.

Questions

  • 1. Complexity: does implementing approach #2 would require significantly more effort in which case approach #1?
  • 2. Approach: is the above (starting with approach #1) how y'all (engineering) have been thinking about this as well?

After discussing with Ed yesterday, it sounds like y'all (engineering) are planning to approach #2 [i.] – is that correct? And if so, why?

  • Per T246481#5945952, I agree with y'all in thinking #2 provides a better experience; I ask the above wondering how the level of effort to implement #2 compares to that of #1.

i.

  1. When a reply link is clicked, display an error message instead of the textfield.

After discussing with Ed yesterday, it sounds like y'all (engineering) are planning to approach #2 [i.] – is that correct? And if so, why?

  • Per T246481#5945952, I agree with y'all in thinking #2 provides a better experience; I ask the above wondering how the level of effort to implement #2 compares to that of #1.

Yes, or maybe both. The difficult part of this task is detecting the lint error, but once we do that, adding either of the interfaces is comparatively easy (#2 only requires writing the error message; and passing the error location to the editor, but the Linter extension already does that, so we can just copy that approach).

Esanders added a subscriber: dchan.

Change 589108 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/extensions/DiscussionTools@master] Show error on pages with fostered content to avoid page corruption in Parsoid

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

  • @matmarex are you able to revise the error message [i] to match the bolded text below?

"Comments on this page can't be replied to because of an error in the wikitext. You can learn about this error by reading the documentation, ask for help by posting here or fix the error by [$2 opening the full page editor]."

Note: I'm assuming the URLs for $1 and $2 should be the same as what you shared in T246481#5942238.


i. https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/DiscussionTools/+/589108/1/i18n/en.json@26

Change 589108 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Show error on pages with fostered content to avoid page corruption in Parsoid

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