On the UIWebView in iOS8, the `window.indexedDB` object is null and read-only, which means it's impossible to shim using something like IndexedDBShim [1]. An article just appeared in Smashing Magazine a few weeks ago with a tutorial about how to use IndexedDB with IndexedDBShim [2]. Anybody following the article will end up with non-working code in an iOS 8 app due to this bug. There's also a relevant IndexedDBShim issue [3]. [1]: https://github.com/axemclion/IndexedDBShim [2]: http://www.smashingmagazine.com/2014/09/02/building-simple-cross-browser-offline-todo-list-indexeddb-websql/ [3]: https://github.com/axemclion/IndexedDBShim/issues/161
It may also be problematic that IndexedDB variables like IDBCursor and IDBKeyRange are also attached to the window object. I've attached a screenshot to demonstrate.
Created attachment 238555 [details] Screenshot of the Safari 7.1 web inspector on an iOS 8 device using a UIWebView
IndexedDB is only supported on WKWebView and Safari. UIWebView uses legacy WebKit and it does not have IndexedDB. Having IDBCursor and IDBKeyRange on the window when IndexedDB isn't supported is likely a bug. Any other issues with IndexedDB in Safari or WKWebView should be filed as separate bugs.
<rdar://problem/18429374>
Oh, yeah. They should be undefined and replaceable. Having window.indexedDB be null and read-only makes polyfills not work.
This also affects NSWebView.
Same thing in global pages of Safari extensions. bug 19318765 @ bugreport.apple.com
Created attachment 254423 [details] Patch v1
The efl-wk2 failure is not due to this patch. The mac-wk1 failure is bewildering, as I accounted for the wk1 changes in this patch (that was the primary goal, in fact) Will have to wait until the EWS run finishes and gives me the full results.
Comment on attachment 254423 [details] Patch v1 Attachment 254423 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/6246540163153920 New failing tests: js/dom/global-constructors-attributes.html
Created attachment 254424 [details] Archive of layout-test-results from ews102 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
mac-mavericks wins out over mac-wk1, even when running wk1 on mavericks. I guess we need a mac-mavericks-wk1
mac-mavericks *is* wk1, and mac-mavericks-wk2 would be for mavericks wk2. Sweet.
Nope nevermind, mac-mavericks wins out over both mac-wk1 and mac-wk2, so that stinks.
Actually mac-wk2 might win over mac-mavericks, so let's see here... I'll just try with a patch
Created attachment 254427 [details] Patch v2 - Try to fix the mavericks wk1 problem
Comment on attachment 254427 [details] Patch v2 - Try to fix the mavericks wk1 problem Attachment 254427 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5973839804628992 New failing tests: js/dom/global-constructors-attributes.html
Created attachment 254430 [details] Archive of layout-test-results from ews105 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
The "flexibility" of the layout test platform directories is really getting in the way here. Might just skip this on Mavericks.
Created attachment 254437 [details] Patch v3 - Fix the Mavericks problem.
Comment on attachment 254437 [details] Patch v3 - Fix the Mavericks problem. View in context: https://bugs.webkit.org/attachment.cgi?id=254437&action=review r=me > Source/WebCore/bindings/js/JSDOMWindowCustom.cpp:194 > + // So to completely disable IndexedDB at runtime we have to not generate these accessors I would say "not autogenerate".
Comment on attachment 254437 [details] Patch v3 - Fix the Mavericks problem. Clearing flags on attachment: 254437 Committed r185322: <http://trac.webkit.org/changeset/185322>
All reviewed patches have been landed. Closing bug.