Page MenuHomePhabricator

Tool is not indented correctly when first comment is indented
Closed, InvalidPublic

Description

Probably not a common case, but maybe this should be handled.

If the first comment in a thread is indented (in this case "Line with trailing spaces" is indented by one ':'):

Correctly indented when replying to level 2 comment:

image.png (477×353 px, 22 KB)

Incorrectly not indented when replying to level 1 comment:

image.png (431×360 px, 21 KB)

Event Timeline

I can't reproduce, can you copy the wikitext from the page you were testing?

: Line with trailing whitespace ->  
: End of comment. [[User:Ed|Ed]] ([[User talk:Ed|talk]]) 14:48, 9 September 2020 (BST)

I tried again, and it is only happening locally. I noticed that locally MobileFrontend is outputting <section> tags even on desktop for me because I had the MF content provider enabled. Turning that off fixed it. I don't know if that means we should close the bug though, because at some point we may need the modifier to work on <section> wrapped output.

You can test this by turning on the MF content provider in desktop:

$wgMFContentProviderClass = 'MobileFrontend\ContentProviders\MwApiContentProvider';
$wgMFAlwaysUseContentProvider = true;
$wgMFMwApiContentProviderBaseUri = "https://en.m.wikipedia.org/w/api.php";

I tried with that wikitext and that config and I still can't reproduce locally. Not sure why that happens.

Try placing a breakpoint in modifier#addListItem on the line covered = utils.getFullyCoveredSiblings( curComment );, and debugging from there. covered will probably be the section node, which I guess isn't really correct. But I don't understand why the reply widget would still be inserted at the wrong indentation level because of that.

JTannerWMF subscribed.

We aren't going to prioritize this right now

I tried again, and it is only happening locally. I noticed that locally MobileFrontend is outputting <section> tags even on desktop for me because I had the MF content provider enabled. Turning that off fixed it. I don't know if that means we should close the bug though, because at some point we may need the modifier to work on <section> wrapped output.

Maybe this was something like T319148?

Not reproducible, likely fixed somehow since 2020, as we've improved mobile support.