Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Global code" casing inconsistency #40

Open
bengourley opened this issue Oct 12, 2017 · 2 comments
Open

"Global code" casing inconsistency #40

bengourley opened this issue Oct 12, 2017 · 2 comments

Comments

@bengourley
Copy link
Contributor

Hi there, first off thanks for an incredible useful collection of modules! 👍

Expected Behavior

I would expect StackFrame.functionName to be consistent across browsers.

Current Behavior

The parsed stack from two different browsers (e.g. Safari 11 vs. Edge 14) which originated in the top level of a <script> tag, yields two distinct strings for StackFrame.functionName:

"Global code" (Safari 11) vs "global code" (Edge 14)

Context

I notice that there are test cases for both versions of this string:

expect(stackFrames[4]).toMatchStackFrame(['global code', undefined, 'http://localhost:8080/file.js', 33, 18]);

expect(stackFrames[4]).toMatchStackFrame(['Global code', undefined, 'http://localhost:8080/file.js', 32, 9]);

So I wonder if this is intentional?

Possible Solution

Personally I would like the library to normalize this string such that stacktraces are more consistent between browsers but I want to know if it is intentionally like this.

If you agree that it should be normalized, I'd be happy to supply a pull request.

Cheers!

@eriwen
Copy link
Member

eriwen commented Oct 13, 2017

Browsers generally have slightly different views on these things as there's no standardization (yet). You're not the first person to ask for normalization, but I would recommend a separate module that can be overlaid atop error-stack-parser. In fact, @auchenberg did a similar thing with error-stack-normalizer though sadly it could not be open-sourced.

I would be willing to provide technical guidance, but I could not take on such a project myself these days as I'm generally fully heads down on the Gradle build tool. What do you think?

@bengourley
Copy link
Contributor Author

bengourley commented Oct 18, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants