if a regex uses capture groups, it won't match if any of the resulting captures is longer than 49991 characters. If you try this regex: /start(.)*end/i on this text startXXXXXXend then it will match until you put more than 49991 "X" between "start" and "end". You can easily test it on http://regexpal.com/ It will work with firefox but not with safari or chrome. This bug does only affect regex with groups in it. If you change the the regex to: /start.*end/i then it will match.
Duplicate of bug 18327?
The title of this bug is misleading. There's no group longer than 49991 characters here. The group is one character long.
(In reply to comment #2) > The title of this bug is misleading. There's no group longer than 49991 > characters here. The group is one character long. > I changed the title. Hope it's more precise now.
The result of the capture group will only be the last character matched. The group is only going to capture a single character.
(In reply to comment #4) > The result of the capture group will only be the last character matched. The > group is only going to capture a single character. > OK. Bad example. The point is, that you'll get NO MATCH at all using webkit. If the text on which the group should match is longer than 49991 chars. Change the regex to: /start(.*)end/i Now you should get the whole XXXX as result of the group. But as with the example above it won't match with webkit...
As a quick fix you may want to try rewriting (.)* as (?:.*(.))? I think there is a good chance that this will be faster on most regex engines, and also this may well work on shipping Safari. (I'm afraid I don't have a 49991 character input string lying around to check). G.
I'm getting confused... It seems that's not only the length of the input string is important but also how you write the group condition... I provided an example page: http://mad-d-sign.de/webkit/regex.html You will see that Test1 and Test2 have slightly different group conditions. While Test1 will return only the last "X" in the first (and only) group Test2 will return all the "X" in the first group. Both regex work on the 49997 characters long input string. Test3 and Test4 again use the two different regex conditions but on a 49998 characters long input string. Test3 does NOT match while Test4 does. In non webkit browsers all 4 tests match. I really hope now it's clear what I wanted to show.
Here's another testcase which is a bit more realistic and very close to the situation which I was investigating when I found this issue. http://www.mad-d-sign.de/webkit/regex2.html It's interesting. The character limit seems to be different again here. We have some Text enclosed by <object> tags. Within are two groups we want to match. Test 1 will match and find the two groups. Group 1 includes all the "X" and group 2 just the word "sometext". In Test2 there is just one more "X" included. Test 2 will not match. The text in test 3 is exactly the same like in test 2. But the regex searches only one group. The one with the "X"s. Test 3 will match! So the additional group and the long text break test 2. Please notice. Test 2 will also match if I remove the question mark to do a greedy search. But in my case it could be that there are more object tags in my text like this: <object>XXXsometext</object><object>XXXsometext</object><object>XXXsometext</object> That's why I need the the none greedy switch. Otherwise I would only get one match including the whole text.
checked again after a long time. Seems to be fixed in Chrom 5.0.375.125! All tests are passed now. Nice!
This now works on Safari 5 on Mac OS X 10.6.4 as well. Marking as RESOLVED/FIXED.
Testing with Chrome makes no sense. This is a bug in code that Chrome does not use.
As mentioned in the first post. When this bug was filed this issue existed in Chrome too. Since I did not watch this topic quite a long time I don't know since when it's gone in Chrome or Safari. I'm just glad it's fixed.