Two things were conflated. Reloading the list bumped the generation, and
the import treated that as its login having changed — so a routine
refresh aborted a healthy import and told the user their account had
moved. The listing and the login are separate facts: the login that
listed a row is now carried with it, and the generation decides only
what may be marked imported.
The local playlist is also created before it is read, so anything
stopping the read left it behind empty — a login that moved, but equally
a server that did not answer. The import reports whether it completed,
and an incomplete one takes its empty playlist with it. A playlist that
genuinely had nothing to add keeps it.
The last write is followed by a pause, and an empty remote playlist
never reaches a check at all, so the list could be replaced before the
import reported itself finished. Marking it then attached to whichever
row carries that ID now — on another account, a different playlist
shown as already imported.
Clearing the in-progress state stays unconditional: it describes a row
that is no longer there either way.
Capturing it where the import starts was too late for the one case that
needed it. The merge dialog waits on the user; a reload landing while it
is open replaces the list and re-bases the credential, and confirming
afterwards captured the new generation and passed every check — reading
a row that no longer exists under whoever now owns the account.
The listing is recorded where the row is chosen and carried to the
import, so what answers the dialog is the list that asked the question.
The credential baseline was recorded before the list it describes had
arrived, and cleared alongside it. A reload landing while an import was
still running therefore moved the baseline under it: the import passed
its check against a login that had never listed the row it was working
on, and a batch resumed through rows that no longer existed. A failed
reload left the same wrong baseline standing with the old rows still on
screen.
The baseline is now recorded where the rows are, so a failed load leaves
the previous login in place, and a generation names the listing itself —
captured by the batch and by each import, so replacing the list stops
what was chosen from it rather than re-authorising it.
Checking that some credential exists was the wrong question. Everything
on screen was read with one particular login, and a replacement is a
different person's account on the same server — its playlist IDs mean
something else entirely, so importing "the same" playlist under it
fetches whatever that ID happens to name there. The credential the list
was loaded with is now recorded, and every import is checked against it
rather than against whatever is current.
The two checks around creating the local playlist are a suspension
apart, so the login can still go between them. Nothing has been read at
that point, and an empty playlist named after somebody else's is not
worth keeping.
The merge dialog waits on the user, so the login can go between choosing
a playlist and confirming it. Reading it then returned quietly: the row
stayed in its importing state with nothing running, and a batch went on
to the next playlist. It now reports what happened and clears up after
itself, like every other way an import stops.
The merge that dialog starts is detached from it, so dismissing the
dialog was never the merge finishing — a batch resumed alongside it and
could begin the next playlist under whoever replaced the login. It is
waited for now, which is what makes the batch sequential.
Importing every playlist creates each local one before reading it, so
aborting a single import left the loop free to carry on: an empty
playlist for each remaining title, or the rest read under whoever
replaced the login. The batch now ends where the first abort happened,
and nothing is created for a login already known to be gone.
Videos are read with one account's credential and written one at a time
into a local playlist, which is not account-scoped: it belongs to
whoever uses the device and syncs to iCloud. The sheet can be dismissed
and somebody else signed in on the same server while the import is still
running — nothing cancels it — and the rest of one person's private
playlist would land in the other's library.
The credential is checked before every write rather than only at the
start. What was already written stays: it was imported under the login
that asked for it.
Five findings against the accounts layer, all real.
A fresh login created a random-UUID account and then flipped
usesAccountLogin, which posts instancesDidChange and re-ran legacy
reconciliation immediately. That guard only looked for an account whose ID
equalled the instance ID, so it synthesized a second, credential-less
account alongside the real one. Signing in now marks the instance migrated,
and reconciliation treats any account on an instance as evidence its login
is already represented.
save() set hasStoredContext, so the save inside reconcileLegacyAccounts
marked the still-default .local context as explicitly chosen and the
legacy-context migration that ran immediately after did nothing. Upgrading
users with a selected server account silently lost it. Only setContext,
applySyncedContext and the migration itself record a choice now.
An Apple Account change re-resolved the credential scope but never told
AccountsManager to reload its identity-namespaced storage - the only reload
was a one-time launch task - so the previous identity's accounts, context
and outbox stayed live under the new one, as did cached per-account
subscription providers. The scope now posts when its resolved value
changes; the accounts store reloads and the provider cache is dropped.
Fourteen call sites still read the pre-revamp instance-keyed Keychain item,
which a new login no longer writes: reopening the source screen showed the
account as signed out, and feed, browse, home and import operations treated
it as unauthenticated. They now resolve the credential through the account
layer, preferring the selected context's account and otherwise any
signed-in account on that instance.
Signing in while the identity scope was still unresolved created the
account in a temporary namespace that reloadForCurrentIdentity later
discards, while credential storage silently refused the write and the UI
reported success. Login is gated on a resolved scope and verifies the
credential actually stored before reporting success, rolling back a
newly-created account if it did not.
The NavigationStack-level background wasn't enough: macOS draws its own
translucent material behind pushed navigation pages, and Form/List
containers draw a translucent scroll background on top of anything
placed behind them, so several pages kept the wallpaper-tinted look.
Bake the opaque background into SettingsFormContainer (covers all pages
built on it, pushed or not) and add opaqueSettingsFormBackground(),
which hides the container's scroll background before applying the
opaque one, to every macOS-reachable Form/List settings page: player
controls and its sub-editors, sidebar settings, edit source, legacy
data import, subscription/playlist import, customize home and its
shortcut style page, and the log viewer. Contributors, translators and
the remote control device page get the plain opaque background.
Claude-Session: https://claude.ai/code/session_0154KH8RAVAvm6iVanhmoW8o
TVSidebarDetailContainer now exposes a showsDismissButton flag instead of
always attaching a Done toolbar item. The button is only enabled where a
view can end up with no focusable element on its own — Device
Capabilities (informational rows) and the Import Playlists/Subscriptions
flows.
Wrap Contributors, Translators, Acknowledgements, and Device Capabilities
destinations in TVSidebarDetailContainer for the consistent sidebar look,
and make the Translators/Acknowledgements rows focusable on tvOS by
wrapping them in Buttons so the Menu remote button can pop the stack.
When all playlists/subscriptions were imported, every row collapsed to a
non-focusable checkmark and the Add All toolbar item disappeared, leaving
the view with no focusable element. The Menu button then closed the app
instead of popping the navigation stack.
Wrap the import destinations in TVSidebarDetailContainer for visual
consistency and add a Done toolbar item (cancellationAction) that is
always present on tvOS, reachable from any list row via swipe-up.
- Fix BGTaskScheduler assertion crash on Mac Catalyst by guarding all
iOS background task APIs with isMacCatalystApp check
- Fix iPad popover crash in UIPopoverPresentationController by adding
.presentationCompactAdaptation(.sheet) to all 27 confirmationDialogs
- Fix SwiftData assertion crash when accessing deleted Bookmark model
properties during SwiftUI hit testing in BookmarkRowView
- Fix UICollectionView invalid item count crash on queue swipe-to-delete
by using ID-based removal with withAnimation instead of stale index
- Fix Range crash in storyboard download when storyboardCount is zero
On tvOS, ContentUnavailableView inside a Group doesn't expand to fill
available space — it sizes to content and aligns top-leading. Add
.frame(maxWidth: .infinity, maxHeight: .infinity) to all instances
so they center correctly in their parent containers.
