Bug 163894 – Remove Unicode case-insensitive matching for usemap=""

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Domenic Denicola]

In https://github.com/whatwg/html/commit/6acdb2122298d2bb7bb839c0a61b4e1f9b0f9bc9 we changed the HTML spec to remove all of its instances of "compatibility caseless" Unicode case-insensitive matching. There were three:

- <object usemap> matching <map name>
- <img usemap> matching <map name>
- radio button group names

All of these have been replaced with simple case-sensitive matching. WebKit already uses case-sensitive matching for radio button group names; see https://bugs.webkit.org/show_bug.cgi?id=90617#c21. This bug is about the usemap cases.

We believe this change will be low-risk due to Chromium use counter data from the stable channel, which reveals that <0.0001% of pages have a map attribute that matches using ASCII case-insensitive matching, but not using case-sensitive mapping. Furthermore, zero additional matches are triggered by Chrome's Unicode case-insensitive matching. Another reason to believe this is low-risk is that the particular Unicode case-insensitive matching used was highly inconsistent and unreliable across browsers; the spec's "compatibility caseless" was fiction.

More background at https://github.com/whatwg/html/issues/1666 and links contained therein. Web platform tests available at:

- http://w3c-test.org/html/semantics/embedded-content/the-img-element/usemap-casing.html
- http://w3c-test.org/html/semantics/embedded-content/the-object-element/usemap-casing.html

[Chris Dumez]

Looks like Firefox already behaves this way. Chrome does not yet.

[Chris Dumez]

Created attachment 297056 [details]
Patch

[Chris Dumez]

(In reply to comment #2)
> Created attachment 297056 [details]
> Patch

With this patch, we pass 100% of:
http://w3c-test.org/html/semantics/embedded-content/the-img-element/usemap-casing.html

[Build Bot]

Comment on attachment 297056 [details]
Patch

Attachment 297056 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2717392

New failing tests:
fast/images/image-usemap-parsing.html

[Build Bot]

Created attachment 297058 [details]
Archive of layout-test-results from ews125 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews125  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6

[Chris Dumez]

Created attachment 297060 [details]
Patch

[Darin Adler]

Surprised this ended up being case sensitive instead of ASCII case insensitive, but super happy that we are done with "compatibility caseless".

[WebKit Commit Bot]

Comment on attachment 297060 [details]
Patch

Clearing flags on attachment: 297060

Committed r209810: <http://trac.webkit.org/changeset/209810>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

It’s interesting: After this patch, there are only two call sites left in the entire WebKit project for the String::foldCase function:

1) In the UCONFIG_NO_COLLATION version of WebCore::SearchBuffer; I am not sure we should keep that around. Is anyone using that configuration?

2) In TypeAhead::handleEvent. Not entirely sure the use there is quite correct.

[Ryosuke Niwa]

(In reply to comment #10)
> It’s interesting: After this patch, there are only two call sites left in
> the entire WebKit project for the String::foldCase function:
> 
> 1) In the UCONFIG_NO_COLLATION version of WebCore::SearchBuffer; I am not
> sure we should keep that around. Is anyone using that configuration?
> 
> 2) In TypeAhead::handleEvent. Not entirely sure the use there is quite
> correct.

I think this code is about matching what the user typed with an option element's text so that should probably be using real Unicode case folding. Although that function really just wants to have startsWithIgnoringCase or something.

[Darin Adler]

(In reply to comment #11)
> (In reply to comment #10)
> > 2) In TypeAhead::handleEvent. Not entirely sure the use there is quite
> > correct.
> 
> I think this code is about matching what the user typed with an option
> element's text so that should probably be using real Unicode case folding.
> Although that function really just wants to have startsWithIgnoringCase or
> something.

Yes, it is about matching what the user typed. But search, for example, does not just use Unicode case folding, it uses other rules for matching that go beyond that, and it seems inadequate to search within the select list using case folded string matching rather than the actual rules we use to match when searching within text. I think the correct ICU API to use might be usearch, not the case folding function.