STR:

1. Open https://www.mozilla.org/en-US/firefox/new/.
2. Right click on an SVG image, e.g. the Mozilla logo at the top left corner, click "Copy image".
3. Open the "Pages" application with a blank document.
4. Edit -> Paste.

Expected:
the copied image is pasted to the document and visible.

Actual:
nothing visible.

Works with Chrome. Doesn't work with Safari.

Copying non-SVG images (e.g. PNGs) works with Firefox too.

Looks like nsClipboard::SetNativeClipboardData could be relevant.

Chrome and Firefox populate the Pasteboard/clipboard with the same representations (see Apple's Pasteboard Programming Guide), however, in a different order:

Firefox:

public.html
Apple HTML pasteboard type
public.tiff
NeXT TiFF v4.0 pasteboard type

Chrome:

public.tiff
NeXT TIFF v4.0 pasteboard type
public.html
APPLE HTML pasteboard type

Apple's Programming Guide doesn't state that the representation's order matters, but instead the pasteboard reader should determine the most appropriate representation:

"A pasteboard reader must find the data type that best suits its capabilities (if any). Typically, this means selecting the richest type available. In the previous example, a rich text editor might provide RTFD, RTF, and NSString representations of copied data. An application that supports rich text but without images should retrieve the RTF representation; an application that only supports plain text should retrieve the NSString object, whereas an image-editing application might not be able to use the text at all."

Presumably, "Pages" chooses the first representation.

Swapping the order when exporting the flavors to the clipboard, here, might fix the problem. Will give it a try.

Swapping the order when exporting the flavors to the clipboard, here, might fix the problem. Will give it a try.

Exporting "public.tiff" before "public.html" indeed fixes the bug.

Moreover, local experiments with self-hosted (python -m SimpleHTTPServer) images showed that first exporting "public.html" leads to loading the image from the server, when pasting to "Pages". That's unnecessary, because the image data is already on the clipboard in "public.tiff".

On macOS, the Pages app depends on the order of the pasteboard
flavors, although it shouldn't, according to Apple's Programming Guide
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/PasteboardGuide106/Articles/pbConcepts.html#//apple_ref/doc/uid/TP40008101-SW1.

I don't know how to write an automated test for this. Exporting the
flavors to the clipboard can be triggered by a Mochitest, but it doesn't
allow reading from macOS's native pasteboard.

Checking the "paste" event doesn't cover this scenario either and the
order of its flavors is not affected by this change. So that's not
usable as an indirect test.

Writing a unit test for nsCopySupport::ImageCopy is also insufficient,
because the produced transferable still has to be propagated to the
pasteboard, which could alter the order.

In theory, one would have to run a mochitest which exports to the
clipboard and then run a separate executable which checks the
pasteboard's content. However, it seems Gecko's test-harness doesn't
provide this and extending it seems infeasible.

https://hg.mozilla.org/mozilla-central/rev/271bfc90ac86
https://hg.mozilla.org/mozilla-central/rev/e0e6d6de6f48

Reproduced the issue using Firefox 87.0a1 (20210201213620) on macOS 11.2.3.
Verified fixed with Firefox 87.0 (20210315170302) on macOS 11.2.3. The SVG image is correctly pasted inside Pages aplication.