Evaluates given script in every frame upon creation (before loading frame's scripts) and returns script's id.

Example

"method":"Page.addScriptToEvaluateOnNewDocument","params":{"source":"//# sourceURL=__puppeteer_evaluation_script__","worldName":"__puppeteer_utility_world__"}
"result":{"identifier":"1"}

Since this figures in Puppeteer's FrameManager._ensureIsolatedWorld, it might also block many gutenberg tests as in https://bugzilla.mozilla.org/show_bug.cgi?id=1597877#c1 -- but this is unclear right now.

Three concerns that should be investigated here:

• How does Chromium deal with deprecation in the script cache?
• Is there a memory limitation on the maximum number of allowed scripts?
• When during document loading is the script evaluated? (load vs DOMContentLoaded for example)

Another thing which comes into my mind is also the order of the scripts to evaluate. There could be code that gets modified by multiple registered scripts. As such the order would matter. Maybe it is just by the time when scripts got added.

If the "worldName" parameter is specified, then this command "creates an isolated world with the given name and evaluates given script in it. This world name will be used as the ExecutionContextDescription::name when the corresponding event is emitted."

This part is what creates the "secondary world" in Puppeteer after each navigation, so it's definitely blocking gutenberg and more. It's the other piece of the puzzle, alongside Bug 1597877.

Looks like Puppeteer registers a dummy script with this command and only relies on it for execution contexts for their "secondary world", as described above.

Depends on D55169

Depends on D55169

https://hg.mozilla.org/mozilla-central/rev/f988a09bb821