When storing an object that contains a WebCrypto CryptoKey to an IDB object store with auto incrementing primary key we get the following error: Error: Unable to inject record key into record value See also https://gist.github.com/sechel/415c34b9bf80f3adeba52856d2377393
I tried the test case in Safari. It doesn't reproduce the bug. A very primitive suggestion here is to see if SerializedCryptoKeyWrap.h has caused some troubles for GTK+.
I remember I told Zan not to wrap/unwrap Crypto Keys for GTK+, so it shouldn't cause any troubles for you. Wrapping crypto keys when storing them into IndexedDB is a legacy behavior to protect them in order to address early limitations of the spec. However, since we have existing clients that have already stored wrapped keys in IndexedDb, Apple ports couldn't get rid of it at this moment.
(In reply to Jiewen Tan from comment #2) > I remember I told Zan not to wrap/unwrap Crypto Keys for GTK+, so it > shouldn't cause any troubles for you. > > Wrapping crypto keys when storing them into IndexedDB is a legacy behavior > to protect them in order to address early limitations of the spec. However, > since we have existing clients that have already stored wrapped keys in > IndexedDb, Apple ports couldn't get rid of it at this moment. Keys are still not wrapped for the GTK+ port, as recommended. At least per this bug report, issue is observed with the Safari Tech Preview. OTOH the test case passes on GTK+/WPE as well, meaning that the issue appears to be present (as otherwise the test case would fail).
Failure occurs during deserialization because UniqueIDBDatabase provides an ExecState from which a usable ScriptExecutionContext cannot be retrieved. That's currently necessary in order to pipe the serialization and deserialization operations all the way up to the WebChromeClient in UIProcess. https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/bindings/js/SerializedScriptValue.cpp#L477 https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/bindings/js/ScriptState.cpp#L65
> OTOH the test case passes on GTK+/WPE as well, meaning that the issue appears to be present (as otherwise the test case would fail). Thats right, sorry for causing confusion. The test case is written canary style meaning it will fail if the issue has been resolved. BTW, this bug seems to be related as it also involves creating indices with WebCrypto keys present: https://bugs.webkit.org/show_bug.cgi?id=177350
Anything new in the meantime? I will now perform another attempt to port out web application to Safari. Its pretty frustrating that I need so many Workarounds just due to WebCrypto.
This has been fixed in Safari 13.x.x.
<rdar://problem/56613473>