Page MenuHomePhabricator

Reply widget attached outside of mw-parser-output when viewing old revision and logged out
Closed, ResolvedPublic


Visit while logged and and hit [reply],

Observe a new <dl> is attached to the DOM as a sibling of the main mw-parser-output node.

This doesn't happen if you are logged in, or viewing the latest revision of the page (?!)

If you use the edit-conflict-reload feature, the "Loading..." message does not get cleared as we only update the mw-parser-output node.

Event Timeline

Change 769536 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Don't allow the root node to be treated like a comment frame

This is caused by the code that lets the reply tool (and the real reply) appear outside of a frame like in this example:

image.png (791×1 px, 45 KB)

To achieve this, CommentModifier tries to find a set of sibling nodes that almost exactly matches the comment's range. There is some ugly code implementing the "almost exactly" part, basically it ignores various nodes according to various made up rules – for example, our own [reply] buttons and markers, and HTML comments (check the wikitext source for an example).

There were two bugs in that code:

  • It was ignoring all headings on the page, just like it ignores the markers, because we add data-mw-comment attribute to them and it was treating it like data-mw-comment-start/data-mw-comment-end
  • If the comment's range almost exactly matched the <div class="mw-parser-output"> node (because it was the only thread item on the page – or the only thread item except for headings, considering the bug above), it would treat it like a regular frame, thus displaying the reply tool outside of it.

Change 769536 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Don't allow the root node to be treated like a comment frame

The number of <dl> elements remain the same after hitting/toggling [reply]. See
Looks good to me.