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".
Related
I want to create desktop application compatible with other OS.For that I'm using electron with angular.Because both are frame work whether it will effect performance or loading time, and also whether deploying easy,can we use all the features of angular when we use with electron like routing..?
Electron uses Chromium and NodeJS which is the reason why it is compatible with other OSs. You can talk with the NodeJS process from your angular-app which opens up some possibilities. For example opening native file-dialogs to let the user choose files. Electron also already abstracts some platform specific operations like getting the user home to save some configuration files for example.
You can use routing just like in any Angular app and I think you can use most features like you would normally but dont take me for granted on this one.
I would not say it affects your loading time to combine those too. During development you have to build your angular app before electron can start up and use those files but in production Angular is already ready to be loaded so they dont hinder each other.
Is there a way to use Chromium switches after starting it up, or must they be enabled on start up? For example, can switches be passed to the renderer processes, or just to the main process?
I want to turn on paint flashing in Chromium (actually in my Electron app which runs on top of Chromium).
Devtools has a checkbox that turns this on, but I want to be able to turn this on without devtools, and after the app has started.
I know there's a show-paint-rects flag I can use:
chrome.exe --show-paint-rects
In my Electron app, I would need to use app.commandLine.appendSwitch:
app.commandLine.appendSwitch("show-paint-rects");
I also found a ui-show-paint-rects flag that lives in something called the "compositor," but that may be irrelevant for me.
Both of these work, but since Chromium uses a multi-process architecture, I'm hoping that there's a way I can specify that switch, or otherwise, turn on a feature in one process and not have to specify it at startup.
Is there a way to do this in Chromium? (Would be ideal to do this in Electron, but I'm not counting on it)
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 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.