Community
Participate
Working Groups
With the implementation of the protocol the javascript error handling has been much improved, as it is now possible to record during which operation an error occured. However, this does not help if the error occurs during the widget rendering ("flushGlobalQueues"), like in Bug 395667. In that case only the error message and the flush phase is displayed. The following additonal information could be gathered: - protocol id of the widget rendered, or (in case of subwidgets) of the parent - classname of the widget - protocol type of the widget or (in case of subwidgets) of the parent - possibly the widgets outerHTML, states map, some essential property values I think this could be achieved without destroying the errors stack-trace by storing the currently rendering widget in the Widget class (statics). Having this in 2.0 would be a really good idea!
I'll extend this bug instead of opening a new one: We should also improve handling of non-criticical JavaScript errors. We make a destinction between JS error thrown while parsing and rendering a server response, and other "non-critical" errors thrown during DOM events. (see ErrorHandler.processJavaScriptError.) Unlike what I remembered we already do not crash the client as a result of non-critical errors if the client is not in debug variant (which is practically always the case for me). The error is only printed to the console. There are some improvements that would be useful here: - Some DOM events are not caught by processJavaScriptError (e.g. unload events, scroll, events, certainly some more), which may cause the browser (depending on the settings) to display an error window of it's own. We should capture all those. - Some errors during response evaluation/rendering may be non-critical too, but they are all handled as critical. We should look to capture those with processJavaScriptError too.
