RomM version
4.8.1 (also reproducible on master, as of 05/01/2026)
Describe the bug
In Web, when using the UI in places like "Collections", and "Search", when one applies filters from the drawer, the URL dynamically changes to reflect what the user is filtering for via query parameters. This includes platform parameters. However, refreshing the page, or manually entering a URL with them, behaves differently. Most filters apply as expected, but the platform-related parameters (AFAIK, "platform=x" and "platforms=x,y,z" don't apply, and moreover get stripped from the URL.
This can be inconvenient when trying to refresh for testing / getting fresh states, creating bookmarks, sharing, and others, though can be partially worked around via smart collections, but is also inconsistent with how the rest of the parameters work, and general GET query semantics, and can lead to confusion.
To Reproduce
Steps to reproduce the behavior:
- Go to Search on the web UI, and filter by platform, and optionally other attributes. Things should work as expected, and URL will be something like
http://localhost:3000/search?search=mario®ions=USA®ionsLogic=any&platforms=33
- Refresh and / or just directly input the above the above URL on some browser
- Search results will reflect most filters being applied, except for the platform one. Moreover, the platform parameter will be stripped from the URL, resulting in something like
http://localhost:3000/search?search=mario®ions=USA®ionsLogic=any. The same behavior occurs on "Collections", e.g. http://localhost:3000/collection/6?search=mario&platforms=27, and is mostly irrelevant on "Platforms", where you're always filtering by one platform anyway.
Expected behavior
All filters implied by the URL parameters should apply, and searches should be idempotent, and lead to the same.
Screenshots
N/A
Server (please complete the following information):
- OS: [Debian]
- Version [13]
Client (please complete the following information):
- Device: [Any on Web]
- OS: [Any]
- Browser [Firefox]
- Version [151]
(Also tested on Chromium, same thing reproduces).
Additional context
The core of the issue seems to be here:
|
if (urlPlatforms !== undefined) { |
|
const platformIds = (urlPlatforms as string) |
|
.split(",") |
|
.filter((p) => p.trim()) |
|
.map(Number); |
|
const platforms = platformIds |
|
.map((id) => platformsStore.get(id)) |
|
.filter((p): p is NonNullable<typeof p> => p !== undefined); |
|
if (platforms.length > 0) { |
|
galleryFilterStore.setSelectedFilterPlatforms(platforms); |
|
} |
|
} else if (urlPlatform !== undefined) { |
URL parameters are all parsed together, but unlike most other filters, which are strings (as opposed to proper object), currently, platforms need be loaded from the API, so the IDs in the parameters can be matched to a proper platform object, which is necessary for using platform-related attributes (like names) in other parts of the code. This particular issues arises because by the time the code above executes, platforms have not yet been loaded from the API - so galleryFilterStore won't match the query parameters to anything, and they'll be ignored.
There is some nuance to this, because fetching platforms at this point would likely result in a race condition with other parts of the code that are loading platforms. That will either be inefficient, or lead to this call being ignored, as the async code currently taking place detects there is one in place and returns an empty Array.
I have worked on a PR to implement a working solution to this, which I hope to publish in a PR over the next few days. I hope to also publish some other PR's related to URL parameters and filtering which might benefit from this.
RomM version
4.8.1 (also reproducible on master, as of 05/01/2026)
Describe the bug
In Web, when using the UI in places like "Collections", and "Search", when one applies filters from the drawer, the URL dynamically changes to reflect what the user is filtering for via query parameters. This includes platform parameters. However, refreshing the page, or manually entering a URL with them, behaves differently. Most filters apply as expected, but the platform-related parameters (AFAIK, "platform=x" and "platforms=x,y,z" don't apply, and moreover get stripped from the URL.
This can be inconvenient when trying to refresh for testing / getting fresh states, creating bookmarks, sharing, and others, though can be partially worked around via smart collections, but is also inconsistent with how the rest of the parameters work, and general GET query semantics, and can lead to confusion.
To Reproduce
Steps to reproduce the behavior:
http://localhost:3000/search?search=mario®ions=USA®ionsLogic=any&platforms=33http://localhost:3000/search?search=mario®ions=USA®ionsLogic=any. The same behavior occurs on "Collections", e.g.http://localhost:3000/collection/6?search=mario&platforms=27, and is mostly irrelevant on "Platforms", where you're always filtering by one platform anyway.Expected behavior
All filters implied by the URL parameters should apply, and searches should be idempotent, and lead to the same.
Screenshots
N/A
Server (please complete the following information):
Client (please complete the following information):
(Also tested on Chromium, same thing reproduces).
Additional context
The core of the issue seems to be here:
romm/frontend/src/components/Gallery/AppBar/common/FilterDrawer/Base.vue
Lines 366 to 377 in 2b0df19
URL parameters are all parsed together, but unlike most other filters, which are strings (as opposed to proper object), currently, platforms need be loaded from the API, so the IDs in the parameters can be matched to a proper platform object, which is necessary for using platform-related attributes (like names) in other parts of the code. This particular issues arises because by the time the code above executes, platforms have not yet been loaded from the API - so
galleryFilterStorewon't match the query parameters to anything, and they'll be ignored.There is some nuance to this, because fetching platforms at this point would likely result in a race condition with other parts of the code that are loading platforms. That will either be inefficient, or lead to this call being ignored, as the
asynccode currently taking place detects there is one in place and returns an empty Array.I have worked on a PR to implement a working solution to this, which I hope to publish in a PR over the next few days. I hope to also publish some other PR's related to URL parameters and filtering which might benefit from this.