* 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 loading of devtools extensions on startup
The persisted DevTools Extensions were not being loaded correctly at startup. The `addDevToolsExtension` function was not defined when it was being called. An error was being thrown and ignored, so the whole thing would fail silently. I moved the code to load the extensions to the end of the event handler, so now it works.
* fixup: remove trailing spaces to unblock CI
* fixup: add logging when the Electron Enable Logging env var is set
* Fix linter error on undefined srcDirectory
* fixup: catch exception when loading extension
* Revert "fixup: catch exception when loading extension"
This reverts commit 42c2cf95bcaab8abfc5fbecbe4365d3adfe36d5b.
- introduce API BrowserWindow#[add,remove,get]Extension
- make [add,remove, get]DevToolsExtension use newly introduced API
- make the app persist only the extensions added via
#addDevToolsExtension
The sandbox option allows multiple webContents in one renderer process, so using
the only the renderer id to identify WebContents instances is no longer an
option.
WebContents::GetID now returns a 64-bit integer, which is composed of both the
process id(high 32), and the RenderViewHost routing id(low 32). Also add a
`GetProcessID` that retrieves the renderer process id, a requirement in some of
our javascript code.
If an extension has already been loaded (for instance because it’s
persisted), `addDevToolsExtension` will return nothing, which is
confusing. This adds a little `console.warn` to educate people about
what’s happening.
Closes#5854
