Bug 14931 – JavaScript regular expression non-participating capturing parentheses fail in 3 different ways

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Kris Kowal]

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

[Mark Rowe (bdash)]

Created attachment 15923 [details]
Test case based on Steve Levithan's blog post

[Mark Rowe (bdash)]

Created attachment 15924 [details]
Working test case based on Steve Levithan's blog post

[Mark Rowe (bdash)]

WebKit ToT passes three of the tests.  Opera 9.22 passes them all.

[Mark Rowe (bdash)]

<rdar://problem/5403816>

[Steven Levithan]

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.

[Mark Rowe (bdash)]

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.

[David Kilzer (:ddkilzer)]

I wonder if later versions of PCRE have fixed these issues.

[Darin Adler]

(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.

[Darin Adler]

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.

[Darin Adler]

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.

[Darin Adler]

Created attachment 15945 [details]
patch, fixes 3 problems so all the tests pass now

[Darin Adler]

(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.

[Maciej Stachowiak]

Comment on attachment 15945 [details]
patch, fixes 3 problems so all the tests pass now

r=me

[Darin Adler]

Committed revision 25026.