Bug 218018 – Error handling for ISO-2022-JP is incorrect

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: DOM

[Anne van Kesteren]

See tests added and corrected in https://github.com/web-platform-tests/wpt/pull/26158. In particular it seems 0x0E, 0x0F, and 0x1B are not treated as errors which could lead to XSS in badly constructed sites.

(I think a similar problem applies to form submission, but I didn't write tests for that.)

(There's also some specification changes for this: https://github.com/whatwg/url/pull/558 and https://github.com/whatwg/encoding/pull/238.)

[Darin Adler]

Strange, Alex’s new code in TextCodecCJK::iso2022JPDecode has code like this:

    if (byte <= 0x7F && byte != 0x0E && byte != 0x0F && byte != 0x1B) {
        m_iso2022JPOutput = false;
        result.append(byte);
        break;
    }
    m_iso2022JPOutput = false;
    return SawError::Yes;

Sure looks like that would treat it as an error. Wonder why that’s not working. Or maybe Anne is testing an older version of Safari that used the ICU decoder?

[Darin Adler]

Oh, is this encode rather than decode?

[Alex Christensen]

*** This bug has been marked as a duplicate of bug 218046 ***