Hi Solomon! Had a pre-refactor for you in the structured clone messaging you reviewed before. This is to support sending Blobs over extension messaging. This change seems out of place at first glance, but makes more sense in the context of the blob support downstream change: [\[Extensions\] Add Blob support to extension messaging. (7311207)](https://crrev.com/c/7311207)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Whoops! 😮 Actually adding Solomon now.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
A quick question.
[](Message* message, mojom::MessagePort* port) {Restore? See line 625 for more. cref() enforces constness and prevents mutation in callback.
```suggestion
[](const Message* message, mojom::MessagePort* port) {
```
&message));Should `std::cref(message)` be preferred over `&message` to make the lifetime assumptions explicit, given the risk of a dangling reference if this ever becomes async?
```suggestion
std::cref(message)));
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi Chromium IPC Reviews! Could you review the //extensions/common/mojom.* changes?
Restore? See line 625 for more. cref() enforces constness and prevents mutation in callback.
```suggestion
[](const Message* message, mojom::MessagePort* port) {
```
Done
Should `std::cref(message)` be preferred over `&message` to make the lifetime assumptions explicit, given the risk of a dangling reference if this ever becomes async?
```suggestion
std::cref(message)));
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
From googleclient/chrome/chromium_gwsq/ipc/config.gwsq:
IPC: ort...@chromium.org
📎 It looks like you’re making a possibly security-sensitive change! 📎 IPC security review isn’t a rubberstamp, so your friendly security reviewer will need a fair amount of context to review your CL effectively. Please review your CL description and code comments to make sure they provide context for someone unfamiliar with your project/area. Pay special attention to where data comes from and which processes it flows between (and their privilege levels). Feel free to point your security reviewer at design docs, bugs, or other links if you can’t reasonably make a self-contained CL description. (Also see https://cbea.ms/git-commit/).
IPC reviewer(s): ort...@chromium.org
Reviewer source(s):
ort...@chromium.org is from context(googleclient/chrome/chromium_gwsq/ipc/config.gwsq)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
// We use a raw pointer to `message` here because `SendToPort` executesWas the raw pointer reverted?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// We use a raw pointer to `message` here because `SendToPort` executesWas the raw pointer reverted?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
23 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: extensions/browser/api/messaging/extension_message_port.cc
Insertions: 0, Deletions: 4.
@@ -614,10 +614,6 @@
// Since we are now receiving a message, we can mark any asynchronous reply
// that may have been pending for this port as no longer pending.
asynchronous_reply_pending_ = false;
-
- // We use a raw pointer to `message` here because `SendToPort` executes
- // synchronously (iterating over `frames_` and `service_workers_`), ensuring
- // `message` remains valid for the duration of the broadcast.
SendToPort(base::BindRepeating(
[](const Message& message, mojom::MessagePort* port) {
port->DeliverMessage(message.Clone());
```
[Extensions] Make Message move-only and add Clone()
Refactor extensions::Message to be a move-only type and add an explicit
Clone() method. This is a prerequisite for supporting JS blobs in
extension messages, which will require switching the underlying storage
from mojo_base::BigBuffer to blink::CloneableMessage (which contains
move-only payload types like Mojo remote handles).
Explicit copying via Clone() is moved to call sites where it is strictly
necessary, such as when broadcasting a message to multiple listener
contexts (e.g., ExtensionMessagePort::DispatchOnMessage).
Key changes:
- Make Message move-only; add Clone().
- Pass Message by value (using std::move) in routing logic (e.g.,
MessageService, MessagePort) instead of by const reference.
- Change std::unique_ptr<Message> return type of MessageFromV8 to
std::optional<Message> to reduce allocation overhead.
- Update MessageService::PendingMessage to be a struct instead of a
typedef for std::pair (per the style guide (preferring named members
over std::pair/tuples)
- Update tests to accommodate move-only semantics and use
testing::Property.
This change should be architectural-only and maintains the existing
JSON(string)/StructureCloned(BigBuffer) serialization logic.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |