Browser Extension crashes when passing large data to jq (1.7.16-beta.8)

[twschiller]

Context

• Observed on 1.7.16-beta.8
• Information on customer site: https://www.notion.so/pixiebrix/Release-1-7-16-b539854bbfe74494b3be6e952b475e49
• Slack Thread: https://pixiebrix.slack.com/archives/C023KL47XV4/p1672966213033059

Steps to Reproduce

• Add this brick to a trigger: @pixies/4964-repro-brick
• Run the trigger
• Open the sidebar

Discussion

• Might be related to WEBEXT_MESSENGER_LOGGING is turned on in release builds for sandbox #4968

Investigation

• Looks like a memory leak and/or absurd CPU utilization
• Might be related to M1. Federico is not able to product, and it didn't come up during 1.7.15 testing on my Intel Mac

[twschiller]

It works for me on main on my M1 Mac if I modify the jq brick to not use the sandbox.

So there’s probably one of two things happening (or both):

• The postMessage is croaking due to large data (might have to use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer or similar?)
• The sandbox is croaking due to jq

[fregante]

Heads up: these are just my assumptions and may not be factual.

---

The second part could be possible:

• frames might have memory limitations, usually for third party origins, but ideally not for extensions

If that's not the case, I can't think of anything else because:

• the sandbox isn't special in any other way, it's just a local page served from Chrome-extension:// just like others, except without Chrome.* APIs
• if the frame isn't compute-limited, potentially it's even better than in-content-script evaluation because it's a whole new "thread". This means it should be able to stall without blocking the main loop. I suppose it can still crash the tab though.

[corinnemayans]

@twschiller - I'm removing the milestone on this one because it is old and I'm closing that milestone. Probably need to add a new milestone to this one unless this issue should be closed out with the old one.