An option to disable the video history/queue control with the "back" button

[nbmrjuhneibkr]

Checklist

• I checked, but didn't find any duplicates of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one feature request. I will open one issue for every feature I want to request.

Describe the feature you want

v0.20 appears to be keeping the history/queue of previously opened videos separately from the actual browsing history.
As discussed in #4462 , this interferes with the normal behavior of the Back button, and may be inconvenient and counterintuitive.
The solution would be to add an option to always treat the Back button the same way as it's treated in any web browsing application, and don't control the video queue with it.

Is your feature request related to a problem? Please describe it

Unless the minimized player is closed manually (which also stops any playback), Back button will always open previous video (even if autoplay is disabled, and user never actually watched the video) instead of going to the previous page (playlist/channel/video/search results).

Additional context

#4462 (comment)

How will you/everyone benefit from this feature?

This will allow to keep traditional navigation with Back button always leading to the previously opened page.

[avently]

Finally. You made a normally described issue

[nbmrjuhneibkr]

Finally. You made a normally described issue

Am I getting a medal for that or something? All issues submitted by me are made in compliance with the contribution guidelines.

[FriendlyNeighborhoodShane]

Besides changing the behaviour of the back button, IMO the video should not automatically be added to this queue (and shown in the mini player) at all, unless it has actually been played (by autoplay or otherwise). Perhaps a dedicated "add to queue" button can be introduced.

[max1ly]

My two cents. One of the confusions i have with the queue is that videos i watched haven't been removed from the queue automatically after they completed, so when i press back (device's back button) i usually navigated through the stack of finished videos, which is slightly annoying. I'd prefer that navigation from current video to be leading to Channel and then to Subscriptions list, without implicit queue.

If the queue is still desired, then it would be great if the interaction with it was more transparent. From what it sounds like, seems it should be a separate feature with explicit submenus like "add to/remove from queue" with a separate tab for the list maybe.
For example, how it's done in AntennaPod, see a screenshot - the app has a Queue list which basically contains current playlist of episodes to play, where user can edit the order etc

[MD77MD]

I would like to have the back button as well but not in current newPipe status. the video queue history is just essential in the current newPipe structure and this why. newPipe lakes the multiple windows/fragments the orgenal YouTube app have, as you know we could have up to 5 search instances that we can interact and switch between them. while newPipe can handle only one search instant. in my experience (which is actually a work around) is the queue history helps to mitigate the lake of this hey feature by holding videos i have searched and opened back to back then go through them one by one.

I know this is a stupid work around but what to do, however, if the multi-window feature is added (in the next +5 years, maybe) then i think we can do something about it. perhaps a toggle in options would do. but to be honest i would still love to have it.

@Maxily your idea for have a queue panel is even more important. to be honest I've been having similarly thoughts. a separate independent queue panel that could be accessed easily fun anywhere in the app, not from the notification panel. moreover, we also most have "add next" for this to function properly. Maybe you can open an new issue for this

[gregor-tb]

I also struggle with the back / history.

Open a video from feed, "close" it with back button minimizes the player, what is a nice feature, you can hear the outro and browse the next video.

BUT when you don't close the Mini-Player by yourself + open a new video from feed, you expect to go back to feed (with minimized player etc.). But instead you get back to the previous video detail page, that is very annoying. No matter if you watched the video or just visited the page, starting from feed should not enqueue (or be optional).

An overall present "back to feed" button would also fix the issue, because going back in history through dozen search pages is also frustrating, I restart the app then, it's faster... :(

[avently]

@gregor-tb

An overall present "back to feed" button would also fix the issue, because going back in history through dozen search pages is also frustrating, I restart the app then, it's faster... :(

Yep, it's much faster than to close the mini player with gesture down or via tap on X button. Nice idea!

[eudes]

I understand the technical difficulties in making the back button work as requested, but the current behaviour is totally contrary to mobile app UX idioms and should be reverted. No one expects the back button to take you to something different than the pervious screen. This only happens with obtrusive ad focused websites, and it annoys the hell out of everyone.

The expected behaviour of the back button is to take you back to the last screen, whatever that is. The "the take me to the previous video" verb is not something anyone expects from the native buttons, and should be made explicit by using something like a "previous track" button on the video overlay.

If decoupling this UI feature from the queue mechanism is impossible, then I suspect the queue mechanism is not particularly well designed and should be given some more thought.

[Vrihub]

I understand the technical difficulties in making the back button work as requested, but the current behaviour is totally contrary to mobile app UX idioms and should be reverted

I agree in principle, but if reverting would cause too much disruption, or require too much refactoring of the existing code, then until a solution is found, I think this non-standard behaviour ("swipe down" is the new "back") should at least be well documented, so that the user can be familiar with it from day one (instead of being puzzled and learn it with frustration).

By "documented" I mean with a help screen that would appear the first time the app is run (or the first time the back button is used :)); perhaps also a "question mark" icon somewhere in the main video screen could lead to this help screen, like the one we currently have in the "What's new" screen to explain "fast mode".

[nbmrjuhneibkr]

Any updates on this? @eudes said it best: current behavior of the system button in NewPipe contradicts basic mobile UX. At the very least, this non-standard behavior should be optional and/or be handled by a custom UI element - not by a system button.

[opusforlife2]

Hack at this moment. Swipe down the upper interface instead of clicking back button.

@SameenAhnaf That's not a hack. That is the actual intended navigation flow. xD

Have you not read the 0.20.0 blog post?

[avently]

@SameenAhnaf do you know that you can edit your messages instead of deleting and recreating them? Or it's a hack for you too? Why do we have to receive dozens of emails because of you wanting to receive an attention?

[avently]

@SameenAhnaf I don't receive an email if someone edits their comment so can't say what you can do. Maybe you can try to write to github support they are pretty fast

[ShrimpBFM]

I barely use the app anymore since this nasty mini player was introduced because of the issue described here and also the fact
that I don't want the mini player all.

There should be an option to disable it.
When I watch a video and press the back button, the video should close and I should get back to my search results or subscription feed (where ever I came from.) - Like the app used to be in the golden days.

Neither do I want some video sound going on and distract me while I browse for the next video, nor do I want to tap a little X on my phone with my thumb unsuccessfully.

Not having such annoyances used to be the main reason to use this app over regular YouTube to me.
But then you added extra steps and annoyances into the experience with the introduction of this mandatory "feature".

I check the app every couple of months and it is still not optional.

Please make the app user-friendly again.

[opusforlife2]

@ShrimpBFM You can swipe down on the video with two fingers to close it completely.

[Multipanda]

This has now become worse, rather than having to click back a few times, if I've watched a bunch of videos through the suggestion feed i now have to click back through every single one making the app bordeline useless if I want to get back to the app's start screen.
My solution has been to shift to the fork Newpipe Preunified, and I probably won't go back until they make the unified player optional:
https://github.com/XiangRongLin/NewPipe-preuinified/releases

[nbmrjuhneibkr]

@opusforlife2 This is non-intuitive, and can't be done with one hand. Not a viable solution for the problem.

[avently]

Made a PR with a fix, take a look: #6895

[eudes]

Gave it a quick test and it's all I was hoping for :). Thank you!

For anyone wanting to try it: download the build artifact, which contains the APK; install; change the following setting (in the app) to you preferred action: Settings > Video and Audio > Behaviour > Back press in player. The YouTube app-like behaviour is called "Hide into the mini player".

This is the artifact with this feature (as of right now): https://github.com/TeamNewPipe/NewPipe/suites/3461129393/artifacts/82255089
You may need to be logged in to github to download it.

[SameenAhnaf]

Closing in favor of #4569

[opusforlife2]

4569 is a special case of this issue. It doesn't completely replace it.

[devycarol]

I, too think that this is important for concerns related to accessibility, consistency with other video browsers such as mainline YT, and consistency with the rest of the Android UX.

With the exception of its implementation in things like web browsers, the 'back' gesture isn't really meant to navigate backward through content that is being browsed—we would then expect there to be a 'forth' button as well. While it can be inconsistent at times, it is principally meant to take the user back to the previous UI scene.

This is why the YT app behavior of minimizing the video player is better in my opinion, because it's more consistent with that standard. Back-and-forth media history navigation should be a thing reserved for media-control buttons, and it should be uncommon to trigger accidentally.

And just from an accessibility and ease-of-use standpoint, I think minimizing the player to go search is a principal action that shouldn't have to involve reaching up and gesture-controlling all the time—phones are getting huge these days :P.