Add autoplay toggle to the video player

[kommunarr]

Add autoplay toggle to the video player

Pull Request Type

• [X] Feature Implementation

Related issue

closes #1181

Description

Adds autoplay toggle to the media player.

• Behavior:
  • When in a playlist, the Autoplay Playlist Videos setting is the one exposed/manipulated. Otherwise, the Autoplay Recommended Videos setting is the one exposed/manipulated.
  • The autoplay button is hidden when autoplay is not possible.
    • Note: "possible" being defined as the existing checks in Watch.js to call this.$refs.watchVideoPlaylistplayNextVideo.
  • When the autoplay countdown timer is going down, disabling autoplay will abort the countdown.
• (Adopted from #4342) Updated very confusing autoplay labels' EN-US values to more understandable meanings (see Screenshots section for details)
• Removes now-redundant autoplay toggle above Recommended Videos and playlist pause button in Playlist Options
• For icon considerations, only the deprecated list of Material icons are available, so we don't have access to autoplay/autopause. I decided on play_circle/play_pause instead. One other considered alternative was toggle_on/toggle_off, but it would have been less descriptive.
• Minor bug fix: Previously, the Shaka mobile overflow menu intersected with the top bar on many mobile devices (e.g., in the quality settings or playback rate settings), blocking the top entries from being visible. This has now been fixed.

Screenshots

Autoplay off:

Autoplay on:

Mobile overflow menu:

Autoplay Settings Label/Ordering Changes: (Autoplay Videos -> Start Videos Automatically, moved to bottom) (Play Next Video -> Autoplay Recommended Videos, moved to top) (Autoplay Playlists -> Autoplay Playlist Videos)

Rationale: define "autoplay" consistently, colocate autoplay buttons, colocate the non-autoplay right-column buttons. To preempt the potential criticism that moving the controls might confuse users who have forced themselves into learning the existing labels/ordering, I disagree. I have worked a good deal with these values as both a developer and a user, and I still mess these up. I would contend that the benefit of the changes starkly outweighs the risk.

Before	After

Testing

• Test that disabling autoplay aborts the autoplay countdown
• Test that the Autoplay toggle does not appear for a non-playlist video when Hide Recommended Videos is enabled
• Test that the Autoplay toggle does not appear for a playlist video when it's the last video in the playlist and loop is disabled
  • Check that it does appear when loop is then enabled
• Test that using the autoplay toggle causes the video to autoplay / not autoplay accordingly and updates the corresponding setting (playlist versus non-playlist)
• Bug fix validation: Check that mobile Shaka overflow menu does not intersect with top nav bar when in the playback rate or quality selection menus

Desktop

• OS: OpenSUSE
• OS Version: TW

Additional context

I considered firing handleEnded on enabling autoplay on an ended video in order to start the autoplay countdown, but I decided against it. Partially because it's a race condition risk to wait sufficiently long for isAutoplayEnabled to update, partially because it's not that important.

I originally marked this story as a good first issue, but considering its 3+ y/o age and the amount of time it would take to guide a new contributor through all of the above bullet points & intricacies, I decided to take a stab at it myself.

[kommunarr]

I think the pause button can be removed.

To be honest, I've never even noticed this feature existed until you just pointed it out. Removed

[PikachuEXE]

I wonder why in additional to adding the button to player (great for mobile especially which I have no problem with) There is no button on playlist panel (previously pause button)

As a desktop user I expect controls for playlist to be all on that panel

[kommunarr]

The "Stop autoplay after this video" button is a very niche feature amongst other apps and seems to have been our temporary replacement for an easily accessible autoplay toggle. The cost of users having to switch to using the autoplay toggle for their use cases is less than that of having to maintain two redundant features. Even if we were to make the older pause button act exactly like the autoplay toggle, the mental load cost of multiple controls on the same page with the same behavior is high and should be avoided whenever possible.

[PikachuEXE]

I think you misunderstand my comment

I am saying I expect to see that new button on playlist panel instead of just inside the player

If "the mental load cost of multiple controls on the same page with the same behavior is high", I expect to see it in playlist panel

[kommunarr]

I am saying I expect to see that new button on playlist panel instead of just inside the player If "the mental load cost of multiple controls on the same page with the same behavior is high", I expect to see it in playlist panel

Still not sure I understand your point. The autoplay toggle will be visible in the player bar in such a case. There is no point in moving the location of the autoplay toggle or duplicating it for different kinds of videos. Autoplay, as of this PR, will be a property identified with the video player rather than a playlist control, the same as the audio level or theater mode.

[PikachuEXE]

There is a point, playlist related info should be visible on playlist panel including auto play enabled or not https://github.com/FreeTubeApp/FreeTube/issues/1181 is about full screen/full window mode about not being able to toggle it without exiting the mode and not about default/theater mode Which is why I support adding that button to player but the status should be on the playlist panel first

[kommunarr]

Will leave it for other team members than us to decide, as we seem to be in another of our famous impasses. Will leave my main points up:

Autoplay, as of this PR, will be a property identified with the video player rather than a playlist control, the same as the audio level or theater mode. Even if we were to make the older pause button act exactly like the autoplay toggle, the mental load cost of multiple controls on the same page with the same behavior is high and should be avoided whenever possible. Given these facts, it is not worthwhile to move the location of the autoplay toggle or duplicate it specifically for the case of playlist videos, and we should instead keep the functionality in one consistent, non-duplicated location for all videos.

[efb4f5ff-1298-471a-8973-3d47447115dc]

There is a point, playlist related info should be visible on playlist panel including auto play enabled

This isnt playlist related info. All buttons in there affects the whole playlist (except for the standard skip to next/previous video buttons). This is a button that is related to the individual video and by the introduction of this button we made the association to the playlist.

https://github.com/FreeTubeApp/FreeTube/issues/1181 is about full screen/full window mode about not being able to toggle it without exiting the mode and not about default/theater mode

That is just an example. The purpose of my issue is to make it the same as YT.

If we look at Autoplay in YT it is always enabled in playlists. BUT on YT everything that regards Autoplay is built into the player. So when new users come from YT to FT I'd argue that new users are mentally way more familiar with the way its done now.

[PikachuEXE]

@efb4f5ff-1298-471a-8973-3d47447115dc I assume you are referring to autoplay control which I can find at https://youtu.be/Wkr2n5Fs_NA?t=30

I am not opposing adding a button in the player

If the objective is the make FT looks like YT (not limited to this PR), then prev/next playlist item buttons should be in player as well (not suggesting they should be done in the same PR)

If this is the case I can agree with the placement but only if the prev/next buttons are moved too (in the same/another PR)

[kommunarr]

I think we're on the same page now. I / whomever can work on that in a separate PR (~whoa, has no one made a feature request for that one at all yet? That actually surprises me~ You continue to astound me @efb4f5ff-1298-471a-8973-3d47447115dc!)

[efb4f5ff-1298-471a-8973-3d47447115dc]

Relevant issue https://github.com/FreeTubeApp/FreeTube/issues/1220 :D

@kommunarr maybe controls for previous next video can be implemented after https://github.com/FreeTubeApp/FreeTube/issues/2138#issuecomment-1073724876, Shift+N / Shift+P

In my mind sounds like the logical next step

[PikachuEXE]

Waiting for https://github.com/FreeTubeApp/FreeTube/pull/5857 to be merged first

[kommunarr]

One change that needs to be added to this PR, as aptly noticed by a teammate, is changing the force overflow menu breakpoint. I would prefer to wait until this chore of moving some of our controls into an overflow menu in desktop/tablet view is merged before doing so, as it could change the intent. I can probably take the chore up this week unless someone else has a clearer vision for it that they would like to enact.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[efb4f5ff-1298-471a-8973-3d47447115dc]

One change that needs to be added to this PR, as aptly noticed by a teammate, is changing the force overflow menu breakpoint. I would prefer to wait until this chore of moving some of our controls into an overflow menu in desktop/tablet view is merged before doing so, as it could change the intent. I can probably take the chore up this week unless someone else has a clearer vision for it that they would like to enact.

If i may ask what is the progress on this? Is this chore holding up this PR?

[kommunarr]

@efb4f5ff-1298-471a-8973-3d47447115dc That's correct. There are decision points regarding the context menu that I would prefer to not be directly involved in, and I would also prefer for #6400 to go ahead first in the queue.

[github-actions[bot]]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[PikachuEXE]

https://github.com/FreeTubeApp/FreeTube/pull/6400 expected to be merged after this?

[kommunarr]

I still needed to adjust the force overflow menu breakpoint; this is now ready for review. In retrospect, I think it would make sense for this to go first instead of #6400 so we can have one PR for implementing the logic for both autoplay settings.

[PikachuEXE]

Briefly tested (except mobile & code review I will let others review those parts