Bug 229178 - IndexedDB: Unknown error "Cannot inject key into script value"
Summary: IndexedDB: Unknown error "Cannot inject key into script value"
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Service Workers (show other bugs)
Version: Other
Hardware: All iOS 14
: P1 Blocker
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-08-16 20:53 PDT by captainjono
Modified: 2021-10-12 23:28 PDT (History)
8 users (show)

See Also:


Attachments
Crash (92.55 KB, text/plain)
2021-08-16 20:53 PDT, captainjono
no flags Details
crash with STP Release 130 (Safari 15.0, WebKit 16612.1.26.1.5) installed (92.85 KB, text/plain)
2021-08-19 16:50 PDT, captainjono
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description captainjono 2021-08-16 20:53:25 PDT
Created attachment 435663 [details]
Crash

I am seeing this crash while intercepting a request inside of a ServiceWorker that consequently performs a XmlhttpRequest, does some scrypto, then attempts to access indexdb. It happens at the same place everytime on both macOS (big sur) & iOS (14+). I cant create a minimal repo, seems to only happen when a combination of these servicices is put until real-world load.

I am using WkWebView via Xamarin and have opened up an associated issue here: https://github.com/xamarin/xamarin-macios/issues/12391

The same code does not crash on chrome webkit. If this is indicatite of a problem with my javascript code, could i please get pointers/documentation on what performant JS may look like when attempting to do resource intensive things like in app, e2e encryption. We use ServiceWorker extensively to offload compute.
Comment 1 captainjono 2021-08-16 20:55:02 PDT
Also created a feedback assistance request with Apple: FB952110
Comment 2 Alexey Proskuryakov 2021-08-17 09:30:01 PDT
> Also created a feedback assistance request with Apple: FB952110

Thank you for posting this, cross-referencing reports in this way is very helpful. However, I cannot open this feedback, could you please double check if the number is correct?

> If this is indicatite of a problem with my javascript code

It is not, this is a WebKit issue. I doubt that it can be fixed based on a crash log alone though, would it be possible for you to share a test case?
Comment 3 Radar WebKit Bug Importer 2021-08-17 09:34:56 PDT
<rdar://problem/82033074>
Comment 4 captainjono 2021-08-17 16:28:03 PDT
Sorry, hopefully these work. 

https://feedbackassistant.apple.com/feedback/9521110
TSI: 777259503

There is some additional logs and a repo attached here (did not want this code public) for another crash we saw when using scrypto calls -  doesnt feel the same as this crash because it doesnt produce a crash report, but it was repeatable and occoured at the same spot every time. This crash just recycles the render process, but we have worked around it by using the JS bridge and executing the calls in the host app instead.

We are attempting to get a miminal repo for this crash but its complicated because this is a client/server app and there is alot of mock...

If u have any ideas about possible workarounds - ie. could we pull this code out of ServiceWorker and run it in a normal context to bypass this bug? That will take some effort, but atleast gives us something to aim for. On iOS we have no other option but to use WkWebView, so we are looking for as many options as possible right now.
Comment 5 Alexey Proskuryakov 2021-08-17 16:45:16 PDT
Thank you, FB9521110 works.

rdar://82005138
Comment 6 youenn fablet 2021-08-19 00:29:15 PDT
I think this is fixed by bug 227540 which uses a binary semaphore to block the worker on unwrapping the key.
@captainjono, can you try reproducing the issue in Safari Tech Preview, which should have the fix for bug 227540?

*** This bug has been marked as a duplicate of bug 227540 ***
Comment 7 captainjono 2021-08-19 16:50:10 PDT
Created attachment 435919 [details]
crash with STP Release 130 (Safari 15.0, WebKit 16612.1.26.1.5) installed
Comment 8 captainjono 2021-08-19 16:53:17 PDT
With the latest updates including STP on macOS i am still repoing the same crash. We use WkWebView, not safari directly, incase this matters. I am not familiar with relation between these components, by installing STP, does it upgrade the system WkWebView?
Comment 9 captainjono 2021-08-19 20:01:26 PDT
We have just been able to test on latest iOS15 beta and first look seems its fixed this crash, we are seeing this log message now after our application progresses signficantly further then it did before:

https://xrefs.me/WebCore/webcore/Source/WebCore/bindings/js/IDBBindingUtilities.cpp.html#476

Should i open another ticket? I have updated our FB:ticket with a screenshot of JS console when this occours. 


Given this info, will this mean our app will only support iOS15+?

Could i please get advice/links to doco on how to deploy this to macOS including previous versions (catalina etc)? Ive installed latest xcode beta, latest stp, still repoing old crash.
Comment 10 captainjono 2021-08-19 22:50:25 PDT
I have just installed macOS monteray latest beta and sure enough WebContent no longer crashes, rather hits the same new UnknownError as iOS15.
Comment 11 youenn fablet 2021-08-20 00:16:19 PDT
(In reply to captainjono from comment #8)
> With the latest updates including STP on macOS i am still repoing the same
> crash. We use WkWebView, not safari directly, incase this matters. I am not
> familiar with relation between these components, by installing STP, does it
> upgrade the system WkWebView?

Yes this matters, system WKWebView will not be updated by installing STP.

@cdumez or @sihui may have insights on how to avoid this crash
I guess a repro case might help those investigations.

> https://xrefs.me/WebCore/webcore/Source/WebCore/bindings/js/
> IDBBindingUtilities.cpp.html#476
> 
> Should i open another ticket? I have updated our FB:ticket with a screenshot
> of JS console when this occours. 

We can keep this bug for understanding the unknown error.
A repro case is highly recommended.
Comment 12 captainjono 2021-08-23 23:05:28 PDT
We have not been able to get a minimuim repo together but my company would be willing to provide a set of binarys and instructions to repo if there are no other options.

This issue is a critical blocker for us. Any advice on ways that we can avoid these issues or work around these bugs would be appreciated.
Comment 13 captainjono 2021-08-26 17:56:19 PDT
Bump for advice om workaround or fix?
Comment 14 captainjono 2021-09-15 20:53:56 PDT
We have retested with the latest beta on macOS & iOS15(19A344)

Still receiving "unknown error: cannot inject..." just in a different location in our apps execution. Happens 100% of the time in that new location.
Comment 15 youenn fablet 2021-09-16 01:10:23 PDT
Without a way to (even flakily) reproduce the bug, it seems hard to investigate further.
Comment 16 captainjono 2021-09-16 23:52:26 PDT
In FB9521110 i have attached the only test-case we have. It will repo 100% of the time. Goodluck with the setup :)
Comment 17 Sihui Liu 2021-10-05 12:33:53 PDT
Updated the bug title to reflect current issue: the crash is fixed and now the app is blocked by IDB error according to reporter.

Hi captainjono, I see you've provided instructions on reproducing in Windows. Can you provide a test app that can be run directly in macOS or iOS? From your description, this issue is not specific to Windows. 
(There's difference in implementation for different OS, so if you only reproduce this on Windows build, we may want to ask developer who is maintaining the port to take a look.) 

On macOS and iOS builds, we will be able to add some loggings to help figure out the underlying issues. I am not sure we can do that in Parallels.

If you are looking for workaround for this unknown error, according to the code path, it happens when you let IndexedDB generates the key (e.g. using key path) for the record, so you may want to set the key explicitly when adding a record.
Comment 18 captainjono 2021-10-06 16:27:39 PDT
(In reply to Sihui Liu from comment #17)
> Updated the bug title to reflect current issue: the crash is fixed and now
> the app is blocked by IDB error according to reporter.
> 
> Hi captainjono, I see you've provided instructions on reproducing in
> Windows. Can you provide a test app that can be run directly in macOS or
> iOS? From your description, this issue is not specific to Windows. 
> (There's difference in implementation for different OS, so if you only
> reproduce this on Windows build, we may want to ask developer who is
> maintaining the port to take a look.) 

I Sihui,

We provided an iOS and macOS app "client app" which uses an embedded WKWebView as its UI. To reproduce the crash, you require a Windows App to act as the server. During the comminication process between these 2 apps, the UnknownError is triggered on the client app.

The server app can be run on Win10 via Parallels on macOS as per instructions provided.

We have no other way of reproducing the issue. I hope you understand.

> 
> On macOS and iOS builds, we will be able to add some loggings to help figure
> out the underlying issues. 

great


> If you are looking for workaround for this unknown error, according to the
> code path, it happens when you let IndexedDB generates the key (e.g. using
> key path) for the record, so you may want to set the key explicitly when
> adding a record.

excellent. this is exactly the kind of advice we wanted. we will verify if this is viable.
Comment 19 captainjono 2021-10-12 23:28:32 PDT
> If you are looking for workaround for this unknown error, according to the
> code path, it happens when you let IndexedDB generates the key (e.g. using
> key path) for the record, so you may want to set the key explicitly when
> adding a record.

I can confirm that generating the keys explicitly has fixed our issue with UnknownError.