* feat: add support for node / preloads in subframes
This feature has delibrately been built / implemented in such a way
that it has minimum impact on existing apps / code-paths.
Without enabling the new "nodeSupportInSubFrames" option basically none of this
new code will be hit.
The things that I believe need extra scrutiny are:
* Introduction of `event.reply` for IPC events and usage of `event.reply` instead of `event.sender.send()`
* Usage of `node::FreeEnvironment(env)` when the new option is enabled in order to avoid memory leaks. I have tested this quite a bit and haven't managed to cause a crash but it is still feature flagged behind the "nodeSupportInSubFrames" flag to avoid potential impact.
Closes#10569Closes#10401Closes#11868Closes#12505Closes#14035
* feat: add support preloads in subframes for sandboxed renderers
* spec: add tests for new nodeSupportInSubFrames option
* spec: fix specs for .reply and ._replyInternal for internal messages
* chore: revert change to use flag instead of environment set size
* chore: clean up subframe impl
* chore: apply suggestions from code review
Co-Authored-By: MarshallOfSound <samuel.r.attard@gmail.com>
* chore: clean up reply usage
* chore: fix TS docs generation
* chore: cleanup after rebase
* chore: rename wrap to add in event fns
* fix: child window with nativeWindowOpen should disable node integration
* Revert "fix: do not enable node integration in child window if not enabled (#15076)"
This reverts commit 0252d7686c.
This patch is not needed anymore since we are force disabling node integration
for child windows.
This fixes the crash in RunScriptsAtDocumentStart when "affinity" option
is specified. Previously we were assuming only one main frame exists in
the renderer process, but the "affinity" option breaks this option.
There is also a bug that "node::Environment::GetCurrent" does not return
nullptr for context without a env in it, I'm not sure whether it is a
bug of Node or V8.
Define a "require" argument in the wrapper functions that runs browserify
bundles, which will prevent browserify from leaking the require function.
Note that this doesn't affect the isolated renderer script, only when `-r` flag
is passed to browserify command it will export a require function. It is still
added to isolated renderer script to prevent future mistakes(doesn't hurt
defining a "require" local).