I'm building an application with Electron and packaging with Electron Builder. When running electron, I want to pass this command line argument: --enable-mixed-sandbox.
Is it possible? How?
This:
app.commandLine.appendSwitch('enable-mixed-sandbox')
wouldn't work due to:
Note that it is not enough to call
app.commandLine.appendSwitch('--enable-sandbox'), as electron/node
startup code runs after it is possible to make changes to chromium
sandbox settings. The switch must be passed to electron on the
command-line:
electron --enable-sandbox app.js
It is not possible to have the OS sandbox active only for some renderers, if --enable-sandbox is enabled, normal electron windows
cannot be created.
You can use app.commandLine.appendSwitch in your applications main script (the one that opens the Electron window)
Example for your switch would be
app.commandLine.appendSwitch('enable-mixed-sandbox')
another way of doing it, you can use spectron to start the app in debug mode. which allows you to pass any arguments you want.
const Application = require('spectron').Application
// Returns a promise that resolves to a Spectron Application once the app has loaded.
// Takes a Ava test. Makes some basic assertions to verify that the app loaded correctly.
function createApp (t) {
return new Application({
path: 'path/to/app',
args: ['-r', '--enable-mixed-sandbox'],
env: {NODE_ENV: 'test'},
waitTimeout: 10e3
})
}
https://github.com/electron/spectron#new-applicationoptions
I got a response on that issue I raised and linked to in the comments:
app.enableMixedSandbox() // Experimental macOS Windows
See here for documentation.
Related
I have an electron app, that loads some css's from spring boot server.
When I run app from npm from sources, I can run as
ng build && electron . --disable-http-cache
and it works without the cache.
If I build my app with electron-packager to app.exe, how can I disable cache.
Start .exe-file with --disable-http-cache doesn't work
UPDATE
The only approach that works is to clear cache from main process before app loads the page. But is there any another way to disable cache?
Another possibility is to use Electron's commandLine.appendSwitch () in the main process on the app object, right before anything gets executed:
const { app } = require ("electron");
app.commandLine.appendSwitch ("disable-http-cache");
// any other main process code
This will append --disable-http-cache to Chromium's command line, just like appending it to the electron command would. When having this in code, you do no longer have to run your app with appending this switch as it will automatically be added.
You can also add a no-cache header inside loadURL() of the route that is requesting the css (or even the root route)
webContents.loadURL(url, {"extraHeaders" : "pragma: no-cache\n"})
A complete mini example gist
I am using foreverjs within my electron app main like so:
const forever = require("forever-monitor");
let child = forever.start(scriptPath, {fork: true});
I am doing this intentionally over using child_process.fork because I want foreverjs to monitor the forks and restart them when needed.
Well - the above works, but looking at my dock on mac osx, I see that the electron app is duplicated for each fork. In production it is the same -- the app icon get's duplicated N times in the Dock for each process.
Investigating further I found the cause but not the solution. The cause is that when you fork a process normally using child_process from within electron, it launches it using the Electron Helper app.
However when you fork a process using forever.js it uses the Electron app itself, thus explaining the duplicates.
How do I force forever to use the Electron Helper app when forking and not the Electron app itself?
OK, so I figured it out. Quite simply you need to pass one environment variable to foreverjs like so:
const forever = require("forever-monitor");
let child = forever.start(scriptPath, {fork: true, env: {ELECTRON_RUN_AS_NODE: 1}});
Doing this and the fork will correctly use its prepackaged version of node instead of launching another copy of electron "main".
I am on an Electron + Create React App stack.
I am using Electron Updater (https://github.com/develar/electron-updater) for auto updates.
Platform: Linux, Format: AppImage.
When my app checks for updates, I get the following error:
APPIMAGE env is not defined.
Has someone experienced the same issue? Suggestions required.
Please don't use electron-updater anymore, since it is no longer supported according to its GitHub page.
Most often, this occurs when you are trying to use the auto updater in development mode (or non-packaged AppImage mode). It only works in a packed production build.
For me however, this also occurred in a packed AppImage, and turned out to be caused by using the webpack DefinePlugin, like this:
plugins: [
new webpack.DefinePlugin({
"process.env": {
NODE_ENV: JSON.stringify("production")
},
...
Removing the process.env definition allowed APPIMAGE to be defined once again in the distributed package. It seems the rest of the definitions can be left in place safely without breaking the auto-updater.
If removing this definition is not possible for your use-case, according to some users it's possible to simply override it at the beginning of your main thread (not renderer thread) file like this:
process.env.APPIMAGE = path.join(__dirname, 'dist', `MyApp-${app.getVersion()}.AppImage`)
... obviously with the correct file name in the 3rd argument of Path.join.
This override approach didn't seem to do anything for me though, so I myself went with simply removing process.env from the DefinePlugin definitions, but it may help in other cases.
try to use electron-builder for building your app cause this module is is in maintainance only mode.
the autoUpdate for linux is not possible, you can do that only for mac and windows try to read this documentation.
I am working in an Electron project in where I have several webviews to load different websites that share the same session (of the type “persist:id”). I have developed an adblock system that works at the level of the webview that works in the following way:
let mySession = session.fromPartition(‘persist:id’);
session.webRequest.onBeforeRequest(['*://*./*'], (details, cb) => {
if (adBlockActiveForSession(details.webContentsId)){
// adblock operations
}
}
This works in the development and with production flag. However, when I create a release/executable, it doesn't work. I noticed that, in the release, details doesn't have “webContentsId”, but it does in development.
Also I have check the documentation and it says that the webContentsId is an optional value in the onBeforeRequest callback.
why it works in development but not when I create a release? When can webContentsId be access in the parameter details and when it can’t? There is some flag I should use when doing the release package? Should I consider this a bug? has someone experienced the same issue?
Thank you
note: In order to insure that the webview has its webContent id, before loading an url I load an empty site, and after dom ready, I start to do the real url loadings.
Operating system:
development in Ubuntu, Mac, release in Mac, Windows. Both releases have the same problem.
Expected behavior
onBeforeRequest should return the information of the webContent that has created the request. That information is inside details.webContentsId
Actual behavior
onBeforeRequest returns it when working in development version and with the production on, however, when doing a package to create a release onBeforeRequest doesn’t return the webContentsId of the webContent that did the request
I'm trying to pass command line arguments to my already packaged app on execution.
(Already packaged with electron-builder and installed the .dmg on my mac)
I navigated into the /Applications/myApp.app/Contents/MacOS folder where the application executable is located. Then i run.
exec myApp --myNewArgument theFancyValue
For some reason "myNewArgument" does not appear in my process.argv array.
Am i missing anything? I thought the arguements will automaticly be passed to my electron main process.
I am thankfull for any help.
Yes, the passed command line arguments appear in the process.argv array, but only from the main process.
From a renderer process, you'll need to access the main process arguments using remote.process:
require('electron').remote.process.argv
https://www.electronjs.org/docs/api/command-line states that
(commandLine.appendSwitch(...)) This will not affect process.argv. The intended usage of this function is to control Chromium's behavior.
As such, only the appp.commandLine.getSwitchValue as mentioned in other comments allows you to get these command line switches
In addition to the use of switches as command line parameters, the use of arguments is also supported. Arguments take the form of "someData" in the final command line, where switches take the form "--namedParameter=someData".
In code, commandLine.appendArgument(value) is used to add the argument. These arguments are given before all switches in the generated command line.
They are also intended to affect Chromium's behavior. Again:
(commandLine.appendArgument(value)) Note: This will not affect process.argv. The intended usage of this function is to control Chromium's behavior.
Since there is no key for the parameter, there does not appear to be a way to directly read it from code as there is with a switch.
https://www.electronjs.org/docs/api/command-line-switches gives a list of supported switches.
In case of packaged source of electron app, command line arguments can be accessed using following function. Let's say if we have passed the command line argument as --myNewArgument=theFancyValue. It can be retrieved like this in the main.js:
import { app } from "electron";
app.commandLine.getSwitchValue("myNewArgument");
This works for development mode as well.