1847897 - JSON PrettyPrint feature is rounding large numbers

Status: RESOLVED FIXED

(DevTools :: JSON Viewer, defect, P2)

Description

[soehme]

Attachment: test.json

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

1. Download attached file test.json (or create new in text editor and store somewhere). The content of the file is
   {"a":100000000000000001}
2. In Firefox in new Tab hit CTRL+O
3. In the dialog Browse the test.json and open it
4. Click "Raw Data"
5. Click "Pretty Print"

Actual results:

Output of the Pretty print is:
{
"a": 100000000000000000
}
The Number 100000000000000000 can also be seen in step 3. in the tree view

Expected results:

Pretty Print output should be:
{
"a": 100000000000000001
}
Also non-rounded number 100000000000000001 should be displayed in step 3. in tree view.

It is important to display values without modification and only change whitespace outside of strings when debugging APIs communicating with JSON format.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::File Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Tooru Fujisawa [:arai]]

thank you for reporting.
this comes from the limitation of JavaScript, which uses IEEE754 for numbers.
this is dupe of bug 1431808

Comment 3

[soehme]

My bug was closed as duplicate of bug 1431808
bug 1431808 was fixed and I retested with latest nightly build 136.0a1 (2025-01-20) (64-Bit)

But the solution of bug 1431808 did not fix this, it made it worse. Now the Pretty print output (following same click instruction) is

{
"a": {
"source": "100000000000000001",
"parsedValue": 100000000000000000
}
}
and not the expected result from my original report.

There needs to be a seperate solution for this.

I am therefore resetting it back to UNCONFIRMED status.
Feel free to close it as duplicate of another bug if this is already known and a solution for the pretty print part already is in work.

Comment 4

[Julian Descottes [:jdescottes]]

Thanks for checking, Bug 1431808 indeed made this worse but we should now be able to properly fix the initial issue.

Comment 5

[Tom Schuster (Limited availability until May 5)]

Could we do something like this instead:

a: 100000000000000000 [Raw: 100000000000000001]

Comment 6

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

Set release status flags based on info from the regressing bug 1431808

:nchevobbe, since you are the author of the regressor, bug 1431808, could you take a look?

For more information, please visit BugBot documentation.

Comment 7

[soehme]

(In reply to Tom Schuster from comment #5)

Could we do something like this instead:

a: 100000000000000000 [Raw: 100000000000000001]

I am not sure if I would like this solution.

My expectation with pretty print would be that it produces a valid JSON file that has identical content to the original file, only the (non-significant) whitespace is changed to make the file more readible.

The danger with the originally reported behaviour is that the file is changed but with bigger files than the simple test file, changes might go unnoticed by user (note: if the file is saved after pretty-print it saves the output of the pretty-print feature). With the proposed solution, user would definitely notice, but resulting file would not longer be valid JSON.

acceptable solutions could IMHO be:

• simply use the raw value (as the expected behaviour I have written in original report)
• same behaviour as originally reported, but display a clear warning that the resulting pretty-printed file is changed compared to original (so user should not use pretty print if they require unchanged file, for example when debugging JSON HTTP interface that is not JS based)
• or let user decide if JS parsed or raw values should be used

Comment 8

[Nicolas Chevobbe [:nchevobbe]]

Thanks for the report, I'm just going to fix the issue and properly display the raw value , we don't need to display the parsed value here IMO since it's already shown in the JSON tab

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Attachment: Bug 1847897 - [devtools] Fix JSON viewer pretty print for numbers whose source is different from JS parsed value. r=#devtools.

In Bug 1431808, we're handling those numbers in the tree,
which changes the data we're then using for pretty printing.
This patch handle those JSON_NUMBER using a replacer function
and JSON.rawJSON in the JSON.stringify call we're using.
This also allows us to handle -0.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8066155efb5a
[devtools] Fix JSON viewer pretty print for numbers whose source is different from JS parsed value. r=devtools-reviewers,jdescottes.

Comment 11

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/8066155efb5a

Comment 12

[soehme]

rechecked with Firefox Nightly 136.0a1 (2025-01-26) (64-Bit) -> fixed as expected :)