chrome.webstore.install() failure detail string error codes? - google-chrome

I can't seem to find the failure detail string error codes for chrome.webstore.install() 's failure callback... For that matter, I'm not sure if there's documentation for this part of Chrome app development??

From https://developers.google.com/chrome/web-store/docs/inline_installation#triggering
This function [the failure callback] is invoked when inline installation does not successfully complete. Possible reasons for this include the user canceling the dialog, the linked item not being found in the store, or the install being initiated from a non-verified site. The callback is given a failure detail string as a parameter. You may wish to inspect or log that string for debugging purposes, but you should not rely on specific strings being passed back.

Related

WebAssembly crash info in window.onerror()

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')?

Exception handling with Realbrowserlocusts

In using realbrowserlocusts class it appears that I'm limited in any exception handling.
The only reference that partially works is: self.client.wait.until(EC.visibility_of_element_located ....
In a failed condition where the element is not found the script simply starts over again. With the script I'm working with I need to maintain a solid session state; I need to throw and exception(report an error), log the user out and then let the script start over again. I've been testing out the behavior with the locust.py script that Nick B. created with several approaches to "try, except" and they work running without realbrowserlocusts (selenium only) but with it the execution just stops.
Any examples would be greatly appreciated.
In its current format I've been able to run 3x the amount of a browser-based load per/agent/slave than our commercial tool. My goal is to replace it with a locust/selenium approach.
locust-plugins's WebdriverUser has a little bit better exception handling I think. A failure to find an element will log a failed request and if you use RescheduleTaskOnFail (as in the the example) it will restart the task when that happens.
https://github.com/SvenskaSpel/locust-plugins/blob/master/examples/webdriver_ex.py

How are exceptions handled by the browser?

I decided to figure out how the browser processes the script with only one line in the code, and this line is an exception.
Let's say we have this exception:
throw Error("custom error");
By specification ecma262 ThrowStatement returns a completion record with throw type.
When the script ScriptEvaluation is executed:
If result.[[Type]] is normal, then
Set result to the result of evaluating scriptBody.
Return Completion(result).
this makes it clear to us that a completion record with throw type is returned from ScriptEvaluation
But the ecma262 specification does not say when an error is thrown to the console. I need help to see how whatwg specification intercepts error throw from ecma262.
The behaviour you're seeing is specified in the WHATWG HTML standard (emphasis mine).
https://html.spec.whatwg.org/multipage/webappapis.html#calling-scripts
Otherwise, set evaluationStatus to ScriptEvaluation(script's record).
If ScriptEvaluation does not complete because the user agent has aborted the running script, leave evaluationStatus as null.
If evaluationStatus is an abrupt completion, then:
...
...
Otherwise, rethrow errors is false. Perform the following steps:
Report the exception given by evaluationStatus.[[Value]] for script.
Clean up after running script with settings.
Return evaluationStatus.
https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors-in-documents
When the user agent is to report an exception E, the user agent must report the error for the relevant script, with the problematic position (line number and column number) in the resource containing the script, using the global object specified by the script's settings object as the target. If the error is still not handled after this, then the error may be reported to a developer console.
Also, ECMAScript doesn't actually have a console, that's specified at https://console.spec.whatwg.org

How to handle "Unexpected EOF at target" error from API calls?

I'm creating a Forge application which needs to get version information from a BIM 360 hub. Sometimes it works, but sometimes (usually after the code has already been run once this session) I get the following error:
Exception thrown: 'Autodesk.Forge.Client.ApiException' in mscorlib.dll
Additional information: Error calling GetItem: {
"fault":{
"faultstring":"Unexpected EOF at target",
"detail": {
"errorcode":"messaging.adaptors.http.flow.UnexpectedEOFAtTarget"
}
}
}
The above error will be thrown from a call to an api, such as one of these:
dynamic item = await itemApi.GetItemAsync(projectId, itemId);
dynamic folder = await folderApi.GetFolderAsync(projectId, folderId);
var folders = await projectApi.GetProjectTopFoldersAsync(hubId, projectId);
Where the apis are initialized as follows:
ItemsApi itemApi = new ItemsApi();
itemApi.Configuration.AccessToken = Credentials.TokenInternal;
The Ids (such as 'projectId', 'itemId', etc.) don't seem to be any different when this error is thrown and when it isn't, so I'm not sure what is causing the error.
I based my application on the .Net version of this tutorial: http://learnforge.autodesk.io/#/datamanagement/hubs/net
But I adapted it so I can retrieve multiple nodes asynchronously (for example, all of the nodes a user has access to) without changing the jstree. I did this to allow extracting information in the background without disrupting the user's workflow. The main change I made was to add another Route on the server side that calls "GetTreeNodeAsync" (from the tutorial) asynchronously on the root of the tree and then calls it on each of the returned children, then each of their children, and so on. The function waits until all of the nodes are processed using Task.WhenAll, then returns data from each of the nodes to the client;
This means that there could be many api calls running asynchronously, and there might be duplicate api calls if a node was already opened in the jstree and then it's information is requested for the background extraction, or if the background extraction happens more than once. This seems to be when the error is most likely to happen.
I was wondering if anyone else has encountered this error, and if you know what I can do to avoid it, or how to recover when it is caught. Currently, after this error occurs, it seems that every other api call will throw this error as well, and the only way I've found to fix it is to rerun the code (I use Visual Studio so I just rerun the server and client, and my browser launches automatically)
Those are sporadic errors from our apigee router due to latency issues in the authorization process that we are currently looking into internally.
When they occur please cease all your upcoming requests, wait for a few minutes and retry again. Take a look at stuff like this or this to help you out.
And our existing reports calling out similar errors seem to point to concurrency as one of the factors leading up to the issue so you might also want to limit your concurrent requests and see if that mitigate the issue.

Service Worker not prompting to be registered - net::ERR_FILE_EXISTS

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.