Javascript Regular Expression Non-participating capturing groups behave incorrectly in edge cases. Steve Levithan did a case study on which forms of non-capturing groups conformed to the ECMA spec and Safari passes a paltry 1 of his use cases. Please refer to his blog post for details: http://blog.stevenlevithan.com/archives/npcg-javascript
Created attachment 15923 [details] Test case based on Steve Levithan's blog post
Created attachment 15924 [details] Working test case based on Steve Levithan's blog post
WebKit ToT passes three of the tests. Opera 9.22 passes them all.
<rdar://problem/5403816>
MRowe, thank you for the test case. It looks like my results listed for IE and Firefox were correct, but not the results for Opera or Safari. I hate to misrepresent things like that. I used a slightly modified version of the dump method from netgrow.com.au to generate my original results (I've just reproduced them now). It looks like that code had problems. So Safari gets 3 out of 14, instead of 1. :-) I will update my blog post as appropriate.
Steven, I did my tests against newer versions of both Opera and WebKit than the results in your blog post, so that probably accounts for the differences.
I wonder if later versions of PCRE have fixed these issues.
(In reply to comment #7) > I wonder if later versions of PCRE have fixed these issues. Some of the most basic issues are differences between Perl and JavaScript, so I wouldn't expect PCRE to fix them. Instead I think it's up to us to patch PCRE so it doesn't have these issues. That's what the JAVASCRIPT macro in our PCRE is for -- so we can make changes like these that are theoretically suitable to merge upstream.
Created attachment 15941 [details] patch that fixes a couple of the failures There are many separate issues here, some inside PCRE and some outside. Here's a fix to one of the issues, specific to String.replace.
8 of the tests are failing because the PCRE engine uses the same array for results from the regular expression match that it uses internally to determine what back-references should match. So all the cases that say (x)?\1 fail to match since there is no expression 1. The specification says that \1 should match the empty string in this case. This is all discussed in the article, but I thought it was worth mentioning that the issue is affecting 8 of the test cases.
Created attachment 15945 [details] patch, fixes 3 problems so all the tests pass now
(In reply to comment #7) > I wonder if later versions of PCRE have fixed these issues. FWIW, none of these problems turned out to be PCRE bugs.
Comment on attachment 15945 [details] patch, fixes 3 problems so all the tests pass now r=me
Committed revision 25026.