Open Bug 1316680 Opened 7 years ago Updated 6 months ago

dom/indexedDB/test/test_error_events_abort_transactions.html fails to run >1 time in the same browser session


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





(Reporter: jmaher, Unassigned)


(Blocks 1 open bug)


in experimenting with a possible new test verification job, I examined existing tests and realized that many do not run >1 time in the same browser session:
./mach mochitest dom/indexedDB/test/test_error_events_abort_transactions.html --repeat 1

67 INFO TEST-UNEXPECTED-FAIL | dom/indexedDB/test/test_error_events_abort_transactions.html | got success when it was not expected!
    @dom/indexedDB/test/test_error_events_abort_transactions.html line 17 > eval:1:1
this is an area I am not very familiar with.  From what I can tell we generate the error while connecting to the database:

and we probably have some condition in there from the first time running the test that makes us fire request.onsuccess instead of request.onerror.

As it stands, I am unable to find an owner for these tests. I would like to know:
1) is this test (and ideally other mochitest indexeddb tests) duplicated in functionality to web-platform-tests:
2) why is this failing, what are techniques to fix this?
3) there is no triage owner for the bugzilla component listed here:

:overholt, can you find someone to be an owner of this component overall and be a contact for answering my questions above?
Flags: needinfo?(overholt)
Jan or Bevis can help you.
Flags: needinfo?(overholt)
Flags: needinfo?(jvarga)
Flags: needinfo?(btseng)
The root cause is that the test DB was not clear after finished.
Most of the mochitest in indexedDB are enclosed by its helpers.js which will help to clearAllDatabases() before and after the test:,227
However, this test case is run inside an iframe that was not supported by the helpers.js, so a specific version of clearAllDatabases() for this one is needed.
The alternative solution is to invoke "indexedDB.deleteDatabase(window.location.pathname);" at the beginning of the test to ensure that there is not DB existed before the test.

Besides, these mochitests are not duplicated to web-platform-tests:
   - Most of our test verified in both main thread and service worker while wpt doesn't.
   - Some of the test cases are created to verify gecko specific features that are not standardized in w3c.
We could move the tests in common to wpt in the future if the test harness for IDB in wpt are well-defined.

BTW, is there any list of the failure IDB test cases that cannot be repeated > 1 time?
I could help to clarify the problem and come out the solution if needed.
Flags: needinfo?(btseng)
thanks for the information here!  There are 3 tests that I could find which fit this category:

Ideally we should clean these up after the test, in case there is something else which is run in the same browser session which could be affected by the left over data/state.
(In reply to Joel Maher ( :jmaher) from comment #1)
> 3) there is no triage owner for the bugzilla component listed here:

That should be me/Hsin-Yi (I'm fine with my name being there despite Hsin-Yi and Andrew McCreight doing lots of the heavy lifting unless they want the glory :).
Emma, see comment 5 about getting a triage owner for dom/indexedDB.
Flags: needinfo?(ehumphries)
Created bug 1317419 to assign triage owner.
Flags: needinfo?(ehumphries)
See response in comment 3.
Flags: needinfo?(jvarga)
Priority: -- → P3

:sgiesecke, did the situation change or is comment 3 maybe something to consider whenever we are going to touch indexed DB tests?

Flags: needinfo?(sgiesecke)

(In reply to Jens Stutte [:jstutte] from comment #9)

:sgiesecke, did the situation change or is comment 3 maybe something to consider whenever we are going to touch indexed DB tests?

The situation has not changed for at least dom/indexedDB/test/test_error_events_abort_transactions.html

Yes, we should improve this when touching the tests. I will consider this in the test improvement plan.

Flags: needinfo?(sgiesecke)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.