Improve performance of `Clipboard::Read` by reading data from clipboard asynchronously
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: mbrodesser-Igalia, Assigned: edgar)
References
(Blocks 2 open bugs)
Details
(Keywords: perf)
Attachments
(5 files, 1 obsolete file)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
Bug 1755863 - Part 3-2: Use async nsClipboard API to implement clipboard.read(); r?NeilDeakin!,nika!
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 |
Implementation advice:
- There's a WPT for
read()
ing aClipboardItem
with two types from the content process. - Some to-be-written async version of
FillAllExternalData
will have to be called. - Converting
IPCDataTransfer
objects toDataTransfer
objects might need to cover what https://searchfox.org/mozilla-central/rev/68a5327697ec43aa55b458c504c4b313c9c80528/dom/ipc/ContentChild.cpp#3206-3241 covers too. https://searchfox.org/mozilla-central/rev/211649f071259c4c733b4cafa94c44481c5caacc/dom/base/nsContentUtils.cpp#7528 could be relevant too.
Assignee | ||
Comment 1•3 years ago
|
||
Assignee | ||
Comment 2•3 years ago
|
||
Depends on D145377
Assignee | ||
Comment 3•3 years ago
|
||
Depends on D145378
Assignee | ||
Comment 4•3 years ago
|
||
Depends on D145379
Assignee | ||
Comment 5•3 years ago
|
||
Assignee | ||
Comment 6•3 years ago
|
||
Hi Neil, in this bug, we would like to use async IPC to get the clipboard data from OS for clipboard.read()
(we have done a similar thing for clipboard.readText()
in bug 1472338). To achieve that, I introduce some async API in nsIClipboard, and make web Clipboard
implementation use those nsIClipboard API directly without going through DataTransfer. Would you mind taking a look? It would be appreciated if you could give some feedback on the WIP patches.
Comment 7•3 years ago
|
||
I can take a look in more detail if you like, but some initial feedback:
- The widget changes in the first patch don't seem particularly necessary. The apis that get formats/flavours aren't asynchronous in any os, that I know of, nor should it have any performance issue, so I think we only need to use a asynchronous api here to wait for the format info to pass across our content to parent process boundary and can just use the existing clipboard methods in the parent process.
- Is the code in the third patch in ReadHelper intended to be limited to specific formats? Is this api limited in what formats it supports?
- We shouldn't be calling clipboard->AsyncGetData in the ClipboardItem constructor -- it should be called in ClipboardItem::GetType.
The general design looks ok though.
Assignee | ||
Comment 8•3 years ago
|
||
(In reply to Neil Deakin from comment #7)
I can take a look in more detail if you like, but some initial feedback:
- The widget changes in the first patch don't seem particularly necessary. The apis that get formats/flavours aren't asynchronous in any os, that I know of, nor should it have any performance issue, so I think we only need to use a asynchronous api here to wait for the format info to pass across our content to parent process boundary and can just use the existing clipboard methods in the parent process.
But if we only use the asynchronous API in content process, which means we need to call different nsIClipboard API on parent process and content process in DOM clipboard code, which I would like to avoid doing so.
- Is the code in the third patch in ReadHelper intended to be limited to specific formats? Is this api limited in what formats it supports?
Yes, we intended to do that for now, Blink and Webkit only support those mime types on clipboard API, too. We could support more later if needed.
- We shouldn't be calling clipboard->AsyncGetData in the ClipboardItem constructor -- it should be called in ClipboardItem::GetType.
Actually, this is what we expect. Spec also defines the system clipboard data is read when read() is called, https://w3c.github.io/clipboard-apis/#dom-clipboard-read.
Assignee | ||
Comment 9•3 years ago
|
||
(In reply to Edgar Chen [:edgar] from comment #8)
(In reply to Neil Deakin from comment #7)
- The widget changes in the first patch don't seem particularly necessary. The apis that get formats/flavours aren't asynchronous in any os, that I know of, nor should it have any performance issue, so I think we only need to use a asynchronous api here to wait for the format info to pass across our content to parent process boundary and can just use the existing clipboard methods in the parent process.
But if we only use the asynchronous API in content process, which means we need to call different nsIClipboard API on parent process and content process in DOM clipboard code, which I would like to avoid doing so.
On a second thought, we could use the existing API to get formats/flavors first, we could do that later if we figure out it is necessary.
Assignee | ||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 10•3 years ago
•
|
||
Assignee | ||
Comment 11•3 years ago
•
|
||
Updated•3 years ago
|
Assignee | ||
Comment 12•3 years ago
|
||
Depends on D145378
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 13•3 years ago
•
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 14•3 years ago
|
||
Assignee | ||
Comment 15•3 years ago
|
||
Depends on D145378
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Comment 17•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/65e1dba3f3ec
https://hg.mozilla.org/mozilla-central/rev/b318f0bf426e
https://hg.mozilla.org/mozilla-central/rev/1c15d67cce05
https://hg.mozilla.org/mozilla-central/rev/4e8b144ba280
https://hg.mozilla.org/mozilla-central/rev/2102746fdbcb
Description
•