Make history page remember last query string & search limit

[PikachuEXE]

Pull Request Type

• [ ] Bugfix
• [x] Feature Implementation
• [ ] Documentation
• [ ] Other

Related issue

Description

Make several page types remember last query string & search limit to deal with

• Search in history
• Found a few videos
• View one of them, go back last page, oops not filtered

Page types:

• History page
• Channel tab (Channel List for current profile)
• User Playlists page
• Single User Playlist page
• Single Channel page

Screenshots

No video I am lazy

Testing

• Ensure last used search query and data limit restored when revisiting history page
• Ensure they are not restored after clearing query text / in new window
• Ensure no 2 time rendering on page initial render

Desktop

• OS:
• OS Version:
• FreeTube version:

Additional context

There are 2 commits & first one is refactor Might easier to review per commit

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

I understand where you're are coming from but this behavior is also not apparent in Playlists tab, Channel tab, and a Channel page.

Channel page one also applies to Nr 6 on the list of issue https://github.com/FreeTubeApp/FreeTube/issues/2446 which is a way bigger issue

Just to clarify im not against this but I think we should do it for all pages instead of one for the sake of a consistent UX

[kommunarr]

I'd also like to know rationale, as I don't see any requests for this. I'm not necessarily opposed to it, but I don't have any reason to believe that the app remembering my last query would cause fewer irksome moments than the app not remembering it.

[PikachuEXE]

Making it work like search query page I realize this when searching in history (and several videos popup), click one of them, not the one I want, go back, oops Though I can always open in new windows (but mobile can't do it?) Up to you guys

[kommunarr]

If you want, you can share the build & I can try it out for a while in personal use. It sounds nice in theory, but it feels more horizontal of a change for the use cases where you want to go to the initial page state & now have to click to clear the input. The search bar is also omnipresent, so you wouldn't ever forget what was going on, but here I could see it leading to momentary confusion and re-familiarizing yourself with the context of what's going on & what you were searching beforehand. Seems like maybe "open in a new tab" covers the type of use case you're mentioning better (albeit I guess not if you didn't expect to misclick).

[PikachuEXE]

Used router.replace to ensure the query text restored only on clicking back Clicking on history link won't restore it

About the catch after replace: https://v3.router.vuejs.org/guide/advanced/navigation-failures.html

Update 1: Use my custom build if you want - https://github.com/PikachuEXE/FreeTube/actions/runs/9345433122

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

Just to clarify im not against this but I think we should do it for all pages instead of one for the sake of a consistent UX

Just retested it but my opinion on this hasnt changed.

[PikachuEXE]

@efb4f5ff-1298-471a-8973-3d47447115dc Can you list all the page types so I won't miss any on next update?

[kommunarr]

That sounds like it would be a pretty sizable change to the codebase for a small feature. I would personally advise putting this one on the backburner just because I'm not sure if the feature would provide enough utility versus the effort to maintain it.

[github-actions[bot]]

This PR is stale because it has been open 28 days with no activity. Remove stale label or comment or this will be closed in 14 days.

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

@efb4f5ff-1298-471a-8973-3d47447115dc Can you list all the page types so I won't miss any on next update?

Sure:

• FT Channel tab
• User Playlist tab main view
• Inside User Playlist
• Creator Channel page

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

Q: Why does it take a while for the thumbnails to appear when navigating back to the History tab? Why isnt it instantly shown?

https://github.com/user-attachments/assets/ec7489f5-c9eb-4571-82d9-9aad7a674d07

[github-actions[bot]]

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

[PikachuEXE]

Q: Why does it take a while for the thumbnails to appear when navigating back to the History tab? Why isnt it instantly shown?

Fixed

[github-actions[bot]]

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

[PikachuEXE]

FT Channel tab User Playlist tab main view Inside User Playlist Creator Channel page

Also done but for the Creator Channel page one I am not really confident (even though I tested it a bit

[github-actions[bot]]

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

[github-actions[bot]]

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

[PikachuEXE]

Updated

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

Notice that results are ordered in a different when navigating back to the channel page

https://github.com/user-attachments/assets/374d566d-037c-4913-9538-e120d69b1d15

[PikachuEXE]

I can reproduce it once but cannot reproduce afterward, no idea how results are sorted (or just taking from API)

https://github.com/user-attachments/assets/c57b8fd2-bfee-4f79-a408-b3f32c7ce7b0

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

I can reproduce it once but cannot reproduce afterward, no idea how results are sorted (or just taking from API)

If you switch often enough you can make it happen again. It is showing the loading animation so maybe its trying to do something in the background?

Uhh why its focused like that? Dev branch doesnt seem to do that.

https://github.com/user-attachments/assets/a3428fbf-0321-4c0a-b1a4-7e260429b1dc

[PikachuEXE]

It is showing the loading animation so maybe its trying to do something in the background?

• newSearch
• this.isElementListLoading = true
• searchChannelLocal or searchChannelInvidious

Ya it's searching

Uhh why its focused like that? Dev branch doesnt seem to do that.

Caused by changeTab -> showOutlines. it's a bug that is never visible until now Fixed

[PikachuEXE]

If you switch often enough you can make it happen again.

I can't make it happen anymore

Maybe you can find the request and look at the result order to see if that matches the order of result displayed?

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

I tried to reproduce it again but it took me a solid minute going back and forth to make it happen again. Maybe its not that big of a deal?

[PikachuEXE]

If you can prove that the result order is incorrectly/ever manipulated with this PR then it should be fixed Otherwise it could be just temp search result order alternating for who knows why

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

If you can prove that the result order is incorrectly/ever manipulated with this PR then it should be fixed

I would love to but im not sure how. Could you give me some more instructions on top of the ones u already provided in https://github.com/FreeTubeApp/FreeTube/pull/5192#issuecomment-2390338307

[PikachuEXE]

• Go into a channel, search stuff
• Inspect latest request (request payload with query
• Preview tab, contents...tabs, find element with expandableTabRenderer, content...contents, expand those items to inspect video IDs

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

I would like to console log the videoID's because expanding everything like this makes my head hurt. Where should I put the console.log?

[PikachuEXE]

Change

        if (isNewSearch) {
          this.searchResults = results
        } else {
          this.searchResults = this.searchResults.concat(results)
        }

to

        if (isNewSearch) {
          this.searchResults = results
          results.forEach(e => {
            if (e.type === 'video') console.log(`${e.type}: ${e.videoId}`)
            else if (e.type === 'playlist') console.log(`${e.type}: ${e.playlistId}`)
            else console.log(`${e.type}`)
          })
        } else {
          this.searchResults = this.searchResults.concat(results)
        }

searchChannelLocal is not modified by this PR

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

Left one is just a normal search. Right one is when coming back to the channel page