Open Bug 1184703 Opened 6 years ago Updated 3 years ago

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

Categories

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

defect

Tracking

()

Tracking Status
firefox40 --- ?
firefox41 --- ?
firefox42 --- affected

People

(Reporter: cpeterson, Unassigned)

References

(Blocks 1 open bug)

Details

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?
Flags: needinfo?(khuey)
I'm OOO until July 27.
Flags: needinfo?(khuey)
Jan, can you please take a quick look at this Netflix error when you have time?
Flags: needinfo?(Jan.Varga)
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?
Flags: needinfo?(keving)
We default it to 8 seconds but is configurable
Flags: needinfo?(keving)
(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.
Flags: needinfo?(Jan.Varga)
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
Flags: needinfo?(Jan.Varga)
(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.
Flags: needinfo?(Jan.Varga)
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?
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.
Flags: needinfo?(keving)
I can look into that, I believe its configurable
Flags: needinfo?(keving)
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.
Flags: needinfo?(keving)
Summary: [Netflix] error F7053-1807: indexDB.open never called back → [Netflix] error F7053-1807: indexedDB.open not called back (within 8 second timeout)
Lowering priority of bugs that don't need to block initial EME rollout.
Priority: P1 → P2
Kevin, are you still seeing F7053-1807 errors? I don't have any F7053-1807 numbers in our test results spreadsheet or meeting notes.
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
Flags: needinfo?(keving)
Priority: P2 → P5
You need to log in before you can comment on or make changes to this bug.