yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Make the provider reorder control honest #255

New Issue
Closed
opened 2026-08-25 18:15:15 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-25 18:15:15 +01:00
Owner
Copy Link
Copy Source

Two problems in the same control, both pre-existing from #204 and both found
while implementing #251, which deliberately left them alone.

1. An invisible control that still takes focus. web/src/style.css has:

.provider-move:disabled { visibility: hidden }

At each end of the provider list the reorder button is hidden this way. But
visibility: hidden removes it from the accessibility tree only in some
engines and, more to the point, the button is still in the DOM and — depending
on how the disabled state is applied — can still be announced or tabbed to. A
keyboard or screen-reader user meets a control that appears to be nothing.

disabled already blocks the click, so the hiding is decoration, not
mechanism. Either leave it visibly disabled (the shared .control:disabled
colour already says so honestly), or drop opacity while keeping it in place so
the row does not reflow as the operator reorders.

2. Reorder buttons are found by position. refreshProviderEdges in
web/src/settings.ts locates them with button:nth-of-type(1) and
nth-of-type(2). The day a third button joins a provider row — a delete, a
test-connection — the edge enable/disable logic silently targets the wrong
control. Nothing errors; it just stops being right.

Give them a data- attribute or a class and select on that.

Neither is urgent. Both are the kind of thing that is cheap now and confusing
later.

Found while implementing #251.

Depends on: #204

Two problems in the same control, both pre-existing from #204 and both found while implementing #251, which deliberately left them alone. **1. An invisible control that still takes focus.** `web/src/style.css` has: ```css .provider-move:disabled { visibility: hidden } ``` At each end of the provider list the reorder button is hidden this way. But `visibility: hidden` removes it from the accessibility tree only in some engines and, more to the point, the button is still in the DOM and — depending on how the disabled state is applied — can still be announced or tabbed to. A keyboard or screen-reader user meets a control that appears to be nothing. `disabled` already blocks the click, so the hiding is decoration, not mechanism. Either leave it visibly disabled (the shared `.control:disabled` colour already says so honestly), or drop opacity while keeping it in place so the row does not reflow as the operator reorders. **2. Reorder buttons are found by position.** `refreshProviderEdges` in `web/src/settings.ts` locates them with `button:nth-of-type(1)` and `nth-of-type(2)`. The day a third button joins a provider row — a delete, a test-connection — the edge enable/disable logic silently targets the wrong control. Nothing errors; it just stops being right. Give them a `data-` attribute or a class and select on that. Neither is urgent. Both are the kind of thing that is cheap now and confusing later. Found while implementing #251. Depends on: #204
naps62-yolo added this to the Subtitles milestone 2026-08-25 18:15:15 +01:00
naps62-yolo added the difficulty/easyphase/9-subtitlesarea/webtype/bug labels 2026-08-25 18:15:15 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/web difficulty/easy phase/9-subtitles type/bug
Milestone
No items
No Milestone Subtitles
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#255
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?