24166 2009-02-25 11:47:29 -0800 Regex: capture groups don't match on text longer than 49991 chars 2010-07-28 01:03:22 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) PC Windows XP RESOLVED FIXED P2 Normal --- 0 nk111 webkit-unassigned barraclough darin ddkilzer ggaren nk111 oldest_to_newest 110995 0 nk111 2009-02-25 11:47:29 -0800 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. 111225 1 ap 2009-02-26 10:48:36 -0800 Duplicate of bug 18327? 111237 2 darin 2009-02-26 11:12:20 -0800 The title of this bug is misleading. There's no group longer than 49991 characters here. The group is one character long. 111262 3 nk111 2009-02-26 11:58:34 -0800 (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. 111291 4 darin 2009-02-26 13:13:41 -0800 The result of the capture group will only be the last character matched. The group is only going to capture a single character. 111295 5 nk111 2009-02-26 13:59:52 -0800 (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... 111399 6 barraclough 2009-02-26 23:55:55 -0800 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. 111422 7 nk111 2009-02-27 02:31:43 -0800 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. 111625 8 nk111 2009-02-28 09:16:15 -0800 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. 256832 9 nk111 2010-07-27 14:19:00 -0700 checked again after a long time. Seems to be fixed in Chrom 5.0.375.125! All tests are passed now. Nice! 256862 10 ddkilzer 2010-07-27 14:56:04 -0700 This now works on Safari 5 on Mac OS X 10.6.4 as well. Marking as RESOLVED/FIXED. 256882 11 darin 2010-07-27 15:16:53 -0700 Testing with Chrome makes no sense. This is a bug in code that Chrome does not use. 257060 12 nk111 2010-07-28 01:03:22 -0700 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.