(Regarding https://w3c.github.io/IndexedDB/#create-a-request-to-retrieve-multiple-items)
To parse the input and creating a key range out of it, the algorithm has these two steps:
-
If running is a potentially valid key range with queryOrOptions is true, then:
-
Else:
But consider this case in LayoutTests/imported/w3c/web-platform-tests/IndexedDB/idbindex_getAll.any.js:
index_get_all_values_test(
/*storeName=*/ 'out-of-line', /*options=*/ {count: 10}, 'maxCount=10');
This calls index.getAll(undefined, 10), Here, queryOrOptions is undefined/null and the count is present. The test expects that we use an unbounded keyRange and return 10 items.
Run the algorithm with this input:
In step 8, is a potentially valid key range with queryOrOptions will return false. So we'll proceed to the "else" case where we attempt to access fields of queryOrOptions. They will all be undefined/null. So we lose the count and this test should fail. We shouldn't be accessing the fields of an undefined/null value. This is an ill-defined scenario.
Assuming that test is correct (please clarify if it's not), the spec should account for queryOrOptions being absent since the IDL says that's allowed: optional any queryOrOptions.
Given the expectations of the test, perhaps the spec should have a step before Step 8 that says:
- If
queryOrOptions is undefined or null:
- Set range to be an unbounded key range .
- Set direction to "next".
- Else Step 8
- Else Step 9
Another reason (besides the test's expectations) to use an unbounded key range if queryOrOptions is undefined or null is that this is what https://w3c.github.io/IndexedDB/#convert-a-value-to-a-key-range does.
What do we think? Thanks for taking a look!
(Regarding https://w3c.github.io/IndexedDB/#create-a-request-to-retrieve-multiple-items)
To parse the input and creating a key range out of it, the algorithm has these two steps:
If running is a potentially valid key range with queryOrOptions is true, then:
Else:
But consider this case in LayoutTests/imported/w3c/web-platform-tests/IndexedDB/idbindex_getAll.any.js:
This calls
index.getAll(undefined, 10), Here,queryOrOptionsis undefined/null and thecountis present. The test expects that we use an unbounded keyRange and return 10 items.Run the algorithm with this input:
In step 8, is a potentially valid key range with queryOrOptions will return false. So we'll proceed to the "else" case where we attempt to access fields of
queryOrOptions. They will all be undefined/null. So we lose the count and this test should fail. We shouldn't be accessing the fields of an undefined/null value. This is an ill-defined scenario.Assuming that test is correct (please clarify if it's not), the spec should account for
queryOrOptionsbeing absent since the IDL says that's allowed:optional any queryOrOptions.Given the expectations of the test, perhaps the spec should have a step before Step 8 that says:
queryOrOptionsis undefined or null:- Set
rangeto be an unbounded key range .- Set direction to "next".
Another reason (besides the test's expectations) to use an unbounded key range if
queryOrOptionsis undefined or null is that this is what https://w3c.github.io/IndexedDB/#convert-a-value-to-a-key-range does.What do we think? Thanks for taking a look!