According to https://w3c.github.io/IndexedDB/#dom-idbobjectstore-get, IDBObjectStore.get should return undefined as result. In Safari 10, null is being returned instead and seems to be a regression.
This breaks existing web app that assumes undefined will be returned when the object does not exist in the object store. null is a defined value for object.
<rdar://problem/28726701>
This is yet another one where I'm shocked there's no relevant w3c test
(In reply to comment #3) > This is yet another one where I'm shocked there's no relevant w3c test We only pass 80% of those IDB w3c tests last I checked.
(In reply to comment #4) > (In reply to comment #3) > > This is yet another one where I'm shocked there's no relevant w3c test > > We only pass 80% of those IDB w3c tests last I checked. There's tons of tests (I'm guessing ~20%) targeting IDB 2.0 features. When you subtract out things we don't support, we should pass the suite.
Regardless, I can't reproduce the bug reported here. Attaching the test case I'm using that shows we correctly return undefined instead of null.
Created attachment 291668 [details] Test case that does *not* show the bug
Please attach a test case that actually shows the bug. We can't fix what we can't verify is broken.
Figured out the reason I got a null is because of another IndexedDB regression https://bugs.webkit.org/show_bug.cgi?id=162554. Also, I verified the problem has been fixed in Safari Technology Preview. Sorry for confusion!
(In reply to comment #9) > Figured out the reason I got a null is because of another IndexedDB > regression https://bugs.webkit.org/show_bug.cgi?id=162554. Also, I verified > the problem has been fixed in Safari Technology Preview. > Sorry for confusion! Aha! Wasn't even an IndexedDB regression, but definitely affected IDB users! Glad we have an explanation. I'll close the radar, too.