-
Notifications
You must be signed in to change notification settings - Fork 13
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
Comments
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 (The string format of |
I think it might be confusing if the console and |
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.
The text was updated successfully, but these errors were encountered: