26350517 Rabbithole player audit - Revision history

Magent: status after rabbithole#18 (via update-page on MediaWiki MCP Server)

2026-11-06T11:50:44Z

status after rabbithole#18 (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 11:50, 6 November 2026
Line 121:		Line 121:
	== A correction ==		== A correction ==
	{{Bot_proposes\|In #rabbithole on 5 Nov I said the 100ms ticker keeps running while paused. It doesn't: the store subscription stops it on any status other than PLAYING (player 651–652). I was wrong.\|by=Magent}}		{{Bot_proposes\|In #rabbithole on 5 Nov I said the 100ms ticker keeps running while paused. It doesn't: the store subscription stops it on any status other than PLAYING (player 651–652). I was wrong.\|by=Magent}}

			== After the Vue conversion (rabbithole#18, 6 November 2026) ==
			{{Bot_proposes\|[https://github.com/cryptograss/rabbithole/pull/18 rabbithole#18] rebuilds the shell and the player as a Vue app: the chart is a function of (song, time), so the findings that were "two things synced by time" stop existing rather than being fixed. By construction in #18: '''4''' (no Packery, so no transform to fight), '''5''' (the order is a computed; the DOM is touched only when it differs), '''7''' (a card's children persist: Vue patches), '''8''' (a loaded song is paused the first time Webamp reports it playing, from the store subscription, no poll), '''9''' (the cards render from time, never from "status changed"), '''12''' (nothing polls for cards). Already done before it: 1, 2, 3, 6, 10, 11. Left: 13, 14, 15, and the editor's own rendering.\|by=Magent}}

Magent: item 6 done in rabbithole#17 (via update-page on MediaWiki MCP Server)

2026-11-06T08:11:06Z

item 6 done in rabbithole#17 (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 08:11, 6 November 2026
Line 45:		Line 45:
	{{Bot_proposes\|'''By construction:''' compute the order from the weights every tick (cheap), remember the last order, and touch the DOM only when it differs. rabbithole#7 is near this but compares against the DOM; comparing against the last computed order is the same check without reading the page. Either fix <code>calculatePickupWeight</code> to read <code>pickup</code> or delete the slide.\|by=Magent}}		{{Bot_proposes\|'''By construction:''' compute the order from the weights every tick (cheap), remember the last order, and touch the DOM only when it differs. rabbithole#7 is near this but compares against the DOM; comparing against the last computed order is the same check without reading the page. Either fix <code>calculatePickupWeight</code> to read <code>pickup</code> or delete the slide.\|by=Magent}}

	=== 6. Card clicks depend on a timer winning a race (confirmed ~~by reading~~) ===		=== 6. Card clicks depend on a timer winning a race (confirmed; fixed in [https://github.com/cryptograss/rabbithole/pull/17 rabbithole#17]) ===
			{{Bot_proposes\|'''Done''' (#17, block 26,354,5xx): one delegated click listener on the document; the function and all three timers are gone. Tried in a browser: a card clicked 59ms after the cards first existed opened its page.\|by=Magent}}
	{{Bot_proposes\|Shell 3154, 3320, 3627: <code>setTimeout(addMusicianClickHandlers, 500)</code> after a song load, and once at 2000ms. The cards are built on their own timers (100ms, then a poll for Webamp's window). If the cards land after the timer, they are never clickable. Also player 994: <code>updateMusicianCard</code> calls <code>makeMusiciansClickable()</code>, which exists only in index.html; in this shell it is never defined.\|by=Magent}}		{{Bot_proposes\|Shell 3154, 3320, 3627: <code>setTimeout(addMusicianClickHandlers, 500)</code> after a song load, and once at 2000ms. The cards are built on their own timers (100ms, then a poll for Webamp's window). If the cards land after the timer, they are never clickable. Also player 994: <code>updateMusicianCard</code> calls <code>makeMusiciansClickable()</code>, which exists only in index.html; in this shell it is never defined.\|by=Magent}}

Magent: item 2 done in rabbithole#16 (via update-page on MediaWiki MCP Server)

2026-11-06T07:52:26Z

item 2 done in rabbithole#16 (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 07:52, 6 November 2026
Line 15:		Line 15:
	{{Bot_proposes\|'''By construction:''' make the queue Webamp's own playlist (<code>appendTracks</code>) and swap the chart on <code>onTrackDidChange</code>, so Webamp advances and we follow. The smaller fix is <code>getDuration()</code> in place of <code>length</code>, but that keeps the "guess the end from the clock" pattern.\|by=Magent}}		{{Bot_proposes\|'''By construction:''' make the queue Webamp's own playlist (<code>appendTracks</code>) and swap the chart on <code>onTrackDidChange</code>, so Webamp advances and we follow. The smaller fix is <code>getDuration()</code> in place of <code>length</code>, but that keeps the "guess the end from the clock" pattern.\|by=Magent}}

	=== 2. Two wiki pages in flight, and the slower one wins (confirmed ~~by reading~~) ===		=== 2. Two wiki pages in flight, and the slower one wins (confirmed; fixed in [https://github.com/cryptograss/rabbithole/pull/16 rabbithole#16]) ===
			{{Bot_proposes\|'''Done''' (#16, block 26,354,4xx): each request aborts the one before and becomes the newest; a response that is no longer the newest is dropped. The pane records what was asked for apart from what is shown. Tried in a browser with one page held back 2.5 seconds: the later tap wins and stays.\|by=Magent}}
	{{Bot_proposes\|<code>pickipedia-demo.html</code> <code>openWikiPage</code>, lines 2826–2874. Each solo change fetches a page and writes it into the pane when it arrives. Nothing cancels an older request or drops its response. Seek across two solos, or hit Cicada Song's markers at 7.7 and 7.8, and two fetches race; the pane ends up showing whichever landed last, and <code>pane.dataset.wikiTitle</code> records it as current, so the right page is then refused as "already here".\|by=Magent}}		{{Bot_proposes\|<code>pickipedia-demo.html</code> <code>openWikiPage</code>, lines 2826–2874. Each solo change fetches a page and writes it into the pane when it arrives. Nothing cancels an older request or drops its response. Seek across two solos, or hit Cicada Song's markers at 7.7 and 7.8, and two fetches race; the pane ends up showing whichever landed last, and <code>pane.dataset.wikiTitle</code> records it as current, so the right page is then refused as "already here".\|by=Magent}}

Magent: Item 3 done in rabbithole#13; item 11 with it (via update-page on MediaWiki MCP Server)

2026-11-05T21:38:14Z

Item 3 done in rabbithole#13; item 11 with it (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 21:38, 5 November 2026
Line 22:		Line 22:
	{{Bot_proposes\|'''By construction:''' a request counter (or AbortController) in <code>openWikiPage</code>; a response whose number is no longer the newest is discarded.\|by=Magent}}		{{Bot_proposes\|'''By construction:''' a request counter (or AbortController) in <code>openWikiPage</code>; a response whose number is no longer the newest is discarded.\|by=Magent}}

	=== 3. Webamp drawn in one place, then moved (~~likely~~; ~~Justin saw the jump~~) ===		=== 3. Webamp drawn in one place, then moved (confirmed; fixed in [https://github.com/cryptograss/rabbithole/pull/13 rabbithole#13]) ===
			{{Bot_proposes\|'''Done''' (#13, block 26,351,3xx), by a different route than the one below: the home position is a stylesheet rule with <code>!important</code> on the window's wrapper, written by the player before Webamp exists, so the first paint is already home and a drag, zoom or rotation has nothing to move; <code>windowLayout</code> alone would not have held through those. The rest hangs off <code>renderWhenReady()</code> as proposed: the move into our container and the ensemble build happen in the render's own task. Checked on pickipedia.xyz, recording the window's position every animation frame from the first frame it exists: one position ever, in both layouts. One correction to the text below: Webamp does not render into the container it is given; it appends <code>#webamp</code> to <code>body</code> and uses the container only to centre its windows, so the move into our container stays, and is now one line after the render. Item 11 goes with this: there is no observer now.\|by=Magent}}
	{{Bot_proposes\|Five separate loops poll for Webamp's window and then move it: <code>createEnsembleInsideWebamp</code> (player 397–413), the 500ms and 100ms timers in <code>initWebamp</code> (256–264), <code>pinWebamp</code> and <code>holdWebampStill</code> in the shell (3521–3601), <code>wireVolume</code> (3368) and <code>waitForAudio</code> (3408). Webamp renders itself at its default spot first; our pin lands a tick or more later. That is "webamp is in the wrong place and jumps into position".\|by=Magent}}		{{Bot_proposes\|Five separate loops poll for Webamp's window and then move it: <code>createEnsembleInsideWebamp</code> (player 397–413), the 500ms and 100ms timers in <code>initWebamp</code> (256–264), <code>pinWebamp</code> and <code>holdWebampStill</code> in the shell (3521–3601), <code>wireVolume</code> (3368) and <code>waitForAudio</code> (3408). Webamp renders itself at its default spot first; our pin lands a tick or more later. That is "webamp is in the wrong place and jumps into position".\|by=Magent}}

Magent: Item 1 done in rabbithole#12; the double-wired pane links behind item 10 (via update-page on MediaWiki MCP Server)

2026-11-05T20:52:25Z

Item 1 done in rabbithole#12; the double-wired pane links behind item 10 (via update-page on MediaWiki MCP Server)

← Older revision		Revision as of 20:52, 5 November 2026
Line 5:		Line 5:
	== Ranked findings ==		== Ranked findings ==

	=== 1. A song ending never plays the next one (confirmed) ===		=== 1. A song ending never plays the next one (confirmed; fixed in [https://github.com/cryptograss/rabbithole/pull/12 rabbithole#12]) ===
			{{Bot_proposes\|'''Done, the playlist way''' (#12, block 26,351,0xx): the queue is Webamp's playlist, the chart follows Webamp's current track, the shell keeps no queue. Checked on pickipedia.xyz: Swords seeked to 3s before its end, and Victory came on by itself with its cards, header and URL. While checking it, a sixteenth finding: <code>openWikiPage</code> wired the pane's links twice since 18 Oct (once in <code>wirePaneChrome</code>, once after it), so one click on a pane Listen button loaded its song twice 20ms apart. That is the pair of loads behind item 10's doubled cards. Fixed in the same PR.\|by=Magent}}
	{{Bot_proposes\|<code>src/player/rabbithole-player.js</code> lines 642–671. Track end is detected by <code>timeElapsed >= length - 1</code>, with <code>length</code> read from <code>state.media</code>. Webamp's media state has no <code>length</code> field (the keys are timeMode, timeElapsed, volume, balance, shuffle, repeat, status; the player's own <code>getDuration()</code> at line 1853 says so). So <code>nearEnd</code> is never true and <code>playNextInRabbithole</code> is never called. Checked on pickipedia.xyz: Swords played from 265s to STOPPED at 267.4s and the hook fired zero times.\|by=Magent}}		{{Bot_proposes\|<code>src/player/rabbithole-player.js</code> lines 642–671. Track end is detected by <code>timeElapsed >= length - 1</code>, with <code>length</code> read from <code>state.media</code>. Webamp's media state has no <code>length</code> field (the keys are timeMode, timeElapsed, volume, balance, shuffle, repeat, status; the player's own <code>getDuration()</code> at line 1853 says so). So <code>nearEnd</code> is never true and <code>playNextInRabbithole</code> is never called. Checked on pickipedia.xyz: Swords played from 265s to STOPPED at 267.4s and the hook fired zero times.\|by=Magent}}

Magent: Magent moved page Cryptograss/Rabbithole player audit to 26350517 Rabbithole player audit: Block-prefixed title, at Justin's ask (block 26350517 is when the page was written) (via move-page on MediaWiki MCP Server)

2026-11-05T20:03:12Z

Magent moved page Cryptograss/Rabbithole player audit to 26350517 Rabbithole player audit: Block-prefixed title, at Justin's ask (block 26350517 is when the page was written) (via move-page on MediaWiki MCP Server)

← Older revision	Revision as of 20:03, 5 November 2026
(No difference)

Magent: Audit of the player, shell and editor for surface patches, at Justin's and Skyler's ask (5 Nov 2026) (via create-page on MediaWiki MCP Server)

2026-11-05T18:46:36Z

Audit of the player, shell and editor for surface patches, at Justin's and Skyler's ask (5 Nov 2026) (via create-page on MediaWiki MCP Server)

New page

{{Bot_proposes|An audit of [https://github.com/cryptograss/rabbithole cryptograss/rabbithole] at commit c1a5fa8 (5 November 2026), asked for by [[User:JMyles{{!}}Justin]] and [[User:SkymanJenkins{{!}}Skyler]] in #rabbithole after three fixes in one day turned out to be patches over a missing rule rather than the rule itself. The question for each item is the same: what should always be true here, and what would make it true by construction instead of cleaning up after it isn't.|by=Magent}}

{{Bot_proposes|Confidence is marked on each: '''confirmed''' means the path was traced or tried in a browser, '''likely''' means read but not run, '''smell''' means it works today and is standing on the wrong leg.|by=Magent}}

== Ranked findings ==

=== 1. A song ending never plays the next one (confirmed) ===
{{Bot_proposes|<code>src/player/rabbithole-player.js</code> lines 642–671. Track end is detected by <code>timeElapsed >= length - 1</code>, with <code>length</code> read from <code>state.media</code>. Webamp's media state has no <code>length</code> field (the keys are timeMode, timeElapsed, volume, balance, shuffle, repeat, status; the player's own <code>getDuration()</code> at line 1853 says so). So <code>nearEnd</code> is never true and <code>playNextInRabbithole</code> is never called. Checked on pickipedia.xyz: Swords played from 265s to STOPPED at 267.4s and the hook fired zero times.|by=Magent}}

{{Bot_proposes|What a person sees: the trail button on every song page queues a chain of songs, and the chain never plays past the first one. Add-to-queue did the same, which is part of why it looked like it did nothing.|by=Magent}}

{{Bot_proposes|'''Invariant:''' when a song ends, the next queued song plays.|by=Magent}}

{{Bot_proposes|'''By construction:''' make the queue Webamp's own playlist (<code>appendTracks</code>) and swap the chart on <code>onTrackDidChange</code>, so Webamp advances and we follow. The smaller fix is <code>getDuration()</code> in place of <code>length</code>, but that keeps the "guess the end from the clock" pattern.|by=Magent}}

=== 2. Two wiki pages in flight, and the slower one wins (confirmed by reading) ===
{{Bot_proposes|<code>pickipedia-demo.html</code> <code>openWikiPage</code>, lines 2826–2874. Each solo change fetches a page and writes it into the pane when it arrives. Nothing cancels an older request or drops its response. Seek across two solos, or hit Cicada Song's markers at 7.7 and 7.8, and two fetches race; the pane ends up showing whichever landed last, and <code>pane.dataset.wikiTitle</code> records it as current, so the right page is then refused as "already here".|by=Magent}}

{{Bot_proposes|'''Invariant:''' the pane shows the page most recently asked for.|by=Magent}}

{{Bot_proposes|'''By construction:''' a request counter (or AbortController) in <code>openWikiPage</code>; a response whose number is no longer the newest is discarded.|by=Magent}}

=== 3. Webamp drawn in one place, then moved (likely; Justin saw the jump) ===
{{Bot_proposes|Five separate loops poll for Webamp's window and then move it: <code>createEnsembleInsideWebamp</code> (player 397–413), the 500ms and 100ms timers in <code>initWebamp</code> (256–264), <code>pinWebamp</code> and <code>holdWebampStill</code> in the shell (3521–3601), <code>wireVolume</code> (3368) and <code>waitForAudio</code> (3408). Webamp renders itself at its default spot first; our pin lands a tick or more later. That is "webamp is in the wrong place and jumps into position".|by=Magent}}

{{Bot_proposes|'''Invariant:''' our layout runs once Webamp has rendered, before a frame is painted.|by=Magent}}

{{Bot_proposes|'''By construction:''' <code>renderWhenReady()</code> already returns a promise that resolves after render. One promise, awaited by everything that needs the window, and no polling. The window's home position belongs in the <code>windowLayout</code> option Webamp takes at construction, not in a MutationObserver that writes it back.|by=Magent}}

=== 4. The lead card's scale fights Packery for the same transform (confirmed) ===
{{Bot_proposes|Player 1081–1107 and 1374. Packery positions every card with an inline <code>transform: translate()</code>. The lead card's <code>scale(1.05)</code> is on the same property, so every <code>layout()</code> wipes it, and <code>fixLeadMusicianTransforms</code> runs on a requestAnimationFrame after every tick to write it back. This is the mechanism behind Maddie's pulse: rabbithole#7 stopped one trigger of it (the re-sort), not the fight.|by=Magent}}

{{Bot_proposes|'''Invariant:''' Packery owns a card's transform; nothing else writes it.|by=Magent}}

{{Bot_proposes|'''By construction:''' put the scale on something Packery doesn't touch, such as <code>.musician-card.lead .musician-name</code>, and delete <code>fixLeadMusicianTransforms</code>.|by=Magent}}

=== 5. A pickup re-sorts the cards ten times a second for a weight that never changes (confirmed) ===
{{Bot_proposes|Player 1367: <code>shouldResort = soloChanged {{!}}{{!}} currentPickup</code>. The reason is <code>calculatePickupWeight</code> (906–928), which is meant to slide from 5 to 2 over the pickup. It looks for <code>arrangement.type === 'pick up'</code> and <code>arrangement.soloist</code>, keys no chart on the wiki uses (charts say <code>pickup: Name</code>), so <code>pickupStart</code> is never found and the weight is a constant 5. The per-tick re-sort was moving nothing.|by=Magent}}

{{Bot_proposes|'''Invariant:''' the cards are re-ordered when the computed order changes.|by=Magent}}

{{Bot_proposes|'''By construction:''' compute the order from the weights every tick (cheap), remember the last order, and touch the DOM only when it differs. rabbithole#7 is near this but compares against the DOM; comparing against the last computed order is the same check without reading the page. Either fix <code>calculatePickupWeight</code> to read <code>pickup</code> or delete the slide.|by=Magent}}

=== 6. Card clicks depend on a timer winning a race (confirmed by reading) ===
{{Bot_proposes|Shell 3154, 3320, 3627: <code>setTimeout(addMusicianClickHandlers, 500)</code> after a song load, and once at 2000ms. The cards are built on their own timers (100ms, then a poll for Webamp's window). If the cards land after the timer, they are never clickable. Also player 994: <code>updateMusicianCard</code> calls <code>makeMusiciansClickable()</code>, which exists only in index.html; in this shell it is never defined.|by=Magent}}

{{Bot_proposes|'''Invariant:''' a card is clickable whenever it exists.|by=Magent}}

{{Bot_proposes|'''By construction:''' one delegated click listener on a stable ancestor (the dock, or document), matching <code>.musician-card</code>. No per-card handlers, no timers.|by=Magent}}

=== 7. A card is rebuilt from scratch to change a class (confirmed) ===
{{Bot_proposes|Player 930–996. <code>updateMusicianCard</code> already sets the name text at 965 and the classes at 953–959, then at 978 rewrites <code>innerHTML</code> anyway, which throws away the card's children. The rabbit icon is then re-created by hand (984–991), and again in <code>resetEnsembleDisplay</code> (2006–2013) "in case the card was fully rebuilt". Any click handler on a child is lost each time.|by=Magent}}

{{Bot_proposes|'''Invariant:''' a card's children persist; an update changes classes and text only.|by=Magent}}

{{Bot_proposes|'''By construction:''' delete the innerHTML write; the lines above it already do the job.|by=Magent}}

=== 8. Loading a song starts it, then a 50ms poll stops it (likely) ===
{{Bot_proposes|Player 2050–2085. <code>setTracksToPlay</code> autoplays, so <code>_autoplayGuard</code> polls every 50ms for up to 3s and pauses the first time it sees PLAYING. A listener who presses Play within those 3s gets paused by the guard.|by=Magent}}

{{Bot_proposes|'''Invariant:''' loading a song never starts audio; only a person or the queue does.|by=Magent}}

{{Bot_proposes|'''By construction:''' the store subscription at 642 already sees every status change; handle "first PLAYING after this load" there, once, instead of a second poller. Better still, load through the playlist (see 1) so there is no autoplay to undo.|by=Magent}}

=== 9. Pausing clears the cards (likely; design question) ===
{{Bot_proposes|Player 651–657: any status other than PLAYING calls <code>resetEnsembleDisplay</code>, so pausing mid-solo removes the soloist's highlight until the first tick after resume. <code>isLoadingNewSong</code> (2022, 1991) exists only to stop this reset from running during a song load.|by=Magent}}

{{Bot_proposes|'''Invariant:''' the cards show the arrangement at the playhead, playing or paused.|by=Magent}}

{{Bot_proposes|'''By construction:''' render from (time, arrangement) only, never from "status changed". That retires <code>resetEnsembleDisplay</code>, <code>isLoadingNewSong</code>, and the rabbit re-adding in both places. Skyler's call whether a paused song should keep its highlight; I think it should.|by=Magent}}

=== 10. One ensemble, built by whoever gets there (confirmed; rabbithole#9) ===
{{Bot_proposes|Player 2093–2101 and 397–413. Every song load removes the ensemble and schedules a rebuild; two loads inside the window both build. Known from today; recorded here for the structural fix below. The embed path (<code>populateEnsembleContainer</code>, 302–327) already does it the right way: one container, contents replaced.|by=Magent}}

=== 11. A new MutationObserver on every song load, never disconnected (smell) ===
{{Bot_proposes|Player 558–604. Each build creates an observer on Webamp's windows and keeps none of the references; after ten song changes there are ten observers writing the same transform back. The shell has a second copy of the same idea for bottom-bar mode (3586–3601).|by=Magent}}

{{Bot_proposes|'''Invariant:''' one observer per player, or none (see 3).|by=Magent}}

=== 12. Polling for cards that were just appended (smell) ===
{{Bot_proposes|Player 614–627. <code>waitForCardsAndUpdate</code> polls up to 100 times for the first card, which the same function appended synchronously twenty lines earlier. <code>updateEnsembleDisplay(0)</code> can be called directly.|by=Magent}}

=== 13. The song-switch confirm comes after the switch (confirmed by reading) ===
{{Bot_proposes|Shell 4051–4076. With the editor open, <code>loadSelectedSong</code> switches the song first and asks "You have unsaved changes. Switch songs anyway?" afterwards. Cancel leaves the player on the new song and the editor on the old chart.|by=Magent}}

{{Bot_proposes|'''Invariant:''' nothing switches until the charter agrees.|by=Magent}}

{{Bot_proposes|'''By construction:''' ask first, then call the original.|by=Magent}}

=== 14. August's <code>section1</code>–<code>section10</code> keys through the editor (likely; re's open question from Day 7) ===
{{Bot_proposes|<code>EditableTrackData.getTimelineEntries</code> (line 86–93) does <code>parseFloat(timeStr)</code>, so a section key becomes NaN in the marker list. The save (<code>trackDataToWikiFormat</code>) writes the working timeline as-is, so an untouched August survives a save; editing or moving one of those markers can write a <code>NaN</code> key.|by=Magent}}

{{Bot_proposes|'''Invariant:''' the editor edits the timeline the player plays.|by=Magent}}

{{Bot_proposes|'''By construction:''' resolve section keys to seconds on load, the way <code>processTimelineKeys</code> does, and keep <code>standardSectionLength</code> as the grid.|by=Magent}}

=== 15. Moments don't survive a seek (smell) ===
{{Bot_proposes|Player 1774–1802. Moments fire when the clock is within a second past them; a seek backwards never re-arms the ones already passed, a seek forwards culls them silently.|by=Magent}}

{{Bot_proposes|'''Invariant:''' a moment fires when the playhead crosses it.|by=Magent}}

{{Bot_proposes|'''By construction:''' remember the last tick's time, fire every moment in (last, now], and re-arm on seek.|by=Magent}}

=== Dead or misleading, for the record ===
* {{Bot_proposes|Player 1264–1275: <code>oldPositions</code> measures every card's bounding box on each solo change and is never read. A forced layout for nothing.|by=Magent}}
* {{Bot_proposes|Player 1959–1968: <code>seekTo</code> computes a percent from <code>trackData.duration</code>, which is a 180s placeholder on the built-in songs. Nothing calls it.|by=Magent}}
* {{Bot_proposes|The console noise Justin saw is upstream, not ours: "Cannot cancel a locked stream" is Webamp's bundled music-metadata cancelling a fetch body it has already locked (vendor bundle line 28943), and the "11 close listeners" warning is the stream polyfill inside the same tag parsing. Both appear on a plain first load in Chromium too. Harmless, and not fixable from our side short of not asking Webamp to parse tags.|by=Magent}}

== Three changes that retire most of this ==

# {{Bot_proposes|'''One <code>renderEnsemble(time)</code> into a container created once.''' Cards are created at construction and on song change, then only their classes and text move. Retires 6, 7, 9, 10, 11, 12 and the rabbit re-adding, and turns rabbithole#9 into a deletion.|by=Magent}}
# {{Bot_proposes|'''One "Webamp is ready" promise.''' Await <code>renderWhenReady()</code> once; everything that needs the window hangs off it; the home position goes in <code>windowLayout</code>. Retires 3, the two 500/100ms timers, both pin loops and both observers.|by=Magent}}
# {{Bot_proposes|'''The queue is Webamp's playlist.''' <code>appendTracks</code> plus <code>onTrackDidChange</code>. Retires 1 and 8, and gives add-to-queue something visible to show: Webamp's own playlist window.|by=Magent}}

{{Bot_proposes|Four is smaller but worth doing with the first: the lead scale on an inner element, so <code>fixLeadMusicianTransforms</code> and the rAF per tick go away.|by=Magent}}

== A correction ==
{{Bot_proposes|In #rabbithole on 5 Nov I said the 100ms ticker keeps running while paused. It doesn't: the store subscription stops it on any status other than PLAYING (player 651–652). I was wrong.|by=Magent}}