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

Specify units used for column numbers #42

Closed
robertknight opened this issue Dec 16, 2021 · 13 comments
Closed

Specify units used for column numbers #42

robertknight opened this issue Dec 16, 2021 · 13 comments

Comments

@robertknight
Copy link

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
Copy link
Member

ljharb commented Dec 16, 2021

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

@iainireland
Copy link

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
Copy link
Member

ljharb commented Jan 4, 2022

@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
Copy link
Collaborator

erights commented Jan 9, 2022

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
Copy link
Member

ljharb commented Jan 9, 2022

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
Copy link

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
Copy link
Member

ljharb commented Jan 10, 2022

@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
Copy link

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

@mitsuhiko
Copy link

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
Copy link

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
Copy link
Member

ljharb commented Aug 11, 2023

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

@ljharb ljharb closed this as completed Aug 11, 2023
@mk-pmb
Copy link

mk-pmb commented Aug 14, 2023

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

@ljharb
Copy link
Member

ljharb commented Aug 14, 2023

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

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

No branches or pull requests

6 participants