Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Safari IndexedDB/WebSQL bug wishlist

Safari IndexedDB/WebSQL bug wishlist

Big overview of what's missing in Safari 7.1+ and iOS 8+ in terms of browser storage.

Updated May 25th 2016

Safari (general)

UIWebView

WKWebView

Homescreen apps/Chrome for iOS

More details

@dfahlander

So happy that things are moving! Thanks Apple and thanks Nolan for giving Apple some pressure ;)

@chrisritter

The lack of indexeddb in web workers is going drive us crazy... Hopefully the Safari team gets on this for iOS 10

@nolanlawson
Owner

@chrisritter I have a workaround for that, which is to use a pseudo-webworker: http://github.com/nolanlawson/pseudo-worker

@kilbot
kilbot commented Feb 29, 2016

I've been struggling with unexpected behaviour in Safari, it seems to have been fixed in the WebKit nightlies, but I thought I'd post it here in case anyone else is having the same issue. When doing a batch merge on an index (get then put), it seems Safari does not keep track of the auto increment value, it will just overwrite data.

http://bl.ocks.org/kilbot/3a1f7adf04842806baa8

@nealeu
nealeu commented Apr 11, 2016

It looks like we're going to have to keep telling our clients: Get a Chromebook, or an Android tablet/phablet, but whatever you do, just don't get an iOS device. With Ubuntu tablets and phones appearing now, alongside Android One, Apple really need to wake up and smell the coffee. It's 2016, and we want to write once for mobile web apps, not write an "app" per mobile OS. Safari has become to us what IE6 was, except more buggy.

@dfahlander

Just ran dexie unit tests on Safari Technology Preview Version 9.11 (11601.6.15, 11602.1.27) and for the first time it actually succeeds most of the tests (1107 assertions of 1117 succeeded). It handles multiValued indexes and compound keys perfectly, and it's fast. There seem to be a trivial issue left that makes the remaining 10 assertions fail. I'm suspecting that indexedDB.cmp() doesn't work as expected but need to dig into it a little deeper to find out for sure.

@dfahlander

It turned out to be an insane bug still present in their latest technology preview: When having multiple object stores and querying an index of one store, you will also get matches for indexes on other stores. cursor.key shows values from the index of another store. cursor.value shows random duplicate values from the store you are querying.

Basically, if you have objectStores 'students' with an index 'name' and 'schools' with an index 'city', and you query the 'name' index on 'students' with no range specified (or WITH a range - it doesnt matter), you will get a cursor that iterates a mix of student names and cities. Each onsuccess callback from the cursor will have a key that sometimes is a student name and sometimes a city. The value though is always a student and some students are shown multiple times - one time with the name key and another time with a city key,

What's the easiest way to file this issue?

@nolanlawson
Owner

@dfahlander In the past I've had good luck filing issues on https://bugs.webkit.org/ with reproducible test cases. For some examples of bugs I've filed that got fixed, see the links above.

BTW unfortunately Github does not send notifications when you add comments to a Gist, so might be best to communicate via email or elsewhere. :)

@Bnaya
Bnaya commented Jul 20, 2016 edited

what the status in iOS9.3? is it ready for use? (wkwebview)

@ghost
ghost commented Aug 5, 2016

still getting indexDb is undefined even with pseudo-webworker, does it support Blob ??

@dfahlander
dfahlander commented Aug 22, 2016 edited

There's still one severe bug left: https://bugs.webkit.org/show_bug.cgi?id=158833. I get no attention from the guys at webkit bugzilla about this bug. In current preview of Safari 10, it still mixes keys in different object stores with each other when opening a cursor to iterate entries.

@dfahlander

Ni Nolan, unfortunately there's been no one looking at my reported bug on webkit
https://bugs.webkit.org/show_bug.cgi?id=158833. It's really severe. Now that Apple claims to support the full standard, it's a pity if they didn't fix this one becuase it's yet another "mixing contents between ObjectStores" bug and it would harm their reputation. Is there anything you could do to make them open my bug (reported back in June)

@dfahlander
dfahlander commented Sep 22, 2016 edited

Update: Bradley Eidson fixed the issue today. He confirmed:

With my fix, with the Dexie test suite, I see:
1122 assertions of 1122 passed, 0 failed.

Let's hope it will do it to iOS and MacOS as well. They probably would need some pressure to get the issue published. If anyone reading this knows a site or web app that uses IndexedDB with multiple ObjectStores and possibly colliding primary keys (for example using autoIncremented primary keys), please let me know! I need concrete samples to set some pressure.

@dfahlander

Also, @nolanlawson, would it be possible to get the issue into your wishlist?

@cesar-oyarzun-m
cesar-oyarzun-m commented Sep 27, 2016 edited

@dfahlander I'm testing on IOS 10.1 beta 1 using cordova but it seems to be an issue with security, I'm getting SecurityError (DOM Exception 18): IDBFactory.open() called in an invalid security context . Do you know if this was actually fix on IOS 10?

@erhanyasar

I got still problem with it and issued you #260 would you please take a look?

@paulfrench

Is indexeddb finally okay on a certain version of IOS ? I've tested my application against 10.3.1 and it seems okay apart from storing blobs. I still have to transform a blob to a base64 encoded string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment