[Webkit-unassigned] [Bug 29103] typeAheadFind in select element is case-sensitive for Cyrillic and Greek

[bugzilla-daemon at webkit.org]

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


Hironori Bono <hbono at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hbono at chromium.org




--- Comment #5 from Hironori Bono <hbono at chromium.org>  2009-09-17 00:30:33 PDT ---
Thank you for your comments.
We should have had a discussion about how to fix this issue before sending a
review request. Sorry for sending such a confusing review request.

(In reply to comment #4)
> (From update of attachment 39415 [details])
> This seems like an awfully broad fix for such a specific symptom.

In my honest opinion, I'm also wondering if it is a good option to change
WTF::toASCIILower() with WTF::Unicode::toLower() in StringImpl::reverseFind() 
even though it is pretty simple.

> Are there other bugs caused by reverseFind using toASCIILower?

As far as I have tested, SelectElement::typeAheadFind() is the only possible
place which calls StringImpl::reverseFind() with non-ASCII string (via
WebCore::String::startsWith()).
That is, it may be an overkill to replace WTF::toASCIILower() with
WTF::Unicode::toLower() just for SelectElement::typeAheadFind().

> If the new way is better/more correct, wouldn't we want find to work the same way?

WTF::Unicode::toLower() calls an ICU function u_tolower(). So, it works not
only ASCII characters but also non-ASCII characters, such as Latin, Greek,
Cyrillic, etc. But, as I noted above, SelectElement::typeAheadFind() is the
only possible place that needs this feature.

> What performance impact does this have?

Even though I haven't measured any data. I'm sure this change decreases the
performance of parsers more or less, because StringImpl::startsWith() is called
from many parsers, such as CSS parsers, HTML parsers, etc.

Regards,

Hironori Bono

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