Page MenuHomePhabricator

Adding <small> tag in a reply using DiscussionTools provides no way to auto-close the tag if one wants their signature to be made the same size
Closed, ResolvedPublicBUG REPORT

Description

Problem: When one adds a <small> tag to a reply using the DiscussionTools extension, there is currently a bug in that the tag is not auto-closed, say, if one wants their signature to be included within the small text size.

Steps to Reproduce:

  1. Create a talk page post
  2. Reply to talk page using the DiscussionTools extension, adding a <small> tag before you type your first word
  3. Do not manually close the </small> tag, allowing DiscussionTools to perform the task
  4. Go back into the edit screen, and note the tag is not auto-closed

Actual Results: <small> tag is not auto-closed, creating problems for subsequent replies or even new threads

Expected Results: <small> tag should be auto-closed, if not closed manually by the authoring user, such as in cases where the signature is to be the same font size as the rest of the post

Examples:

  1. Reply
  2. Manual fix

Event Timeline

@RhinosF1 mentioned that I should be able to manually add the four tildes (~~~~) as my signature, which I hadn't initially considered. It's less ideal, as I do feel this shouldn't be too difficult to resolve this bug by having the extension check for an unclosed <small> tag and close any <small> tags present in the reply, but is still an acceptable workaround; however, upon further testing, the four tildes (~~~~) is simply added to the auto-added signature that the extension adds. So, as a secondary or in addition to fix, the extension should check for any four tildes already in the reply and, if present, not add a signature.

This will be fixed by the new indented comment syntax (T230683), which should create a per-comment context from which unbalanced tags can't escape.

One could round-trip the wikitext through Parsoid to ensure balanced syntax, but this is counter to what we have tried to do so far with the wikitext mode, which is that should preserve the wikitext as-typed by the user as much as possible.

@RhinosF1 mentioned that I should be able to manually add the four tildes (~~~~) as my signature, which I hadn't initially considered. It's less ideal, as I do feel this shouldn't be too difficult to resolve this bug by having the extension check for an unclosed <small> tag and close any <small> tags present in the reply, but is still an acceptable workaround; however, upon further testing, the four tildes (~~~~) is simply added to the auto-added signature that the extension adds. So, as a secondary or in addition to fix, the extension should check for any four tildes already in the reply and, if present, not add a signature.

Task T268558 is another request to support this workaround.

Similar to T302257 for the concept in general; not sure that "autoclose" is the right answer - we should be careful about what content tools inject in to a user's revision.

We're currently thinking that a better solution for this use case is to allow you to type the whole comment with <small> at the beginning and ~~~~</small> at the end, and avoid adding a duplicate signature in this case (T268558).

Automatically closing the tag is more difficult to do, and users might not be happy about the tool changing the wikitext they typed any more than absolutely necessary (adding indents).

No I mean, why is this only about the "small" tag - closing with </big> </strong> or anything else is the exact same problem.

The small tag is the only one that anyone has asked for, and it's easier to discuss when you say "the small tag" rather than "all formatting tags such as small, big, strong and so on".

But I agree that all formatting tags such as small, big, strong and so on should behave the same in this regard.

OK, that's what I requested in T302257 - fixing the problem in general; the user story on this one seems to be asking for the extension to insert matching closing tags.

OK, that's what I requested in T302257 - fixing the problem in general; the user story on this one seems to be asking for the extension to insert matching closing tags.

To be clear, that that was just one possible option I thought of. I don't really care how it's resolved. What was the end result that we ended up doing to resolve this, @ppelberg?

With T268558 being solved - do we really need this done? Isn't this request now along the lines of: "If a user inputs garbage, garbage is output"?

With T268558 being solved - do we really need this done? Isn't this request now along the lines of: "If a user inputs garbage, garbage is output"?

I wouldn't characterize it like that, but it's the same bug I reported in T268558. T268558 seems to have resolved this bug in a different way, which seems fine to me. So all we need to do is merge this task into that task and consider it resolved, I think?

Xaosflux claimed this task.

@dmehus we can just close this out to stop the tracking, thank you for letting us know that the reported issue is good now.