* 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: emit IPC event in correct context if isolation and sandbox enabled
IPC events were not being delivered to renderer processes when both
`contextIsolation` and `sandbox` were enabled. This is because the
`AtomSandboxedRenderFrameObserver` class was incorrectly using the
`MainWorldScriptContext`, rather than conditionally selecting the
context based on if isolation was enabled.
Fixes#11922
With mixed sandbox enabled we need to load the chrome.* APIs in the
sandbox init.js so that chrome extensions load correctly.
This mirrors the equivilant impl in `atom_renderer_client.cc`
Fixes#15561
* docs: Add 'worker' as a possible value for `process.type`
* fix: make certain properties on `process` read only:
* `mas`
* `windowsStore`
* `versions.electron`
* `versions.chrome`
* `type`
* `pid`
* `sandboxed`
* remove printing related things from chromium_src
* chore: add printing build flag and patch
* fix: include PrintingService on other platforms too
* fix: printing_handler is only needed on Windows
* fix: format BUILD.gn properly
* fix: rename printing build flag to avoid conflict with chromium
* fix: place previously missed printing calls behind build flag
* fix: accidentally renamed flag in patch file
* fix: don't include all printing strings
* fix: allow ShowItemInFolder and OpenItem to block, fixing a DCHECK crash
* fix: make things compile, some changes got lost while rebasing
* fix: remove rogue line from BUILD.gn
* chore: update patch description
* style: lint fix
* chore: use chromium printing buildflag, move node related stuff out of patch
* revert: remove ScopedAllowBlockingForTesting call
* fix: fix my rebase blooper
* fix: re-add header lost during rebase, update patch
* fix: add <map> include, tweak the patch a bit
* revert: remove rogue diff from patch
* fix: clean up after rebase
* chore: fix cpplint 'include_what_you_use' warnings
Typically by including <memory>, <utility> etc.
* chore: fix 'static/global string constant' warning
Use C style strings instead of std::string.
Style guide forbids non-trivial static / global variables. https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
/home/charles/electron/electron-gn/src/electron/script/cpplint.js
* refactor: remove global string variables.
Fix 'global string variables are not permitted' linter warnings
by using the base::NoDestructor<> wrapper to make it explicit that
these variables are never destroyed.
The style guide's take on globals with nontrivial destructors:
https://google.github.io/styleguide/cppguide.html#Static_and_Global_Variables
* fix: initializer error introduced in last commit
* fix: remove WIP file that was included by accident
* fix: include order
* fix: include order
* fix: include order
* fix: include order, again
* Don't use JSON to send the result of `ipcRenderer.sendSync`.
- Change the return type of AtomViewHostMsg_Message_Sync from `base::string16`
to `base::ListValue`
- Adjust lib/browser/api/web-contents.js and /lib/renderer/api/ipc-renderer.js
to wrap/unwrap return values to/from array, instead of
serializing/deserializing JSON.
This change can greatly improve `ipcRenderer.sendSync` calls where the return
value contains Buffer instances, because those are converted to Array before
being serialized to JSON(which has no efficient way of representing byte
arrays).
A simple benchmark where remote.require('fs') was used to read a 16mb file got
at least 5x faster, not to mention it used a lot less memory. This difference
tends increases with larger buffers.
* Don't base64 encode Buffers
* Don't allocate V8ValueConverter on the heap
* Replace hidden global.sandbox with NodeBindings::IsInitialized()
* Refactoring: check NodeBindings::IsInitialized() in V8ValueConverter
* Refactor problematic test to make it more reliable
* Add tests for NaN and Infinity
