[CraftStick]

Key change

Clicking the music strip in a profile header while that profile's music is already playing now only opens the track list. The player is not recreated and the playback is not restarted. The first click, when nothing from this profile is playing, behaves as before: it starts the music and opens the list.

A new activeProfileMusic hook in PeerInfoUIHooks returns the current state and the ProfileSavedMusicContext of the player in the navigation header when it plays the music of the same peer, and nil otherwise. The app-side implementation checks the header context object and the shared audio player (getAudioPlayer()), so it does not depend on the header view, which does not exist before the first playback.

PeerInfoHeadItem.openProfileMusic() opens the list with that state and context, not with the ones of the profile screen that was just opened. When a profile is closed and opened again while its music keeps playing, the new screen has its own ProfileSavedMusicContext, and tracks that the list loads further, adds, removes or reorders through it would not reach the queue of the running player. The hook returns nil, and the previous behaviour (a new player) is used, when the running player has no state yet or belongs to another account than the profile screen, so with several accounts the list never edits the music profile of the account that is playing. The hook also returns the track that is playing now, and the list is opened scrolled to it, not to the main track of the profile, which can be out of view in a long list.

Reason

openProfileMusic() always created a new APProfileSavedController and called start(), which begins with the first track of the profile, and installing the new player stops the previous one. As a result, a track chosen from the list was replaced by the first track as soon as the strip was clicked again, and the list could not be used to pick another track while music was playing.

Screenshot/video result (before/after)

The same scenario on both builds: open a profile with two saved tracks, click the strip, pick the second track (No Love) in the list, close the list, click the strip again.

Before

After

Confirmation

Tested on macOS 26.7.1 (25G241), Apple M2, with local Debug builds of master at e537320 (before) and of this branch (after).

1. Opened my own profile, which has two saved tracks, and clicked the music strip. Expected: the first track starts and the list opens. Actual: as expected, with and without the change.
2. Picked the second track in the list and closed the list. Expected: it keeps playing. Actual: as expected.
3. Clicked the strip again. Before the change: the list opened and the first track was playing from 00:01. After the change: the list opened and the second track kept playing (00:10, then 00:12 two seconds later).
4. Picked each track in the list again. Expected: the chosen track starts from 00:00. Actual: as expected.
5. Closed the player with the cross in the header and clicked the strip. Expected: the first track starts from the beginning, as before. Actual: as expected.

Testing limitations:

• Only my own profile was tested. The code path is the same for other users' profiles, but I did not open one with music.

• Only macOS 26.7.1 was available. No other macOS version and no Intel machine were used.

• Multiple accounts (the account check and the other-account fallback) and VoiceOver were not tested.

• Closing the profile and opening it again while its music keeps playing, then loading more tracks or reordering them in the list, was not tested in the app. The change only compiles in a build and makes the list use the running player's own context.

• I built with the Postbox assert in OrderedItemListTable.replaceItems disabled (-assert-config Release), because a Debug build traps on my account at launch on a duplicate recent inline bot entry. This is unrelated to the change.

• I confirm that I have tested the affected behavior and verified that it works properly, or verified the content and links for a documentation-only change.

[macosswift]

Issues:

• PeerInfoHeadItem.swift:871-874: when the profile is closed and opened again while its music keeps playing, clicking the strip opens the list bound to the new screen's ProfileSavedMusicContext while the running APProfileSavedController still uses the old one, so tracks the list loads further, adds, removes or reorders are not in the player's queue and clicking such a track does nothing.

[macosswift]

Issues:

• PeerInfoUIHooksInstall.swift:204: activeProfileMusic does not check that the running player belongs to the same account as context, so with two accounts, music of user X playing from account A and the strip of X's profile clicked in account B opens the list on A's ProfileSavedMusicContext, and adding or removing a track in that list changes A's profile music.

• PeerInfoHeadItem.swift:872: When the strip is clicked while another track than the profile's main one is playing, the list is opened with musicFile (the profile's main track) as its scroll anchor, so it scrolls to that track instead of the one that is playing, which can be out of view in a longer list.