This is the correct behaviour in http://www.ecma-international.org/ecma-262/6.0/, and the working draft at http://tc39.github.io/ecma262/. It's also the correct behaviour for older properties like "multiline" and "global", which used to be own data properties of RegExp instances, and so would ordinarily return "undefined" instead of throwing.

I do vaguely recall discussion about making RegExp.prototype a RegExp object instead of a plain object without any of the RegExp internal slots again, but can't find this anywhere.

Yang knows more probably

Indeed working as intended.

And yes, I think there were discussions to revert RegExp.prototype to a RegExp object, but iirc nothing came of it. Dan should know more.

What is puzzling me is that this throws in Chrome beta (v48), but not in
Chrome canary (v49) or Chrome v47.
So maybe this was indeed reverted.

On Tue, 15 Dec 2015, 4:30 p.m. yangguo@chromium.org via Monorail <
v8@monorail-prod.appspotmail.com> wrote:

Well, the change was never reverted, and still lives in ToT (https://chromium.googlesource.com/v8/v8/+/master/src/js/harmony-regexp.js#44)

We reversed the ES2015 change of making Number.prototype an ordinary object without internal slots, but didn't really consider reversing it for RegExp. Mark Miller considered important from an SES perspective to have RegExp.prototype not be a RegExp because the compile method mainpulates a piece of shared state (though compile is not spec'd, and V8 already didn't allow compile on RegExp.prototype), and further, it's cleaner to have everything match the new ES2015 style of classes, embodied by class syntax, rather than the weird previous way, where the prototype was a sort of instance. I didn't realize it if there was a web compatibility risk for the ES2015 change of making RegExp.prototype not a RegExp.

The ES2015 spec makes it very clear that RegExp.prototype.sticky should throw. If you want to do feature testing, you can do 'sticky' in RegExp.prototype, or RegExp.prototype.hasOwnProperty('sticky'). But if this sort of feature testing is all over the web already, we may need to revisit this decision.

Chrome v49.0.2587.3 dev-m throws and v49.0.2593.0 canary, which is later, doesn't

Relevant CL: https://codereview.chromium.org/1509733010/. This has not yet hit Canary.

Setting to WontFix because this is working according to specification.

I might not be so quick to mark this as WontFix. Previously, RegExp.prototype.sticky was a way to feature-test for the 'sticky' flag. Now, feature testing has to use a different API. This is a potentially breaking change. I'd like to know whether this was encountered in practice on a website, or if it's a theoretical concern. We could argue for a spec change that these property accessors need to return 'undefined' on RegExp.prototype (or in general if the type check fails) due to web compatibility concerns in the standards committee, without overturning the whole prototype model.

I have come across this due to Atlassian Stash breaking, will give the
specifics tomorrow but its definitely causing compatibility issues in the
wild.

On Wed, 16 Dec 2015, 4:15 p.m. littledan@chromium.org via Monorail <
v8@monorail-prod.appspotmail.com> wrote:

Does it also break on other browsers?

OK, I reverted the patch for now. I think we might be able to solve this with a spec change to make that accessor more tolerant https://github.com/tc39/ecma262/issues/262 . It's unfortunate that people do feature testing this way, but it's so pervasive that I don't think we can tell them not to. We don't have a very ergonomic alternative available.

Firefox and Edge don't implement this behavior yet, as I wrote in the second comment on https://github.com/tc39/ecma262/issues/262

how many sites can possibly be performing a test like this? As opposed to `RegExp.prototype.hasOwnProperty("sticky")`. I assume this has been measured, because "RegExp.prototype.sticky" isn't a very useful test by itself anyways

This has not been measured. We only have a small number of UseCounters in V8 at the moment, and it is a bit of work to put in each one.

This pattern is a useful test--users can compare 'undefined' vs 'false' for the result for a reliable test of whether 'sticky' is supported.

I think the burden of proof for all of these compat issues should be on the advocates of the new, potentially breaking change that it's not breaking, rather than on the people pushing on the breaks. With the new stage model, future versions of ECMAScript should have more due diligence already done on web compatibility compared to the big group of untested changes that ES2015 gave us.

In this case, we have concrete evidence that this broke a site, and it came basically instantly after it was shipped in Canary. There's nothing strange about the usage (this follows the way people often do feature testing), and the website is prominent. For me, that's enough evidence that it's not web-compatible.

As far as I can tell, JSC does not implement "sticky" in YARR, and does not implement accessors for it in their builtin code, so that accounts for 1 browser.

https://bugzilla.mozilla.org/show_bug.cgi?id=1192038 seems to be the main issue for Mozilla, otherwise their code already implements the non-generic-ness that V8's does.

Not sure about Chakra, but I am willing to bet they just haven't gotten around to changing this yet. V8 may be in a good position to collect usage information, and most likely the usage here is very low

To elaborate, Atlassian Stash uses XRegExp, and that library contained this feature test.

According to https://www.npmjs.com/package/xregexp, it is a moderately widely used library.

The issue is only present in XRegExp v2 which was released in 2012. XRegExp v3 includes a more robust feature test that is compatible with the ES2015 spec.

Atlassian Stash (and anyone else still using XRegExp v2) should update to XRegExp v3. @vp2177, do you happen to have a contact at Atlassian?

FWIW, I’ve reached out to Atlassian asking them to update to XRegExp v3 in Bitbucket Server (which is the new name for Stash, apparently) through their support form.

Atlassian responded:

> The upgrade of XRegExp to v3 is occurring in the release of Bitbucket Server version 4.3, the details of this can be found here: BSERVDEV-11403 https://jira.atlassian.com/browse/BSERVDEV-11403

Awesome, thank you.

I haven't found anything else on the web actually, using this version of Chrome, that breaks.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/98f819c3e0c92d54a306cdacadda73cf96d21b52

commit 98f819c3e0c92d54a306cdacadda73cf96d21b52
Author: littledan <littledan@chromium.org>
Date: Tue Dec 22 06:35:22 2015

Add web compat workarounds for ES2015 RegExp semantics

Unexpectedly, websites depend on doing feature testing with
RegExp.prototype.sticky and browser testing with RegExp.prototype.toString().
ES2015 newly throws exceptions for both of these. In order to enable shipping
new ES2015 semantics, this patch puts in narrow workarounds for those two
cases, keeping their old behavior. UseCounters are added for how often
those particular cases come up, so we can see if it can be deprecated.

R=yangguo
BUG= v8:4637 , v8:4617 
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1543723002

Cr-Commit-Position: refs/heads/master@{#32997}

[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/include/v8.h
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/src/js/harmony-regexp.js
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/src/js/regexp.js
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/src/runtime/runtime-internal.cc
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/src/runtime/runtime.h
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/test/cctest/test-regexp.cc
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/test/mjsunit/es6/regexp-flags.js
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/test/webkit/fast/js/kde/RegExp-expected.txt
[modify] http://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52/test/webkit/fast/regex/toString-expected.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/08a1d1a28847caf62a996d93f11da982d2649061

commit 08a1d1a28847caf62a996d93f11da982d2649061
Author: bmeurer <bmeurer@chromium.org>
Date: Tue Dec 22 07:37:09 2015

Revert of Add web compat workarounds for ES2015 RegExp semantics (patchset #3 id:40001 of https://codereview.chromium.org/1543723002/ )

Reason for revert:
Breaks nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/5883

Original issue's description:
> Add web compat workarounds for ES2015 RegExp semantics
>
> Unexpectedly, websites depend on doing feature testing with
> RegExp.prototype.sticky and browser testing with RegExp.prototype.toString().
> ES2015 newly throws exceptions for both of these. In order to enable shipping
> new ES2015 semantics, this patch puts in narrow workarounds for those two
> cases, keeping their old behavior. UseCounters are added for how often
> those particular cases come up, so we can see if it can be deprecated.
>
> R=yangguo
> BUG= v8:4637 , v8:4617 
> LOG=Y
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
>
> Committed: https://crrev.com/98f819c3e0c92d54a306cdacadda73cf96d21b52
> Cr-Commit-Position: refs/heads/master@{#32997}

TBR=yangguo@google.com,yangguo@chromium.org,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= v8:4637 , v8:4617 

Review URL: https://codereview.chromium.org/1546493003

Cr-Commit-Position: refs/heads/master@{#32999}

[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/include/v8.h
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/src/js/harmony-regexp.js
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/src/js/regexp.js
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/src/runtime/runtime-internal.cc
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/src/runtime/runtime.h
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/test/cctest/test-regexp.cc
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/test/mjsunit/es6/regexp-flags.js
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/test/webkit/fast/js/kde/RegExp-expected.txt
[modify] http://crrev.com/08a1d1a28847caf62a996d93f11da982d2649061/test/webkit/fast/regex/toString-expected.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/424ef009a5d394ca212de8b8c91b963e424f7e72

commit 424ef009a5d394ca212de8b8c91b963e424f7e72
Author: littledan <littledan@chromium.org>
Date: Tue Dec 22 09:16:30 2015

Reland of Add web compat workarounds for ES2015 RegExp semantics (patchset #3 id:40001 of https://codereview.chromium.org/1543723002/ )

Unexpectedly, websites depend on doing feature testing with
RegExp.prototype.sticky and browser testing with RegExp.prototype.toString().
ES2015 newly throws exceptions for both of these. In order to enable shipping
new ES2015 semantics, this patch puts in narrow workarounds for those two
cases, keeping their old behavior. UseCounters are added for how often
those particular cases come up, so we can see if it can be deprecated.

This reland replaces problematic legacy const usage with var, to
avoid issues with nosnap builds.

R=yangguo
CC=bmeurer
BUG= v8:4637 , v8:4617 
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel

Review URL: https://codereview.chromium.org/1545633002

Cr-Commit-Position: refs/heads/master@{#33002}

[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/include/v8.h
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/src/js/harmony-regexp.js
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/src/js/regexp.js
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/src/runtime/runtime-internal.cc
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/src/runtime/runtime.h
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/test/cctest/test-regexp.cc
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/test/mjsunit/es6/regexp-flags.js
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/test/webkit/fast/js/kde/RegExp-expected.txt
[modify] http://crrev.com/424ef009a5d394ca212de8b8c91b963e424f7e72/test/webkit/fast/regex/toString-expected.txt

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3cdcef55d54c954da0eb448301ba53ee23ea37f4

commit 3cdcef55d54c954da0eb448301ba53ee23ea37f4
Author: littledan <littledan@chromium.org>
Date: Sat Dec 26 04:19:20 2015

Thread up two new V8 UseCounters for ES2015 RegExp compat

These UseCounters were added in the V8 patch at
https://codereview.chromium.org/1545633002
They track how often web compatibility-driven workarounds to the
ES2015 spec are triggered. If the frequency goes down over time,
then we can remove one or both of them.

R=japhet@chromium.org
CC=yangguo
BUG= v8:4637 , v8:4617 

Review URL: https://codereview.chromium.org/1547143002

Cr-Commit-Position: refs/heads/master@{#366891}

[modify] http://crrev.com/3cdcef55d54c954da0eb448301ba53ee23ea37f4/third_party/WebKit/Source/bindings/core/v8/V8PerIsolateData.cpp
[modify] http://crrev.com/3cdcef55d54c954da0eb448301ba53ee23ea37f4/third_party/WebKit/Source/core/frame/UseCounter.h

This was fixed by the patch at https://codereview.chromium.org/1545633002 . Unfortunately, I seem to have dropped the backport to 48 on the floor, and the fix is only found in 49.