I browsed through the other threads - there was no concrete answer.
I implemented a service worker for notifcations
http://docs.pushwoosh.com/docs/chrome-web-push
I checked everything - all scripts are in root, the keys are well implemented. However, I do not get prompted to allow notifs.
Console output reads:
GET https://mydomain/service-worker.js net::ERR_FILE_EXISTS
Note: I do have the correct URL (just changed it here).
What causes the service worker error? How do I fix this?
It isn't anything to worry about. See the internal bug report: https://code.google.com/p/chromium/issues/detail?id=541797 the TL'DR is that when Chrome tries to fetch a new SW if there is no change and thus nothing to install it throws this error message to indicate that state. There is nothing that you need to do.
Related
I am trying to collect crash logs for my WebAssembly application. It's built with emscripten, everything is served from the same domain, testing in Chrome. In the developer console I see a proper error with stack trace when a crash occurs, I'd like to capture this and send it to a server.
Instead I am only getting "Script error." passed to window.onerror() and the fifth parameter is null. This is supposed to happen when violating the same-origin policy (linked question is only about javascript, does not talk about this WebAssembly-specific problem.) Errors occurring in the .js file don't have this problem, only webassembly runtime errors.
I added the crossorigin attribute to the .js file generated by emscripten. The site is running in secure context, the Response object passed to WebAssembly.instantiateStreaming() (in the emscripten-generated .js file) has "basic" as its .type, so as I understand it has no restrictions on what can be done with it. "Access-Control-Allow-Origin" header is set to "*".
For some weird reason I managed to get the full error with stack trace exactly once, so it is apparently possible, but seemingly doing everything the same way I can't get it to work again.
How can this be solved?
instantiateStreaming is promised based so maybe try window.addEventListener('unhandledrejection')?
I was following this guide on native messaging, but now I've come to a stand-still. The developer console on Firefox keeps giving me the same error:
"Attempt to postMessage on disconnected port" along with "Webconsole context has changed" before it.
I've checked the registries, the ping_pong registry key is in the correct place,
HKEY_LOCAL_MACHINE\\SOFTWARE\\Mozilla\\NativeMessagingHosts\\ping_pong,
and it's value is pointing to the location of my manifest.json file.
My extension id and "allowed_extensions" match.
I found this, and it did stop at the end saying I don't have a python script in the batch file, but that shouldn't be the cause of my error messages.
I have Firefox Quantum 61.0.2, if that's of any use.
What am I doing wrong?
This is a generic error and it means the native messaging host configuration is wrong. The specific error is logged in the Browser Console (Firefox Menu --> Web Developer --> Browser Console) and it is much more helpful.
(For me, the specific error was a typo in the native messaging manifest.)
(Discussed in: https://github.com/mdn/webextensions-examples/issues/266)
I've got an application that's been working for a long time.
Recently we created a new app/keys for it, and it's behaving strangely.
(I did figure out the scope requirements had been put in place. I am requesting bucket:create bucket:read data:read data:write).
When I upload a file to a bucket, I've traditionally called done the call to get the object details afterwards, to verify that it's successfully uploaded.
With the new key, I am intermittently getting this error:
GetObjectDetails: InternalServerError {"fault":{"faultstring":"Execution of ServiceCallout servicecallout-auth-acm-request failed. Reason: timeout occurred servicecallout-auth-acm-request","detail":{"errorcode":"steps.servicecallout.ExecutionFailed"}}}
Is this something I should be re-trying with a sleep in between? or is it indicative of something wrong with the upload?
(FYI - putting in a retry seems to have have resolved this for me, but I still don't know if that's the right answer - and if this issue might happen on other calls).
It could be that the service requires a slight delay between a put object and a get, so I would suggest either use a timer or a retry as you mentioned. However a successful response from the upload should be enough to ensure your object has been placed to the bucket without the need to double check.
I am not sure if this is a bug or an error on my side.
I created and instance on GCE and then proceeded to delete it. The deletion failed with message:
The resource 'projects/[PROJECT]/zones/[ZONE]/instances/[INSTANCE]'
was not found
Please note that this is an automated process that runs a couple times per day, so there wasn't a typo inside the commands.
Nevertheless, the instance was deleted.
Now, every time I try to create an instance with the same name, I get:
NAME ZONE MACHINE_TYPE INTERNAL_IP EXTERNAL_IP STATUS
ERROR: (gcloud.compute.instances.create) Some requests did not succeed:
- The resource 'projects/[PROJECT]/zones/[ZONE]/instances/[INSTANCE]' already exists
But I can't see the instance or its disk anywhere in the Developers Console, neither can I delete it from the command line since I get a resource not found.
I believe this is just a browser cache/cookies issue, where your cache still recognizes the resource name as existing when the resource is already deleted. Clearing the browser cache and cookies or using private browsing/incognito mode should do the trick.
Opening
https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1/apps/repair
in a browser, entering the project ID + submitting has fixed a problem with the same error message for me.
I had a non-OSGi application. To convert it to OSGi, I first bundled it up and gave it a simple BundleActivator. The activator's start() started up a thread of what used to be the main() of my app (and is now a Runnable), and remembered that thread. The activator's stop() interrupted that thread, and waited for it to end (via join()), then returned. This all seemed to be working fine.
As a next step in the OSGiification process, I am now trying to use OSGi configuration management instead of the Properties-based configuration that the application used to use. So I am adding in a ManagedService in addition to the Activator.
But it's no longer clear to me how I am supposed to start and stop my application; examples that I've seen are only serving to confuse me. Specifically, here:
http://felix.apache.org/site/apache-felix-config-admin.html
They no longer seem to do any real starting of the application in BundleActivator.start(). Instead, they just register a ManagedService to receive configuration. So I'm guessing maybe I start up the app's main thread when I receive configuration, in the ManagedService? They don't show it - the ManagedService's updated() just has vague comments saying to "apply configuration from config admin" when it is passed a non-null Dictionary.
So then I look here:
http://blog.osgi.org/2010/06/how-to-use-config-admin.html
In there, it seems like maybe they're doing what I guessed. They seem to have moved the actual app from BundleActivator to ManagedService, and are dealing with starting it when updated() receives non-null configuration, stopping it first if it's already started.
But now what about when the BundleActivator's stop() gets called?
Back on the first example page that I mentioned above, they unregister the ManagedService. On the second example page, they don't show what they do.
So I'm guessing maybe unregistering the ManagedService will cause null configuration to be sent to ManagedService.updated(), at which point I can interrupte the app thread, wait for it to end, and then return?
I suspect that I'm thoroughly incorrect, but I don't know what the "real" way to do this is. Thanks in advance for any help.
BundleActivator (BA) and ManagedService (MS) are callbacks to your bundle. BundleActivator is for the active state of your bundle. BA.start is when you bundle is being started and BA.stop is when it is being stopped. MS is called to provide your bundle a configuration, if there is one, or notify you there is no configuration.
So in BA.start, you register your MS service and return. When MS is called (on some other thread), you will either receive your configuration or be told there is no configuration and you can act accordingly (start app, etc.)
Your MS can also be called at anytime to advice of the modification or deletion of your configuration and you should act accordingly (i.e. adjust your app behavior).
When you are called at BA.stop, you need to stop your app. You can unregister the MS or let the framework do it for you as part of normal bundle stop processing.