ANSI colour reset code \x1B[00m does not work

Summary

In CI runner log (HTML view of text output), the commonly used ANSI reset code \x1B[00m does not reset the "terminal" state. The code \x1B[0m does work.

Steps to reproduce

Submit a CI job containing this

#!/bin/dash
printf '\e[32m green \e[m might be normal again? \e[46m cyan background \e[00m should be back to normal \e[0m probably is back to normal\n'

and compare the HTML-view output to what a terminal shows.

Example Project

No example project sorry, but see possible fixes.

This was on an internal "GitLab Community Edition 13.1.4". I waited until local sysads updated from that version before reporting this bug.

What is the current bug behavior?

This often manifests with various tools leaving large expanses of gratuitously coloured text. I have only just realised why they're doing that.

Colours are not reset with CSI 00m, instead the previously effective display styling continues.

The codes CSI m and CSI 0 m do work as expected.

What is the expected correct behavior?

It seems to be a common expectation of colour-generating code that the 00 version will reset state. I had been copying this (cargo cult style), but after reading the references (below) I see I am wasting two bytes.

Output of checks

Untested, sorry for the hit'n'run bug. It's only minor and I guess it's in a library you're using?

Results of GitLab environment info

I don't have access to this on our local install.

Results of GitLab application Check

I don't have access to this on our local install.

Possible fixes

This looks promising,

gitlab-foss-v13.1.4/spec/lib/gitlab/ci/ansi2html_spec.rb:    expect(convert_html("\e[31;44mHello\e[0m world")).to eq('<span class="term-fg-red term-bg-blue">Hello</span><span> world</span>')

so I took a fork and will give it a quick poke.

References

Convenient but probably not definitive

The only related issue I can find is #28598.