1184703 - [Netflix] error F7053-1807: indexedDB.open not called back (within 8 second timeout)

Status: NEW

(Core :: Storage: IndexedDB, defect, P5)

Description

[Chris Peterson [:cpeterson]]

With janv's patch from bug 1183689 and cpearce's test profile, we now fail loading with F7053-1807 and there are no QuotaManager warnings in the log.

Adobe says error F7053-1807 means "indexDB.open never called back".

@khuey: can you or Jan take a look into this error? Why might we not be calling back the open callback?

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I'm OOO until July 27.

Comment 2

[Chris Peterson [:cpeterson]]

Jan, can you please take a quick look at this Netflix error when you have time?

Comment 3

[Chris Peterson [:cpeterson]]

Kevin, how long is Netflix's timeout to detect "indexDB.open never called back"?

cpearce repro'd this error when running a debug build with a Firefox build going in the background. It could be that when the CPU is under load (or slow), Netflix's time limit is too short?

Comment 4

[Kevin]

We default it to 8 seconds but is configurable

Comment 5

[Jan Varga [:janv]]

(In reply to Chris Peterson [:cpeterson] from comment #2)
> Jan, can you please take a quick look at this Netflix error when you have
> time?

The success or error callbacks wouldn't be called if the opening is blocked. That is if the same database has been already opened (and not closed) but with older version number. The blocking can also happen when you try to delete a database that has been opened previously.

To avoid such situations, it's good to set a versionchange event listener on database objects and close databases when the event is fired. For example:

let request = indexedDB.open(databaseName, 1);
request.onsuccess = function(event) {
  db = request.result;
  db.onversionchange = function(event) {
    db.close();
  }
}

I'm not 100% sure this is the case in this bug, but it's my first guess.

Comment 6

[Kevin]

Wouldn't the onblocked event get fired if it was blocked? We do handle the onblocked event and have specific error code for this scenario

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Kevin from comment #6)
> Wouldn't the onblocked event get fired if it was blocked? We do handle the
> onblocked event and have specific error code for this scenario

Yes, it would.

Comment 8

[Chris Peterson [:cpeterson]]

Can the versionchange or abort events be caused by Firefox itself or only when the content changes the schema version or aborts a transaction itself? I assume Netflix is not changing their schema version frequently. They do disallow playing movies in multiple tabs, so perhaps there is some database or transaction teardown that happens when they stop playing the movie in tab #2 that confuses tab #1?

Comment 9

[Johnny Stenback (:jst)]

Kevin, any chance you guys could experiment in a test run with a longer timeout to learn more about what is going on here? Thanks.

Comment 10

[Kevin]

I can look into that, I believe its configurable

Comment 11

[Chris Peterson [:cpeterson]]

Kevin, can you try increasing the 8 second timeout to something longer in next week's beta test? We might then receive slow error callbacks with more information about the problem.

cpearce said he was able to reproduce the indexedDB.open timeout a couple times when using a Firefox profile on a slow memory card.

Comment 12

[Chris Pearce [:cpearce (Not reading bugmail)]]

Lowering priority of bugs that don't need to block initial EME rollout.

Comment 13

[Chris Peterson [:cpeterson]]

Kevin, are you still seeing F7053-1807 errors? I don't have any F7053-1807 numbers in our test results spreadsheet or meeting notes.

Comment 14

[Kevin]

The query I run does report this error as it happens before our start play process. I'll run another query when I get a chance to report these numbers