Passing a blob using native messaging API

How can a blob (of an image, audio, video, PDF) be loaded into an extension page from a native application using the native-messaging API?

If the blob is in a local SQLite file or a separate local file, how is it to be passed to or read in by the browser?

If all that can be sent through the native-messaging API is a JSON string how can this be done?

I’m probably being stupid but I don’t understand and want to pass a file object to create an object URL.

Thank you.

I think you have to convert the binary data to Base64 before sending it.

You can also pass binary data as Uint8Array. This should be more efficient than Base64.

Thank you.

Does it have to be converted back to binary, once received in the extension?

The extension will receive 1MB max per message. I haven’t encountered this with a blob but had a couple errors while building the responses in C and the extension threw an error due to message being too large.

Do you know what I need to read to learn what to do with these pieces of blobs in order to load and display a 5MB jpg map, for example, or five minutes of audio?

Do they have to all be read and concatenated? I’m not sure where to start.

Thank you.

Are you sure you can send typed array? Won’t that be converted into regular number array when serialized to JSON message? If the underlying container is JSON than for sure it’s much better to use Base64. You can use FileReader / readAsDataURL to create base64 and then (await fetch(base64String)).blob() to convert it back.

Typed Arrays are fine when sending data internally (well, I think except Chrome where the internal cloning algorithm doesn’t support those yet).

If you are reaching some message size limit, you can chunk those base64 strings and send them piece by piece… Not exactly piece of cake but doable. But is there really a limit for the message size? Doesn’t sound good.

Thank you. I think the message size is limited based on this from the native messaging API under “App Side”.

On the application side, you use standard input to receive messages and standard output to send them.

Each message is serialized using JSON, UTF-8 encoded and is preceded with a 32-bit value containing the message length in native byte order.

The maximum size of a single message from the application is 1 MB. The maximum size of a message sent to the application is 4 GB.

When I was building the JSON strings in the C app. to send back to the extension, I made a few mistakes and sent too large a string and the extension threw an error concerning the size being too large.

Isn’t there away to get pass “a link” to the blob and have the browser read it as it would when the src is set in a media object? A local HTML page can read a local media file when the path is relative; I was hoping that the C app could some how provide the blob reference and the browser could just read it.

Thanks.

1 Like

No, blob URIs are only in-browser memory pointers. Well, they’re even more restricted than that, since this is the web where everything is sandboxed. Long story short, you would have to send all the contents to the extension.

1 Like

Passing a link? You mean like URL.createObjectURL()? I’m pretty sure nothing like that would work. Browsers are super encapsulated.
But you could potentially create a local web server and use normal http link and download it with fetch. I think I saw some apps doing this. But I’m not sure it’s easier though…

Thank you.

If the file sent from the C app. is an audio or video lecture segment, and the contents are sent in approximate 1 MB chunks, must the entire contents be read, joined, and converted to a blob URL, before playing or can it begin to play while continuing to receive more chunks?

In looking at the indexedDB examples of retrieving and playing an audio or video file, an object URL is created from the request result; but I don’t know if that is really a pointer to the data or a separate copy of the data.

Maybe this MDN example of a media stream can be used if the fetchAB function can be replaced with repeated 1MB requests from the C application.

Thank you.