[Webkit-unassigned] [Bug 81270] FileApi does not handle files with NFD encoded umlaut in file name

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Toni Barzic <tbarzic at chromium.org>  2012-03-20 15:52:45 PST ---
(From update of attachment 132844)
View in context: https://bugs.webkit.org/attachment.cgi?id=132844&action=review

>> Source/WebCore/ChangeLog:3
>> +        [Chromium] FileApi does not handle files with NFD encoded umlaut in file name
> 
> Did you mean the other way around? TextEncoding::encode produces NFC, which is the standard encoding on the Web.

No, I did not mean another way around..
The problem occurs on ChromeOS, where we can access files on the external storage. These files may have names encoded in NFD form. When we try to access, we break because the file url is in NFC form, and the file cannot be fond on the disk.

>>> Source/WebCore/ChangeLog:10
>>> +        -switch all calls to encode to normalizeAndEncode except the ones in platform/KURLGoogle.cpp
>> 
>> Does that introduce another difference between KURL and GURL?  Can you write a test in LayoutTest/fast/url that shows the difference for this patch?
> 
> The goal of existing encode() behavior is to make WebKit on any platform generate the same kind of data as Windows browsers do. So when faced with input that's not in NFC form (like a file name on OS X), it converts the data to NFC.
> 
> I think that this just makes sense. Sending randomly normalized data across the wire (in URLs or otherwise) does not. This patch seems to affect all URLs, not just file system ones.

Do you think it would make sense to introduce encodeWithoutNormalization() method and call it only when generating file urls for filesystem operations?

>> Source/WebCore/platform/text/TextEncoding.h:72
>> +        CString normalizeAndEncode(const UChar*, size_t length, UnencodableHandling) const;
> 
> This new method does not make a lot of sense conceptually.
> 
> 1. There are multiple normalization schemes. Normalize to what?
> 2. You only need to normalize when using one of Unicode encodings (such as UTF-*). So, exposing this as a public method on TextEncoding is confusing.
> 3. As mentioned above, are there any cases where one wants non-NFC data?

see above

>> LayoutTests/fast/filesystem/file-from-file-entry-nfd-name.html:7
>> +<script src="resources/file-from-file-entry-nfd-name.js"></script>
> 
> Please don't split tests into .html and .js. The only exception is fast/js directory, and then the .js part should be pure JavaScript, no DOM.

Hm, most of the tests in fast/filesystem are sepoarated this way..

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