peter
f76a2afbf1
Items 2, 4, 5 and 7 of the bug hunt, one round. They are independent, but they are all the same kind of thing: an action that exists somewhere else in the app and is missing where you actually want it. **5 — the channel name in the YT player is a link again.** It was a `<button>`, so middle-click and Ctrl/Cmd-click did nothing on a thing that looks exactly like a link (the YouTube icon beside it IS an anchor and opens a tab). It is now a real `<a>` whose href is the same `?chan=<id>` URL `openChannel` pushes, with a plain left click still taking the in-app path — that path does more than navigate, since the player must close and reclaim its own Back-to-close history entry first. The "is this click ours or the browser's" test is now ONE predicate (`isPlainLeftClick`), which VideoCard's card link also uses, so a second such link cannot forget the middle-click arm. **2 — "Remove" from inside the player.** The parent owns the removal (the SAME `removeItem` the row menu and the inline ✕ use: one confirm, one optimistic update, one undo-stack rebase), and the player owns what happens next, because it is the only side that knows which item is playing — its launch queue is frozen at mount. It drops the item, plays what followed, and closes when the list runs out. That forced a real fix in Playlists: the player's mount was derived from `shown` every render, so anything that dropped the launch row yanked the player off the screen mid-playback. That was a latent edge (change the view and it happens) and the normal case for this feature. The parent now snapshots what it launched with, and only onClose takes the player down. **4 — "Move to <the last list you moved to>".** The submenu is two levels deep and moving a run of videos into the same list is the shape this gets used in. The remembered id is a per-account pref; the row is derived from `moveTargets`, which already excludes the list you are looking at, so it cannot offer a move to where the video already is. Remembered only on a SUCCESSFUL move — a shortcut to a move that failed is a shortcut to failing again. Absent, not disabled, when there is nothing to repeat: there is nothing to explain. **7 — the live-YouTube results can be sorted.** Client-side, over the page already loaded. Not a new `order=` param, and this is the decision worth recording: the owner's case is "even one page of results", i.e. reorder what is on screen; a re-query would REPLACE the results, which is not what "sort these" means; and the zero-quota scrape source has no order parameter at all, so a server-side control would silently do nothing (or quietly cost 100 quota units) depending on which source served the page. Only keys a search hit carries are offered — `subscribers`/`priority` describe a subscription, which a search hit is not, and `shuffle` on a ranked list is noise. Its own pref, so sorting a search page never re-sorts the library behind it. Verified in the browser on localdev against the real account: the channel name renders as `<a href="…&chan=…">` and a ctrl-click / middle-click is left to the browser while a plain click still opens the channel in-app; removing from the player stepped 1/3 → 1/2 onto the next video and closed on the last one; the row menu grew "Move to “…”" only after a move and only on a list that is not the target; and the results sort reordered by views 41.7M → 29.8M → 24.2M → 15.8M. (The pane's own ctrl-click arrives without the modifier — a harness limit, so the modifier cases were driven as real MouseEvents.) Scratch playlists and the touched prefs were cleaned up afterwards. 22 vitest, mutation-checked against 14 mutations (no href at all · href without the rest of the query · every click hijacked in-app · the middle-click arm dropped from the predicate · plain click no longer in-app · always jumping to the top of the list · the removed item left in the queue · no clamp when the last item goes · an empty queue not reported as "nothing left" · sort-then-reverse flipping ties · unknown values first · titles compared numerically · shuffle offered on search results · direction ignored) — each red on exactly the test that names it. Item 4 has no test of its own: its rule is enforced by construction, not by a check.
54 lines
2.2 KiB
TypeScript
54 lines
2.2 KiB
TypeScript
import { describe, it, expect } from "vitest";
|
|
import { afterRemoval } from "./playerQueue";
|
|
import type { Video } from "./api";
|
|
|
|
// "Delete" from inside the player (the owner asked for it: today the only way to drop a video from a
|
|
// playlist is the Playlists module). The removal itself is the parent's — this is the half the player
|
|
// owns, because only the player knows which item is playing: its launch queue is frozen at mount, so
|
|
// nothing outside can take the item out for it.
|
|
const v = (id: string): Video => ({ id }) as Video;
|
|
const ids = (q: Video[]) => q.map((x) => x.id);
|
|
|
|
describe("afterRemoval", () => {
|
|
it("plays the item that followed the one you removed", () => {
|
|
const q = [v("a"), v("b"), v("c")];
|
|
const next = afterRemoval(q, 1, "b");
|
|
expect(next).not.toBeNull();
|
|
expect(next!.playingId).toBe("c");
|
|
expect(ids(next!.queue)).toEqual(["a", "c"]);
|
|
});
|
|
|
|
it("steps back to the new last item when the last one goes", () => {
|
|
// There is no "next" after the end — falling off it would leave the player on nothing.
|
|
const q = [v("a"), v("b"), v("c")];
|
|
const next = afterRemoval(q, 2, "c");
|
|
expect(next!.playingId).toBe("b");
|
|
expect(ids(next!.queue)).toEqual(["a", "b"]);
|
|
});
|
|
|
|
it("drops the removed item from the queue, so prev/next cannot step back onto it", () => {
|
|
const q = [v("a"), v("b"), v("c")];
|
|
expect(ids(afterRemoval(q, 0, "a")!.queue)).not.toContain("a");
|
|
});
|
|
|
|
it("says nothing is left when the list runs out (the player closes)", () => {
|
|
expect(afterRemoval([v("only")], 0, "only")).toBeNull();
|
|
expect(afterRemoval([], 0, "gone")).toBeNull();
|
|
expect(afterRemoval(undefined, 0, "gone")).toBeNull();
|
|
});
|
|
|
|
it("survives an index that no longer points inside the shortened queue", () => {
|
|
// The index comes from the frozen queue; nothing guarantees it is still in range afterwards.
|
|
const q = [v("a"), v("b")];
|
|
const next = afterRemoval(q, 5, "b");
|
|
expect(next!.playingId).toBe("a");
|
|
});
|
|
|
|
it("is a no-op-shaped answer when the id is not in the queue at all", () => {
|
|
const q = [v("a"), v("b")];
|
|
const next = afterRemoval(q, 0, "not-here");
|
|
expect(ids(next!.queue)).toEqual(["a", "b"]);
|
|
expect(next!.playingId).toBe("a");
|
|
});
|
|
});
|