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
Related
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 building a static app with PouchDB on Google AppEngine.
When I open the site in a browser window, it is showing a version I uploaded several hours ago.
If I open the site in an incognito window, the updated version is displayed (therefore I don't think it is actually an error in the console).
I put a new version number in app.yaml
I have migrated all traffic to the new version.
I have cleared my cache, deleted cookies, checked my application data, everything. I even reinstalled Chrome and Firefox.
I updated my Python version and my Google AppEngine Launcher yesterday; the problem pre-dated that update.
Also: just discovered that if I go to the URL of the updated version
http://4.[app-id].appspot.com, it displays the correct, updated version.
This is happening in Chrome, Firefox, and Edge.
Edit: probably should have mentioned that my site uses Service Workers and IndexedDB. I assume my service workers are caching the previous version, but I would have thought that Ctrl + F5 would clear the cache and show the new version.
I think it must be the Service Workers caching the pages (which is, after all, what they are supposed to do). This is actually really annoying when you are developing though.
A guy called Rich Harris has documented this behaviour and some workarounds on a Github Gist.
Reloading the page doesn't behave as you'd expect
If you make a change to your service worker, then reloading the page
won't kill the old one and activate the new one (it detects the change
by requesting the service worker file each time and comparing the old
and the new byte-for-byte), leaving you somewhat confused as to why
your changes haven't taken effect. This is because the old window is
never actually closed, meaning there's never a time to swap them out –
you need to kill the tab completely then reopen it.
Or you can have the browser do that for you by going to the
Application tab in devtools (in Canary, not stable Chrome yet), going
to the Service Workers section, and checking 'Update on reload'.
UPDATE (13 Nov 2017): This functionality is now available in Chrome, so you don't even need to download Canary.
And here's which bits of the application cache to clear:
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.
I'm working on a little website using dart.
I have one project for the server, and another for the client app (see picture below)
In the server app I serve the client app from the client project like this
runServer() {
var staticHandler = createStaticHandler(r"C:\Users\Lukasz\dart\linkShepherdClient\web\", defaultDocument: 'linkShepherd.html',serveFilesOutsidePath: true);
var handler = new Cascade()
.add(staticHandler)
.add(routes.handler)
.handler;
io.serve(handler, InternetAddress.LOOPBACK_IP_V4, 8080).then((server) {
print('Listening on port 8080');
}).catchError((error) => print(error));
}
Everything worked fine. But now the changes I do in the client project stopped affecting the site served by the server (a site still loads, just an older version, with slightly different styling, but most importantly also an older .dart script file). When I run the client directly from it's project everything is up to date.
Opening and closing the editor does not help.
Is the dart editor actually creating some sort of cache?
The cache might be from dart:io. You should probably launch a pub serve instance and redirect to this during development anyway. This way any transformers (Angular, Polymer, ...) are applied as well.
When deployed the server should serve the build output of the client.
This is an extension of a question I asked here, which went unanswered. I am attempting to use the Meteor app on my iPad that I'm hosting on my own remote server. The issue is that when I run the following command, the app builds successfully:
sudo meteor run ios-device --mobile-server=XXXX:XXXX
The problem begins when I click the build button in Xcode to deploy the app to my device. It seems to build everything OK and even load the data from my remote server. But after a few seconds, it reverts back to a local database/build. When I check the Xcode log, it says "Finished load of http://meteor.local/" so it seems to be overwriting the remote data with new, local data. I'm not sure if I have something enabled that's causing Xcode to load a local database or if there's something that I have to turn off to prevent it from loading.
UPDATE:
I've resolved the issue using the suggestion from Jey DWork to apply the missing environment variables in the Meteor server startup.
The ones I added were:
Meteor.absoluteUrl.defaultOptions.rootUrl
process.env.ROOT_URL
process.env.MOBILE_ROOT_URL
process.env.MOBILE_DDP_URL
Without setting these, the ROOT_URL seemed to be getting overwritten after the initial load. As these environment variables do not seem to be documented, I'm still going to search and see if there is a different solution to this issue (as it seems strange that the app would have to re-load itself multiple times before it's usable). For now though, this is a temporary solution.
Have a look at this post :
I've understood my problem, maybe your problem is the same, all explanations here : stackoverflow.com/questions/34658956/
Your app for smartphone must be built with --server=http://IP:PORT parameters
And
Your app for server must be started with --mobile-server http://IP:PORT parameters