Bug 229178 – IndexedDB: Unknown error "Cannot inject key into script value"

• Component: Service Workers
• Status: REOPENED

[captainjono]

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.

[captainjono]

Also created a feedback assistance request with Apple: FB952110

[Alexey Proskuryakov]

> 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?

[Radar WebKit Bug Importer]

<rdar://problem/82033074>

[captainjono]

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.

[Alexey Proskuryakov]

Thank you, FB9521110 works.

rdar://82005138

[youenn fablet]

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 ***

[captainjono]

Created attachment 435919 [details]
crash with STP Release 130 (Safari 15.0, WebKit 16612.1.26.1.5) installed

[captainjono]

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?

[captainjono]

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.

[captainjono]

I have just installed macOS monteray latest beta and sure enough WebContent no longer crashes, rather hits the same new UnknownError as iOS15.

[youenn fablet]

(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.

[captainjono]

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.

[captainjono]

Bump for advice om workaround or fix?

[captainjono]

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.

[youenn fablet]

Without a way to (even flakily) reproduce the bug, it seems hard to investigate further.

[captainjono]

In FB9521110 i have attached the only test-case we have. It will repo 100% of the time. Goodluck with the setup :)

[Sihui Liu]

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.

[captainjono]

(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.

[captainjono]

> 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.

17.2 seems to have a regression, filed a new issue: https://bugs.webkit.org/show_bug.cgi?id=264099

[Doug Reeder]

I observed this error in every browser for https://notestogether.hominidsoftware.com/ (which after my iPhone 8 was upgraded to iOS 16.7.4  Deleting all website data appears to fix the issue.  I did not observe this for iOS 16.7.2 nor 16.7.3.

The schema is created by:

```
    openRequest.onupgradeneeded = function (evt) {
      const theDb = evt.target.result;
      if (evt.oldVersion < 1) {
        const objectStore = theDb.createObjectStore('note', {keyPath: 'id', autoIncrement: false});
        objectStore.createIndex('byDate', 'date', {});
        const wordsInd = objectStore.createIndex('byWords', 'wordArr', {unique: false, multiEntry: true});
        if (!wordsInd.multiEntry) {
          console.error("IDB: bad wordsInd:", wordsInd.name, wordsInd.keyPath, wordsInd.multiEntry, wordsInd.unique);
          const msg = "This browser does not support full-text search. Try the current version of Firefox or Chrome.";
          reject(new Error(msg));
        }
      }
      if (evt.oldVersion < 2) {
        const searchStore = theDb.createObjectStore('search', {keyPath: 'normalized'});
        searchStore.createIndex('byScore', 'score', {unique: false});
      }
    };
```