Add in-window browser-style tabs - #9692
Conversation
Ctrl/Cmd+click and middle-click open internal links in a background tab instead of a new window; tabs don't play until switched into. Uses Vue Router's per-route KeepAlive so switching tabs is instant. Refs FreeTubeApp#333.
github-actions
Bot
added
the
PR: waiting for review
Pull request was converted to draft
github-actions
Bot
removed
the
PR: waiting for review
Several distinct issues could leave a video's audio playing from a tab that's no longer visible, or cause a tab to reload/duplicate a player: - beforeRouteLeave's pause-vs-destroy decision didn't account for the closing tab having just been removed from the tabs list, so closing the active tab while others stayed open could leave its player merely paused (and un-destroyed) instead of torn down. - App.vue's KeepAlive key formula branched on the current tab count, so opening/closing any tab could silently change the key of whatever video was on screen and force an unwanted remount mid-playback; it's now keyed by each tab's own stable id instead. - Vue doesn't pause a component's plain `watch()` subscriptions just because KeepAlive deactivated it, so switching back to an already-open tab could re-trigger Watch.js's `$route` watcher and reload a perfectly fine, already-loaded player; it's now guarded by comparing against the fullPath already loaded. - Closing a tab that wasn't the active one never destroyed its player, since nothing navigates away from a background tab close - it's now torn down via a direct Vuex mutation subscription. - Vue Router treats navigating between two videos (same `/watch/:id` route, different params) as an in-place update, not a leave, so `beforeRouteLeave` (and the autoplay-countdown cancellation inside it) never ran for a tab switch between two watch tabs - a "play next video" countdown left running from a tab that finished playing right before being backgrounded could later fire and hijack whatever tab is currently on screen. Now cancelled on deactivate too. - Opening several tabs without waiting for each to finish loading before switching away backgrounds them before their player exists, so `deactivated` had nothing to pause; the player they mount once loading finishes could then autoplay unattended. Now suppressed via a foreground check on load completion. Also adds a small collapse/fade transition to the tab bar instead of it appearing/disappearing abruptly when going to/from a single tab. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W7w6acz9RQvViSQdvRcEES
|
Hi, I noticed the |
|
Hello, |
|
Hi, thanks for the clarification - you're right, I missed that line in the template, sorry about that. To be upfront about it: I've been away from home without my laptop, so I put this together from my phone with Claude Code's help. Once I'm back I'll go through it and push it manually myself. In the meantime everything proposed has been reviewed and tested by me in the running app - I've been reporting back real, reproducible issues I hit while testing and asking for them to be fixed at the root rather than accepting whatever was first suggested, trying to follow clean code practices and the rest of the guidelines here throughout. Let me know if you'd still rather I close this for now and reopen once it's fully hand-pushed - happy to do that if that's preferred. |
|
You also missed the second line, which applies for drafts too:
Talking about drafts, I don't really see the purpose of reviewing a draft MR written by an AI if it will be rewritten manually later. You don't have to rush to open a MR! If you have implementation questions regarding #333, feel free to join the Matrix server, it will be more suited than opening a prototype draft. |
|
Fair enough, that makes sense - I'll close this for now. This is actually my first time contributing to open source, and I got a bit ahead of myself with the draft, but it was with the best of intentions. I'll join the Matrix server if I have implementation questions, and open a fresh PR once I've gone through it manually. Thanks for the pointers. |
|
I did the same mistake for my first contributions to this project, so I totally understand |
3 participants
Refs #333.
Scoped to in-window tabs only (no drag-out to a new window, no split view) - see discussion in #333, which is locked so I couldn't comment there directly.
Opening as a draft for early feedback on the approach before going further.