[Webkit-unassigned] [Bug 50554] RegExp.prototype.toString does not escape slashes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=50554





--- Comment #2 from Gavin Barraclough <barraclough at apple.com>  2011-01-14 11:40:29 PST ---
(In reply to comment #1)

Hi Mark,

> From ES5 15.10.7.1:
> "The value of the source property is a String in the form of a Pattern representing the current regular expression."

The term 'representing' seems ambiguous to me, but I guess we can safely assume a pattern represents a regular expression if it would compile to have the same [[Match]] behavior.

I'd suggest the use of the indefinite article is probably key in interpreting this sentence.  The spec refers to 'a' pattern rather than requiring a particular pattern - if the spec is intended to require 'the' pattern from which it was compiled I think it would say so.  As such, given the RegExp /ABC/ I'd suggest that an implementation could return "ABC", "\x61\x62\x63", or any other pattern that would compile to produce the same expression, and still be considered to be in compliance with the spec.

> The grammar for Patterns (15.10.1) seems to indicate that the way Firefox does it is incorrect.

Sorry - I don't follow, what's your reasoning here? - based on the interpretation above, FF's pattern does represent the source, and "abc\/def" is a valid pattern per section 15.10.1 of the spec ("\/" is a valid IdentityEscape).  Are you assuming a more strict definition of 'source'? - that it must match the pattern compiled from?

> I have a patch that fixes the problem with toString() without modifying the behavior of the source property, but it would be much simpler if the behavior of the source property needed to change as well.  Is this what needs to happen?

Great!

If FireFox's behavior is incorrect, then we should stick to producing "abc/def" for source, & just change toString.  But assuming my interpretation of the spec is correct, I'd say changing 'source' too to match FireFox make sense.

pros to switching:
* it's good from a web compatibility perspective to match FireFox.
* from a developer's perspective, the escaped form is more useful (can be concatenated into a string & eval'ed as a valid RegularExpressionLiteral).
* from a developer's perspective, I'd argue having two string representations for a RegExp would be potentially confusing & could be problematic, likely better to have a single canonical string representation associated with a given RegExp.

cons to switching:
* intuitively it seems like 'source' should actually be the source the expression was compiled from.

On balance, I'd certainly favour following FF on this one.

cheers,
G.

[ I think there is probably a cleaner and simpler solution, that is also likely completely impractical.  The fundamental problem here is that there are valid patterns that are not a valid RegularExpressionLiteral.  If we could just amend the spec to make an unescaped forwards slash an invalid pattern character, then this issue should go away. :-P ]

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.