# Check chapter switching and return in Book Isle: match location with visible controls

Language: en
Canonical: [Check chapter switching and return in Book Isle: match location with visible controls](<https://allluckly.cn/en/guides/nasbook-chapter-switch-return-controls/>)
中文：[中文 HTML](<https://allluckly.cn/guides/nasbook-chapter-switch-return-controls/>)
English: [English HTML](<https://allluckly.cn/en/guides/nasbook-chapter-switch-return-controls/>)
Published: 2026-11-06T00:00:00+08:00
Modified: 2026-11-06T12:13:22+08:00
Author: Bison

Use three sample chapters to check position, contents return and shelf re-entry after 1.1.4 interaction improvements, recording the precise scope of stray controls.

English translation of the [Chinese original](<https://allluckly.cn/guides/nasbook-chapter-switch-return-controls/>), translated on 2026-11-06. Original publication dates, attribution, code and version notes are retained.

Book Isle 1.1.4 mentions improved rapid switching and lingering return icons. Rather than repeating ordinary menu toggles, track a route from chapter A to B, into contents and back, then out to the shelf and in again. Changed content does not establish correct control ownership, and a remaining icon does not prove the chapter failed to change. Record content identity and interface state separately before finding where they diverge. Results belong to the current device; source inspection is not a claim of device testing.

## Choose three consecutive chapters and anchors

Choose a downloaded TXT or EPUB with a clear contents list and three consecutive middle chapters, provisionally A, B and C. Retain actual headings and one distinctive phrase per chapter. Avoid first/last chapter boundaries when testing previous/next, since no further chapter may exist there. Bookmark stable content in A or record an external anchor so the starting point remains recoverable. Confirm installed version, system and orientation, without changing device, font and page-turn mode during the first pass. Similar headings require an additional paragraph landmark rather than judging success from the top title alone.

## Verify one ordinary adjacent-chapter transition

Show the current menu and use its available next-chapter control to reach B. Wait for stable content, check heading and phrase, then return to A with previous chapter. If the format lacks matching controls, choose adjacent chapters through contents and label that route instead of assuming universal controls. Issue one action at a time; page swipes, progress dragging and next chapter are different operations. A move to A’s next page is page movement, so inspect the actual target. Establish a normal baseline before comparing a more compact sequence rather than repeatedly accelerating to prove the update effective.

## Retain results during a more compact sequence

After a normal baseline, try A to B and B to C, issuing the second action after the first has visibly responded rather than hammering during animation. Record whether the button is available, when content changes and the final chapter without requiring millisecond timing. Temporary transition unavailability differs from persistent failure after settling; record them separately. If the final chapter is unexpected, check for an extra action rather than immediately attributing a random jump to the app. Return to the anchor and recheck once after stopping rather than sustained stress tapping. This is a describable small workflow, not a performance benchmark or device-limit test.

## Distinguish contents return from leaving the reader

Open contents from B without choosing another chapter, use its available return/close control and confirm you remain near B. Then reopen contents, explicitly choose C and verify that this choice explains the changed passage. Returning from a reader to the shelf differs from leaving a subpanel for text even when icons resemble left arrows. If one return actually exits the reader, record the starting and destination pages and reopen to observe instead of repeatedly backing to the home screen and reporting too much return. Paths may use different bar styles; visible controls must belong to the current layer rather than inexplicably surviving from a departed page.

## Record visual remnants separately from behaviour

If duplicate return icons or an isolated bar remain after text returns, record position, obstruction, menu visibility and chapter first. Do not activate uncertain icons and change the recorded route. Make a normal menu toggle in clear central content and compare whether the remnant follows the whole menu, using a baseline screenshot. If a visual artefact cannot yet be distinguished from an extra responsive button, mark unconfirmed rather than inventing its function. Describe system indicators, reader return and shelf navigation separately instead of calling every upper-edge symbol a remnant. Anonymise private text while retaining necessary interface boundaries.

## Exit to the shelf and reopen the same book

Use the reader’s clear return action, verify the shelf is actually shown, then reopen the same record. Compare title, A/B/C anchors and recent location rather than choosing another volume with a similar cover. Progress may update through the actual reading actions; content anchors are more reliable than percentages alone. Show and hide the menu once after re-entry and inspect whether old-page controls follow. Record frequency and preceding steps for an intermittent occurrence rather than saying always. Preserve a persistent result too, without deleting or reinstalling away its reproduction path. This checks navigation and state restoration, not network synchronisation or device migration.

## Isolate the trigger with a single-route comparison

Split an anomalous long sequence into one adjacent switch, one contents-return trip and one shelf re-entry, each from the same stable chapter. Retain full order if only the combination triggers it; report the shortest route if one action suffices. Keep a separate comparison record for another known-good local book. Do not simultaneously change theme, rotate and start read-aloud, then blame chapter switching, which would add unseparated conditions. If evidence cannot locate a cause, report the visible phenomenon and unknown scope rather than claiming an internal diagnosis. A user report needs actual controls and outcomes, not implementation terminology.

## Save the route record and resume reading

Finish in the chapter you want to continue, with identifiable text, menu and return destination, retaining a bookmark or phrase. Save version, book format, starting point, action order, content result, control phenomenon and occurrence count in a short record. A non-reproduction means normal under these conditions, not disappearance across every platform. Reuse the same three-chapter sample after updates rather than substituting an impression of paging speed for state records. Before saving, exclude another volume’s information from notes and screenshots. A scoped route record is easier to revisit or explain than many unordered screenshots.

## Related tutorials and sources

[Book Isle reader menu visibility: distinguish content taps, menu state and button actions](<https://allluckly.cn/en/guides/nasbook-reader-menu-visibility-check/>); [Book Isle after an interruption: recover context before continuing](<https://allluckly.cn/en/guides/nasbook-interrupted-reading-context/>).

Sources checked on 6 November 2026: the [official Book Isle App Store listing](<https://apps.apple.com/cn/app/id6766198898>) and [Apple Lookup](<https://itunes.apple.com/lookup?id=6766198898&country=cn>) show version 1.1.4, requiring iOS / iPadOS 15.6 or later. This workflow uses local reading, search, bookmarks and notes for manual checking. Readers record the samples and conclusions; automatic file repair or identical interfaces across all readers is not assumed. Confirm available controls against the installed version and file type. The exercise does not claim step-by-step device testing in this batch.