[Webkit-unassigned] [Bug 22210] don't allow NCRs with surrogate codepoints

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 14 15:52:47 PST 2008


jshin at chromium.org changed:

           What    |Removed                     |Added
                URL|                            |http://i18nl10n.com/webkit/n
                   |                            |cr.html

------- Comment #2 from jshin at chromium.org  2008-11-14 15:52 PDT -------
IMHO, we should stick to the standard unless there's a very compelling
compatibility reason for violating that. I don't think there is in this case
(for one, Firefox and IE disagree). I don't have any hard number [1], but I
guess we would gain very little in terms of compatibility by being compatible
with IE. 

IE7 does indeed interpret a pair of NCRs with high and low surrogate codepoints
as a single Unicode character. In the page at the URL field, both 1st and 3rd
columns are rendered identically by IE (U+10400 is shown). In the middle
column, the lone high surrogate code point (D801) is turned invisible while
DC00 (a lone low surrogate code point) is rendered as an empty box. 

Firefox turns any surrogate code points (paired or not) in NCR to U+FFFD
(replacement character). 

BTW, firefox's recent change (in addition to being compliant to CHARMOD) may
have been motivated by security concerns
(http://www.mozilla.org/security/announce/2008/mfsa2008-43.html )

[1] If you really need a hard number, I can produce (ask somebody to produce)
one based on Google's repository, but it seems too much work for too little.

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

More information about the webkit-unassigned mailing list