(In reply to Simon Giesecke [:sg] [he/him] from comment #8) > Maybe the assumption that this does not need to be dispatched to the main thread is wrong? Yes. I understand the rationale of the optimization to be: "we don't need a real JS sandbox because there's no structured clone data to deserialize". However, the use of AutoJSAPI ends up calling `CycleCollectedJSContext::Get()->Context()` to get the thread's JSContext*. There's no such runtime on an IDB I/O thread, however, so this gets and dereferences a null pointer immediately. For the purposes of sanity, I think we want a (non-system-principaled) JS context, which means we either need to instantiate a runtime or that thread when this happens or we need to use the existing code-path. We do want to stop involving the main thread in this situation, but it seems like the immediate fix is to eliminate the optimization and always dispatch.
Bug 1636316 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Simon Giesecke [:sg] [he/him] from comment #8) > Maybe the assumption that this does not need to be dispatched to the main thread is wrong? Yes. I understand the rationale of the optimization to be: "we don't need a real JS sandbox because there's no structured clone data to deserialize". However, the use of AutoJSAPI ends up calling `CycleCollectedJSContext::Get()->Context()` to get the thread's JSContext*. There's no such runtime on an IDB I/O thread, however, so this gets and dereferences a null pointer immediately. For the purposes of sanity, I think we want a (non-system-principaled) JS context, which means we either need to instantiate a runtime on that thread when this happens or we need to use the existing code-path. We do want to stop involving the main thread in this situation, but it seems like the immediate fix is to eliminate the optimization and always dispatch.