The RegEx engine is not behaving correctly for special characters (Octal escaped anyway.) This shouldn't match \s according to the info I have read, which makes sense, but this script works fine in the current Release version. <html><head> <script type="text/javascript" language="javascript1.2"> <!-- var text = "foo"; var nbsp = "\xa0"; alert("Orig: (" + text + ")"); text = text + nbsp + nbsp + nbsp; alert("After: (" + text + ")"); var re = new RegExp(/\xa0*$/); text = text.replace(re,''); alert("Stripped: (" + text + ")"); //--> </script> </head> <body></body> </html>
Created attachment 9047 [details] test case Same test as an attachment.
<rdar://problem/4613467>
Doing more tests I find that \xa0 works fine by itself in a regular expression. It's only failing when it comes right before a *. I suspect the bug is with any character > 127 before a * in a regular expression.
Created attachment 9448 [details] patch with detailed change log and a layout test
(In reply to comment #4) > Created an attachment (id=9448) [edit] > patch with detailed change log and a layout test COMMITTERS: Be ware of applying this patch until Bug 9875 lands! (I'm almost done testing it.) Darin, do the PCRE changes need to be submitted "upstream" back to the PCRE project?
(In reply to comment #5) > Darin, do the PCRE changes need to be submitted "upstream" back to the PCRE > project? After reading the JavaScriptCore changelog, I see that JSC is using a modified PCRE-6.1 that supports UTF-16, so these changes don't make sense to be sent "upstream".
It's worth noting that we have dreams of submitting upstream to PCRE, and, initially, at least, they've said they're amenable by email. We just haven't had the time to work it out.
Comment on attachment 9448 [details] patch with detailed change log and a layout test these non-layout bugs are just too easy
> COMMITTERS: Be ware of applying this patch until Bug 9875 lands! (I'm almost > done testing it.) why?
(In reply to comment #9) > > COMMITTERS: Be ware of applying this patch until Bug 9875 lands! (I'm almost > > done testing it.) > > why? Did you read Bug 9875? The current svn-apply script (and it's had this "feature" for a while now) thinks it can apply patches better than patch(1) can, so all of the svn-property information at the "end" of some of the layout test files will be included in the content of the files when the patch is applied.
(In reply to comment #10) > Did you read Bug 9875? The current svn-apply script (and it's had this > "feature" for a while now) thinks it can apply patches better than patch(1) > can, so all of the svn-property information at the "end" of some of the layout > test files will be included in the content of the files when the patch is > applied. So the work-around is to manually fix the files with property changes in them after using svn-apply until the bug is fixed.
> Did you read Bug 9875? Sorry. I guess it was early for me. For some reason, my brain was convinced that Bug 9875 was the ChangeLog fix to svn-apply!
(In reply to comment #4) > Created an attachment (id=9448) [edit] > patch with detailed change log and a layout test This patch may also fix Bug 9894.
Committed revision 15455.