Open rniwa opened 7 years ago
Do you have a test case or demo already?
I have a very simple test case added in https://bugs.webkit.org/show_bug.cgi?id=175810
OK I've run a modified test with live dom viewer:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5318
In EdgeHTML 15 (via browserstack) I get
error: Element not found.
on line 15
Test case | EdgeHTML | Blink | Gecko | WebKit |
---|---|---|---|---|
clipboardData.setData(" text/PLAIN ", "hello"); |
error | true | false | false |
clipboardData.setData(" tEXT/pLaIN", "world"); |
error | true | false | false |
clipboardData.setData("text/plain; charset=utf-8", "hello"); |
error | true | false | true |
It seems Edge throws an exception if there's leading whitespace in setData
. With leading whitespace removed, EdgeHTML gives
log: true
log: false
log: true
As confusing as it sounds, iOS WebKit behaves differently from macOS WebKit. On iOS, we always stripped leading & trailing whitespaces. Given that I suspect there could be mobile content out there that depends on this behavior.
FWIW, stripping whitespace around the MIME type seems reasonable to me. We'll also be doing that for data: URL MIME types. See https://github.com/whatwg/fetch/pull/579.
Any tests should make sure to test all ASCII whitespace: U+0009, U+000A, U+000C, U+000D, and U+0020.
it looks some ports of WebKit and Blink strips away whitespaces around the type specified to
DataTranfer
'ssetData
,getData
, andclearData
methods. The comment indicates this was needed for IE compatibility.Since iOS WebKit seems to have always had this behavior, I'm worried that not stripping whitespaces would not be backwards compatible.
Given the options, I think we should change the spec to strip whitespaces around the type name.
It would be great if someone could check the behavior of IE/Edge on Windows as well.