Page MenuHomePhabricator

Infobox overlaps with text, prevents editing the latter.
Open, NormalPublic

Description

From mw.org
Launch https://fr.wikipedia.org/w/index.php?title=Tintin_au_pays_des_Soviets&oldid=147961827&veaction=edit in the visual editor, hover over the first sentence. Notice it gets "caught" by Infobox Bande dessinée, and can't be edited normally. You have to click on it, which opens the complex transclusion editor, and scroll all the way to the end of that dialog box to find the first sentence in its "Content" field.

Adding an empty line after the infobox looks like a workaround. Is using a bot to apply it the only thing to do here?

Event Timeline

Elitre created this task.May 18 2018, 1:31 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 18 2018, 1:31 PM
matmarex added a subscriber: matmarex.

Looks like Parsoid is marking up the first paragraph as part of the transclusion. This might be a bug in Parsoid or broken syntax in the infobox template (e.g. unclosed HTML tags).

Whatamidoing-WMF added a subscriber: Whatamidoing-WMF.

It happens with some infoboxes but not with others. Does this suggest that the problem is in the templates?

ssastry triaged this task as Normal priority.May 22 2018, 2:55 PM
Sbailey claimed this task.May 22 2018, 3:09 PM

I just remembered about T178970. Relevant?

Vvjjkkii renamed this task from Infobox overlaps with text, prevents editing the latter. to 6rcaaaaaaa.Jul 1 2018, 1:09 AM
Vvjjkkii raised the priority of this task from Normal to High.
Vvjjkkii removed Sbailey as the assignee of this task.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii edited subscribers, added: Sbailey; removed: Aklapper.
CommunityTechBot assigned this task to Sbailey.
CommunityTechBot lowered the priority of this task from High to Normal.
CommunityTechBot renamed this task from 6rcaaaaaaa to Infobox overlaps with text, prevents editing the latter..
CommunityTechBot edited subscribers, added: Aklapper; removed: Sbailey.

I experimented a bit and I think I found the reason this issue: the template "Infobox Bande dessinée" outputs <nowiki /> at the end, coming from the sub-template "Infobox/Titre en italique" (or its sub-sub-template "Titre en italique"). Parsoid treats it as part of the first paragraph of the article, and then marks the entire paragraph as being "affected by a template" and thus not separately editable.

The <nowiki /> was added deliberately to prevent the PHP parser from rendering an empty paragraph after the infobox (due to the newlines between transclusions of sub-templates): https://fr.wikipedia.org/w/index.php?title=Modèle%3AInfobox%2FTitre_en_italique&diff=prev&oldid=142843034

I am not sure if Parsoid could handle this in a better way. It's an awkward behavior, but it seems to make sense with how paragraph generation works (just imagine that instead of <nowiki />, the template had foo there: it would become a part of the first paragraph of the page).

To work around the issue on French Wikipedia, you'd have to do the following:

  • Remove the <nowiki /> at the end of templates like "Infobox/Titre en italique", "Titre en italique", and any others, to prevent infoboxes using them from being glued to first paragraph in VE
  • Remove the newline between {{Infobox/Fin}} and {{Infobox/Titre en italique|...}} in "Infobox Bande dessinée" and any other infobox using those templates, to prevent an empty paragraph from appearing after the infobox

Here's a minimal page where you can reproduce the problem: https://test.wikipedia.org/wiki/T194945a

{{1x|
<div>a</div>
<nowiki />}}
b

Identical page without the <nowiki /> works fine: https://test.wikipedia.org/wiki/T194945b

{{1x|
<div>a</div>
}}
b
Od1n added a comment.Jul 2 2018, 10:58 PM

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

Yes and no. The visual editor could definitely handle this edge case better, but using <nowiki /> tags like this is somewhat hacky and was fairly likely to cause strange behaviour somewhere else.

So, there's shared responsibility here. The easiest thing to do would be to follow matmarex's steps to fix the problem. Digging into the VisualEditor-Parsoid stack to fix this problem would likely be much harder and more time consuming.

Od1n added a comment.Jul 3 2018, 1:11 PM

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

The difficulty of the fix should be asked to a parsoid developer. If the fix would be too difficult, editing the templates and the pages as suggested above shouldn't be considered as a fix but as a workaround.

As a note of hope, this issue would probably be fixed by T114445.

ssastry added a subscriber: ssastry.EditedJul 3 2018, 1:50 PM

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

The difficulty of the fix should be asked to a parsoid developer. If the fix would be too difficult, editing the templates and the pages as suggested above shouldn't be considered as a fix but as a workaround.

As a note of hope, this issue would probably be fixed by T114445.

Note that Parsoid doesn't strip elements in the input unlike the PHP parser. Parsoid has to handle input a lot more strictly so that when edited output is serialized to wikitext, we don't introduce dirty diffs.

More specifically, in this case, Parsoid won't strip the <nowiki /> tag (unlike the PHP parser). So, this means that the <nowiki/> tag kicks off a new paragraph and it comes from the template.

While we could tweak some of Parsoid's template handling code (for example, by selectively stripping some trailing elements from template output), we have to be careful to not introduce other edge cases.

Talking of workarounds, note that editors added a <nowiki/> to workaround the PHP parser's handling. @matmarex has provided a solution that eliminates that workaround in a way that doesn't need special handling in Parsoid. As noted above, to handle cases like this, we would have to add additional conditional code which breaks the current uniform handling.

So, the cleanest solution that eliminates special cases and workarounds would be the one suggested by @matmarex and hope you consider that.

Od1n added a comment.Jul 3 2018, 2:21 PM

This makes sense. I am just uncomfortable with removing the "nowiki" from the sub (and main) template {{Titre en italique}}. That one "nowiki" fixes many cases of empty <p>.

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

ssastry removed Sbailey as the assignee of this task.Aug 23 2018, 10:07 PM
ssastry added a subscriber: Sbailey.
Od1n added a comment.Aug 23 2018, 10:49 PM

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

I've just tried this, and it doesn't fix the issue…

Od1n removed a subscriber: Od1n.Aug 23 2018, 10:50 PM
Alsee added a subscriber: Alsee.Nov 21 2018, 10:08 AM

(just imagine that instead of <nowiki />, the template had foo there: it would become a part of the first paragraph of the page).

Excellent example, I was going to raise that case myself. It's a pretty simple and obvious thing we might do at any time. We expect (and need) to be able to edit the plaintext after the template. Any editor that can't edit plaintext is clearly broken, regardless of explanations for why it is broken.

The problem is that plaintext is being marked as non editable, instead of having the non editable zone terminate at the end of template output.

VE has a lot of weird and very hard to fix bugs, and they're almost all consequences of a single original architecture error. VE should have been designed as a visual-editor-for-wikitext, instead VE was build with no ability to edit wikitext at all (it's an HTML editor). The big and difficult issues with VE (and community rejection of VE) largely trace back to the crazy complex Parsoid translation hack. The real fix for all these issues would be a genuine visual-editor-for-wikitext.