tc39 / proposal-error-stacks

ECMAScript Proposal, specs, and reference implementation for Error.prototype.stack / System.getStack
https://tc39.github.io/proposal-error-stacks/
MIT License
170 stars 13 forks source link

Specify units used for column numbers #42

Closed robertknight closed 1 year ago

robertknight commented 2 years ago

We encountered an issue in our application where stack traces for the same issue from Firefox and Chrome were resolved to very different locations using sourcemaps by Sentry.

The cause of the issue appears to be that Firefox reports column numbers in terms of Unicode code points, whereas Safari and Chrome seem to use UTF-16 code units. See https://bugzilla.mozilla.org/show_bug.cgi?id=1746374. Most tooling, including Firefox's devtools, seem to expect code units. Another way that tools could potentially misinterpret the column number would be to treat it as a byte offset instead of a string.

In order for crash reports from different user agents to be processed in the same way by downstream tools, it would help if the units and index basis (0 or 1-based) were specified.

ljharb commented 2 years ago

It would always have to use code units, since that’s what JS strings use. Hopefully Firefox fixes this bug.

iainireland commented 2 years ago

To be clear, this was a deliberate decision in Firefox to better match editor column numbers, not a bug. If we collectively decide that it's more important for the column number to be consumable by tooling than by humans, though, it wouldn't be hard to switch back.

ljharb commented 2 years ago

@iainireland because it's observable by JS, then it would potentially kill this proposal because of the added specification complexity that would be needed.

What I'd say is that until there's a collective decision (meaning, all the browsers together) to make that change, it'd be better not to make it in any of them.

erights commented 2 years ago

As @ljharb and I are co-champions of the proposal, I should mention that we have somewhat different approaches. I'm more inclined to figure out what agreement we can get among the implementors on a better semantics, and then try to get them to agree. However, I'll admit that this takes effort, I have not put in that effort on this proposal, and am not likely to in the near future.

Nevertheless, I agree that the issue you raise is worthy of spending effort to get such agreement. A disagreement about this matter will continue to impede much tooling around JS implementations.

ljharb commented 2 years ago

Obviously if a browser wants to stick with a format, we’ll need to support it - but it seems like if this particular change is justified, it’d be worth pursuing a shared consensus on it.

iainireland commented 2 years ago

We haven't officially talked about it yet, but I expect that Mozilla will be happy to standardize on whatever consensus is reached. I just want to highlight that there are trade-offs on both sides here. It seems pretty likely to me that we'll have to settle for code units, but I would hope that we do so based on a more thorough case than "since that's what JS strings use".

ljharb commented 2 years ago

@iainireland fwiw i think it's a great idea to move everyone to using "whatever editors use" - i just think the worst outcome is "everyone's not doing it the same way" :-)

iainireland commented 2 years ago

Cool, I think everybody's on the same page.

mitsuhiko commented 2 years ago

Generally speaking the fact that we count UTF-16 code points is also pretty stupid. If I were to wish for something I would love to instead have byte offsets but here we are. I think given historic context sticking to UTF-16 code points is probably the best to do for what error.stack reports. However I would recommend browsers to just change the display of the stack-trace in the console to recalculate the column offset to actual character offsets instead. Is that an option for you @iainireland?

(The string format of error.stack at this point is pretty heavily overloaded with clutter that is hard to decipher for humans. Sooner or later I also expect that we will reach the limit of what can be encoded into this and a better API will have to come anyways).

iainireland commented 2 years ago

I think it might be confusing if the console and error.stack reported different numbers. Off the top of my head, I'm also not sure how easy/efficient it is to convert one number to the other at that point. It's certainly another option to discuss, anyway.

ljharb commented 1 year ago

It seems like Firefox will fix this in v118, so I'll close this issue.

mk-pmb commented 1 year ago

For easier future reference, can someone update the top post or thread title with the result, which unit was chosen?

ljharb commented 1 year ago

@mk-pmb code units, like everything else - Firefox was the only outlier.