archives

« Bugzilla Issues Index

#1433 — 15.5.4.11: String.prototype.replace calls function even if no match was found

• bug_id: 1433
• creation_ts: 2013-04-11 13:37:00 -0700
• short_desc: 15.5.4.11: String.prototype.replace calls function even if no match was found
• delta_ts: 2013-05-14 18:13:26 -0700
• product: Draft for 6th Edition
• component: technical issue
• version: Rev 14: March 8, 2013 Draft
• rep_platform: All
• op_sys: All
• bug_status: RESOLVED
• resolution: FIXED
• priority: Normal
• bug_severity: normal
• everconfirmed: true
• reporter: André Bargull
• assigned_to: Allen Wirfs-Brock

---

• commentid: 3629
• comment_count: 0
• who: André Bargull
• bug_when: 2013-04-11 13:37:35 -0700

Change algorithm to stop after step 8 if no match was found to ensure compatibility with ES5.

Also remove assertion in step 5 to handle case when RegExp.prototype.@@isRegExp has been removed.


And two additional typos in Table 33:
"emptry" -> "empty" (twice!) and "stringLenth" -> "stringLength"


And for the implementation-defined notes, see bug 1133. Test262 already tests for a certain implementation.

---

• commentid: 3664
• comment_count: 1
• who: Allen Wirfs-Brock
• bug_when: 2013-04-19 15:53:52 -0700

fixed in rev 15 editor's draft.

Regarding the implementation-defined behavior. Is there any variation among existing major implementations?

---

• commentid: 3709
• comment_count: 2
• who: André Bargull
• bug_when: 2013-05-06 14:38:47 -0700

Simply returning after step 8 may not be the right solution due to side effects:
"a".replace("b", {toString: function(){throw 0}})
"a".replace(/b/, {toString: function(){throw 0}})

All major browsers throw an exception for the second call (search value is RegExp). For the search value is String case, JSC and V8 behave differently compared to the others, i.e. they do not throw an exception.

---

Concerning the implementation-defined behaviour question:


Based on the source code at [1,2,3], SpiderMonkey, V8 and JSC all seem to share the same behaviour. Opera seems to be compliant as well, checking the actual source code may be beneficial, though. IE10 has an extension where $0 (and $00) refer to the entire matched pattern, e.g. "ab".replace(/(a)b/, "$1_$01_$0_$00") === "a_a_ab_ab".

For the case where the referenced capture does not exist, the behaviour seems to be the same across all major browsers (also see referenced source code from SM/V8/JSC):

"ab".replace("a", "$2") === "$2b"
"ab".replace(/(a)/, "$2") === "$2b"
"a".replace(/((((((((((a))))))))))/, "$9_$09_$10_$11") === "a_a_a_a1"

Maybe it was allowed to be implementation defined for older SpiderMonkey versions [4], but since [5] SpiderMonkey works like the others. Based on [6], Netscape Navigator also had some quirks, but that isn't important anymore, is it?


[1] http://hg.mozilla.org/mozilla-central/file/b842d26dd5f0/js/src/jsstr.cpp#l1934
[2] http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/string.js?r=14560#328
[3] https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/StringPrototype.cpp?rev=149637#L163
[4] http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsstr.c&rev=3.19&root=/cvsroot#975
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=104375
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=104375#c5

---

• commentid: 3909
• comment_count: 3
• who: Allen Wirfs-Brock
• bug_when: 2013-05-14 18:13:26 -0700

resolved in rev 15, May 14, 2013 draft