1883290 - Cross-origin cross-process Window.postMessage generates significant parent process main thread CPU usage and leads to unbounded memory usage if parent process falls behind in relaying messages

Status: NEW

(Core :: DOM: postMessage, defect, P3)

Description

[Mayank Bansal]

1. Go to https://codepen.io/loficodes/pen/eYQLgyG. Let the demo run for a few seconds
2. In the JS part of the code-pane, change the following line:

Original : let dotSize = 3;
Change to: let dotSize = 1;

3. Let the demo recompile (or force it to recompile) . Let it run for a few seconds

AR: https://share.firefox.dev/3TjYv1o
There is a lot of IPC-y stuff going on between the parent process and a Codepen process.
ER: Not so?

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[Mayank Bansal]

Can repro on a build from Jan2022, so not a recent regression (if at all it is a regression).

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

That codepen.io link doesn't seem to work

Comment 4

[Mayank Bansal]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #3)

That codepen.io link doesn't seem to work

Updated in "URL" and comment #0. Use this : https://codepen.io/loficodes/pen/eYQLgyG

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Based on the profile there there are cross-origin windows posting lots_of messages, so nothing unexpected there. Cross-origin messaging goes through the parent process since content processes don't have direct communication channel between them.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

In some sense this is a case where a content process is trying to flood both parent process' and other content process' main event queue with message events. That is something we could try to limit, perhaps by slowing down the problematic content process.

Comment 7

[Florian Quèze [:florian]]

(In reply to Mayank Bansal from comment #0)

AR: https://share.firefox.dev/3TjYv1o

A lot (12+%) of the CPU time seems spent in NS_NewURI in both the parent and content processes. It's likely the same URI over and over again, would it be possible to avoid parsing it so many times?

Comment 8

[Mayank Bansal]

I found out that that these messages are due to "console.log" things in the JS code. If I comment out all these logs, all the IPC stuff is gone :

console.log removed : https://share.firefox.dev/3QIof66
console.log present : https://share.firefox.dev/3QJ5Dml

Comment 9

[Mayank Bansal]

Another example is https://codepen.io/ada-lovecraft/pen/jEPWBO
Change var ITERATIONS = 5 to 50 and let it recompile
Profile : https://share.firefox.dev/4byAwSB

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Thanks for the profiles! I primarily looked at the profile from comment 9 and it definitely seems like, consistent with :smaug's analysis in comment 5, codepen is exposing a custom implementation of console.log in their "iframeConsoleRunner" and the implementation in the cross-origin iframe (cdpn.io) is then performing a cross-window postMessage back to the codepen.io window which is then seeing a bunch of "message" events.

I'm re-titling this along the lines of :smaug's and will mark this as depending on an enhancement bug about trying to move cross-origin Window.postMessage to using the tentatively planned endpoint-based approach which could provide for the backpressure :smaug discusses in comment 6.