Description
Current Behavior
We have detected a problem when generating stack trace from a SyntaxError. This takes place when the error cause is due to a malformed javascript code, the output of the library is not consistent:
- On chromium browsers it returns a malformed single stack trace element not containing the lineNumber property
- On non-chromium browsers it throws an exception.
Expected Behavior
We would expect one the following two behaviours, being number 2 the preferred:
- Consistency across all browsers. In this case, we would expect the exception on all of them.
- Handle this case and return a well formed single stack trace element, for example:
Steps to Reproduce (for bugs)
The code below reproduces the issue:
<html>
<head>
<title>Inline errors page test</title>
</head>
<body>
<h1>Inline errors page test</h1>
<script type="text/javascript" src="error-stack-parser.js"></script>
<script>
window.addEventListener("error", (errorEvent) => {
const stack = ErrorStackParser.parse(errorEvent.error)
console.log("stack", stack);
})
</script>
<script>
var a: // the malformed javascript here
</script>
</body>
</html>
Important: A SyntaxError generated from a bad usage of a API like JSON.parse does not reproduce the issue
<html>
<head>
<title>Inline errors page test</title>
</head>
<body>
<h1>Inline errors page test</h1>
<script type="text/javascript" src="error-stack-parser.js"></script>
<script>
window.addEventListener("error", (errorEvent) => {
const stack = ErrorStackParser.parse(errorEvent.error);
console.log("stack", stack);
})
</script>
<script>
JSON.parse('<I am not a json>') --> wrong input
</script>
</body>
</html>
Context
Your Environment
This happens on all versions of the library (including the latest one).
Tested on different OS, such as MacOS, Fedora Linux, and Windows 10
Possible Solution
It seems that the parse function it might be the good place to start with the fix. Presumably, there is new condition to be added or a change on the regex that needs to be done, or both.
On Chromium browsers the line return this.parseFFOrSafari(error); is the one being executed, which is wrong.
On our product we have followed a defensive approach to overcome the issue:
We leverage the information available in ErrorEvent. So, if the library throws an exception or generates a malformed stack trace what we do is to extract lineno, colno, and filename from such event.