The page changed, but the menu jumped back to the beginning

Check the destination and the context of getting there

Imagine moving along a long horizontal list and selecting a subject near its end. The detail page may be correct, but returning the menu to its first item makes the next comparison require another long movement. Opening the right content and preserving the route through the content are separate responsibilities.

The August 5 conversation specifies that the menu reset was seen on mobile and that desktop had not yet been checked. I keep that scope instead of treating it as the same confirmed defect on every device. The starting point is knowing which environment revealed which behavior.

The selected subject is not its scroll position

Knowing which artist’s page is open does not tell you where the menu had been positioned. A selected subject can be represented by an identifier. The visible menu position depends on layout, width and the person’s movement. Treat them as one value and the subject can be right while the browsing position is wrong.

I first describe in words what a state variable should remember: the current subject, the position the person had reached or an order the person changed. Different purposes can require different moments to save and different methods to restore.

The duplicated desktop and mobile lists changed

The early template record shows a mobile bar and desktop dock each rendering the same artist list. An August 6 edit combined them into one artist-rail navigation element, with CSS changing its direction. Reading the actual edit input and paired file-update response corroborates a code change, beyond a proposal in the design document.

Combining the markup does not automatically make the old state handling correct. Element selectors, drag direction and position-storage rules must follow the change. A simpler screen structure is a reason to inspect the older assumptions in the code around it.

Read the actual direction rather than duplicate a width rule

The historical JavaScript change read the element’s flex-direction to choose a horizontal or vertical axis. If CSS selects direction while JavaScript keeps a separate width threshold, their rules can disagree in an intermediate range. Reading the rendered direction reduces that duplicated decision.

The excerpt below generalizes the storage-key names to explain the choice. It is not a complete restoration module or an instruction to use the original project’s storage keys. Reversed flex directions or a right-to-left layout require conditions beyond this two-direction illustration.

// The historical change chose the axis from the rendered CSS direction.
const axis = getComputedStyle(rail).flexDirection === 'column' ? 'y' : 'x';
// Use a separate stored position for horizontal and vertical navigation.
const key = axis === 'y' ? 'artist-scroll:vertical' : 'artist-scroll:horizontal';
const position = axis === 'y' ? rail.scrollTop : rail.scrollLeft;
// This excerpt illustrates the choice. It is not a complete persistence module.

Horizontal and vertical positions have different meanings

The follow-up edit on August 6 gave horizontal and vertical navigation separate keys. Putting the same numeric offset into another axis does not necessarily identify the same subject. Reducing and widening the screen can involve two distinct browsing contexts.

An integration also needs to check whether a saved value is possible with the current list length. Removed items or reordered records can make an earlier pixel position mean something different. Whether to preserve a position or locate a subject identifier should depend on how often the list changes.

Unavailable storage should not break browsing

A new reusable implementation should handle storage access failure separately. Browser settings or an execution frame can make persistence unavailable. Selecting a subject and reading its page should still work. Remembering a position is an enhancement that should not become a condition for basic navigation.

This is a condition I would add to the next reusable module, rather than a claim that it has been verified across the current site. Moving an example into production requires deciding the storage scope, lifetime, changed-list behavior and failure handling. One persistence method should not be assumed available to every visitor.

Write down the behavior to retest

Checking a single link to a detail page would miss the original problem. I would test selecting a subject from the far end of the list, choosing another one, then changing the width and returning. Read the active-subject indication and the menu’s actual position separately.

What I verified here is the recorded problem, successful historical file changes, the optimization document’s axis-specific explanation and the single-rail structure in current HTML. It is not a new real-phone restoration test. A reusable implementation should exercise those transitions in the actual screen, including a setting where storage is unavailable.

1. After selecting a subject near the end, is the browsing position retained?
2. Can the subject indicator be right while the menu position is wrong?
3. After switching between horizontal and vertical layouts, does each position return appropriately?
4. If length, order or storage access changes, can basic navigation continue?