Bug 207736 – import-w3c-tests rewriter breaks tests imported/w3c/web-platform-tests/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp-decode*

• Status: NEW
• Component: Tools / Tests

[Carlos Alberto Lopez Perez]

This was discovered meanwhile updating the encoding/ checkout in bug 207644

- The WPT test importer does some strange rewrites of the following two files
imported/w3c/web-platform-tests/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp_chars-csiso2022jp.html (diff from wpt original file: http://sprunge.us/sEkd3Z?diff )
imported/w3c/web-platform-tests/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp_chars.html (diff from wpt original file: http://sprunge.us/XYoSO1?diff )

As you see it adds some strange extra ";" and also comments out some closing span tags.

This two files are needed by the tests 
imported/w3c/web-platform-tests/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp-decode.html
imported/w3c/web-platform-tests/encoding/legacy-mb-japanese/iso-2022-jp/iso2022jp-decode-csiso2022jp.html

this two tests load those files inside an iframe

This strange rewrite that the WPT importer does breaks the subtests affected by those lines
If the right file its used (the original from WPT) all subtests pass (zero failures), but with the strange file rewrote by the WPT test importer there are 26 FAIL lines on the expectation that shouldn't be there.

[Radar WebKit Bug Importer]

<rdar://problem/69331956>

[Sam Sneddon [:gsnedders]]

I'd assume this is caused by the webkitpy.w3c.test_converter parse/serialize cycle. 

One option is waiting on bug 218987 and hoping we get rid of the test converter at that point (or waiting for part 2, bug 218992, which will be the latest point at which it is gone).

The other option is getting the test_converter to not actually rewrite the file if it doesn't make any mutations.