| Auto-Submit | +1 |
Hi Solomon! Could you review the extensions/.* changes please?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
extensions lgtm from a high level, with a few questions for my own understanding.
return StructuredCloneMessageData();Is it ok to return raw message data on error or would an optional SCMD be beneficial?
return v8::Local<v8::Value>();Is it ok to return an empty handle or is an explicit null ok `v8::Null(&isolate);` ?
await new Promise(resolve => setTimeout(resolve, 100));OOC, is there an event based way to handle this? E.g. could 100 become flaky?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Hi Dave! Could you review the third_party/blink/.* changes?
Is it ok to return raw message data on error or would an optional SCMD be beneficial?
I think a std::optional would be clearer but out of scope for this change -- added a TODO.
Is it ok to return an empty handle or is an explicit null ok `v8::Null(&isolate);` ?
`v8::Null(&isolate);` wouldn't be optimal because `null` is a valid JS value so it would be impossible to tell if deserialized value was actually `null` or indicating an error. Added a TODO to make this an optional as well to be more clear since it seems callers check the return or the error which isn't great...
await new Promise(resolve => setTimeout(resolve, 100));OOC, is there an event based way to handle this? E.g. could 100 become flaky?
Great point! Changed to a promise that resolves when the `onDisconnected` handler fires with the deserialization failure error so it should not be flaky.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Solomon! Unfortunately I realized after your +1 that I was changing messaging behavior outside of structured clone serialization with the changes I was making to gin_port.cc and one_time_message_handler.cc. Those changes cause the sender to be notified of a failed deserialization which is a behavior change for JSON serialization too.
I'll think more about whether sending the error back to the sender makes sense later, but for now I've reverted that and adjusted the tests so they don't rely on the sender getting an error to prove that the SAB fails to deserialize in the renderer. You can see the diff between patchset 4 and patchset 6.
Also since I'm removing code and confirmed tests pass locally I think we can treat this as if the trybots have passed so it is ready for re-review.
v8::Local<v8::Value> Deserialize(v8::Isolate*, bool* did_fail = nullptr);Is it possible to change this signature to std::expected<v8::Local<v8::Value>, DeserializationError> ?
where maybe DeserializationError is a
```
enum class DeserializationError {
kDefaultFailure,
};
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
v8::Local<v8::Value> Deserialize(v8::Isolate*, bool* did_fail = nullptr);Is it possible to change this signature to std::expected<v8::Local<v8::Value>, DeserializationError> ?
where maybe DeserializationError is a
```
enum class DeserializationError {
kDefaultFailure,
};
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
bool* did_fail_ = nullptr;Let's change this to just a bool has_error_ = false;
Then add an API that can ask for HasError()...
Deserialize doesn't support multiple calls.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
Let's change this to just a bool has_error_ = false;
Then add an API that can ask for HasError()...
Deserialize doesn't support multiple calls.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[Extensions] Error on SharedArrayBuffer's in extension messaging
Extension messaging transports structured clone payloads via the
`blink.mojom.CloneableMessage` IPC struct, which drops SharedArrayBuffer
(SAB) memory handles over IPC and therefore means they can't be sent
with extension messaging.
Previously:
* For top-level SABs: `sendMessage(<SharedArrayBuffer>)`
* Sending a SAB would appear to succeed serialization in the sender,
but silently resolve to `null` on the receiver side when
deserialization failed to find the dropped handle.
* For embedded SABs: `sendMessage({'key': <SharedArrayBuffer>})`
* Any structured clone deserialization failure in Blink was caught
and swallowed by `V8ScriptValueDeserializer`, simply returning
`v8::Null()`. Extension messaging could not distinguish this failure
from an intentional `sendMessage(null)`.
This CL updates the architecture to correctly handle and report these
errors:
* For top-level SABs:
* `MessageToV8UsingStructuredClone()` now explicitly rejects
top-level SABs before serialization, surfacing a synchronous error
to the sender.
* For embedded SABs:
* `V8ScriptValueDeserializer` and `WebSerializedScriptValue` now
expose an optional `did_fail` out-parameter.
* The extension messaging receiver renderer uses `did_fail` to detect
the deserialization error that occurs for embedded SABs. It logs a
console message of the failure, rather than serialize it as JS
`null`. We don't close the port/channel when this occurs. To do so
would change all messaging behavior. and surface a "Could not
deserialize message" error to inform the receiver of the error.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |