Created attachment 295050 [details] stand alone html that shows the problem There is a problem adding the CryptoKeyPair object into indexedDB. I have attached a html test case that shows this problem. This code works in Chrome and Firefox. Neither browser returns a CryptoKeyPair, and instead returns a plain object.
<rdar://problem/29312605>
> This code works in Chrome and Firefox. but then > Neither browser returns a CryptoKeyPair, and instead returns a plain object. This makes no sense to me. If it truly works, it would have to also *return* a CryptoKeyPair. Are you sure CryptoKeyPair is actually serializable WRT the structured clone algorithm? (I haven't looked into it yet)
(In reply to comment #2) > > This code works in Chrome and Firefox. > > but then > > > Neither browser returns a CryptoKeyPair, and instead returns a plain object. > > This makes no sense to me. > If it truly works, it would have to also *return* a CryptoKeyPair. > > Are you sure CryptoKeyPair is actually serializable WRT the structured clone > algorithm? > > (I haven't looked into it yet) The error we throw: DataCloneError "An object could not be cloned" This strongly suggests that CryptoKeyPairs are not structured cloneable, and therefore are not allowed to be stored in IDB
Also, you state this is a regression, but it is not: Safari 9 also shows the DataCloneError
The current spec for WebCrypto: https://w3c.github.io/webcrypto/Overview.html#cryptokey-interface-clone Specifies the Structured Clone Algorithm for "CryptoKey" objects. It does *not* specify the Structured Clone Algorithm for "CryptoKeyPair" objects. Additionally, the WebCrypto spec explicitly calls out the fact that CryptoKeys should be storable in IndexedDB, but not CryptoKeyPairs.
Basically, until somebody finds a standard that specifies the Structured Clone Algorithm for CryptoKeyPair objects, they absolutely should not be storable in IndexedDB.
I believe the reason Chrome and Firefox allow the put is that they do not recognize the CryptoKeyPair as a "CryptoKeyPair" - They think it's an "Object" And "Objects" are structured cloneable as long as each of their properties are.
(In reply to comment #7) > I believe the reason Chrome and Firefox allow the put is that they do not > recognize the CryptoKeyPair as a "CryptoKeyPair" - They think it's an > "Object" > > And "Objects" are structured cloneable as long as each of their properties > are. Got it. At one point in the history of the spec, CryptoKeyPair objects were their own interface, therefore their own explicit object type. Now they're just an object dictionary (https://w3c.github.io/webcrypto/Overview.html#keypair), which means they are an "Object", which means they are structured cloneable
(In reply to comment #8) > (In reply to comment #7) > > I believe the reason Chrome and Firefox allow the put is that they do not > > recognize the CryptoKeyPair as a "CryptoKeyPair" - They think it's an > > "Object" > > > > And "Objects" are structured cloneable as long as each of their properties > > are. > > Got it. > > At one point in the history of the spec, CryptoKeyPair objects were their > own interface, therefore their own explicit object type. > > Now they're just an object dictionary > (https://w3c.github.io/webcrypto/Overview.html#keypair), which means they > are an "Object", which means they are structured cloneable Fixing this is just a matter of fixing our IDL situation for CryptoKeyPair.
This will be resolved as part of https://bugs.webkit.org/show_bug.cgi?id=163711 *** This bug has been marked as a duplicate of bug 163711 ***
We need a specific hack for this as Bug 163711 will not be resolved in a short term.
*** This bug has been marked as a duplicate of bug 165367 ***