Page MenuHomePhabricator

Empty brackets at the end of comments in API:Parse output
Closed, ResolvedPublicBUG REPORT

Description

List of steps to reproduce
Use API:Parse to preview some wikitext containing a comment, with parameters pst=true and title=Talk:API (or any talk/discussion page).

For instance, enter the following in JS console:

(await new mw.Api().get({
    action: 'parse',
    prop: 'text',
    pst: true,
    text: "Hi. ~~~~",
    title: 'Talk:API',
    disablelimitreport: true,
    formatversion: 2,
})).parse.text

Actual behaviour:
Irrespective of whether DiscussionTools is enabled or disabled, output looks something like this:

Hi. SD0001 (talk) 16:43, 2 October 2021 (UTC) [ ]

There's a stray pair of brackets appear at the end, with no reply button between them. Associated html:

<span class="ext-discussiontools-init-replylink-buttons"><span class="ext-discussiontools-init-replylink-bracket">[</span><a class="ext-discussiontools-init-replylink-reply" role="button" tabindex="0" data-mw-comment="{&quot;type&quot;:&quot;comment&quot;,&quot;level&quot;:1,&quot;id&quot;:&quot;c-SD0001-2021-10-02T16:43:00.000Z&quot;,&quot;replies&quot;:[],&quot;timestamp&quot;:&quot;2021-10-02T16:43:00.000Z&quot;,&quot;author&quot;:&quot;SD0001&quot;}" href=""><!--__DTREPLY__--></a><span class="ext-discussiontools-init-replylink-bracket">]</span></span>

Expected behaviour
Either the reply button should be added properly or shouldn't be added at all.

Event Timeline

This is intended, it happens as a result of T273072. The brackets are hidden using CSS unless you have the reply tool enabled.

Is this causing some problems for you, or does it just look weird?

Is this causing some problems for you, or does it just look weird?

This was reported as a bug for Twinkle here https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Bug:_preview_of_CfD/S_has_trailing_brackets Otherwise doesn't cause any problems.

I would suggest suppressing reply/subscribe buttons completely when ApiParse is used with disableeditsection flag, since reply buttons are basically for editing.

Thanks for the context. That seems like a good idea.

However, I think this is a bug in Twinkle too. It doesn't load the ResourceLoader modules associated with the parsed content. There are other scenarios where that causes problems, e.g. if you used <gallery>File:Example.jpg</gallery> markup, it won't be formatted as a gallery in the preview.

You can use our preview code as an example for how to do that: https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/cfc4f8b7a3e4dd12d4aca0e2c7839b0fa34940ed/modules/dt.ui.ReplyWidget.js#649

Thanks for the pointers – I'll put in the fix in Twinkle.

I started looking into this, and it looks to be a bit more complicated than I expected – the disableeditsection parse API parameter works as a post-processing step after parsing the page, rather than as an option for the parser, so we'd have to implement this in a different way than we currently handle everything else.

It's not impossible but I'm not sure now if it's worth the complexity.

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

[mediawiki/extensions/DiscussionTools@master] Add [reply] link brackets during postprocessing after parser cache

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

Well, I'm going to cheat and leave the markup there, but just remove the brackets, so it's not visible. It turns out to be convenient for other reasons as well.

Change 734688 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Add [reply] link brackets during postprocessing after parser cache

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