Back button returns to older video rather than actually going back

[TheBrokenRail]

Checklist

• I am able to reproduce the bug with the latest version.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected version

0.23.2

Steps to reproduce the bug

1. Search for and open a video (this is video A)
2. Back out to search screen, make sure not to close video A.
3. Search for and open another video (this is video B)
4. Hit the back button

Expected behavior

The back button returns to the search screen and moves video B into the background.

Actual behavior

Video B stops playing completely and NewPipe returns directly to video A.

Screenshots/Screen recordings

Screen_Recording_20220823-000458_NewPipe.mp4

Logs

No response

Affected Android/Custom ROM version

Android 12

Affected device model

Samsung Galaxy S21

Additional information

No response

[TheBrokenRail]

That seems to be a different back button bug.

[opusforlife2]

Some clarification is needed. What your video shows is the expected behaviour.

What I think you're asking: if B is playing, then tapping Back should minimise the video to the mini player just like what happened for A?

Is that correct?

[TheBrokenRail]

Yeah, that's what I expect. If I hit back, I expect it to return to where I was last, which was the search menu.

[opusforlife2]

I suppose if the video is playing, we could minimise it to the mini player and show the underlying screen. Tapping Back here accidentally causes a temporary "loss" of the playing video, after all.

But I don't think it should be done for paused videos, or video pages with thumbnails (where the video hasn't been played yet). If that happens, there will be no way left to navigate through the backstack.

[TheBrokenRail]

I find this intended behavior weird. If I hit the back button, I expect it to go where I was last. So if I'm on home, search up a video, play it, then hit back, I expect it go back to the seach screen. Why is the expected behavior to jump all the way back to the video that was playing earlier? It's just annoying to have to hit back twice to get back to search. If I open a new video, I expect the older video to be closed, not inserted in the backstack where I don't expect it. Just my personal opinion and expectations though.

Also, here's how the official YouTube app works for comparison:

Screen_Recording_20220823-163621_YouTube.mp4

[opusforlife2]

If I open a new video, I expect the older video to be closed, not inserted in the backstack where I don't expect it.

Are you saying that the backstack shouldn't exist?

It's just annoying to have to hit back twice to get back to search.

The action made for that is to swipe down on the playing video. You'll get to the search screen.

[MD77MD]

it's not a bug, this is how it's supposed to behave and in my opinion is better this way, however i would argue it would be better if there is a toggle in settings to choose the back button preferred behavior . don't you think

[Gabr-F]

I finally managed to understand, reading this issue, some of the extremely weird and apparently unpredictable behavior of the back button in NewPipe.

I found out here and in other github issues that there seems to be a feature, the "backstack", that maybe some developers and some of the probably very few users who heard about it use.

Well sorry, but it seems nonsense.

The back button has a universally known precise function and unless you first prominently informed your users and let them choose otherwise, it needs to perform that function.
Which is, to go back to the previous screen. I tapped something, it opened something, if I press back I get back to where I was.

I'm not sure you realize that you're currently doing this instead:

• I search a thing and get the results, history point X:

*X*

• I open a video's page, point V:

     --> *V*
   /
 X 

• I swipe down the video's page *, ostensibly returning to X:

     <-- V
   /
*X* 

• Open another video's page, point W:

     --- V
   /
 X
   \
     --> *W*

If I now tap the back button, the obvious point where to go back is X, the search screen.
What NewPipe is doing instead is going back and then forth to another "history branch"!

It is:

• extremely hard to realize what's happening
• disorienting
• bug-looking
• probably hard to put to some useful use even if you know perfectly well how it works and have used it for long

The current behavior seems to be meant to have a sort of "see later" feature.
Fine, that's a useful feature. But this is a (sorry) terrible way to realize it.
It's also extremely limited, since it only allows to go back to the previously opened video, or to ones earlier but losing the "skipped" ones in doing so.

Alternative common, intuitive and actually useable ways to support that feature are:

• tabs (Having multiple videos open with browser style tabs #5726)
• a "see later" list accessible, in all likelihood, in a tab, and to which videos could be added:
  • simply with a menu command, just as there is a command to add to a playlist, to play the video etc.
  • with a toggleable button, like the "star" in many mail clients, either only in the video pages or also next to each search result, "trending" tab item, playlist item etc.
  • adding a special "see later" playlist at the top of the playlists' selection menu. It should be noted that this:
    • would require an additional tap, making it maybe a little more cumbersome than what is needed for such a feature
    • could be implemented "manually" by any user by simply making a playlist named so to stay at the top of all the others, such as "* see later". Even for what regards the tab, actually, since you can already add a permanent tab of a specific playlist in the interface
    • ... so I actually did that and I'm trying it right now; however it has to be noted that the possibility to do it is not at all obvious for a normal user, I myself often felt the need for a "see later" feature but it didn't occur me to try implementing it in this way; and I didn't remember that you can add individual playlists as a tab, I now know just because I noticed it a few hours ago

I note that having an easily accessible queue and an enqueue command available even when there's no video playing, could be a somewhat decent substitute for this feature, although, maybe not 🤷 .

Also to note that it's common to desire to "see later" not only single videos but also complete (YouTube) playlists.
So ideally it would be better to be able to add those as well, to an hypothetical see later list (not all their videos individually, the playlists themselves as "playlist items"); this might very well be postponed for the future however.

And anyway, what matters is to make the back button behave sensibly, even if it meant not having anymore anything akin to the "backstack" feature.
I say this because the current back behavior confuses everyone, while the backstack feature is maybe used by a handful of people.

---

* by the way, I read criticisms of it but to me the "scroll down" feature of the videos' pages has always seemed intuitve, I think it seemed obvious to try to scroll it down after seeing it "scroll up"

[TheBrokenRail]

Yes! That's exactly what I meant, thank you explaining it in a much better way than I did.

[b-nik]

To put it simply, it feels inconsistent because sometimes back minimizes the video (thus allowing listening to it while browsing the video list for other stuff) and other times back pauses the video and goes back to a previously opened video.

[opusforlife2]

Navigation is something that will probably need to be reworked as part of the rewrite.

[MD77MD]

maybe it can be solved with a toggle to choose what behavior the back button should follow

[opusforlife2]

The problem is that the Back button is a fundamental part of the navigation flow. And there is basically no precedence for making it configurable, so any such modification would be surprising for users. The only customisation I'm personally aware of that many apps seem to use is whether to use a single tap or double tap to close the app.

[GfEW]

The problem is that the Back button is a fundamental part of the navigation flow. And there is basically no precedence for making it configurable, so any such modification would be surprising for users.

Agreed. Some apps allow you to choose whether or not you need to hit back twice in order to leave the app, but such options are relatively rare.

However, to the common, uninitiated user, the real surprise is the confusing Back behavior, as it currently is.

The suggested option would rather offer them a one-time choice between

• (a) perennial surprises by unexpected navigation results that deviate from the well-established "Back takes me back to previous view" paradigm in various "weird" ways, and
• (b) the established, expected behavior.

I, for one, could certainly take the time and wrap my mind around NewPipe's current navigation concept. Doing so would likely pay off quickly for me, personally, but I resist - not so much for the mental effort but because such effort shouldn't be required by an app that's meant to serve common people, in the first place.

(By not understanding the concept, I'm still able to experience the confusion and, should that matter here, authentically discuss possible remedies.)

[MD77MD]

i like back stack... but i also agree this sould be optional