Open Bug 1178829 Opened 9 years ago Updated 2 years ago

[META] Fix remaining idb web-platform-test failures

Categories

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

Product:
Core
Component:
Storage: IndexedDB
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox42 --- affected

People

(Reporter: bzbarsky, Unassigned, Mentored)

References

(Depends on 2 open bugs)

Details

(Keywords: meta, Whiteboard: [tw-dom] btpp-fixlater DWS_NEXT)

Depends on: 1179025, 1178803, 1178806
We're down to idbfactory_open10.htm idbfactory_open9.htm.ini idbobjectstore_createIndex6-event_order.htm idbobjectstore_createIndex7-event_order.htm idbtransaction_objectStoreNames.html interfaces.worker.js
Whiteboard: [tw-dom]
Depends on: 1253634
Assignee: nobody → btseng
Status: NEW → ASSIGNED
Whiteboard: [tw-dom] → [tw-dom] btpp-active
Summary of the remaining test cases: Bug 1274938 depends on the update of IDB spec: - idbfactory_open10.htm - idbtransaction_objectStoreNames.html Bug 1275496 depends on the plan of deprecating the StorageType in IDB: - idbfactory_open9.htm
Whiteboard: [tw-dom] btpp-active → [tw-dom] btpp-fixlater
No longer depends on: 1290853
Note: More failures are identified on wpt-dashboard: (All green in Chrome) http://wpt.fyi/IndexedDB
Depends on: 1120178
Summary of the problems in our implementation according to the remaining wpt failures: 1. Clone before keypath evaluation: (In current implementation, keypath evaluation is done on the passed-in JS object instead of the cloned one. See step 10 for the reason of evaluating on the cloned object in http://w3c.github.io/IndexedDB/#dom-idbobjectstore-put) - clone-before-keypath-eval.html - keypath-exceptions.htm - idb-binary-key-detached.htm 2. Microtasks & promises (Bug 1193394): (In step 4 of https://html.spec.whatwg.org/multipage/webappapis.html#perform-a-microtask-checkpoint, IndexedDB transactions has to be cleaned up at the end of microtask checkpoint. For now, we check this at the meta-stable state which is not part of the standard and is expected to be changed in bug 1193394.) - event-dispatch-active-flag.html - transaction-deactivation-timing.html - upgrade-transaction-deactivation-timing.html - upgrade-transaction-lifecycle-user-aborted.html 3. Index key extraction problem if compounded with |autoIncrement| primary key: (Index key is extracted in the content processes but the auto-incremented primary key is generated later in the parent side. The object can be stored in the IDBObjectStore but is ignored in the IDBIndex: http://searchfox.org/mozilla-central/rev/20e41d4a61a8f5e34c9cf357304b78b3e9bced8a/dom/indexedDB/IDBObjectStore.cpp#1325-1328 ) - idbobjectstore_createIndex15-autoincrement.htm 4. Deprecate StorageType in IDBFactory.open (Bug 1276576) - idbfactory_open9.htm 5. Intermintent failure (mostly on win8-opt build): - fire-error-event-exception.html - idbcursor-update-exception-order.htm - idbdatabase-createObjectStore-exception-order.htm - idbdatabase-deleteObjectStore-exception-order.htm - idbobjectstore-deleteIndex-exception-order.html - idbindex_getAll.html - idbindex_getAllKeys.html - idbobjectstore_getAll.html
Depends on: 1193394
Summary: Fix remaining idb web-platform-test failures → [META] Fix remaining idb web-platform-test failures
Assignee: bevistseng → nobody
Status: ASSIGNED → NEW
Assignee: nobody → jvarga
Priority: -- → P3
Depends on: 1492737
Moving to DWS_NEXT
Assignee: jvarga → nobody
Whiteboard: [tw-dom] btpp-fixlater → [tw-dom] btpp-fixlater DWS_NEXT

:sgiesecke, most dependencies are resolved, maybe we just want to decide, if the remaining few are important enough to keep this bug?

Flags: needinfo?(sgiesecke)

I am not sure what the original purpose of this meta-bug was. The use of "remaining" sounds as if this is meant to fix the failures based on a snapshot state. This has probably largely been addressed, and the meta-bug in this sense could be closed. On the other hand, it might make sense to have a permanent meta-bug that tracks all individual IndexedDB web-platform-test failure bugs, as they come and go.

Flags: needinfo?(sgiesecke)

I'd just like to have clarity about the purpose of this bug. Should this then be:

  1. a collection of all things that are gaps wrt the spec?
  2. a collection of defects of our current implementation?
  3. a mixture of both?

For 1) I would prefer to look at WPT dashboard and avoid manual tracking here, which will tend to be outdated anyway (btw, the bugs to fill such gaps should probably be enhancements, not defects). Once we decide to work on a specific set of gaps, we should then have an enclosing meta-bug with finite scope to track that set. So this bug can probably be closed.
For 2) we have the component, unless we have a lower granularity of commonalities of a smaller sub-set of defects. But I would expect all defects on implemented functionality to have the potential to harm our spec compliance. So this bug can probably be closed or should be made much more specific.
3) I deem neither manageable nor useful. So if we are not able to decide for 1) or 2), this bug can probably be closed, too.

:asuth, can you decide this (and in case adjust)? Thank you!

Flags: needinfo?(bugmail)

:janv, can we ?

Flags: needinfo?(bugmail) → needinfo?(jvarga)

I don't think this should track all defects in our implementation. I think the original idea/goal was to fix all remaining failures in WPT tests.
WPT dashboard is nice, but a meta bug makes it easier to find bugs for specific issues.

Anyway, as Simon said, "Fix remaining idb web-platform-test failures" sounds more like a bug for specific snapshot.
So either we file a new bug or rename it to something more generic, like:
"IndexedDB web-platform-test failures tracking bug"

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