Sample: Transfer a blob from a background context to a page

[dotproto]

Goal of the demo

Demonstrate how an extension can create a blob in the extension's service worker and transfer it to a page's main world.

Suggested implementation

Sketch of my initial implementation plan

1. Have a content script inject an iframe into a page
2. Run a script in the iframe to post a message back to the service worker using navigator.serviceWorker.controller.postMessage()
3. In the SW's message handler, generate a blob OR use structuredClone() to create a copy of a blob.
4. Use event.source.postMessage(msg, [transferable]) to reply to the client and transfer the blob
5. In the iframe's message handler, use window.parent.postMessage(msg, "<origin>", [transferable]) to transfer the data to the page

Related links

• Transfer huge binary data buffer between service worker and content script (more efficiently) w3c/webextensions#293

Notes

Initial findings suggest that it's not possible to transfer variables across origins. I'm tentatively thinking that to work around this, we can use URL.createObjectURL() in the iframe and directly reference the object URL somewhere that's easily visible to the end user (e.g. canvas, Audio/Video element, etc.).

[guest271314]

Here you go https://github.com/guest271314/persistent-serviceworker/tree/main/chromium_extension_web_accessible_resources_iframe_message_event. You can transfer whatever you want. Bonus: Keeps MV3 ServiceWorker persistent.

[guest271314]

Note, the last time I checked Blobs are not transferable.

[guest271314]

Details of the message passing. We create a MessageChannel pair in the MV3 ServiceWorker, then transfer one of the MessagePorts created to the arbitrary Web page where action icon is clicked, to establish direct communication between SeriveWorker and the Web page where port is defined globally.

To send a Blob from the ServiceWorker to the Web page where action icon is clicked include on Line 111 of background.js

port1.postMessage(new Blob(['Message from MV3 ServiceWorker'], {type:'text/plain'})); 

To log messages in the ServiceWorker sent from port2 defined globally in the Web page where click action occurred add the following to Line 114 in background.js

  console.log(e.data);

To transfer substantial amounts of data we can transfer ArrayBuffer (and TypedArray buffer), WebAssembly.Memory (which can grow()), and on Chromium and Chrome Transferable Streams, e.g.,

const {readable,  writable} = new TransformStream();
port1.postMessage(readable, [readable]);
const writer = writable.getWriter();
await writer.write(new Uint8Array([1,2,3,...]));
// close the stream
await writer.close();

on Web page

port.onmessage = async(e) => {
  if (e.data instanceof ReadableStream) {
    await e.data.pipeThrough(...).pipeTo(...);
  }
}

e.g., from an iframe appended to an arbitrary Web page https://github.com/guest271314/captureSystemAudio/blob/master/native_messaging/capture_system_audio/transferableStream.js

onload = () => {
  const { readable, writable } = new TransformStream({
    transform(value, controller) {
      controller.enqueue(value);
    },
    flush() {
      console.log('Flush.');
    },
  });
  const writer = writable.getWriter();
  const id = 'capture_system_audio';
  const port = chrome.runtime.connectNative(id);
  port.name = id;
  async function handleMessage(value, port) {
    // value could be valid JSON, e.g, "[0.123, 0.456,...]"
    if (!Array.isArray(value)) {
      value = JSON.parse(value);
    }
    try {
      await writer.ready;
      // pass Uint8Array to write()
      await writer.write(new Uint8Array(value));
    } catch (e) {
      console.error(e.message);
    }
    return true;
  }
  port.onDisconnect.addListener(async (e) => {
    console.log(e.message);
    await chrome.storage.local.clear();
  });
  port.onMessage.addListener(handleMessage);
  onmessage = async (e) => {
    const { type, message } = e.data;
    if (type === 'start') {
      port.postMessage(message);
      parent.postMessage(readable, name, [readable]);
    }
    if (type === 'stop') {
      try {
        port.disconnect(id);
        console.log(writer.desiredSize, message);
        while (writer.desiredSize <= 1) {    
          await scheduler.postTask(() => {});
          if (writer.desiredSize === 1) {
            console.log('writable', writer.desiredSize);   
            break;
          }
        }
        await writer.close();
        await writer.closed;
        console.log(writer.desiredSize);
        parent.postMessage(0, name);
        onmessage = null;
        await chrome.storage.local.clear();
      } catch (err) {
        console.error(err.message);
      }
    }
  };
  parent.postMessage(1, name);
};

As to quantity or volume streaming JSON (string) or Array with onMessage handler and creating a Uint8Array and utilizing Streams API, I have recorded well over 1 hour of raw PCM (10.5 MB per 1 minute) using the above approach.

There are other ways to communicate between ServiceWorker and a Web page.

However, the above being possible, it would be less cumbersome if the MV3 ServiceWorker could set arbitrary Web pages as a WindowClient - then we could communicate directly, and utilize onfetch (and respondWith() and Response()) without a iframe making requests and multiple intermediary transfering agents. Something like Transferable Streams directly to the ServiceWorker from an arbitrary Web page without necessarily needing onmessage and postMessage(), e.g., https://bugs.chromium.org/p/chromium/issues/detail?id=1214621.

[tophf]

Goal of the demo
transfer it to a page's main world

It's the wrong goal in the context of the linked issue. I guess its title was initially confusing as it mentioned "web page" instead of "web page's content script", so I've changed it to reflect the contents of the issue, which is about the content script. It's a more difficult task to accomplish securely, but still possible via an iframe inside a closed ShadowDOM with a random token + MessagePort as described in the comment linked in the issue. One change to the scheme would be to send the MessageChannel port from SW to the content script via the iframe, then use this port to transfer blobs transferable binary data directly and instantly by specifying the second parameter of postMessage.

---

The following has been proved wrong, see the clarifying comment.

Note that to transfer a huge blob instantly, which is what the related issue is all about, we need the second parameter:~

port1.postMessage(blob, [await blob.arrayBuffer()]);

~It should be mentioned explicitly that it destroys the blob in the source (in SW).

[guest271314]

One change to the scheme would be to send the MessageChannel port from SW to the content script via the iframe

That is what the code I posted does.

Note that to transfer a huge blob instantly, which is what the related issue is all about, we need the second parameter:

port1.postMessage(blob, [await blob.arrayBuffer()]);

As far as I know Blobs are not transferable and that code does not transfer a Blob.

[tophf]

Blob is just a wrapper on the same data exposed via arrayBuffer accessor or other getters on the blob, so this code does transfer the actual data instantly.

[guest271314]

Kindly cite where you read Blobs are transferable.

[tophf]

Not the Blob, the arrayBuffer view of the same data contained in the Blob.

[guest271314]

That is not transferring a Blob. Just deal with ArrayBuffer and TypedArray if you want to transfer data.

[tophf]

A Blob will be received by the listener, so it can be said that the Blob is effectively transferred.

[guest271314]

No it cannot be said, because Blobs are not transferable objects.

[tophf]

Blob is not a Transferable but it's effectively transferable. Anyway, it's semantics.

[guest271314]

Note that Blob is not listed here https://developer.mozilla.org/en-US/docs/Glossary/Transferable_objects#supported_objects.

[tophf]

I know.