[meh7an]

The Picture-in-Picture window has no way to move between items in an album. Keyboard navigation does not reach it either, since it has no focus handling, so once a video opens there the only ways onward are closing the window or pressing Enlarge.

This adds Previous and Next buttons to the Pip window.

Changes

• Two new OverState values and two Buttons, centred on the left and right edges, reusing the existing Pip button style and hover fade. They are painted and hit-tested only when a neighbour exists, so no dead arrow appears at either end of an album.
• Pip::Delegate gains pipCanNavigate(int) and pipNavigate(int). The window answers them from its own navigation context, not from the viewer.
• The window keeps its own context in PipWrap::Navigation: its message, topic, monoforum peer and media list. switchToPip() fills it while the viewer still shows the video, and the window then follows its shared media list through a SharedMediaWithLastViewer subscription of its own, on the video's key and session. Instant View and link preview collage lists don't change, so a copy with the index is enough. PipWrap::entity() resolves the neighbour from that context, so opening, browsing or closing other media in the viewer meanwhile does not change where the buttons lead, and the viewer clears everything on hide, as on dev.
• pipNavigate() hands the neighbour back to the viewer with the same show(OpenRequest(...)) that Enlarge uses, carrying the window's own opener window, topic, monoforum peer and draw button state, with _reShow set so a viewer that already shows that message is not toggled closed. A photo opens in the viewer, and a video goes back into a new Pip window because _showAsPip stays set. The click arrives from inside the Pip mouse handler, so the handoff is queued, and a _pipGeneration counter turns a click queued behind a jump into a no-op.
• Pip::navigationChanged() repaints the window and recomputes the hover state under a resting cursor when its list loads or changes, so a button that appears under the cursor works on the first click.
• _showAsPip stays set as before, so after a jump that lands on a photo, which Pip cannot display, the next video, whether reached with the viewer's arrows or opened from a chat, goes back into the window. Only Enlarge ends that, as on dev.
• A new Pip takes over the hover state from the cursor position before its first paint, through the same handleMouseMove() a real hover uses, then finishes the controls fade at once. A window created under a cursor that is not moving receives no mouse move event, so its controls stayed hidden, faded back in and showed the default cursor until the mouse moved. Every jump builds a new window under the cursor, so a jump now looks like the same window changing its video.
• kControlsCount goes from 7 to 9 in the OpenGL and RHI Pip renderers, with the two icons appended to their atlases at indices 7 and 8. The software renderer needs no atlas change.

Pip holds its document through a const pointer, so continuing in the window means building a new Pip rather than re-pointing the existing one. The request arrives from inside the Pip mouse handler, so the teardown is deferred until that handler has returned.

Testing

Built Debug on macOS against this base. Exercised by hand on both the OpenGL and the RHI renderer: video to video staying in the window, video to photo handing off to the viewer, returning to the window on a later video, and the controls remaining visible across a jump. The software renderer was not exercised, though it needs no atlas change.

After the second review: Pip of a video in the middle of an album, then a photo from another chat opened and closed: the buttons still lead to the video's neighbours, and Next opens the item after the video. The same with the photo taken from the video's own chat, far from it. With the photo opened from a chat in a second window, the item Next opens stays tied to the main window. A window created before its list arrived, or kept paused under the cursor while the list changed, updates its buttons without moving the mouse, and a newly shown Next works on the first click. Video to video by repeated clicks without moving the mouse, video to photo, Enlarge, and closing the window with its button and clicking the same video again (it reopens as a Pip window, as on dev) re-checked.

Screenshot

---

[23rd]

tdesktop/.github/CONTRIBUTING.md

Line 25 in 4d4da47

Unfortunately we **do not merge** any pull requests that have new feature implementations, translations to new languages and those which introduce any new user interface elements.

[john-preston]

Bind PiP navigation to the PiP video’s own message, session, and media collection instead of the main viewer’s mutable navigation state. Playing video A in PiP and then opening photo B currently redirects PiP’s arrows to B’s neighbours; closing B preserves that incorrect context. Keep the contexts separate or provide an explicit handoff, and verify that opening and closing unrelated photos does not change PiP’s navigation targets.

[john-preston]

Opening another window’s video directly into PiP can retain the previous window’s context, making subsequent “Go to message” navigation target the wrong window.

[meh7an]

Opening another window’s video directly into PiP can retain the previous window’s context, making subsequent “Go to message” navigation target the wrong window.

Thanks, fixed. When PiP was already active, a video opened from another window went straight into PiP before the viewer had switched to that window, so the PiP kept the previous one. Now a PiP created while opening a video takes the window that video was opened from, so PiP navigation and "Go to message" go there, while an existing PiP still keeps its own context when unrelated media is opened.