Make {Async}GetNativeClipboardData() more flexible to use
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox140 | --- | fixed |
People
(Reporter: edgar, Assigned: edgar)
References
(Blocks 1 open bug)
Details
Attachments
(7 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Currently, nsIClipboardDataSnapshot.getData{Sync}() retrieves only the first available type of nsITransferable and throws an error if nsITransferable contains a type not in the flavor list. This behavior is primarily due to how each platform implements GetNativeClipboardData(). So when we would like to get data for multiple types, we would need to create a temporary nsITransferable contains only one type for each type that we want to load, e.g. https://searchfox.org/mozilla-central/rev/3b3c7a0c930a5451be3b4088ed795ce01ddf002e/editor/libeditor/EditorBase.cpp#7368-7402.
I think we could try to make nsIClipboardDataSnapshot.getData{Sync}() more flexible to use to support load all available type in nsITransferable and ignore the type if it doesn't in the available flavor list (instead of throwing an error).
In order to support this, we might need to modify the GetNativeClipboardData to make it more flexible to use as well, for example
Result<nsCOMPtr<nsISupports>, nsresult> GetNativeClipboardData(ClipboardType aWhichClipboard, const nsACString& aFlavor);
which takes a MIME type and returns the corresponding data if it is available. Then we could build the behavior we want on the top of it.
| Assignee | ||
Updated•7 months ago
|
| Assignee | ||
Comment 1•6 months ago
|
||
| Assignee | ||
Comment 2•6 months ago
|
||
| Assignee | ||
Comment 3•6 months ago
|
||
Updated•6 months ago
|
| Assignee | ||
Comment 4•6 months ago
|
||
| Assignee | ||
Comment 5•6 months ago
|
||
Depends on D246858
| Assignee | ||
Comment 6•6 months ago
|
||
| Assignee | ||
Comment 7•6 months ago
|
||
This should not change behavior.
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
| Assignee | ||
Comment 8•6 months ago
|
||
To minimize the scope, I’m going to focus this bug on re-implementing {Async}GetNativeClipboardData() to make it more flexible to use. This should not change any existing behavior.
The actual changes to nsIClipboardDataSnapshot.getData{Sync}() — which will then support loading multiple types at once — will be moved to a separate bug.
Comment 10•6 months ago
|
||
Comment 11•6 months ago
|
||
Backed out for causing failures @test_clipboard_cache_chrome.html.
| Assignee | ||
Updated•6 months ago
|
Comment 12•6 months ago
|
||
Comment 13•6 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/969f19c27623
https://hg.mozilla.org/mozilla-central/rev/faa6ec3fbf52
https://hg.mozilla.org/mozilla-central/rev/ca1719d6d9f3
https://hg.mozilla.org/mozilla-central/rev/e510f759b8fa
https://hg.mozilla.org/mozilla-central/rev/53dbe1e6b485
https://hg.mozilla.org/mozilla-central/rev/7bc5a6f9ee17
https://hg.mozilla.org/mozilla-central/rev/36d8024d7f3f
Updated•5 months ago
|
Description
•