Closed robertknight closed 1 year ago
It would always have to use code units, since that’s what JS strings use. Hopefully Firefox fixes this bug.
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.
@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.
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.
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.
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".
@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" :-)
Cool, I think everybody's on the same page.
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).
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.
It seems like Firefox will fix this in v118, so I'll close this issue.
For easier future reference, can someone update the top post or thread title with the result, which unit was chosen?
@mk-pmb code units, like everything else - Firefox was the only outlier.
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.