1431808 - long Integers rounding last two digits to '00' in JSON view

Status: RESOLVED FIXED

(DevTools :: JSON Viewer, defect, P2)

Description

[JR Conlin [:jrconlin,:jconlin]]

Attachment: round_bug.jpg.png

When displaying:

{"last": true, "index": 1516340399466235648, "messages": [{"timestamp": 1516340399466235648, "data": "asdf"}]}

I'm seeing the last two digits of "index" and "timestamp" being set to "00".

See attached screenshot.

Comment 1

[Oriol Brufau [:Oriol]]

This is a JS limitation:

1516340399466235648 > Number.MAX_SAFE_INTEGER
1516340399466235648 === 1516340399466235600

From RFC 7159 page 7,
>   This specification allows implementations to set limits on the range
>   and precision of numbers accepted.  Since software that implements
>   IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>   generally available and widely used, good interoperability can be
>   achieved by implementations that expect no more precision or range
>   than these provide, in the sense that implementations will
>   approximate JSON numbers within the expected precision.  A JSON
>   number such as 1E400 or 3.141592653589793238462643383279 may indicate
>   potential interoperability problems, since it suggests that the
>   software that created it expects receiving software to have greater
>   capabilities for numeric magnitude and precision than is widely
>   available.
> 
>   Note that when such software is used, numbers that are integers and
>   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
>   sense that implementations will agree exactly on their numeric
>   values.

If you need more precision, use strings.

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

Ah. I get that it's a javascript limitation. It's just that it's appearing inside of the built in JSON view. For folks (like me) that might not be aware of the limitation, it might be good to indicate that there was some numeric truncation going on (other than padding zeros).

Comment 3

[Oriol Brufau [:Oriol]]

The native JSON parser does not provide truncation info. It has already been suggested to add a custom parser, but I'm afraid it will hurt performance in big documents. The bottleneck would still be react, of course.

Comment 8

[slaven.rezic]

I think this bug is grave enough to change the devtools.jsonview.enabled default to "false", and to point users to other json viewer addons which don't have this bug.

Comment 14

[sinus-github]

Judging how this is constantly popping up, perhaps it does deserve some priority?
If the built-in JSON parser doesn't provide overflow warnings, perhaps it should? (Where would one file a request like that?)
Or perhaps Moz could re-.stringify() the resultant JS value into JSON and thus verify if parsing succeeded?

Comment 17

[boris]

Still seeing this one in the latest Firefox 98.0.2 for Mac. Quite surprising, actually.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 duplicates.
:Honza, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 19

[Jan Honza Odvarko [:Honza] (always need-info? me)]

This should be fixed, increasing priority.

Comment 20

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Simple test case with instructions available at: http://janodvarko.cz/tests/bugzilla/1431808/

Comment 22

[Oriol Brufau [:Oriol]]

From bug 1815226 comment #5

There's a proposal to expose the raw text to a JSON.parse function so we could transform those numbers into BigInt (See Bug 1658310)

Comment 25

[Nicolas Chevobbe [:nchevobbe]]

Looks like Bug 1855468 is on its way, let's see if we could use it to fix this issue

Comment 32

[Nicolas Chevobbe [:nchevobbe]]

Attachment: proposed solution

Since we have JSON.parse with source support now¹, I played with a solution that I feel could be nice
So whenever we would get a parsed number that is different from the source, we should display the source number properly, and we could add some UI next to it to display the JS parsed value with a UI that would draw attention to this.
This is a very quick prototype, we could rather have the JS logo or something instead of the warning icon, and have a tooltip on the element, or maybe even better, a link to the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON#lossless_number_serialization

Let me know if you have opinions about this

---

¹ should ride the 135 train, see Bug 1934622

Comment 33

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1431808 - [devtools] Display JSON source number when it's different from JS parsed value in JsonViewer. r=#devtools.

This uses a reviver function in JSON.parse that checks if parsed numbers are
different from their source, and in such case, display both the actual source
as well as the JS parsed value next to it as a "warning", with a title explaining
that the JS parsed value is different from the source.

Under the hood, this is using a new Rep that checks for the specific type
we set in the parse function for such numbers. This also means the ObjectProvider
had to be updated to not render the object "grip" we're constructing as having
child properties.

A test is added to cover those different things.

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/20ee09f5657c
[devtools] Display JSON source number when it's different from JS parsed value in JsonViewer. r=devtools-reviewers,bomsy.

Comment 35

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/20ee09f5657c