Repository navigation
A Contents jump he leaves before it loads keeps the chapter he chose (#259) - #325
Open
arimendelow wants to merge 28 commits into
Open
arimendelow wants to merge 28 commits into
arimendelow wants to merge 28 commits into
Conversation
The jump's target is owed as he leaves: the chapter's place in its file once read, otherwise the entry's placed total progression. Closed, it is written; gone inactive, it is written and the jump goes on to write where it lands. An entry never placed inside its file keeps the place before. Fixes #259
A contents jump left on its way that lands before or during the leave's write keeps its landed page: its landing is his move (never already kept by the leave), and a leave write that finishes after it writes the landing again. Entries carry whether placeFragments placed them, so one placed at its file's start counts. The hand-over count (#254) is now taken before the page is sent to the chapter, so an unveiled touch during that send counts as his taking over. Tests: a landing during the leave's write, the leave's place read as it is written, Chapter XL matched exactly, the file's leave helper.
…here A test-only hook after the leave's write lets the unit case release the chapter and wait for the landing inside the leave, so that order is reached every run, not only made likely.
…ow anywhere in the label
…age layout-only CI run 43218442143 logged the chapter's target and the leave's write, yet the reopen found no place: the open's rotation reflow had ended with the page marked layout-only, and locationDidChange dropped the write without a word. The unit test now ends a reflow before the jump. The UI test judges the reopen by place, and past the opening still requires words.
Its write passes hisMove so the leave's write can't count it as already kept, but hisMove also skipped the claim, so Readium's boundary a beat after the landing could be written over his words. The landing now claims its move as a report would, and the gate is spent once it has written. A unit case sends that boundary report during the landing's write.
…ps the usual contest
…ding's holds one
…ort can come inside the write
…ad of the page CI run 43222781890 logged the target and the leave's write, and nothing was saved: that write reads the page, which the chapter still loading held past the app's suspension. The target is now kept in the caller's own turn, as the page a stalled restore left is (#133); the ordinary write follows, and the landing writes over both.
…t is written at once A leave write held by the loading chapter could finish after the landing and stand over it. Tests: the leave with the page answering no reads, and the leave's write held past the landing.
…and spends the leave's gate on every exit The stub held only one read, so a second leave's read on the old code could write the target and pass. The race case now checks the held read is the leave's own.
…oesn't wait on the jump it holds CI runs 43227607428 and 43227616750 hung in it until the job's limit.
…eports it The stub never ended it, so the landing's write was dropped with the reflow's reports in every inactive case (CI run 43233772897).
…res the target to differ from it
…e past the middle
…ot by a page read On b281c2d the armed read hold went to the landing instead, and the case hung until the job's limit (CI run 43239548842).
…t by 0.6 The stub lands on the page holding the chapter's 0.6, at 0.58 (CI run 43245326863), so the exact 0.6 check was a false red.
…d on, so a reopen with no move can be judged
…, whose stalled bare reopen it also hits
…place writer; the fragment promises only the place kept
arimendelow
enabled auto-merge (squash)
November 12, 2026 19:52
# Conflicts: # Gatefold/Reader/ReaderModel.swift
This branch has not been deployed
This file contains hidden or 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
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.
A Contents jump he leaves before its chapter loads now keeps the chapter he chose as his place. Before, it went back to the page he had left.
Fixes #259
Refs #296
Red and green, in the unit tests (PlaceInvariantTests):
saved(f) == landedJSON.The Contents-leave UI test moved to #310. Its reopen hits #310: run 43291536110 was forced up after 13 s on the chapter file's first page, and the restore never settled. The earlier reds at NavigationPlaceUITests.swift:330 were the test's probe, not the app.
reader.savedPlacestayed empty on a reopen with no move, so :330 could never pass. #310 takes the test with that probe fixed.Not covered here: a reflow that ends after the jump has started.
After #195: every veil now lets go at its limit, so on a chapter load slower than that limit, a touch of his after the veil lets go counts as his move, even a tap that only brings up the controls. The jump then gives way to him (#254's rule), and leaving keeps the page he is on, not the target. This is intended: a jump with no veil over it gives way to him.