The following descriptions of browser behavior are based on testing in Internet Explorer 5.5–8, Firefox 3.5, Safari 4, Chrome 2, and Opera 9.64.
There are several cross-browser inconsistencies when using a regular expression as the delimiter with the native String.prototype.split method. Divergences from the ECMA-262 Edition 3 (ES3) standard are listed below.
undefined into the returned array as the result of nonparticipating capturing groups.split specification (Opera passes all tests).XRegExp overrides the native String.prototype.split method with a uniform cross-browser implementation that precisely follows the relevant specification (ES3 §15.5.4.14, pp.103–104).
lastIndex updatesThere are several cross-browser inconsistencies between how the lastIndex property of regular expression objects is incremented and reset. This can cause problems even if you never manually check or set lastIndex in your code, because the RegExp.prototype.exec and RegExp.prototype.test methods use lastIndex to determine the subject string character index where their search should begin. Regexes that use the /y (sticky) flag (new in JavaScript 1.8) have all matches anchored to lastIndex. Divergences from ES3 are listed below, but note that these bugs apply only to regexes that use the /g flag.
lastIndex after zero-length matches using RegExp.prototype.exec and RegExp.prototype.test.lastIndex to the ending position of the last match after running String.prototype.replace and String.prototype.match, rather than resetting it to zero.lastIndex during String.prototype.replace iterations (visible within replacement functions).The XRegExp library automatically fixes these issues for all regexes.
In Internet Explorer, captured values for nonparticipating capturing groups are incorrectly returned by RegExp.prototype.exec and String.prototype.match as an empty string rather than undefined, making it impossible to determine group participation. Firefox splices empty strings instead of undefined into the array returned by String.prototype.split as the result of nonparticipating capturing groups.
The XRegExp library automatically fixes these return values for all regexes.
Traditional regex behavior is that a leading, unescaped ] within a character class is treated as a literal character and does not end the character class. However, this is not true for ES3, which states that [] is an empty set that will never match (similar to \b\B) and [^] matches any single character (like [\s\S] or [\0-\uFFFF]). Internet Explorer and older versions of Safari use the traditional behavior, rather than the correct ES3 behavior. Opera reverses the correct ES3 behavior, so that [] matches any character and [^] never matches.
Regexes created by XRegExp follow the ES3 standard behavior cross-browser.
Internet Explorer incorrectly treats all occurrences of $ as literal text when performing a replacement based on a search value that is not a regular expression.
XRegExp restores the special meaning of $$, $&, etc. for all replacements.