What kind of message sizes are we talking about for these cases?

I've wondered if our message size limits have much value beyond catching inefficient IPC usage in Chrome. If they don't, maybe we should relegate the constraints to DCHECKs and remove hard limits altogether.

Alternatively, if extensions were able to use Mojo IPC here, postMessage could leverage a data pipe for efficient large data transfer with no size limits.

The message limit for extensions is currently 64 MB.  I think that, with the implementation as it is now, that message limit is reasonable and desirable.  Sending extension messages results in multiple string copies, JSON parses, etc, and doing that on exceedingly large data objects is very expensive.  If the extension message system weren't constrained to strings and JSON, this would be different, but there's currently no plans to change that.

Batching in the implementation is possible, but non-trivial, and doesn't address any of the performance concerns of requiring Chrome to serialize/deserialize/copy hundred-megabyte JSON objects.

I'm not exactly sure how large SpectorJS's capture messages are, though clearly they're larger than 64 MB in size.

Regarding this limit being reasonable and desirable: the newly-imposed limit has broken an extremely useful extension. The top-level schema of the JSON message is here:

https://github.com/BabylonJS/Spector.js/blob/master/src/shared/capture/capture.ts

Descriptions of the sub-objects being sent are in the same directory:

https://github.com/BabylonJS/Spector.js/tree/master/src/shared/capture

The really expensive part is probably the ICommandCapture array inside ICapture. The commands are variable-length, so it's difficult to know how many commands could be sent at a time if they had to be chunked up, though a lower bound could probably be guessed.

If switching to use Mojo IPC would allow window.browser.runtime.sendMessage to efficiently transfer large amounts of data that would be awesome. Other extensions like https://github.com/spite/ShaderEditorExtension have been affected by the inefficiencies in this area as well.

IIRC, one of the reasons we didn't really want to allow arbitrarily large messages in the past is because of the jank this can cause (I guess this is what rockot@ meant by inefficient IPC usage?)

That still seems like something that should be true today, no?

If the jank can be significantly reduced by switching to Mojo IPC then we should make the switch and raise or remove the limit. This extension is an example of one which legitimately captures and visualizes large amounts of data from the target page and where it's difficult (though not impossible I'm sure) to chunk it up.

As it stands now, the limit is in place to prevent a crash, not sluggishness.

Changing the extension API to use mojo pipes that stream data through a mojo pipe sounds interesting, but we would likely want to make other changes to the API as well (e.g., not requiring serializing/deserializing all the data) in order to ensure performance, and, realistically, this likely isn't something that we'll tackle in the near-term.

To be clear, the limit in IPC is 128 MiB and that limit has not changed -
we've merely changed the fact that violating it results in a visible crash
report rather than a quietly terminated renderer/extension process. If
users of these extensions weren't running into serious issues before, it
would be because their messages fall within the 64 MiB - 128 MiB range.

If the change to extensions limits are only to prevent crashes, couldn't we
make the message size cap much closer to the IPC system's? Like say, 127
MiB?

Note: this limit was worked around in the extension in https://github.com/BabylonJS/Spector.js/pull/71 . To be fully general and avoid adding knowledge of the objects' schemas to too many places of the code, it manually serializes the object to JSON and then sends the string over using sendMessage in multiple 32 MB chunks. Even though this increases memory use, it doesn't have a noticeable performance impact, because the expensive part of the extension's operation is actually the capture of the trace.

Could something like this chunking be done behind the scenes in the window.browser.runtime.sendMessage implementation, and maybe in postMessage, too?

TL;DR: Yes, and we'd like to, but it's not something we can tackle in the immediate future.

Yes, the messaging APIs could definitely benefit from a bit of overhaul.  Unfortunately, the way to do this in a performant, stable, and backwards-compatible way is non-trivial.  Additionally, with some of the other projects we're working on (like ServiceWorker-based extensions), some of the benefits may be reduced (because workers can use web messaging, which is far superior to extension messaging).  However, my suspicion is we'll need to keep extension messaging around, so it is worth investing in.  This probably isn't something we'll be able to tackle this quarter, though.

Since the extension found a way to work around this, I'm going to make this bug a bit more generic to encompass the general problem - let me know if you disagree.