{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecma262/issues/262","labels_url":"https://api.github.com/repos/tc39/ecma262/issues/262/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecma262/issues/262/comments","events_url":"https://api.github.com/repos/tc39/ecma262/issues/262/events","html_url":"https://github.com/tc39/ecma262/issues/262","id":122600427,"number":262,"title":"Feature testing no longer possible with RegExp.prototype.sticky","user":{"login":"littledan","id":189835,"avatar_url":"https://avatars.githubusercontent.com/u/189835?v=3","gravatar_id":"","url":"https://api.github.com/users/littledan","html_url":"https://github.com/littledan","followers_url":"https://api.github.com/users/littledan/followers","following_url":"https://api.github.com/users/littledan/following{/other_user}","gists_url":"https://api.github.com/users/littledan/gists{/gist_id}","starred_url":"https://api.github.com/users/littledan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/littledan/subscriptions","organizations_url":"https://api.github.com/users/littledan/orgs","repos_url":"https://api.github.com/users/littledan/repos","events_url":"https://api.github.com/users/littledan/events{/privacy}","received_events_url":"https://api.github.com/users/littledan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2015-12-16T21:02:09Z","updated_at":"2015-12-17T02:26:36Z","closed_at":null,"body":"Some websites check for whether the JavaScript implementation supports the 'sticky' flag by reading RegExp.prototype.sticky. Under ES2015, this throws a TypeError because RegExp.prototype is not a RegExp.\r\n\r\nhttps://bugs.chromium.org/p/v8/issues/detail?id=4617#c9\r\n\r\nWhat if we make these flag accessors a little more tolerant? If `this` does not have a [[RegExpMatcher]] internal slot, how about returning `false`? As it stands, this is blocking us from shipping sticky RegExps."},"comment":{"url":"https://api.github.com/repos/tc39/ecma262/issues/comments/165317063","html_url":"https://github.com/tc39/ecma262/issues/262#issuecomment-165317063","issue_url":"https://api.github.com/repos/tc39/ecma262/issues/262","id":165317063,"user":{"login":"littledan","id":189835,"avatar_url":"https://avatars.githubusercontent.com/u/189835?v=3","gravatar_id":"","url":"https://api.github.com/users/littledan","html_url":"https://github.com/littledan","followers_url":"https://api.github.com/users/littledan/followers","following_url":"https://api.github.com/users/littledan/following{/other_user}","gists_url":"https://api.github.com/users/littledan/gists{/gist_id}","starred_url":"https://api.github.com/users/littledan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/littledan/subscriptions","organizations_url":"https://api.github.com/users/littledan/orgs","repos_url":"https://api.github.com/users/littledan/repos","events_url":"https://api.github.com/users/littledan/events{/privacy}","received_events_url":"https://api.github.com/users/littledan/received_events","type":"User","site_admin":false},"created_at":"2015-12-17T02:26:36Z","updated_at":"2015-12-17T02:26:36Z","body":"@allenwb I think *undefined* would make it feature-test as missing, rather than present. I'd rather it feature-test as present so users can take advantage of it.\r\n\r\nI'd really rather not separate this out into Annex B. Right now, Annex B consists of larger, \"chunky\" things. There's a lot in the main spec that's there for compatibility, for example all the extra logic in ArraySpeciesCreate. It would be a mess to move everything like this out into Annex B just because it has to do with compatibility.\r\n\r\nI'm somewhat skeptical putting things in Annex B. There are some things that are really separate and seem to make sense, like `String.prototype.blink`. But I think most of what's there is really core to getting JavaScript running. Many non-web embedding environments, like Node, have both backwards compatibility concerns that require Annex B, or some even beyond that, would really like consistent execution with their non-browser environment compared to the browser. Separating them just makes reading the spec unclear. One person at Google tried to implement JavaScript-compatible regular expressions, and implemented the part that's in the main spec, but was really frustrated to later see the Annex B additions. It's confusing to piece those two parts together (there's no single grammar or semantics definition). I'd really rather not further this confusion by separating out the definition of the 'sticky' accessor into the hypothetical one with the world with no backwards compatibility concerns, and the real-world one in Annex B.\r\n\r\n@evilpie Oh sorry, I just skimmed the thread and saw a bunch of discussion about things throwing and compatibility concerns; it was an honest misunderstanding.\r\n\r\n@bterlson It's not clear to me exactly what we would do with usage data. Say we find that 0.5% of the web reads RegExp.prototype.sticky. Then what do we do? How do we do effective evangelism, and then how do we know that we're done? I'd rather stay conservative and maintain existing interfaces until there's a strong justification to changing them.\r\n\r\nV8 has tried to ship this and run extremely quickly into the fact that it broke the web. The offending code actually looks pretty typical to me, given the way the rest of JavaScript and web APIs work and the way that feature testing is often done. It's the ES2015 spec which is uncharacteristically strict in its checking, not the user code being especially sloppy. It's just not common in JavaScript for reading an innocent property on a primordial to throw like that. The spec change to fix web compatibility would be simple: replace throwing the TypeError with returning false."}}