DataTransfer's setData, getData, and clearData should allow "same-ness" to ignore charset #2947
Comments
|
What about other parameters? Are parameters basically ignored or would text/plain;x=x and text/plain;x=y be unequal? |
|
In WebKit, we ignore all parameters (inconsistently unfortunately :(). Basically, we treat all |
|
Seems unfortunate for MIME types such as |
|
Oh, I meant just for |
|
So the |
|
I cannot reproduce this. In Chrome in Live DOM Viewer ends up logging the empty string, not "test". Chrome seems to require a literal ASCII case-insensitive match. |
|
Oh, interesting. Chrome's behavior changes between <!DOCTYPE html>
<div contenteditable="true" onpaste="test(event.clipboardData)" style="border: solid 1px black; width: 100px; height: 100px;"></div>
<pre id="log"></pre>
<script>
function w(text) {
document.getElementById('log').textContent += `"${text}"\n`;
}
function test(d) {
d.setData("text/plain;charset=utf-8", "test");
w(d.getData("text/plain;"));
}
test(new DataTransfer());
</script> |
|
So basically if it starts with an ASCII case-insensitive match for (Note that |
|
iOS WebKit always ignored charset for |
|
I wouldn't mind changing the above to starting with an ASCII case-insensitive match for |
|
On iOS, we used to strip away all Unicode whitespaces and checked if MIME type started with |
|
Would you parse everything as a MIME type then or some such? E.g., in Chrome |
|
In iOS, we only treat MIME types that start with |
When
DataTransfer's method such asgetDatais called, Safari & Chrome both ignores the charset for the sake of equality at least on Mac. This would mean that, for example,setData('text/plain; charset=utf-8', 'foo');is equivalent tosetData('text/plain; charset=Shift_JIS', 'foo');. Firefox seems to treat these MIME types as distinct types even on Mac.Given there is no mechanism to differentiate text MIME types based on charset on some platforms such as Mac, the spec should allow this behavior.
The text was updated successfully, but these errors were encountered: