DOMException: Connection to Indexed Database server lost. Refresh the page to try again

[oarsheo]

IOS 12.2 ( Cordova ) DOMException: Connection to Indexed Database server lost. Refresh the page to try again

the database crashes from time to time Has anyone encountered this problem?

[jcesarmobile]

Looks similar to https://github.com/ionic-team/cordova-plugin-ionic-webview/issues/352

Can you provide more information? like webview plugin version and some code to reproduce?

[sechel]

Same issue here 😳, seems to have been introduced by iOS 12.2. Hasn't been observed before.

[cepm-nate]

Update: Saving an image from the camera into IDB seems to trigger this pretty often, whereas selecting an image from the gallery and saving THAT into IDB works fine.

My workflow: I have two inputs of type "file". One is set to take a photo from the mobile camera, the other to select a file of type image (one has the "capture" attribute, the other does not). Their 'OnChange' events are both set to the same function which saves the data from the input.file into IDB. (after also resizing it using Canvas).

Somehow the camera sourced image is killing the IDB server connection, while the gallery sourced image works fine (even gallery images taken with the same camera and resolution). But once the IDB server connection is killed, all IDB related calls end up with the same error Connection to Indexed Database server lost. Refresh the page to try again. And again, all of this only on iOS mobile devices. Safari on OSX, and Chrome on Windows and Android work great.

I'm not asking for help here, just reporting what I've found so far.

Testing results (all from a fresh page reload, iPhone 12.2):

• Attaching a file from the gallery produces no error.
• Taking a photo in portrait: ~7 out of 10 fail.
• Taking a photo in Landscape: ~8 out of 10 fail.
• Taking a photo in portrait then rotating it before 'accepting' it (the 'Use Photo' text), 9 out of 10 fail. It feels dirty to be mentioning camera orientation or how a file was put into a "file input" when all the methods use the same IDB storage functions, but for some reason they seem to be connected.

Sometimes I will be able to take 3 or 4 photos before the crash, sometimes not even 1. The first error is always An internal error was encountered in the Indexed Database server, then following interactions emit Connection to Indexed Database server lost. Refresh the page to try again .

[sechel]

Our users start seeing this error but it doesn't seem to be connected to images in our cases. My feeling is that it may be triggered under memory pressure.

[timbru31]

I could not reproduce this issue with the iOS 12.3 beta anymore - can anyone confirm this, too?

[jcesarmobile]

Looks like this was an Apple bug and seems to be fixed in 12.3, can you verify?

[timbru31]

It is fixed, but not yet deployed/live in an iOS update, see: https://bugs.webkit.org/show_bug.cgi?id=197050#c14 (and newer comments)

[mredbishop]

Nope, not fixed. Not fixed in iOS 12.2, 12.3, or 12.4. Fixed in iOS 13 https://bugs.webkit.org/show_bug.cgi?id=197050#c22

[Maikell84]

Is there anything we can do, to get around this bug? Is there a good way to reproduce this bug? For me it only appears very rarely and randomly.

[oarsheo]

import localforage from 'localforage'

export default {
    async init (configWallet) {
        try {
            // IOS 12.2 fixed crash IndexedDB
            // DOMException: Connection to Indexed Database server lost. Refresh the page to try again
            let driver = []
            if (window.device && device.platform.toLowerCase() === 'ios') {
                driver = [
                    localforage.WEBSQL,
                    localforage.LOCALSTORAGE
                ]
            } else {
                driver = [
                    localforage.INDEXEDDB,
                    localforage.WEBSQL,
                    localforage.LOCALSTORAGE
                ]
            }
            await localforage.config({
                driver,
                name: configWallet.name
            })
            await localforage.ready()
        } catch (error) {
            console.error('localforage.config Error: ', error)
        }
    }
}

[guigons]

Same Here! I can reproduce this issue, if you click to lockscreen with app opened on screen and wait 5 minutes VOYALÁ. Connection server lost, and app goes down (CRASH). Any work around about this?

[mcfarljw]

We've been getting reports from users and error logs that seem to support what they are seeing. It's definitely iOS specific and it appears the later release of iOS 12 and all of iOS 13. It's hard to say exactly what is occurring, but somehow indexedDB is getting stuck in an unreadable and unwritable state. We use both localForage and Dexie.

It's almost impossible to consistently reproduce as it happens very rarely. Here are the suspected error messages we're seeing in our logs with partial stack traces:

Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.

at transaction line NaN, column null ([native code]:null)
at initializePromise line NaN, column null ([native code]:null)
at Promise line NaN, column null ([native code]:null)
at promiseReactionJob line NaN, column null ([native code]:null)

Connection to Indexed Database server lost. Refresh the page to try again

at Q line null, column null (null:null)

UnknownError An internal error was encountered in the Indexed Database server

at Q line null, column null (null:null)

My first through was that the database was getting closed. So I added a check to all of our writes to check if the database was closed and then reopen it. Pushed out an update with that, but it's still happening. One of the error messages above mentions database connection is closing which kind of implies that it's neither in a closed or open state, so I'm not really sure how to handle that.

[ghenry22]

I don't have the link handy any more but there was a bug logged against webkit related to indexedDB becoming inaccessible after either the hybrid app is suspended and resumes or a web browser window is minimised and brought back to front.

I was able to reproduce it consistently, in our case we just stopped using indexedDB as there was no easy fix for it.

Sorry I don't have the original bug link on hand any more.

[samunit]

Any progress on this issue or any fixes that have been discovered? We are receiving the same errors from some of our users as well.

[thduttonuk]

We get this error consistently when going into flight mode and then updating indexed db multiple times. Using ios 13.1.1

[lincolnthree]

Yep, here's the Safari issue: https://bugs.webkit.org/show_bug.cgi?id=197050

[NaturalDevCR]

This seems to be present in iOS 14.4.2 still

[lincolnthree]

Still experiencing this in iOS 15

[pradeepaanumalla]

This is still happening in ios 15+

[jasonwinshell-br]

I'm seeing this problem on iOS 15.6 when using the GeniusScan document scanning Cordova plugin. This plugin overlays the Ionic app for an extended period of time. When the plugin returns, IndexedDB has closed the connection and all subsequent store actions fail with "DatabaseClosedError: UnknownError Connection to Indexed Database server lost. Refresh the page to try again".

Is there some workaround? Some way to keep IndexedDB alive?

ionic info

Ionic:

Ionic CLI : 6.20.1 (/opt/homebrew/lib/node_modules/@ionic/cli) Ionic Framework : @ionic/angular 6.0.3 @angular-devkit/build-angular : 13.1.4 @angular-devkit/schematics : 13.1.4 @angular/cli : 13.1.4 @ionic/angular-toolkit : 5.0.3

Cordova:

Cordova CLI : 11.0.0 Cordova Platforms : android 10.1.1, ios 6.2.0 Cordova Plugins : cordova-plugin-ionic-keyboard 2.2.0, cordova-plugin-ionic-webview 5.0.0, (and 22 other plugins)

[CodeCommander]

Is this issue still occurring on iOS 16 beta?

[jasonwinshell-br]

I have not yet tried to resolve the problem with iOS 16. However, I do have some further information. To be sure it wasn't a particular Cordova plugin (GeniusScan) that was causing the problem, I swapped in Scanbot - another document scanning plugin. The same thing happened. XCode revealed it was the WebProxyProcess that was crashing and reloading the entire web view -- essentially restarting my Ionic 6 / Cordova web app. I could see the restart messages. I had been running the app on an iPhone XR with latest iOS 15.x I hadn't restarted my phone for weeks. So I restarted it and found that the problem had cleared. Whatever the issue is, it builds up over with extended use, until the WebProxyProcess no longer seems to be able to run memory-intensive (I'm assuming) plugins that have UIs that overlay the background app.

I also verified the same pair of plugins on other iOS devices and did not see a problem. Since I restarted the phone the problem has not come back. I did notice that when the problem was occurring it seems to occur more and more often with more severe outcomes - the worst being a restart of the web view. It's quite clear the XCode console logs.

[jasonwinshell-br]

I saw this problem again using the standard Cordova camera plugin. According to the XCode console, the WebProxyProxyProcess crashed unexpected after closing the camera plugin and the app web view relaunches -- thus severing any context to the pre-crash web view.

I am seeing: WebProcessProxy::didClose: (web process 0 crash) WebProcessProxy::processDidTerminateOrFailedToLaunch: reason=4 ProcessAssertion: Failed to acquire RBS Background assertion 'ConnectionTerminationWatchdog' for process because PID 0 is invalid ProcessAssertion::acquireSync Failed to acquire RBS assertion 'ConnectionTerminationWatchdog' for process with PID=0, error: (null) .. etc.

The problem is not resolved by restarting the app. The only solution is to reboot the OS entirely. I suspect some accumulating failure in the iOS infrastructure that runs the web view within the hybrid app. The issue is revealed more quickly by those plugins that run a modal UI launched from the web view. It's as if the OS believes that the hybrid's web view has become abandoned while the plugin in front most and kills the web view. It would be great if Apple engineering would look at this issue is it doesn't seem to resolvable by programmatic workarounds.

Thoughts?

[lincolnthree]

I agree that this bug is something outside of our control, as Ionic/Capacitor developers. It is an OS-level issue that requires a restart to get working again, and isn't something we can fix or work around as far as I can tell. I'd encourage everyone here to please add your vote and comment on the Safari issue itself. The folks at Apple need to know it's a serious problem:

https://bugs.webkit.org/show_bug.cgi?id=197050

[jasonwinshell-br]

The crash of IndexedDB (the Safari bug) is a side-effect of iOS having restarted the web view after it detects the embedded web view in the Cordova hybrid app as a zombie process, perhaps due to lack of response to some polling mechanism while a Cordova plugin is running a modal UI. That's my theory.

[jasonwinshell-br]

I can confirm that the problem is still happening with iOS 16. It happens even with using the standard camera plugin (cordova-plugin-camera 6.0.0 "Camera"). If you use open the plugin UI (i.e. take a photo) enough times, eventually the "WebProcessProxy" seems to think that the web view died and restarts the web view, effectively reloading the application. Even restarting the app does not remedy the problem. It's some long term cumulative problem that requires booting iOS entirely.

This is a show stopper problem, with no workaround for Cordova developers, which Apple needs to fix.

Please vote this issue up.

== related issues: https://github.com/apache/cordova-ios/issues/1103 https://bugs.webkit.org/show_bug.cgi?id=197050

WebProxy source code: https://opensource.apple.com/source/WebKit2/WebKit2-7604.1.38.1.6/UIProcess/WebProcessProxy.cpp.auto.html

[jh-gh]

Hi @jasonwinshell-br I would like to upvote this issue ... but I don't see a way to do so on the apple bugzilla site (I am signed in). Is there a way to do so?

Also, would you be able to add your recent info to that bugzilla ticket? It was last updated in June 2021 with comments about iOS 14.

[cschoenecker]

This also happens to me on my application. Maybe we can use the detection of the application in the foreground to recreate the connection if it falls in error? I plan to test this on my application:

App.addListener('appStateChange', state => {
      if (state.isActive) { // if isActive is true, App got sent to foreground, if it is false, it got sent to the background
        console.log("App open in foreground");
        // Fix connection Storage sometime lost (iOS)
        try {
          feedStore.state.storage.get('settings');
        }
        catch (err){
          console.log("Try storage recreated")
          this.createStorage()
        }
      }
    })

[lincolnthree]

@cschoenecker Interesting idea. What is your createStorage() method doing? I'd be interested in trying this as well.

That said, I am pretty sure that when this bug happens, it's because Safari's database thread has crashed, and it requires a full device restart to fix. If an application restart fixes the issue, this solution might work. Interested to hear more about how this goes.

[cschoenecker]

I will rather in my case restart the application if the connection to indexedDB is lost, like this:

App.addListener('appStateChange', state => {
      if (state.isActive) { // if isActive is true, App got sent to foreground, if it is false, it got sent to the background
        console.log("App open in foreground");
        // Fix connection Storage sometime lost (iOS)
        try {
          feedStore.state.storage.length(); // call Ionic stockage API
          console.log("Storage connection OK")
        }
        catch (err){
          console.log("Storage connection NOK, refresh the page to restore IndexedDb to a working state.");
          // Refresh the page to restore IndexedDb to a working state.
          //this.createStorage()
          window.location.reload();
        }
      }
    }) 

appStateChange use Capacitor/app CreateStorage init my Ionic-storage DB :

methods: {
    createStorage(){
      // Storage Init
      const storage = new Storage({
        name: 'feeds_db',
        driverOrder: [Drivers.IndexedDB, Drivers.LocalStorage]
      });
      (async () => {
        await storage.create();
        console.log('Storage created');
      })();
      feedStore.state.storage = storage;
    },