« Bugzilla Issues Index

#1553 — Change “EscapeSequence 0 [lookahead ∉ DecimalDigit]” to match reality

As posted by Yusuke Suzuki (

EscapeSequence ::
0 [lookahead ∉ DecimalDigit]

Because of "[lookahead ∉ DecimalDigit]", strictly speaking, "\08" and "\09" are ill-formed StringLiterals.
But engines in the wild (at least V8, SpiderMonkey, JSC) accept this form and recognize it as "\x008".

To bridge the gap, I think it would be better to introduce this form to the spec officially.

Added some tests here: (see the last two tests)

Behaviour for noctal escapes in strict-mode is different across engines, e.g. the proposed tests only work in V8 and Presto, other engines report a strict-mode error (SpiderMonkey/JSC/IE).

EscapeSequence with leading "0":
- sloppy mode
=> accepted in major engines as "\08" == "\0" + "8"

- strict mode
=> accepted in V8/Presto as "\08" == "\0" + "8"
=> SyntaxError in IE/JSC/SpiderMonkey

EscapeSequence without leading "0":
- sloppy mode
=> accepted in major engines as "\8" == "8"

- strict mode
=> accepted in IE/SpiderMonkey/V8/Presto as "\8" == "8"
=> SyntaxError in JSC

- sloppy mode
=> accepted in major engines as 08 == 8
=> Note: SpiderMonkey reports warning in shell

- strict mode
=> accepted in IE/Presto/JSC/V8 as 08 == 8
=> SyntaxError in SpiderMonkey


> While this is a perfectly valid error to throw, it apparently breaks banks. Throwing a warning and automatically falling back to handling the literal as decimal rather than octal would possibly be preferable (at least for the time being).

Sounds like the spec needs to be changed to match reality after all.

That bug is about number literals like 08, not string escape sequences.

But yes, alas, I think we will have to back out the patch we landed in <>. The spec should do the same.

See also Bug #3124, (which relates to legacy octal escape sequences followed by 8 or 9 in sloppy mode, rather than \0 followed by 8 or 9 in all modes).

I've open Bug 3477 for a definite answer to the more general issue of backslash followed by one ore more digits in string and template literals.

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