New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 600171 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Inspector: incorrect value in response preview for large numbers

Reported by phaik...@gmail.com, Apr 3 2016

Issue description

Chrome Version       : 49.0.2623.110 (Developer Build) (64-bit)
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari:
    Firefox: FAIL 45.0.1
         IE:

What steps will reproduce the problem?
(1) make a server to response JSON data with a larged 64-bit number. I tested things like: {"id": 129679101443080193}
(2) make a script or use Postman to request to it
(3) open the Inspector, activate the Network tab
(4) trigger the request, view the request's response information in Network tab

What is the expected result?
the Preview and Response tabs should show the same correct number

What happens instead?
the Preview tab shows an INCORRECT number (129679101443080200), while the Response panel shows the CORRECT number.

I believe the json parser used in the Inspector has some issues with such large numbers (still in signed int64 range). The same parser is probably used by Firefox, which has the same bug. The incorrect number is always in +-10 range of the correct one, it looks like.

Please provide any additional information below. Attach a screenshot if
possible.
 
Selection_020.png
70.1 KB View Download
Selection_021.png
74.9 KB View Download
Cc: tkonch...@chromium.org
Labels: Needs-Feedback
Could you please please a sample test case/ HTML file to reproduce the issue from test team end.

Comment 2 by phaik...@gmail.com, Apr 6 2016

I wrote a small test server and attached below. You can run the compiled binary on Linux 64bit or compile the Go source file. After the test server is run, you open Chromium Developer Tools, go to localhost:1323, switch to the Network tab, then check the Raw and Preview panels like how I said.
test.go
307 bytes View Download
Project Member

Comment 3 by sheriffbot@chromium.org, Apr 6 2016

Labels: -Needs-Feedback Needs-Review
Owner: tkonch...@chromium.org
Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Needs-Review Needs-Bisect
Cc: pfeldman@chromium.org
Components: Platform>DevTools
Labels: Te-NeedsFurtherTriage
Owner: ----
Labels: -Needs-Bisect
Removing the bisect label as this is out of scope for Test team.

Comment 7 by allada@chromium.org, Apr 29 2016

Status: WontFix (was: Unconfirmed)
This is not an issue because if you type the number 129679101443080193 into console it will be converted to 129679101443080200 because of V8's internal double conversion. If you run: JSON.parse('{"id": 129679101443080193}') it will also give you {id: 129679101443080200} for the same reason.

I do not see this as an issue because it is part of EMCAScript's spec.
see: https://tc39.github.io/ecma262/#sec-terms-and-definitions-number-value

Sign in to add a comment