Indexed DB: Use correct range upper limit for index iteration #24386
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
approved these changes
Jun 29, 2020
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2274085
branch
from
7aef769
to
8d3e4bc
Compare
When iterating a forwards, comparisons are done between each record found and the range's bound to know when to stop. There's an special case for reverse cursors where a starting key is needed at the upper end of the range, so the uppermost key in the range is looked up as the starting cursor position. The code to do this for indexes was not guarded by a check for the cursor direction, though. This was harmless for most forward iterations as the uppermost actual key would match the upper bound anyway. But when iterating a cursor over a range in an index, records can change their index keys and thus appear again in the iteration. This would lead to the cursor stopping at what was no longer the actual uppermost key in the range, missing records in the iteration. Add the missing check, and a WPT to verify this behavior. (The code dates back to before 2013, so this is not a recent regression.) Bug: 1091731 Change-Id: I23336ba03d31607607d496fc7e18c28bcf644cf0 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2274085 Commit-Queue: Joshua Bell <jsbell@chromium.org> Reviewed-by: enne <enne@chromium.org> Cr-Commit-Position: refs/heads/master@{#783792}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-2274085
branch
from
8d3e4bc
to
512a3db
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When iterating a forwards, comparisons are done between each record
found and the range's bound to know when to stop. There's an special
case for reverse cursors where a starting key is needed at the upper
end of the range, so the uppermost key in the range is looked up as
the starting cursor position.
The code to do this for indexes was not guarded by a check for the
cursor direction, though. This was harmless for most forward
iterations as the uppermost actual key would match the upper bound
anyway. But when iterating a cursor over a range in an index, records
can change their index keys and thus appear again in the iteration.
This would lead to the cursor stopping at what was no longer the
actual uppermost key in the range, missing records in the iteration.
Add the missing check, and a WPT to verify this behavior.
(The code dates back to before 2013, so this is not a recent regression.)
Bug: 1091731
Change-Id: I23336ba03d31607607d496fc7e18c28bcf644cf0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2274085
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#783792}