Summary: | Remove Unicode case-insensitive matching for usemap="" | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Domenic Denicola <d> | ||||||||
Component: | DOM | Assignee: | Chris Dumez <cdumez> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | cdumez, commit-queue, darin, kling, koivisto, rniwa | ||||||||
Priority: | P2 | ||||||||||
Version: | Safari Technology Preview | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Domenic Denicola
2016-10-24 08:49:52 PDT
Looks like Firefox already behaves this way. Chrome does not yet. Created attachment 297056 [details]
Patch
(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 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 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
Created attachment 297060 [details]
Patch
Surprised this ended up being case sensitive instead of ASCII case insensitive, but super happy that we are done with "compatibility caseless". Comment on attachment 297060 [details] Patch Clearing flags on attachment: 297060 Committed r209810: <http://trac.webkit.org/changeset/209810> All reviewed patches have been landed. Closing bug. 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. (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. (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. |