Bug 179963 - Unrepresentable characters in <input type="file"> filenames are incorrectly encoded
Summary: Unrepresentable characters in <input type="file"> filenames are incorrectly e...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-22 19:24 PST by Victor Costan
Modified: 2017-11-23 14:02 PST (History)
6 users (show)

See Also:


Attachments
Patch (58.24 KB, patch)
2017-11-22 19:33 PST, Victor Costan
ap: review-
ews: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews103 for mac-elcapitan (2.15 MB, application/zip)
2017-11-22 20:33 PST, Build Bot
no flags Details
Archive of layout-test-results from ews116 for mac-elcapitan (2.91 MB, application/zip)
2017-11-22 20:57 PST, Build Bot
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Costan 2017-11-22 19:24:23 PST
Unrepresentable characters are currently converted to "?". All other browsers use HTML entities to encode such characters.

This is the same bug as https://crbug.com/661819 and I will upload a ported version of https://crrev.com/c/755342, which fixes this bug.
Comment 1 Victor Costan 2017-11-22 19:33:22 PST
Created attachment 327478 [details]
Patch
Comment 2 Victor Costan 2017-11-22 19:34:14 PST
FWIW, while running the new LayoutTests on the unpatched version of WebKit, I got this crash.

ASSERTION FAILED: size >= m_size
/Users/costan/WebKit/WebKitBuild/Debug/usr/local/include/wtf/Vector.h(1088) : void WTF::Vector<char, 0, WTF::CrashOnOverflow, 16, WTF::FastMalloc>::grow(size_t) [T = char, inlineCapacity = 0, OverflowHandler = WTF::CrashOnOverflow, minCapacity = 16, Malloc = WTF::FastMalloc]
1   0x119d3de1d WTFCrash
2   0x10c0b1fc2 WTF::Vector<char, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>::grow(unsigned long)
3   0x10e94cee1 WebCore::encodeComplexUserDefined(unsigned short const*, unsigned long, WebCore::UnencodableHandling)
4   0x10e94cd5d WebCore::TextCodecUserDefined::encode(unsigned short const*, unsigned long, WebCore::UnencodableHandling)
5   0x10e94d5b8 WebCore::TextEncoding::encode(WTF::StringView, WebCore::UnencodableHandling) const
6   0x10e8fb93a WebCore::FormDataBuilder::addFilenameToMultiPartHeader(WTF::Vector<char, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WebCore::TextEncoding const&, WTF::String const&)
7   0x10e8fb751 WebCore::FormData::appendMultiPartFileValue(WebCore::File const&, WTF::Vector<char, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>&, WebCore::TextEncoding&, WebCore::Document*)
8   0x10e8fab5f WebCore::FormData::appendMultiPartKeyValuePairItems(WebCore::DOMFormData const&, WebCore::Document*)
9   0x10e8fa9dd WebCore::FormData::createMultiPart(WebCore::DOMFormData const&, WebCore::Document*)
10  0x10e26ba98 WebCore::FormSubmission::create(WebCore::HTMLFormElement&, WebCore::FormSubmission::Attributes const&, WebCore::Event*, WebCore::LockHistory, WebCore::FormSubmissionTrigger)
11  0x10dee4390 WebCore::HTMLFormElement::submit(WebCore::Event*, bool, bool, WebCore::FormSubmissionTrigger)
12  0x10dee44f6 WebCore::HTMLFormElement::submitFromJavaScript()
13  0x10c884b6a WebCore::jsHTMLFormElementPrototypeFunctionSubmitBody(JSC::ExecState*, WebCore::JSHTMLFormElement*, JSC::ThrowScope&)
14  0x10c86fede long long WebCore::IDLOperation<WebCore::JSHTMLFormElement>::call<&(WebCore::jsHTMLFormElementPrototypeFunctionSubmitBody(JSC::ExecState*, WebCore::JSHTMLFormElement*, JSC::ThrowScope&)), (WebCore::CastedThisErrorBehavior)0>(JSC::ExecState&, char const*)
15  0x10c86fc6c WebCore::jsHTMLFormElementPrototypeFunctionSubmit(JSC::ExecState*)
16  0x225343801168
17  0x1188f4a34 llint_entry
18  0x1188ecb97 vmEntryToJavaScript
19  0x11961b4ae JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*)
20  0x1195c2b35 JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
21  0x119818b3a JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
22  0x119818c19 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&)
23  0x119818ebd JSC::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&)
24  0x10d6f496b WebCore::JSMainThreadExecState::profiledCall(JSC::ExecState*, JSC::ProfilingReason, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&, WTF::NakedPtr<JSC::Exception>&)
25  0x10d72ef62 WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext&, WebCore::Event&)
26  0x10dc71ed2 WebCore::EventTarget::fireEventListeners(WebCore::Event&, WTF::Vector<WTF::RefPtr<WebCore::RegisteredEventListener>, 1ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc>)
27  0x10dc699ca WebCore::EventTarget::fireEventListeners(WebCore::Event&)
28  0x10dcc3794 WebCore::Node::handleLocalEvents(WebCore::Event&)
29  0x10dc6983d WebCore::EventContext::handleLocalEvents(WebCore::Event&) const
30  0x10dc6a506 WebCore::dispatchEventInDOM(WebCore::Event&, WebCore::EventPath const&)
31  0x10dc6a02d WebCore::EventDispatcher::dispatchEvent(WebCore::Node&, WebCore::Event&)
Comment 3 Build Bot 2017-11-22 20:33:58 PST
Comment on attachment 327478 [details]
Patch

Attachment 327478 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/5335647

New failing tests:
http/tests/fileapi/send-dragged-file-form-utf-8-part1.html
http/tests/fileapi/send-dragged-file-form-windows-1252-part1.html
http/tests/fileapi/send-dragged-file-form-iso-2022-jp-part1.html
http/tests/fileapi/send-dragged-file-form-x-user-defined-part1.html
Comment 4 Build Bot 2017-11-22 20:33:59 PST
Created attachment 327479 [details]
Archive of layout-test-results from ews103 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-elcapitan  Platform: Mac OS X 10.11.6
Comment 5 Build Bot 2017-11-22 20:57:44 PST
Comment on attachment 327478 [details]
Patch

Attachment 327478 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/5335673

New failing tests:
http/tests/fileapi/send-dragged-file-form-utf-8-part1.html
http/tests/fileapi/send-dragged-file-form-iso-2022-jp-part1.html
http/tests/fileapi/send-dragged-file-form-x-user-defined-part1.html
http/tests/fileapi/send-dragged-file-form-windows-1252-part1.html
Comment 6 Build Bot 2017-11-22 20:57:46 PST
Created attachment 327480 [details]
Archive of layout-test-results from ews116 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-elcapitan  Platform: Mac OS X 10.11.6
Comment 7 Alexey Proskuryakov 2017-11-22 23:29:33 PST
How does it make any sense to use HTML entities in file names?

I don’t think that there is any scenario where the behavior of other browsers is beneficial to the user.
Comment 8 Victor Costan 2017-11-23 01:43:54 PST
ap@: Thank you for the quick feedback!

I personally think it's pretty crazy as well. At the same time, achieving interop means that server operators can use the same piece of code to read the filename from all browsers, which seems better than having to deal with different results from different browsers.
Comment 9 Darin Adler 2017-11-23 14:02:47 PST
Do those other browsers use "&amp;" for the ampersand character too?