[Bug]: Page Navigation State Incorrectly Refactored and Non-Functional

[CyanVoxel]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

TagStudio Version

Alpha v9.5.0 Pre-Release 3

Operating System & Version

macOS 15.1.1

Description

Due to a series of ill-informed refactors the page navigation state system has become completely changed post-v9.4 and has broken core navigation functionality. These refactors have also tied frontend-specific state management into the SQL backend, making it difficult to separate and restore pre-v9.5 functionality.

Expected Behavior

The page navigation state should function more or less how it did in v9.1-v9.4. This includes the following core functions:

• Forward/backward navigation between "page states" of search results
• Controlled by the "<" and ">" buttons next to the search bar as well as the back/forward buttons on supported mice
• Page state includes:
  • Page contents
  • Page index
  • Search query of current page
  • Scrollbar position of page
• Navigation between pages should swap out these properties when navigating
• Page navigation states can be informed by but not replaced by the page navigation buttons at the bottom of the screen. These should not replace navigation states like they were refactored to do in 9.5, but rather serve as an entry point to create additional navigation frames for the navigation state system, such as in 9.4 and below.

As an analogy for how the prior and intended behavior worked, the library navigation state system should behave similar to a web browser's navigation system. A stack is created based on the previous pages you've visited, including the web addresses, scrollbar positions, and subpage locations. Navigating through these states should reflect the order in which you've visted them, not the order of how pages are set up on a website itself.

A copy of how the navigation should function is present in the navigation code from v9.1-v9.4. It also remains present in the v9.5 codebase, specifically inside one of the methods that was refactored to break this behavior:

# Ex. User visits | A ->[B]     |
#                 | A    B ->[C]|
#                 | A   [B]<- C |
#                 |[A]<- B    C |  Previous routes still exist
#                 | A ->[D]     |  Stack is cut from [:A] on new route

Regarding some of the newer intertwined state management things introduced in the v9.5 codebase: the page size limit should be purely a frontend attribute. This should not be part of the backend codebase, and should not be stored inside the ts_library.sqlite file. A full list of Entry ID results should be returned by the library backend and correctly sliced and worked with by the frontend.

Steps to Reproduce

N/A - Codebase issue

Logs

N/A