dataTransfer is missing types
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox96 | --- | fixed |
People
(Reporter: vissu_nbkr, Assigned: evilpie)
References
()
Details
(Keywords: parity-chrome, testcase)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Safari/605.1.15
Steps to reproduce:
- Open https://codepen.io/rohinikumar4073/pen/VwzKRgz?editors=1011
- Click on Create DataTransfer button
- Observe the console.
Actual results:
- Check the file type is not the dataTransfer types
Expected results:
- The dataTranser should have types.
Comment 1•3 years ago
|
||
Not a bug in Firefox. Please see https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html
Comment 2•3 years ago
|
||
Behavior appears to be identical in Vivaldi. I don't believe either that or the lack of a descriptive summary are enough to close this as Invalid.
Comment 3•3 years ago
|
||
@Gingerbread Man: In that case, please feel very free to reopen. :)
Comment 4•3 years ago
|
||
Mirko, do you know what the expected behavior is here? Thanks.
Chrome's behavior here:
"DataTransfer"
"DataTransfer" "types" // [object Array] (2)
["text/plain","Files"]
Firefox's behavior:
"DataTransfer"
"DataTransfer" "types" // [object Array] (1)
["text/plain"]
Chrome's behavior is the one required by the spec: https://html.spec.whatwg.org/multipage/dnd.html#concept-datatransfer-types.
It contains:
"When the contents of the DataTransfer object's drag data store item list change, or when the DataTransfer object becomes no longer associated with a drag data store, run the following steps:" [...]
"If there are any items in the DataTransfer object's drag data store item list whose kind is File, then add an entry to L consisting of the string "Files". (This value can be distinguished from the other values because it is not lowercase.)" [...]
"Set the DataTransfer object's types array to the result of creating a frozen array from L."
I guess Firefox's behavior is not a recent regression.
Since all data transfer items are available via dataTransfer.items
there's a workaround for this. Moreover dataTransfer.types
is considered of the old interface, see https://html.spec.whatwg.org/multipage/dnd.html#the-datatransfer-interface, whereas dataTransfer.items
is part of the new interface. Hence prioritizing as P3.
Assignee | ||
Comment 8•3 years ago
•
|
||
The problem is that DataTransferItemList::GetTypes
only iterates through mIndexedItems[0]
to look for files. But DataTransferItemList::Add
adds the file with a new index at 1.
Assignee | ||
Comment 9•3 years ago
|
||
It almost feels like we should just use mItems for this, because AppendNewItem
right above this function already seems to handle adding files correctly.
However that would break GetTypes system callers that expect additional types.
I am not sure if I should try updating HasFile to follow GetTypes, because
https://bugzilla.mozilla.org/show_bug.cgi?id=1623239 already ran into issues
with a similar change.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Pushed by evilpies@gmail.com: https://hg.mozilla.org/integration/autoland/rev/daa38e1f0561 DataTransfer.types should include 'Files'. r=masayuki
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/31594 for changes under testing/web-platform/tests
Comment 12•3 years ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Description
•