Within a WKWebView on iOS 8 (12A366), simply run some minimal openDatabase code: openDatabase('mydatabase', 1, 'mydatabase', 5000000, function (db) { console.log('it works!'); }); This results in the following error: Error: SecurityError: DOM Exception 18 I can understand that you might not want to enable Web SQL by default, but it seems from the WebKit Framework Reference [1] that there's no way to enable it. Would it make sense to have an option on the WKPreferences [2] such as `databaseEnabled`? In Android, such an option is available on the WebSettings object [3] so that developers have a workaround for the DOM Exception 18 error. Thanks! [1]: https://developer.apple.com/library/ios/documentation/Cocoa/Reference/WebKit/ObjC_classic/index.html [2]: https://developer.apple.com/library/ios/documentation/WebKit/Reference/WKPreferences_Ref/index.html [3]: https://developer.android.com/reference/android/webkit/WebSettings.html#setDatabaseEnabled%28boolean%29
<rdar://problem/19878179>
<rdar://problem/19029603>
*** Bug 140443 has been marked as a duplicate of this bug. ***
FWIW this happens 100% for me when opening the web inspector (GTK port): resource:///org/webkitgtk/inspector/UserInterface/Base/ImageUtilities.js:39:17: CONSOLE WARN Can't open database due to: Error: SecurityError: DOM Exception 18. Images will be generated instead of loaded from cache.
Yes, the problem is that we don't set any quota, so 0 is used so there's not enough quota in all the cases. I think we just need to implement APIUIClient::exceededDatabaseQuota, providing a default quota.
This problem affects Firefox for iOS https://bugzilla.mozilla.org/show_bug.cgi?id=1226025
The recent Chrome update for iOS (9.2.1) re-introduces this issue. The simple test case in the opening post now returns the "SecurityError: DOM Exception 18" error again.
(In reply to comment #5) > Yes, the problem is that we don't set any quota, so 0 is used so there's not > enough quota in all the cases. I think we just need to implement > APIUIClient::exceededDatabaseQuota, providing a default quota. Note that we did this and don't have the problem anymore.
Mozilla/5.0 (iPhone; CPU iPhone OS 9_2_1 like Mac OS X) AppleWebKit/601.1 (KHTML, like Gecko) CriOS/48.0.2564.87 Mobile/13D15 Safari/601.1.46 "SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent." in persistence.store.websql.js line 64 Error began for all users who upgraded to Chrome 48. Do I understand correctly that the fixes include 1) stop using WebSQL in Chrome or 2) use Safari? Thank you
(In reply to comment #9) > Mozilla/5.0 (iPhone; CPU iPhone OS 9_2_1 like Mac OS X) AppleWebKit/601.1 > (KHTML, like Gecko) CriOS/48.0.2564.87 Mobile/13D15 Safari/601.1.46 > > "SecurityError: DOM Exception 18: An attempt was made to break through the > security policy of the user agent." in persistence.store.websql.js line 64 > > Error began for all users who upgraded to Chrome 48. > > Do I understand correctly that the fixes include 1) stop using WebSQL in > Chrome or > 2) use Safari? > > Thank you This bug is about the fact that WKWebView has WebSQL disabled by default, and app developers have no way to enable it. The fix is for us to either find a way to enable it by default, or to add API for app developers to enable it.
> This bug is about the fact that WKWebView has WebSQL disabled by default, > and app developers have no way to enable it. If that's the case, it's a major step back. We currently do a fallback to IndexedDB, which is even more buggy with large amounts of data than the previous version of Chrome.
> (In reply to comment #9) > The fix is for us to either find a way to enable it by default, or to add > API for app developers to enable it. Thanks Brady for your reply. So developers would be able to enable WebSQL programmatically (with JavaScript) so that it is available for app distribution, or would end-users have to enable this in their own browser? Since WebSQL is being phased out anyway, my boss is interested in redoing the app with a different storage system. What will be the new cross-browser standard for local databases capable of holding MBs of data? Thanks
(In reply to comment #12) > > (In reply to comment #9) > > The fix is for us to either find a way to enable it by default, or to add > > API for app developers to enable it. > > Thanks Brady for your reply. > > So developers would be able to enable WebSQL programmatically (with > JavaScript) so that it is available for app distribution, or would end-users > have to enable this in their own browser? The "API" for developers to enable it will not be a javascript API. It will be a native app API (since that's what we're talking about here - Native apps using WKWebView) > Since WebSQL is being phased out anyway... WebKit has no intention of removing WebSQL. Just because other vendors were not interested in implementing it due to the inherent reliance on SQLite does not mean we plan on removing our implementation.
(In reply to comment #11) > > This bug is about the fact that WKWebView has WebSQL disabled by default, > > and app developers have no way to enable it. > > If that's the case, it's a major step back. AFAIK, this never worked in WKWebView apps, so it's not a regression for WKWebView. Do you have evidence otherwise? If this *did* used to work for WKWebView, fixing it takes a whole new priority.
This should get fixed. Our app was made 2.5 years ago just because iOS did not support IndexedDB, so we have chosen the WebSQL... Now it gets disabled and IndexedDB is full of bugs? Why would they disable the WebSQL... I know it is not a standard anymore but it is the only functional thing (except sync localstorage which we don't want to use).
(In reply to comment #15) > This should get fixed. Our app was made 2.5 years ago just because iOS did > not support IndexedDB, so we have chosen the WebSQL... Now it gets disabled > and IndexedDB is full of bugs? Why would they disable the WebSQL... I know > it is not a standard anymore but it is the only functional thing (except > sync localstorage which we don't want to use). WebSQL has never worked in WKWebView. We would like for it to, but it's not as easy as flipping a switch.
as it's not available, why does window.openDatabase exist? breaking feature detection really sucks
(In reply to comment #17) > as it's not available, why does window.openDatabase exist? breaking feature > detection really sucks window.openDatabase should not exist when the feature is not enabled. But that is a separate bug report from what is described here.
http://trac.webkit.org/changeset/199901
Technically, this is a duplicate of Bug 156928. Sorry for the forward dupe. *** This bug has been marked as a duplicate of bug 156928 ***