Catch openDatabase SecurityError when on a third-party domain in Safari

[exogen]

Safari and Mobile Safari both disallow third party cookies by default. Unfortunately, they also treat WebSQL as a cookie-like storage mechanism and thus disallow it when in a cross-origin IFRAME.

Load this in Safari or Mobile Safari to see the error: http://jsfiddle.net/exogen/nBCGD/

If you don't see the error, it's likely because you've changed the default setting of disallowing third-party cookies. But here it is:

SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent.

It's particularly bad as the localForage library doesn't even finish running due to the exception. So if your page is running inside an IFRAME, and the parent window is on a different domain, any JS in the frame that runs after localForage will likely break.

[tofumatt]

I wonder if #52 is related to this?

I'm not exactly sure what the fix is here... or if it's an important issue? I would imagine that localForage's main use-case is inside apps storing reasonably large bits of data in a fast way, and I don't see a lot of overlap with those kind of apps and pages that get included inside IFRAMEs from another parent domain.

I don't do much cross-domain IFRAME stuff, but is there an easy way to check for that sort of state and disallow WebSQL as a storage backend in that situation? I might be fine with that as an option.

Combined with #79, I'm also guessing we could fix this?

[exogen]

That's interesting – I wonder if the default WebKit policy is to deny third party cookies/storage and PhantomJS is just inheriting that policy? I tried looking for the default policy in the WebKit source tree and couldn't find it.

AFAIK there's no way to detect the policy besides just attempting access and catching the SecurityError. The fix for #79 seems promising, although the detection will be off – it will detect that WebSQL is supported and thus may end up preferring that driver, but the openDatabase line will still fail, right? It seems like the safest option is to wrap the openDatabase call in a try/catch.

[tofumatt]

I'm currently on a train and my wifi is bad, so I can't seem to load your fiddle. I tried to create a test case with a cross-origin iframe and it seems to have passed, but maybe I got it wrong. This might have been solved already though, given the test already passes without the try/catch block we figured we'd need.