Description
When the end of a PDF is reached in the new loader (bitECS), switching to the next page loops it back to the beginning, while in the old loader (A-Frame) it does nothing and stays at the end. The same looping behavior occurs with the previous page button when at the beginning of the document.
To Reproduce
Steps to reproduce the behavior:
Open a Hubs room with the new loader enabled.
Drop in a PDF.
Cycle through the pages until you reach the end.
Click the next page button one more time and see that it loops back to the beginning.
Expected behavior
The A-Frame loader stops at the end of the PDF and doesn't loop back to the beginning. The bitECS loader should do the same.
Hardware
Device: Laptop
OS: Linux
Browser: Chromium
Additional context
Having discussed this at a development meeting, looping back to the opposite end of the PDF isn't necessarily a bad thing, however it appears to be an unintentional change. Support for looping around to the other end of a PDF may be implemented in the PDF component of the Blender add-on/Spoke to allow the explicit use of this behavior.
Description When the end of a PDF is reached in the new loader (bitECS), switching to the next page loops it back to the beginning, while in the old loader (A-Frame) it does nothing and stays at the end. The same looping behavior occurs with the previous page button when at the beginning of the document.
To Reproduce Steps to reproduce the behavior:
Expected behavior The A-Frame loader stops at the end of the PDF and doesn't loop back to the beginning. The bitECS loader should do the same.
Hardware
Additional context Having discussed this at a development meeting, looping back to the opposite end of the PDF isn't necessarily a bad thing, however it appears to be an unintentional change. Support for looping around to the other end of a PDF may be implemented in the PDF component of the Blender add-on/Spoke to allow the explicit use of this behavior.