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

Status: NEW

(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