Closed Bug 1557852 Opened 6 months ago Closed 3 days ago

JS Window Actors do not automatically serialize nsIPrincipals

Categories

(Core :: DOM: Content Processes, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mconley, Unassigned)

References

Details

We added automatic nsIPrincipal serialization over the message manager in bug 1032592, and front-end has kinda grown used to being able to send principals like any other primitive object.

We appear to have lost that with JS Window Actors - Principals can still be sent on one side, but come out as empty Objects on the other side. I'm working around this in bug 1505909 by manually using the E10SUtils.(de)serializePrincipal helper methods, but we should add back the capability of automatically serializing these principals over JS Window Actors, otherwise we might run into weird cases where we end up not having a Principal when we expect one.

cc'ing Neil and Abdoulaye so that they know about this and don't get caught be surprise.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Priority: -- → P3
Flags: needinfo?(jmathies)
Blocks: 1467212
Flags: needinfo?(nika)
Flags: needinfo?(jdai)

I looked into this and I think I've figured out your issue.

When you send the message over IPC with sendAsyncMessage, with the code as it is today, a warning is actually being logged to the console, it looks like this:

 0:04.31 INFO Console message: [JavaScript Warning: "Sending message that cannot be cloned. Are you trying to send an XPCOM object?" {file: "resource:///actors/ContextMenuChild.jsm" line: 687}]

This error is produced if the attempt to StructuredClone your object fails. This is a warning, and not an error, for historical reasons (due to us trying to match the behaviour of MessageManager). When we fail to clone, and emit this message, the fallback is to try to serialize all objects as-if they were JSON. https://searchfox.org/mozilla-central/rev/40ef22080910c2e2c27d9e2120642376b1d8b8b2/dom/base/nsFrameMessageManager.cpp#417-434

There is some other object in your data parameter list which is not serializable, and so we're falling back to using JSON serialization, which doesn't handle nsIPrincipal correctly, which is why you need to manually serialize. Sending a nsIPrincipal directly should work fine.

Flags: needinfo?(nika)
Flags: needinfo?(mconley)
Flags: needinfo?(jdai)

Finally went and confirmed this - yeah, Principals serialize fine, and whatever problem I was seeing is gone now. shrug.

I filed bug 1597787 to stop serializing / deserializing.

Status: NEW → RESOLVED
Closed: 3 days ago
Flags: needinfo?(mconley)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.