Support detection of indexedDB window variable

[lincolnthree]

Support detection of indexedDB window variable using Chrome supported variable name.

This seems to fix some race conditions that cause the indexeddb driver to fail detection and move on to the next configured driver (a very odd situation with little fallback)

On another note, it might be nice to get a console warning or callback when driver fallback has occurred.

[lincolnthree]

@tofumatt Interested in your thoughts on this. It seems Chrome has (or recently has moved to) a different variable name for indexedDB.

[tofumatt]

I'll take a look at this over the weekend (sorry, bit of a busy week for me right now), but I'm surprised this is an issue, as I think the idb file uses those same globals...

[lincolnthree]

@tofumatt Here's a screenshot that might help. From Chrome 86.0.4240.80 (Official Build) (x86_64)

[lincolnthree]

PS. I have confirmed in testing and in production that this patch does fix the issue.

[lincolnthree]

Bump.

[atjn]

@lincolnthree you have fundamentally misunderstood the problem. The browser has never had a window.idb object, even the first draft from 2010 uses window.indexedDB. The variable idb is imported from the idb.js file, and is a pesudonym for window.indexedDB + a few vendor-specific names.

I'd guess that you are using a bundler which runs the check for window.indexedDB inside the bundler, and condenses that whole check to false because your bundler doesn't support window.indexedDB, and then ships the permanently disabled code to the browser.
Your "fix" is to completely ignore the idb check and implement your own narrower check which breaks backwards compatibility with the vendor-prefixed databases.

If you ask me, the real solution would be to release a new major version of localForage that requires support for indexedDB 2.0, which is 95% supported in the wild. This would allow you to delete the idb.js file and change line 7 to:

if (!indexedDB?.open) {

[lincolnthree]

@lincolnthree you have fundamentally misunderstood the problem. The browser has never had a window.idb object, even the first draft from 2010 uses window.indexedDB. The variable idb is imported from the idb.js file, and is a pesudonym for window.indexedDB + a few vendor-specific names.
Your "fix" is to completely ignore the idb check and implement your own narrower check which breaks backwards compatibility with the vendor-prefixed databases.

@atjn Whether you intended to or not, a non-zero amount of condescension has come through in your response. Absent any real feedback or help from the maintainer in this situation, and without an expert understanding of every line of how localForage works, I did my best to find a solution. That solution may not have been correct, and I may have misunderstood the problem, but at least I tried, suggested a fix, requested feedback, and waited for over two years with no response.

Now that we have that out of the way, I appreciate that you've suggested a better solution. My fix (correct or not) has been working in production for the past two years with no crash reports or bugs submitted from users, so I'm fine with whatever you decide is the right path forward.

Best of luck.

[atjn]

@lincolnthree I am very sorry, it was not my intention to be condescending. I was trying to be as clear and convincing as possible, and reading it again, I can see that that accidentally also made it condescending.
I think your fix is perfectly fine for your use-case and I applaud that you are trying to help fix this upstream. I was simply trying to contribute with a solution that would be better suited for the broader ecosystem and for maintainability in the long run :)

[lincolnthree]

@atjn Thanks. I appreciate your response. It's easy to mis-interpret written communication, too. So I can own that part as well.

Thanks for contributing an updated solution, and for supporting the need for a fix. I agree that I think upgrading to IndexedDB 2 would probably be ideal. At this point, given the stats you cited on browser support/usage, it just makes sense. Doing it in a 100% backwards compatible way would also be helpful for some, but probably not necessary depending on the users for a given application. Certainly wouldn't matter for us if IE weren't supported. Hah.

Anyway, thanks again and who knows. Maybe this will get fixed sometime :)