Bugzilla 5.1.2+ confuses Markdown code blocks in multiple comments

[Ivan Krylov]

On Mon, 19 Feb 2024 13:57:55 +0300
Ivan Krylov <ikrylov at disroot.org> wrote:

> I think this boils down to the Bugzilla::Markdown object caching code
> blocks in $self->_(indented_)?code_blocks and then the rest of the
> rendering process reusing the cached Markdown object in
> Bugzilla->markdown.

Actually, no, that's not the problem. I'm sorry for being so hasty to
post. If everything worked correctly, $self->_(indented_)?code_blocks
would always be empty after Bugzilla->markdown->markdown(...) returns.
My workaround "repairs" the object if it ever ends up in this state, but
it shouldn't be happening in the first place.

The problem arises due to Text::Markdown giving an empty string to
Bugzilla::Markdown where it expects a number of removed fenced code
blocks:

Bugzilla::Markdown::_DoDelayCodeBlocks(
 Bugzilla::Markdown=HASH(0x55561fd283e8),
 ""
) called at Bugzilla/Markdown.pm line 496
Bugzilla::Markdown::_DoBlockQuotes(
 Bugzilla::Markdown=HASH(0x55561fd283e8),
 ""
) called at /usr/share/perl5/Text/Markdown.pm line 534
Text::Markdown::_RunBlockGamut(
 Bugzilla::Markdown=HASH(0x55561fd283e8),
 "",
 HASH(0x55562094c9f8)
) called at /usr/share/perl5/Text/MultiMarkdown.pm line 313
Text::MultiMarkdown::_Markdown(
 Bugzilla::Markdown=HASH(0x55561fd283e8),
 "Some comments:\x{a}\x{f222}\x{a}\x{f111}\x{a}\x{f222}\x{a} "...
) called at /usr/share/perl5/Text/MultiMarkdown.pm line 269
Text::MultiMarkdown::markdown(
 Bugzilla::Markdown=HASH(0x55561fd283e8),
 "Some comments:\x{a}\x{f222}\x{a}\x{f111}\x{a}\x{f222}\x{a} "...
) called at Bugzilla/Markdown.pm line 79
Bugzilla::Markdown::markdown(
 Bugzilla::Markdown=HASH(0x55561fd283e8),
 "Some comments:\x{a}\x{a}  + I do not think there is ever a"...
) called at -e line 6

In turn, this happens because Text::MultiMarkdown::_ParseMetaData
returns an empty string when given the following:

$ perl -MText::MultiMarkdown -MData::Dumper -E'
 print Dumper(
  Text::MultiMarkdown::->new()->_ParseMetaData(
   "Some comments:\n\x{F222}\n\x{F111}\n\x{F222}\n\n"
  )
 )'
# $VAR1 = '';

This will happen to any comment that starts with a sentence ending with
a colon, followed by a code block:

$ perl -I. -MBugzilla -MBugzilla::Attachment -MBugzilla::Markdown \
 -MData::Dumper -MCarp::Always -MPath::Tiny -E'
 my $markdown = Bugzilla::Markdown::->new();
 print Dumper $markdown->markdown(
  "Starts with a colon:\n".q[```]
  ."\nfollowed by a code block\n".q[```]."\n"
 );
 if ( @{$markdown->_code_blocks}
   or @{$markdown->_indented_code_blocks}
  ) { die Dumper(
   $markdown->_code_blocks,
   $markdown->_indented_code_blocks
  ); }
'
$VAR1 = "Starts with a colon:<br>
\x{f111}<br>


";
$VAR1 = [
          'followed by a code block
'
        ];
$VAR2 = [];
 at -e line 7.

Disabling the MultiMarkdown metadata support seems to avoid this
problem:

--- a/Bugzilla/Markdown.pm
+++ b/Bugzilla/Markdown.pm
@@ -60,7 +60,10 @@ sub new {
     tab_width => MARKDOWN_TAB_WIDTH,

     # Bugzilla uses HTML not XHTML
-    empty_element_suffix => '>'
+    empty_element_suffix => '>',
+
+    # Otherwise may eat sentences ending with colons:
+    use_metadata => 0,
   );
   $obj->{tab_width}            = MARKDOWN_TAB_WIDTH;
   $obj->{empty_element_suffix} = '>';

At the very least, with the patch above, processing the whole
comment stream results in output as expected and empty
$markdown->_code_blocks and $markdown->_indented_code_blocks after each
comment.

-- 
Best regards,
Ivan