We've been seeing an significant increase in the number of script errors reported in our app that uses the Realtime API. Specifically this started happening around 1/27/16 at ~6/7PM PST. Poking around a bit I believe I was able to track this back to the XHR error callback installed by the Realtime API.
function EA(a) {
a.onerror = function() {
self.xc()
}
}
In this handler self will always refer to window.self which seems like very much the wrong thing as there is never an xc function on the window object. While this doesn't appear to be causing any significantly bad behavior (although it may be contributing to further issues with re-connection), it would be great to have these errors handled.
Is this something other people are seeing as well or a known issue? Is anyone using a workaround?
This has been resolved and you should notice your errors diminish tomorrow when it is released.
This error does not cause any issues with re-connection. The onerror handler is invoked when there are network issues, which are (generally) automatically retried regardless of whether this particular execution path chokes at this point.
Related
I work on a Vaadin 8-based application. In a couple of hard-to-characterize scenarios - and I haven't been able to isolate the triggering factor - document.createElement starts to return undefined on all calls. This has been seen in both IE11 and Chrome (but in different circumstances in each case). My first theory was that it might be a browser out-of-memory issue, but I created a scenario with many more DOM elements that did not reproduce the error, and memory profiling showed no notable spike in memory usage at the point the problem happens. Also, when it happens it's at a predictable point in time - not random enough to be that sort of environmental issue.
When the problem happens, the console reports an odd status for the document.createElement function - it looks 'broken', but doesn't appear that it's just been clobbered by another function or something. Following is what the console shows under normal circumstances:
...while this is what shows after the problem occurs (plus a reference to a nonexistent attribute on document, to illustrate the difference between that and what createElement shows):
In Chrome the behavior in the console is similar:
Has anybody seen such a symptom in any browser and/or have any insight in tracking down the cause?
EDIT 17 January 2018: When I originally wrote this I only witnessed the problem behavior in IE11. Since then I have seen the same behavior under a different circumstance in Chrome.
My issue was that document.createElement was being replaced by some (buggy) injected anti-phishing JS I wasn't aware of. The problem with that JS is outside the scope of this question, but debugging tips provided in comments on the question were valuable in tracking it down:
The fact that document.createElement was being shadowed was discovered by noting that document.hasOwnProperty('createElement') returned true.
Defining a setter function for document.createElement that triggers the debugger helped me track down the offending code. I used the break-on-access snippet for this purpose, but also see simple code in this comment above for a roll-your-own alternative.
I'm new to Angular2 and have been charged with developing "robust error handling". So far I've followed the simplistic examples (console.logging) for adding custom error handling. But sometimes, if the page completely stops loading due to the error, we will want to redirect the user.
However sometimes, as below, although there are errors, the page otherwise loads completely. Are there are only certain types of errors that stop the page from completely loading? One of the following 6 types perhaps?
Any error can stop your page from rendering, depending on where it occurs in your process. Any error can fail to be caught if it is in a callback or other asynchronous action.
Be careful with terms like "robust error handling" - I've seen huge commercial projects that claim just that, but actually just silently truck over loads of issues, kind of like on error resume next.
I find the golden rules are:
If your app can continue through an exception (such as getting corrupt JSON data from a non-essential service) then that specific case should always be explicitly handled.
Otherwise a unexpected exception should always break something visible.
That second rule is counter intuitive, but it really is best practice. Users will complain about errors that they see, and visible exceptions and crashes will upset them and reduce their confidence in your application.
However, exceptions that they don't see still happened, and because you've silently trucked through them whatever caused them is still there. Silent exceptions cause data to be lost or corrupted. They cause the kind of bugs that you only find out about after 6 months in production. They cause the kind of bugs you can get sued over.
Users will forgive you for obvious errors that you fix quick, they will leave and never come back if you lose data and don't immediately know about it.
Ok, so that all said, the errors you seem to be highlighting are asynchronous, and related to a problem sometimes described as callback hell.
In your screenshot the error is from an HTTP GET request - this will typically be a method where you make an AJAX request, have a callback to fire when it succeeds, but don't have a callback to handle the exception.
Angular2 uses promises, which is the next error line of your screenshot. Promises wrap those callbacks and allow you to chain them - they really help with callback hell, but they're not a magic bullet: you have to make sure that every .then() has an error handler or a following .catch().
However, there is an even better way: with Angular2 you can use TypeScript, and that means you can use async and await. These are syntactic sugar for promises, but they also work with try-catch to make error handling of asynchronous exceptions much easier.
I've blogged about that in a lot more detail than I can fit here.
TL;DR: in Angular2 use async/await (with TS transpilation if you need it) to make sure that your Promise and callback exceptions make it back up, and then handle what you expect/can work around and visibly crash for what you can't.
I have a webgl page running in chrome.
Every now and then chrome will report the following error.
[.WebGLRenderingContext]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to render with no buffer attached to enabled attribute 1
I've tried to debug where the error is occurring but I cannot. I can reliably cause it to occur, but when I debug the error is reported on seemingly random lines. I suspect this is because of the asynchronous nature of gpu rendering.
Is there a good way to debug this?
You can use a debug wrapper to wrap the WebGL context and call gl.getError after every WebGL function.
There is an example of one available on the official WebGL Wiki.
Per default WebGL doesn't tell you much about it, you have to query all the information you need yourself. Once you know how to do that, those errors will tell you all you need to debug it. The getter for your case would be
var attribLocation = 1;
gl.getVertexAttrib ( attribLocation, gl.VERTEX_ATTRIB_ARRAY_BUFFER_BINDING );
Which, if you query it before your draw call, will probably return null, which means you're not calling vertexAttribPointer correctly when setting up or switching buffers.
So you go to the point in your code where you set the pointers and enable the arrays and confirm that the location you just enabled with enableVertexAttribArray returns also returns null if you query the buffer at this point. Now you know if you messed up with the pointer. You know you fixed it, when the query returns the correct WebGLBuffer Object.
There are getters for all the states (WebGL is mostly about managing state), they are a bit tricky to use, but using them will greatly help you understand everything going on all the time, when you need or don't need to make calls in order to update that state and where you made mistakes.
You can look the getters and the arguments they take up in the spec
SpectorJS is a tool aimed at WebGl developers wanting to know what happens in their context. It enables capturing of all the available information from a frame. You will be able to look at your entire commands list with their associated visual states and context information.
https://github.com/BabylonJS/Spector.js
I have a problem with webgl context lost/restored.
My application is very heavy with allot of information, graphs, lists, ... and map.
In the map i'm using webGL in order to get the best performances. My code is handling context lost and restored properly.
I'm starting a big operation that causes loading data from the server, parsing it,... This sometimes making the browser loose my webgl context. The problem is that the context is never restored. When I do again this big operation, then i got the restore event.
In my opinion it is related to memory and the garbage collector freeing time.
But I don't really know what to do, and how to solve this.
An approach to handling the lost could be to recreate the canvas and re-initialize your application for the GL parts. In the end, all resources are gone, so the added overhead for context re-creation should not be too troubling and you can take action immediately when the webglcontextlost event arrived.
(not sure if that's the best idea though...)
Commenting on the Answer by Raziza regarding WEBGL_lose_context:
Don't use this one like you proposed there. This extension is merely a debugging tool and should only be used to simulate this behavior.
See also here: https://www.khronos.org/registry/webgl/extensions/WEBGL_lose_context/
Found a way to call restore context manually. Don't know if it is good/smart to do, but it is working for me.
We do it by using the extension WEBGL_lose_context.
MDN reference
// Loading the extension
var ext = gl.getExtension("WEBGL_lose_context");
...
// This code in the context lost event, wait 3 secs for forcing
// restore context
var restoreTimeout = setTimeout(function() {
ext.restoreContext();
}, 3000);
...
// This code in restore context event
// incase we got restore not from my timeout, i'm canceling it
restoreTimeout && clearTimeout(restoreTimeout);
I am debugging the site with Chrome Developer Tools. If I check "pause on all exceptions", it pauses a few times when the site is loading and points to jquery.min.js(#line). These are only caught exceptions.
How can I track it back to see which function of my code causes the exception in jquery?
Also, should I really spend some time to track it down, if all my scripts function properly?
Thanks
Update. The problem is that I cannot see any of my functions in the call stack - only jquery calls:
Perhaps I can safely ignore these since all the exceptions are handled.
For issues like the one you're dealing with I find the printStackTrace method handy and keep it in my dev toolkit.
http://www.eriwen.com/javascript/js-stack-trace/
In a method where I'm having issues, I'll simply do the following:
var trace = printStackTrace();
console.log(trace);
I hope this might help you out. Good luck.
You can view the call stack in the debugger to see if your code caused the invoked code to throw an exception. Unfortunately, you may see some exceptions that were triggered within code running within a timer. Also, keep in mind that jQuery sometimes does a try..catch to detect browser traits, so you really should only be concerned with unhandled exceptions.