This together with tor-browser!482 is the 12.0 backport of tor-browser!481, fixing tor-browser#41520 (part of tor-browser#41518).
text/plain
and text/html
fallback flavors escaping the filtertext/x-moz-url
data flavor to be added to the transferable object) as it was originally meantrichard (a5767f29) at 14 Dec 12:44
Bug 41520: (Regression) Rearranging bookmarks / place items by drag...
This together with tor-browser!482 is the 12.0 backport of tor-browser!481, fixing tor-browser#41520 (part of tor-browser#41518).
text/plain
and text/html
fallback flavors escaping the filtertext/x-moz-url
data flavor to be added to the transferable object) as it was originally meantSuperseded by tor-browser!482 (merged) + !118 (merged).
Addresses @henry's finding in tor-browser#41353.
OK you won
ok I checked through the mozilla code for all calls to setting the "x-moz-place-" data types and the only type used for drag and drop I found was "text/x-moz-place". So I think it is pretty safe for us to just compare against "text/x-moz-place" directly. If it turns out we need another type we can add it to the list later.
What features would use this?
ContentAreaDropListener._addLinksFromItem()
when called in a content processes (i.e. dropping links from chrome UI
to content frame
or content frame
to different content frame
).
The most recent opaque drag payload is always in the main process, so we resort to IPC if this content process has an empty one (first drop in this process) or a stale one from a previous drag & drop transaction.
Ah, they use x-moz-place-action
and x-moz-place-empty
, but that seems to be just for clipboard. E.g. https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/browser/components/places/content/controller.js#1089
That's strange why they would do that because the content type for calls to PlacesUtils.wrapNode
is only ever "x-moz-place", so I don't know where they would expect the other types from.
But in the two cases where controller.js uses startsWith
the previous code has already reduced the types to a limited set with getFirstValidFlavor
, so it is not acting as a wild card like we are doing here. But it probably won't make a difference in practice, unless another type starts using x-moz-place
prefix.
What features would use this?
Because otherwise dropping from chrome to content cannot work.
I've used it because Mozilla's Places code (controller.js
) does the same, so we're in good hacky company.
Out of curiosity, why do we have this? This is for content process messaging, but why would we need this?
type !== "text/x-moz-place" // don't touch bookmarks
I still think we should not use startsWith
because it seems hacky. If we want to preserve the other data types we should list them all here separately.
But I think those other "x-moz-place-" types only appear within the json data for the "x-moz-place" type. So I think it would be a bug for it to appear as the data transfer type.
Could we switch to something more like Crypto.randomUUID()
?
Cherry-picked with the new path and as a fixup! of 10760 to 102.5.0esr/12.5 as tor-browser@3844f07c.
Merged, thank you very much for contributing!
Add back FileUtils which was accidentaly removed in 004b629b Fixes: "ReferenceError: FileUtils is not defined startup-observer.js:121"
This closes tor-browser#41519