User-Agent: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.8.1.2) Gecko/20061201 Epiphany/2.18 Firefox/2.0.0.2 (Ubuntu-feisty) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en; rv:1.8.1.2) Gecko/20061201 Epiphany/2.18 Firefox/2.0.0.2 (Ubuntu-feisty) When searching for text on a webpage precomposed characters are not found/searched as their equivalent characters according to Unicode. Example: - a page has "école" that's with <U+00E9 LATIN SMALL LETTER E WITH ACUTE>. - search for "é" <U+0065 LATIN SMALL LETTER E;U+0301 COMBINING ACUTE ACCENT> Result, "école" is not a match yet "é" should match "é" Reproducible: Always

Related bug: bug 202251

(In reply to comment #1) > Related bug: bug 202251 Both bugs should be fixed together. Altough I'd suggest fixing bug 374795 (this bug) first. To fix 374795, it would be enough to normalize strings to NFD before comparison. To fix 202251, the NFD strings could be stripped from some categories of characters (combining marks, enclosing marks, non spacing marks, and some punctuation). One might want to go as far as NFKD instead of NFD for opaque match, i.e. ² would match 2.

(In reply to comment #2) > One might want to go as far as NFKD instead of NFD for opaque > match, i.e. ² would match 2. In that case, there should be a checkbox or something - overgeneralizing at search engines is annoying. Surprisingly, Google searches for “²” and not “2”, though, while Yahoo and Yandex search for “2”.

OK, let’s consider this not‐a‐duplicate. I am now using Unicode quotes and dashes all the time, so I support this enhancement (it is, if I am right that no other browser has this feature). I am not sure if, say, ‘«’, ‘“’ and ‘"’ can be all considered equivalent without custom configuration data…

Probably comment #4 is better suited for bug 202251, though.

This originated as a Firefox bug, so it shouldn't have been moved to Seamonkey, I think.