I have a weird case.
I use chrome 75 for Mac OS.
When I push code in console some page
if ('caches' in window) {
console.log(`cache is supported`)
}else{
console.log(`cache is not supported`)
}
as a result I see that this is supported but I have local server on 8080 from vue. When I call it there it return that cache doesn't exists.
When I export vue cli code as production still cache is not supported in window.
Any ideas why? Thanks in advance for any hints.
Related
Very simply, I would like to disable the display of the repeated workbox messages that appear in my browser console while I am debugging. For instance, I don't need to see:
WorkBox: Using NetworkFirst to respond to '/fonts/KFOlCnqEu92Fr1MmEU9fBBc-.woff'
It clutters my FireFox console and it is something I dislike very much. If you like it, fine, please don't try to change my mind about the benefit of such useless (to me) messages.
Do you know how to turn it off?
For info sake, I am using Quasar and Vue to create a SPA - not even a PWA.
Thanks.
Simply add self.__WB_DISABLE_DEV_LOGS = true at the top of your service worker (sw.js) file.
Contrarily to what answers posted here say, the solution is not:
to unregister your service worker to get rid of the messages. Your app may need it to run properly
to add workbox.setConfig({debug: false}) unless knowing what it does:
it switches between a production build and a debug build. workbox automatically selects the debug build when running on localhost.
For me worked:
Console -> Application tab -> Service workers -> sw.js unregister
You can use workbox.setConfig({ debug: false }); in order to use production build and remove extra logging, otherwise adjust your web console log level filtering accordingly.
Doc : https://developers.google.com/web/tools/workbox/guides/troubleshoot-and-debug
You add this setting in your service worker definition file, after the import. For example:
importScripts(`https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-sw.js`);
if (workbox) {
console.log(`Yay! Workbox is loaded š`);
} else {
console.log(`Boo! Workbox didn't load š¬`);
}
// Switch debug logging on/off here. Default is on in dev and off in prod.
workbox.setConfig({debug: false});
For more information on this see https://developers.google.com/web/tools/workbox/guides/configure-workbox#configure_debug_builds_vs_production_builds
Thanks to the answer provided by Antonina K, I was able to locate an answer for FireFox. In case anyone else needs this. As Antonina mentioned, in Chrome, the console has an application tab that has references to all the service workers used by the browser. FireFox does not have the tab (or, at least my version does not).
In FireFox, open a new tab and place about:serviceworkers in the address bar. Scroll through the list to find the workbox service worker. For me, it was listed as localhost:8080. I deregistered that worker and I no longer see the multitude of workbox messages in my console. I can finally debug my app again!
Here is the link that I referenced to fix the problem:
Manage Service Workers in FireFox and Chrome
So I'll keep this succinct: When trying to install, my service worker fails. This is all of my code in sw.js:
var cacheName = 'randomstring';
var filesToCache = [ '/' ];
self.addEventListener('install', function (e) {
console.log('[ServiceWorker] Install');
e.waitUntil(
caches.open(cacheName)
.then(function (cache) {
console.log('[ServiceWorker] About to fail');
return cache.addAll(filesToCache);
})
);
});
I get an exception because cache is undefined (on the cache.addAll bit).
Not really sure why this is the case?
I've used service workers before and never encountered this issue. This is my first time using a service worker with an ASP.Net back-end though, so not sure if that's the problem?
So, I figured this out. I was going to vote to close the question, but I figured I'd leave it here as I saw some other people with this issue who didn't know how to resolve it. Even though it's super-stupid :) (or more accurately, I am).
So I was running the website via the "Play" button, aka "Start Debugging", which, in Visual Studio 2017, launches a special Chrome window, in which the above error will be thrown.
To work around the issue, I can (or you can, internet traveller of the future) simply start without debugging, host the website in IIS, etc.
EDIT: If there's a better workaround where I can use the service worker in debug mode, please suggest it and I'll mark that as the answer. For my specific problem though, the above workaround is fine :).
Encountered the same problem and found some other ways.
VS recognises "chrome.exe" while debugging and adds some parameters, thatĀ“s why service workers wonĀ“t working.
There is an option Debug => Option => Debugging => General => Enable javascript debugging for asp.net (Chrome, Edge and FireFox). If you donĀ“t want to use js debugging in vs - like me because i use chrome for js debugging - just deactivate this option and service workers will work.
VS Enable JS Debugging in Chrome
Alternatively you can add chrome as a new "browser" and switch the browser for debugging. Because vs recognise "chrome.exe" make a symlink via administative commandline "mklink chromedirect.exe chrome.exe" and add it as new browser in visual studio.
This can be done under the "Play" context menu => Browse with.
VS Play Context Menu
Just add chromedirect.exe without any arguments and a friendly name like "Google Chrome Direct". After that you can switch to the browsers and select if you want VS JS Debugging or not.
I am looking to get UPnP device discovery, description done in Javascript - either in standalone browser environment or in NodeJS
Towards that, I tried below two solutions but both did not work for me. Details -
1]NodeJS bases:
https://www.npmjs.com/package/upnp-client
After correcting few typos in the example app, and running it in node (My nodeJS is running under X-Ubuntu Virtual Machine inside Virtualbox)
I get below errors on running the upnp-client example app
dgram.js:399
throw new errnoException(process._errno, 'addMembership');
^
Error: addMembership EBADF
at new errnoException (dgram.js:457:11)
NodeJS version: v0.10.25
Upnp client api: 0.0.1
2]Under Browser(Chrome/IE)
https://www.npmjs.com/package/upnp-client
None of them at the versions I have supported the navigator.getNetworkServices API which seems to be needed for this library
How can i get UPnP device discovery working in Javascript?
Any other solutions or pointers to resolve above errors/workarounds appreciated.
UPnP uses TCP/UDP packages for advertisement/discovery/etc. And since browsers cannot open network sockets, the short answer is: No. We can't use UPnP in a browser at the moment.
The only glimmer of hope is the Network Service Discovery, which is still in development phase in most of the browsers. In Chrome for example you could enable it using chrome://flags/#enable-experimental-web-platform-features, and then would be able to do something like this (from W3C draft):
function showServices( services ) {
// Show a list of all the services provided to the web page
for(var i = 0, l = services.length; i < l; i++) console.log( services[i].name );
}
navigator.getNetworkServices('zeroconf:_boxee-jsonrpc._tcp').then(showServices);
The main idea is to run a random page on Internet Explorer and get javascript errors and logs.
Is there a way to recover javascript console logs and execution error
from a random web page without accessing the F12 tool on Internet
Explorer?
I found that with Chrome based browser, you can get it on your AppData file log by adding --enable-logging --v=1 args when launching.
Any solution with any language are welcome.
Thank you for your answer.
NOTE :
random page on Internet Explorer means that I do not have the access on the source code.
Basic solution to this would be:
1. Use Exception Handling to catch the errors.
2. Log errors in a Global Array
3. Log the errors in a file using Blob and URL.createObjectURL. All recent browsers support this.
Have you considered using a Bookmarklet that:
Overrides window.console.log and window.console.error (to intercept messages)
Logs incoming messages somewhere using createObjectURL?
Or you could use something like firebuglite and auto-enable it like this:
<script type="text/javascript" src="https://getfirebug.com/firebug-lite.js">
{
overrideConsole: false,
startInNewWindow: true,
startOpened: true,
enableTrace: true
}
</script>
More instructions are here: http://getfirebug.com/firebuglite
If the F12 tool is not of your interest, then what about the Event Viewer? Open Event Viewer from Control Panel -> System and Security -> Administrative Tools -> Event Viewer.ā Then select the log Applications and Services Logs\Internet Explorer.
By default no events are being logged for Internet Explorer, to enable them create a new DWORD registry value named Feature_Enable_Compat_Logging under the following registry key:
HKCU\SOFTWARE\Microsoft\Windows\Internet Explorer\Main \FeatureControl
and set the registry value to 1.
Check the logs you get to see if it's what you're looking for.
One idea would be to write a browser extension which listens for window.onerror and writes to a file. Definitely not as elegant as the Chrome solution, but it would work fairly well.
Using local proxy might be a good one-time solution.
Charles web debugging proxy app has nice UI and it allows to replace any response with local resource.
So basically you'll need:
Download one any of the js files used on target page
add any code you wish to saved version
set up Charles to serve you your local version instead of remote one
You might try Fiddler. It's got its own logging and has amazing inspection power. It won't capture IE specific errors, since it's at a different layer, but it will definitely get you any code that's coming over the wire.
Some clients are failing to load the Google API in a production environment, but I'm not able to find anything wrong with my code.
Here's what I've got:
// Load Google's JavaScript Client API using requireJS !async plugin.
// You can learn more about the async plugin here: https://github.com/millermedeiros/requirejs-plugins/blob/master/src/async.js
define([
'async!https://apis.google.com/js/client.js!onload'
], function () {
'use strict';
console.log("googleAPI has loaded", window.gapi, window.gapi.client);
return window.gapi;
});
I've pulled this information from: Load async resource with requirejs timeout
The error message being displayed is:
Uncaught Error: Load timeout for modules:
async!https://apis.google.com/js/client.js!onload_unnormalized2,async!https://apis.google.com/js/client.js!onload
http://requirejs.org/docs/errors.html#timeout
This code doesn't produce any issues for me locally. It loads fine.
The first step I took to debug the issue was increasing the waitMinutes in requireConfig from 7 to 90. I thought maybe many people have very slow connections:
define(function () {
require.config({
baseUrl: 'js/',
enforceDefine: true,
// I'm seeing load timeouts on in googleAPI -- seeing if increasing wait time helps.
waitSeconds: 90,
...
});
});
This did not seem to affect the issue. I still see many clients reporting an issue.
What other debugging options are available to me in this scenario? Thanks
So I ran into a similar issue when trying debug my application in Internet Explorer 8, and maybe my experience is similar to your clients'.
For me, I found that I was receiving a timeout error because my test browser was having issues retrieving resources through https due to outdated root certificates. I do all of my Internet Explorer testing in a VM running windows 7. When I was trying to load my application I received the same error you mentioned in your post:
Uncaught Error: Load timeout for modules:
async!https://apis.google.com/js/client.js!onload_unnormalized2,async!https://apis.google.com/js/client.js!onload http://requirejs.org/docs/errors.html#timeout
I tried the url manually and was brought to a 'Untrusted Certificate' warning page on my browser. This confused me, but as I later found out the root certificates on my windows os were outdated and causing a failure with the https handshake. The async plug-in seems to consume the authentication exceptions and just sits waiting for something to magically go through leading to the timeout error.
The solutions I found to work are as follows:
Update the root certificates of the os
Change the security properties of my browser to not require certificate authentication
As for suggestions for further debugging, I have two ideas:
Try setting your browser's security properties as high as possible and see if you can recreate the issue (or just temporarily remove your local certificates)
Ask your clients to set their browser's security properties as low as possible, making sure to disable certificate authentication requirements, and ask them if they are still having problems. (If their problems go away, they might need to manually update their local certificates)