IndexedDb version number displayed as 32-bit signed integer
Reported by
neosc...@gmail.com,
Dec 18
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Steps to reproduce the problem: 1. Create a new IndexedDB with a version number greater than the max for a 32-bit signed integer. For example, 1545169336539. 2. Open the Chrome developer tools "Application" tab and browse to the IndexedDB created in step 1. 3. The version number shown is displayed as if it were a 32-bit signed integer. -1018890021 for the example value used in step 1. Note, this only affects the display of the version number. The implementation seems to properly handle larger numbers. What is the expected behavior? The version number displayed for the IndexedDB should properly display positive numbers that don't fit into a 32-bit signed integer. What went wrong? The version number display for the IndexedDB is displaying positive numbers that don't fit into a 32-bit signed integer as if they were 32-bit signed integers. Did this work before? No Chrome version: 71.0.3578.98 Channel: stable OS Version: 4.17.19-041719-generic Flash Version:
,
Dec 19
Thanks for filing the issue! @Reporter: Could you please provide sample Test file/URL that reproduces the issue which help in further triaging it in. If possible provide screencast of the issue which help in better understanding. Thanks!
,
Jan 7
Repro step:
1. Open DevTools>Application, open console drawer
2. Type to console: window.indexedDB.open("debug1", 2147483647), notice there is a new IndexedDB instance in DevTools>Application>IndexedDB named "debug1", version is 2147483647
3. Type to console window.indexedDB.open("debug2", 2147483648), notice there is a new IndexedDB instance in DevTools>Application>IndexedDB named "debug2", version is -2147483648.
4. Type to console window.indexedDB.open("debug3", 2147483649), notice there is a new IndexedDB instance in DevTools>Application>IndexedDB named "debug3", version is -2147483647.
The version number should be >0 in step 3,4.
Therefore, the version number is treated as a signed 32-bit integer, but the number accepted in console is treated as a signed 64-bit integer.
,
Jan 10
CL1403675:
type 'window.indexedDB.open("debug", 2147483648)' in console, inspect Application>IndexedDB
image 1: before commit
image 2: after commit
,
Jan 10
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/8e2a0962114bed0a9fe047ec5c62dabc3ea52157 commit 8e2a0962114bed0a9fe047ec5c62dabc3ea52157 Author: Harley Li <hhli@chromium.org> Date: Thu Jan 10 17:22:28 2019 DevTools: fix version number overflow in Application>IndexedDB Originally the version number displayed in Application>IndexedDB is restricted to signed 32bit, so it will be negative if for example (a) type 'window.indexedDB.open("debugDB", 2147483648);' in console, or (b) a databse instance is updated for 2147483647 times. This patch fixes the problem. Bug: 916286 Change-Id: Ib56def7f8c1de246cac917cdd1c40d60b914eb4d Reviewed-on: https://chromium-review.googlesource.com/c/1403675 Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Haihong Li (Harley) <hhli@chromium.org> Cr-Commit-Position: refs/heads/master@{#621622} [modify] https://crrev.com/8e2a0962114bed0a9fe047ec5c62dabc3ea52157/third_party/blink/renderer/core/inspector/browser_protocol.pdl [modify] https://crrev.com/8e2a0962114bed0a9fe047ec5c62dabc3ea52157/third_party/blink/renderer/devtools/front_end/application_test_runner/IndexedDBTestRunner.js [modify] https://crrev.com/8e2a0962114bed0a9fe047ec5c62dabc3ea52157/third_party/blink/renderer/modules/indexeddb/inspector_indexed_db_agent.cc [add] https://crrev.com/8e2a0962114bed0a9fe047ec5c62dabc3ea52157/third_party/blink/web_tests/http/tests/devtools/indexeddb/database-version-number-expected.txt [add] https://crrev.com/8e2a0962114bed0a9fe047ec5c62dabc3ea52157/third_party/blink/web_tests/http/tests/devtools/indexeddb/database-version-number.js
,
Jan 10
|
||||
►
Sign in to add a comment |
||||
Comment 1 by gov...@chromium.org
, Dec 19