Page MenuHomePhabricator

DiscussionTools doesn't handle unclosed nowiki in previous section.
Open, LowPublicBUG REPORT


List of steps to reproduce (step by step, including full links if applicable):

What happens?:
The tool correctly wraps the {{tq|test}} part in <nowiki></nowiki> tags, but that causes the previously unclosed <nowiki> in a previous section to be parsed, causing most of the page to appear incorrectly.

What should have happened instead?:
The appearance of the rest of the page should remain unmodified, which would entail closing the previous <nowiki> or making it self-closing (e.g. <nowiki />).

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc:

Event Timeline

Thanks for the report. I think the issue is slightly different than what you described. What I am seeing here is:

The problem actually occurs because the page has an unclosed <nowiki> in an earlier comment. It's easy to find in the wikitext editor if you enable syntax highlighting:

image.png (2×3 px, 952 KB)

The unclosed nowiki tag does nothing, until your edit accidentally adds the closing tag </nowiki>, and wikitext formatting gets disabled on all of the comments inbetween.

To avoid the issue, I think DiscussionTools actually should modify that unclosed tag! (Technically, that would happen in Parsoid.) This is what happens in other cases – e.g. if there's an unclosed {{ somewhere on the page, it gets wrapped in nowiki, so that adding }} in another comment doesn't wrap all of the comments inbetween in a template.

matmarex renamed this task from DiscussionTools inserts nowiki into previous section. to DiscussionTools doesn't handle unclosed nowiki in previous section..May 31 2021, 4:52 PM
matmarex added a project: Parsoid.

Good catch. I was wondering why the <nowiki> wasn't being displayed as a change. I agree that, if the previous tag was being ignored by the parser because it was unclosed, adding a reply should try to keep that status-quo.

Arlolra moved this task from Needs Triage to Bugs & Crashers on the Parsoid board.
Arlolra subscribed.

Parsoid has some ability in WikitextEscapeHandlers::hasWikitextTokens and the whole ConstrainedText thing to detect if text we're about to serialize needs escaping because it'll combine with previous characters to form valid syntax / tokens, as @matmarex says. But, in practice, that probably works more on a line than at a page level at the moment.

An unclosed extension tag is going to combine with a newly introduced subsequent balanced one, regardless of which tool is adding it to the page, but I guess that's a bigger problem for Parsoid / VE / DiscussionTools because it violates WYSIWYG. One way to preserve that might be to change the behaviour of unclosed extension tags to consider the rest of the page their content. That would help to surface the problem in a more obvious way when introducing it and avoid the need to worry about the combining. But that's how the legacy preprocessor used to work and it was changed in

So, I'll just put this on the agenda for the next Parsing Team meeting to discuss.

Briefly, the proposed solution from the Parsing side is that we should add a lint for "unclosed nowiki" (if there isn't already one, there may well be, "unclosed tag" is probably close enough) and then have DiscussionTools check the lints for the given page before saving (or starting?) an edit and warn the user if there are "problematic" lints for the page. It doesn't (shouldn't) be too fancy: no need to detect whether the edit-in-process contains a <nowiki> for instance -- there are too many corner cases here to spawn endless ratholes to waste time in. It should just be a big hammer where if there are lints in a given set of categories present the user will be warned, and we can add new lints to that category as we find new cases of this sort.

So in this sense the editor would be warned there was an unclosed tag (or specially an unclosed <nowiki>) on the page at some point during their comment, which would make it clear what's happened when their edit appears broken. Longer-term, de-linting work by wiki gnomes will fix the fundamental issue, and things like "balanced sections" will help mitigate their effect.

That would work for us, since we already check the lints for fostered content (for T246481).