nsIClipboard::HasDataMatchingFlavors() doesn't check cached transferable properly
Categories
(Core :: Widget: Cocoa, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: edgar, Assigned: edgar)
References
Details
Attachments
(1 file)
nsIClipboard::HasDataMatchingFlavors() uses the cached transferable first if any, but the cached transferable is shared between different clipboard types and it is also possible that the system clipboard is updated by other application, so it is possible that nsIClipboard::HasDataMatchingFlavors() doesn't return the correct result.
We could notice this flaw by following below steps:
- Set
dom.events.asyncClipboard.clipboardItem
,dom.events.asyncClipboard.readText
anddom.events.testing.asyncClipboard
totrue
. - Open https://edgarchen.github.io/dragndropclipboard/.
- Copy some string from web page in Firefox.
- Click
read()
button in page opened in step2. - We should get two types:
text/html
andtext/plain
. - Open a text file from TextEditor app.
- Copy some string in TextEditor app.
- Click
read()
button in page opened in step2.
Expect result:
We should get only one type: text/plain
.
Actual result:
We get two types, text/html
and text/plain
, instead. And the data of text/html
is empty.
It seems to me that we need to do the same check as nsIClipboard::GetNativeClipboardData()
in https://searchfox.org/mozilla-central/rev/e35e7107299a46a696b8aa8a4a5c03a39458ac21/widget/cocoa/nsClipboard.mm#311. For long term, we probably want to have separated caches for each clipboard type, I have filed some bug to improve the clipboard code, like bug 1812078 and bug 1810850, we could do that there.
Assignee | ||
Comment 1•1 year ago
|
||
Updated•1 year ago
|
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9bef555dcdc4 [Cocoa] Check cached transferable properly in nsClipboard::HasDataMatchingFlavors; r=spohl
Comment 3•1 year ago
|
||
bugherder |
Updated•1 year ago
|
Description
•