1350575 - RegExp constructor doesn't preserve newlines in source

Status: RESOLVED INVALID

(DevTools :: Console, defect)

Description

[1212jtraceur]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36

Steps to reproduce:

In the JS console on a Nightly build (55.0a1 (2017-03-25) (64-bit)), run the following:

RegExp('\n').source


Actual results:

The string source of this regex contains the literal characters \ and n (codes 92 and 110).


Expected results:

The regex source should contain only a single linefeed character.

See here for more details/context: https://github.com/slevithan/xregexp/pull/163#issuecomment-288633467

> This seems to be a quirk in Firefox (not certain it's technically a bug).
> What's happening is that when the string pattern is converted into a regex,
> Firefox is changing the string '\n' (LF, char code 10) to the regex pattern /\n/,
> which seems inappropriate to me even if it's not technically a bug (not
> sure what the spec might have to say about this edge case which only matters
> when looking at the string  source  of the resulting regex). The string source
> of this regex now contains the literal characters \ and n (codes 92 and 110),
> rather than LF. :-/

Comment 1

[Loic]

Regressed by 1342526
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=be76983050c7cbefea0427a625627651a039b089&tochange=d13bb1ff158ac8a7a10e6cd687f8b1b03cc888ec

Comment 2

[1212jtraceur]

On second thought, it seems I was mistaken on this one, after reading through https://github.com/kangax/compat-table/issues/798 and the linked resources.

Comment 3

[Marcia Knous [:marcia]]

Adjusting flags based on the resolution of the bug.

Comment 4

[Tom Tromey :tromey]

Clearing the NI.