Enforce sandbox on all spawned BrowserWindow objects #91
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The docs (https://www.atom.pe/docs/api/sandbox-option/) say we should be using the browser-native
window.open
implementation, but in practice that appears very much false. Electron, no matter our set of options, appears to always make a hit to the ipcRenderer withwindow.open
calls, causing the calling code to explode due to the sandbox making that impossible.By using
app.enableSandbox()
, it puts the sandbox in place over all BrowserWindow objects, including the temporary ones which empirically are being created forwindow.open
. We do not need to specifysandbox: true
to the BrowserWindow with this approach, though uncommenting and therefore reintroducing the flag causes our lovely ipcRenderer error again.As far as I can tell, the sandbox does actually get applied to the window though the fact that
sandbox: true
still does things despite the docs saying otherwise leaves me a bit uncomfortable.Fixes element-hq/element-web#13719