Browser-injected JavaScript should never raise unhandled JavaScript exceptions |
||||||||||||||
Issue descriptionLots of web developers rely on services that track all invocations to window.onerror. If bling ever generates unhandled JS exceptions itself, it can cause analytics problems for such users (eg. swamping out their own issues with bling-specific ones). For example see: http://stackoverflow.com/questions/26483541/referenceerror-cant-find-variable-gcrweb issue 590375 Any hits when googling for "gCrWeb" Can we come up with some scheme to reduce the risk that exceptions will ever escape from bling-internal JS code?
,
Nov 14 2016
Do we have any UMA metrics today about unhandled exceptions generated by bling JavaScript code?
,
Nov 14 2016
,
Nov 14 2016
,
Nov 14 2016
,
Nov 14 2016
+eugenebut
,
Nov 14 2016
,
Nov 14 2016
We can wrap all JS execution in try-catch block.
,
Dec 22 2016
This bug does not block/418827. 418827 is an actual bug in Autofill feature, catching the exception will not fix that race condition.
,
Mar 20 2017
Is that link in #10 the right one? That's about the (slighly related) __gCRWeb issue. By the way, I assume there are some cases where we do want specific exceptions to escape. Eg. if we're wrapping an API that (by spec) can throw exceptions in certain situations, then we should still allow those exceptions through. The issue here is just with exceptions coming from our own implementation that aren't specified to be part of the behavior of the API being invoked. /cc danyao@ who might be looking at this
,
Mar 20 2017
Sorry, that doc belongs to crbug.com/665045. Removing comment #10
,
Apr 24 2017
,
Jul 12 2017
,
Oct 26
,
Oct 26
,
Oct 26
|
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by rbyers@chromium.org
, Nov 14 2016