Library Affected:
workbox.setConfig
Browser & Platform:
"all browsers".*
Issue or Feature Request Description:
I am planning to set debug mode : true
here is the process i am following :
using PWA to store the mode value : true/false in a cache
Opening the cache and set the debug value using the stored variable.
the problem is everything is async and install event is getting called before workbox.setconfig
Does anyone know any workaround for this
The various workbox.* methods need to be executed synchronously at service worker startup, in order to load the required runtime bundles and establish the proper event listeners before events start firing. You're not going to be able to do anything asynchronous, like read from the Cache Storage API or IndexedDB, prior to initializing Workbox.
I don't know how much flexibility you need in terms of toggling whether Workbox is in debug mode or not, but maybe the following would help. It allows you to use a URL query parameter to determine whether a given service worker registration will trigger Workbox's debug mode or not.
// Inside your service worker,
// before you make any other calls to workbox.* methods.
const url = new URL(location.href);
const debug = url.searchParams.has('debug');
workbox.setConfig({debug});
and then when you register:
// To enable debugging:
navigator.serviceWorker.register('/service-worker.js?debug');
// To run without debugging:
// navigator.serviceWorker.register('/service-worker.js');
You might already know this, but Workbox will automatically switch into debug: true mode when it detects it's running on localhost, and run in production mode by default otherwise.
Related
I'm following this tutorial to create a simple web app with a Microsoft 365 login. I'm currently getting this error when debugging locally (http://localhost:8080):
Warning:
mgt-loader.js:61 A parser-blocking, cross site (i.e. different eTLD+1) script, https://unpkg.com/#microsoft/mgt/dist/bundle/wc/webcomponents-loader.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
In Azure, I have the Redirect URIs set up to match (http://localhost:8080).
After some googling, I tried adding async, but then I get this warning and the login button doesn't appear:
mgt-loader.js:61 Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.
What would be causing this warning and how can I fix it?
First, check out how document.write works: https://developer.mozilla.org/en-US/docs/Web/API/Document/write
You will understand why you cannot run document.write in asynchronous context (try running document.write('Hello world!'); in console on any page).
Warning tells you that a parser blocking (synchronous), cross site (not coming from the same domain as website) scripts can be blocked by Chrome in the future if someone has unstable or bad internet connection.
If you want it to run synchronously without that warning, you have to bundle that JS code with your own, or just serve it from your own origin, same as your website (e.g. localhost:8080). You can download #microsoft/mgt npm package and for bundling - use gulp, webpack or other tool of your choice.
https://unpkg.com/#microsoft/mgt#2.4.0/dist/bundle/wc/webcomponents-loader.js
This script tries to differentiate between async and sync contexts (line 175) and run document.appendChild (instead of write) for async context - but for some reason the check fails (readyState === loading).
https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState
How to check if an Javascript script has been loaded Asynchronously (Async) or async attribute is present?
If you want to run this in non-blocking manner, you could try to fix the script by yourself.
There is a Github repo for that toolkit (https://www.npmjs.com/package/#microsoft/mgt), but there is no issue regarding async loading, nor regarding the warning that you have noticed - so maybe nobody else has noticed or thought about it yet.
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
We are using Spring XD for executing some batch jobs and considering to use Spring Cloud Dataflow. For this I wanted to remote debug a execution of a Task and I was not able to make it working.
I tried to export the following environment variable before the SCDF server is started:
spring.cloud.deployer.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Also tried to pass as argument in the GUI while invoking the task:
app.<appname>.local.javaOpts=Xdebug -Xrunjdwp:transport=dt_socket,address=12201,server=y
Nothing seems to be working.
I'm able to debug the composed-task-runner launched by SCDF using the listen debugger mode, this will also work for your task as well.
Run Debugger in your IDE in listen mode on port 5006. (this project's classpath should have composed-task-runner sources, put break point some where )
Run SCDF with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 option, attach debugger to the SCDF process in your IDE on port 5005 (attach mode).
Put breakpoint at this line :
String javaOptsString = getValue(deploymentProperties, "javaOpts");
in JavaCommandBuilder class (for spring-cloud-deployer-local v.1.3.0.M2 it's line #83).
Launch your task - debugger stops at breakpoint.
Step Over once in your IDE, the value of javaOptsString is null now. Using IDE, set the value of javaOptsString to
-agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y
Press Resume in IDE.
Your breakpoint set in #1 should be hit in few seconds.
If you know how to pass javaOpts as deployment properties of your task - you will be able to debug in listen mode without this nightmare ;-). I've not found a way to escape = and , characters in the -agentlib:jdwp=transport=dt_socket,server=n,address=localhost:5006,suspend=y javaOpts deployment property.
We are working on an improved solution for the local-deployer - you can follow spring-cloud/spring-cloud-dataflow#369 for tracking purpose.
There is, however, the following option that exists to aggregate all the application logs into the server console directly, which might be useful while in active development.
stream deploy --name myStream --properties "deployer.*.local.inheritLogging=true"
Finally I was able to remote debug a composed task or regular task. Follow the below steps:
In scdf UI go to tasks and click on the definition section
Click play button (invoke) on the task/composed task that you want to invoke.
On the launch task page define your task arguments
Add the following properties by clicking 'Add Property' button:
- deployer.composed-task-runner.local.debugPort=12103
- deployer.composed-task-runner.local.debugSuspend=y
Now launch the task
You can now see in the log that when the composed task's java process is launched it is called with the debug parameter.
If you want to control the heap memory or any java options you can do by adding the following property:
deployer.composed-task-runner.local.javaOpts=Xmx2048M
Note that 'composed-task-runner' is the name of the App (Not the name of the task).
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 using a windows 10 machine. I'm also running a docker container that is running a rails application. Whenever I make a change to any server side code (i.e controllers or models) I'm required to do a docker restart app.
However my friend is using the same container on his apple machine but when he makes changes to any server side code he does not have to restart his app.
Why is this?
Rails has a configuration option (config.cache_classes) that specifies whether or not your application code should be cached in memory between requests. Having this option set to true will require you to restart your app if you make changes; having it set to false reloads your code on every request, so you don't have to restart.
It is recommended to set this to false in the development environment only, because Rails works faster if it doesn't have to reload your code every time it starts processing a request. In production, you should leave it set to true.