DataTransfer's setData, getData, clearData should strip whitespaces on type

[rniwa]

it looks some ports of WebKit and Blink strips away whitespaces around the type specified to DataTranfer's setData, getData, and clearData 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.

[zcorpan]

Do you have a test case or demo already?

[rniwa]

I have a very simple test case added in https://bugs.webkit.org/show_bug.cgi?id=175810

[zcorpan]

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

[zcorpan]

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

[rniwa]

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.

[annevk]

FWIW, stripping whitespace around the MIME type seems reasonable to me. We'll also be doing that for data: URL MIME types. See whatwg/fetch#579.

[annevk]

Any tests should make sure to test all ASCII whitespace: U+0009, U+000A, U+000C, U+000D, and U+0020.