escape() is incorrect

[ChALkeR]

Build environment: macOS
XS 16.9.1, slot 32 bytes, ID 4 bytes from jsvu

Description
escape() seems broken and does not properly escape chars

> ~/.jsvu/bin/xs -e "print(escape(String.fromCodePoint(0x80)))"                                   
�
> ~/.jsvu/bin/xs -e "print(escape(String.fromCodePoint(0x81)))"     
�
> ~/.jsvu/bin/xs -e "print(escape(String.fromCodePoint(0x80, 0x81)))"
%80%81
> ~/.jsvu/bin/xs -e "print(escape(String.fromCodePoint(0x7F)))"
%7F
> ~/.jsvu/bin/xs -e "print(escape(String.fromCodePoint(0x80, 0x42)))"
�B

0x80 and 0x81 should be always escaped, instead, the behavior depends on surrounding chars

Spec: https://tc39.es/ecma262/multipage/additional-ecmascript-features-for-web-browsers.html#sec-escape-string

It's in additional browser features, but if it's present it should be implemented correctly
Otherwise, feature-detecting libraries could misbehave (while e.g. not implementing this function at all would have been valid)

[phoddie]

Thanks for the report. We'll take a look. Agreed that if the implementation is non-conforming, it should be fixed.

This is pretty obscure. Would you share how you found it? Thanks!

[phoddie]

We've got a fix that will be part of our February release. Thanks again!

[ChALkeR]

This is pretty obscure. Would you share how you found it? Thanks!

@phoddie I wrote a test engine that supports testing across different platforms, including XS (repo, npm, docs)

That was also behind #1490 and #1515 reports

It supports snapshots (generated on Node.js), which in combination with fixed PRNG (e.g. from @noble/hashes) makes it easy to check that behavior is consistent on random data

I used that to build a lib which implements Uint8Array operations (including full TextEncoder / TextDecoder polyfill) (repo, npm, docs).

Example CI run on XS: https://github.com/ExodusOSS/bytes/actions/runs/21693593036/job/62558826407
(expand the 7 minutes step)

While it didn't fail on XS in regular tests, testing a codepath intended for Hermes (which uses escape() for performance reasons) failed on XS. See ExodusOSS/bytes@51623bb

This is how I found that

[phoddie]

Thank you for explaining. That all makes good sense. Very thorough cross-engine tests like this are the most practical way to find subtle variances between engines. test262 can't predict every possible place an implementation might diverge and no implementor gets every single spec step right. Consequently, incorrect edge cases like this do slip in. Thanks again for taking the time to report your findings.

FWIW – I dream of the day when there will be a differential fuzzer for JavaScript. That would automate this further. That's tricky though, because there are valid variance (Error messages, Math.random, Date()). Fuzzilli appears to have some active work in this direction, though it looks intended to be use to test different modes of an engine (JIT/no-JIT) rather than across engines.