IndexedDB ObjectStore.put()/.add() functions not adding new object to database
Reported by
almighty...@gmail.com,
Dec 21 2017
|
||||||
Issue descriptionChrome Version : 63.0.3239.108 (Official Build) (64-bit) URLs (if applicable) : https://almightynassar.github.io/BrokenStarsAndroid/ Other browsers tested: Firefox: OK (57.0.1 (64-bit)) Chrome : OK (63.0.3239.84 (Official Build) (64-bit)) What steps will reproduce the problem? (1) Click on the top-left corner menu, and then select 'Ships' (2) Select 'New' from the tabbed list, then scroll down to the bottom of the page and click 'Random' to auto-fill the form (you could fill the form out yourself, but that is not related to the bug) (3) Click on the 'Submit' button. A dialog box should open up and inform you the ship has been saved. (4) Scroll back to the top of the page and select the 'List All' tab. The new ship will not appear because indexedDB has not saved it. (5) Use developer tools, open up 'Application', and select IndexedDB -> Broken Stars -> Ship Store. No new line will have been inserted. What is the expected result? A new record for the ship is to be inserted into IndexedDB after using the .put() command (during the 'Submit' button click event). Changing .put() to .add() does not resolve the issue, so I assume .add() has the same problem. What happens instead? No error, no new ship, no change to the indexedDB database. Please provide any additional information below. Attach a screenshot if possible. This worked previously on Chrome, so in case my workflow is no longer "standard" I will give snippets of my javascript code (it is a github repository so you can browse it there). Setting up the database connection: // Ensure an implementation of indexedDB exists let indexedDB = window.indexedDB || window.mozIndexedDB || window.webkitIndexedDB || window.msIndexedDB || window.shimIndexedDB; try { // Open (or create) a database connection let dbOpenRequest = indexedDB.open("BrokenStars", self.data.version) // Handles database opening success event dbOpenRequest.onsuccess = function(e){ // Store the result of opening the database self.data.database = e.target.result // Handles general errors on the database self.data.database.onerror = function(e) { console.error("DB ERROR: " + e.target.errorCode); } console.log("Database Opened") } I have a shortcut function to grab the ShipStore table: getShipStore() { return self.data.database.transaction('ShipStore', 'readwrite').objectStore('ShipStore') } Finally save the data: let store = this.$bsFactory.getShipStore() let data = this.ship.deflate() let resultSet = store.put(data)
,
Dec 21 2017
,
Dec 22 2017
More testing. Note that the previous failing Chrome test and the successful Firefox one was run from my home Linux Mint laptop (at work right now). Will give more specs of the underlying OS when I arrive back home. The previous successful Chrome test was from a Windows Vista machine (again, from home). Will provide OS details because Chrome on my work machine (ElementaryOS) apparently works despite having the same version. Please let me know if you want anything specific. Windows Machine (Work) Windows 10 Home Version: 1709 OS Build: 16299.125 ______________________ Edge: FAIL Microsoft Edge 41.16299.15.0 Microsoft EdgeHTML 16.16299 Firefox: OK 56.0 (32-bit) Firefox (after update): OK 57.0 (64-bit) Chrome: OK 63.0.3239.84 (Official Build) (64-bit) (cohort: Stable) Revision 8f51ed0e633e109109762a3deb18a50e8c138819-refs/branch-heads/3239@{#643} JavaScript V8 6.3.292.46 ElementaryOS Machine (Work) Linux caesar 4.10.0-42-generic #46~16.04.1-Ubuntu SMP Mon Dec 4 15:57:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ______________________ Chrome: OK 63.0.3239.108 (Official Build) (64-bit) Revision d2626860fae283daee484943e6820af18fc73fd9-refs/branch-heads/3239@{#676} JavaScript V8 6.3.292.48 Firefox: OK 57.0.1 (64-bit)
,
Dec 22 2017
The failing instance Linux Mint Machine (Laptop - after system update) Linux nassar-laptop 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ______________________ Chrome: FAIL 63.0.3239.108 (Official Build) (64-bit) Revision d2626860fae283daee484943e6820af18fc73fd9-refs/branch-heads/3239@{#676} JavaScript V8 6.3.292.48 Deleting the any existing indexedDB instance does not fix the issue (it will still make the requisite stores though, it just won't save a record to them).
,
Dec 22 2017
Unable to reproduce the issue on Win-10, ubuntu 14.04 and mac 10.12.6 using chrome reported version #63.0.3239.108 and latest canary #65.0.3300.0. Attached a screen cast for reference. Following are the steps followed to reproduce the issue. ------------ (1) Clicked on the top-left corner menu, and then select 'Ships' (2) Selected 'New' from the tabbed list, then scroll down to the bottom of the page and click 'Random' to auto-fill the form (you could fill the form out yourself, but that is not related to the bug) (3) Clicked on the 'Submit' button. A dialog box should open up and inform you the ship has been saved. (4) Scrolled back to the top of the page and select the 'List All' tab. Observed that the new ship appeared without any issues. Could anyone from inhouse team have a look into the issue as from comment #4, issue seems to happen on Linux Mint Machine. Thanks...!!
,
Dec 23 2017
Ok this is weird. The bug is no longer reproducable on my machine. I will go through the steps I took before the bug disappeared. - I tested the bug again to ensure it was still there. At this stage the bug was still failing - I installed Chromium in the background so I could see if the bug was reproducable there (installed version 63.0.3239.84 (Official Build) Built on Ubuntu) - I installed two different extensions for screen recording: BugReplay and Screencastify. I uninstalled BugReplay because I liked the look of Screencastify. - Set up the tab for recording and went through the steps of reproducing the bug. **This time there was no error**. - Opened up Chromium. There was no error going through the steps. - Fully closed Chrome and reopened it. There was no error going through the steps. Either the extensions fixed something, or Chromium installed something with it that cleared out my bug. I'll continue playing with it, but at this stage I cannot reproduce the bug anymore.
,
Dec 26 2017
almightynassar@ As per comment #7 shall we close the issue ?
,
Dec 29 2017
I had it re-occur on Wednesday 27th Dec, but could not reproduce it once I turned on the screen-casting extension. It hasn't shown up again since, but I am trying different things to see if I can reproduce it reliably. If you close this bug and I discover a reliable method to reproduce the bug on my machine, can I add comments or should I make a new bug (referencing this one)?
,
Dec 29 2017
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 2 2018
Closing this issue as per comment #9 @almightynassar: Please feel free to log a new bug or re-open this bug if this happens again. Thanks!!
,
Jan 2 2018
If you observe this happening again, please check: * Is the put() call throwing an exception? This could happen if e.g. the recording being stored was missing the primary key (e.g. had no 'name' property). * Is the put() request firing an error event? (E.g. is resultSet.onerror firing instead of onsuccess?) * Is the transaction committing or aborting? (e.g. modify getShipStore to add `onabort` and `oncomplete` event handlers to the transaction). Note that it's possible for a put to succeed but a transaction to fail (e.g. due to quota issues or I/O error), although I don't imagine that applies in this case (Also, shout-out from a long-time Traveller wonk here!) |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by dtapu...@chromium.org
, Dec 21 2017