Bug 96799 – WebString for Chromium has no way to do case-insensitive comparisons

• Component: WebKit Misc.
• Status: RESOLVED WONTFIX

[Brian White]

The Source/Platform/chromium/... WebString class has no way to do case-insensitive comparisons which are needed in order to recognize various tags that are not required to be all lower-case (even though they typically are).

CL forthcoming...

[Brian White]

Created attachment 164175 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[James Robinson]

Comment on attachment 164175 [details]
Patch

Where do you intend to use this?  Normally if you have a WebString and you want to do non-trivial operations on it you would convert it to the chromium or WebKit type (std::string, std::wstring, WTF::String) and do the operations there.

[Brian White]

It's in support of this:
http://codereview.chromium.org/10916316/

Which itself is in response to this:
http://code.google.com/p/chromium/issues/detail?id=145689

The basic problem is that the comparison of "meta" strings needs to be case-insensitive.  They're held as WebString objects and, while it's possible to convert them, it seems better to just allow access to the case-insensitive comparison already available for the internal representations.

-- Brian

[James Robinson]

In chromium code you can convert a WebString to base::string16 and do a case-insensitive comparison there.  That seems just as easy.

Case-insensitive comparisons are a bit tricky - depending on your locale and the exact use case it could mean one of many things.  Upper/lowercasing are not reversable operations on arbitrary unicode strings.

[Darin Fisher (:fishd, Google)]

(In reply to comment #5)
> In chromium code you can convert a WebString to base::string16 and do a case-insensitive comparison there.  That seems just as easy.
> 
> Case-insensitive comparisons are a bit tricky - depending on your locale and the exact use case it could mean one of many things.  Upper/lowercasing are not reversable operations on arbitrary unicode strings.

^^^ This.  Chromium shouldn't be holding onto WebString.  It is just a data type used to pass information across the API boundary.  I'd be surprised if the cost of copying a WebString matters.

[Brian White]

I don't think locale is relevant in this case since the strings being compared are things like "content-language" (from the "meta" tag in the HTML header).

As for whether Chromium should be using WebString or not for this case, I cannot say.  I just know that it _is_ and it is currently calling "equals" on these strings when it neeeds to call "equalsIgnoringCase".

Is there a reason why WebString should _not_ expose the "equalsIgnoringCase()" method of the implementing class when it already exposes "equals()"?

-- Brian

[Adam Barth]

The risk is that future code might call it in error.  WebString is just intended for interchange between WebKit ans the embedder, not for any "interesting" operations.

[Brian White]

As you wish.  I'll work around the limitation.