Navigation history dropdowns

[kommunarr]

Navigation history dropdowns

Pull Request Type

• Feature Implementation

Related issue

closes #2740

Description

• On long press (0.5s) or right-click of a non-disabled navigation arrow, load <=15 surrounding history entries (their route.meta.title - see "Work for a future PR" below). The history entry dropdown presentation behaviors are taken from FF:
  • Show 15 history entries at most. If at the 7th entry from start/last, show results from the start/last. Otherwise, show 7 earlier entries & 7 later entries.
  • The current entry is included in both menus. It's marked with a different color, checkmark, and higher boldness.
• @contextmenu.prevent='' is set on the navigation arrows to prevent the context menu appearing on right-click in dev mode.
• The titles are updated to reflect new behavior: Click to go forward, right-click or hold to see history / Click to go back, right-click or hold to see history (language with inspiration from Chrome [Click to go forward, hold to see history] & FF). These titles are also now visible on hover even when the icons are disabled.
• Thanks to the use of window.history.go and the new ability to go straight to an identical route from earlier in the history, you'd probably wonder how that's handled. Turns out that it doesn't reload the page, just updates the history state. This is fine, I just thought I should point it out.
• Implementation detail: The top-nav-is-colored mixin in top-nav.scss unfortunately is not compatible with the use of :deep, a selector which is required for ft-icon-buttons to actually work styling-wise in the top nav with the legacy non-icon-button-but-almost navIcon font-awesome-icon pattern we're using there (theme doesn't go far enough). So that's why we're doing .topNavBarColor ${selector} for the new SCSS code instead of using the mixin (which thankfully is very fine given that it's a very simple mixin).

Minor cleanup:

• d18b549: Incidentally as a way of cleaning up an extra event handler to worry about in ft-icon-button, replaces the mouseDownOnIcon focusout logic in ft-icon-button in favor of more straightforward logic (adopted from List sorting & display settings #4231)
• Incidentally, makes topNav.historyForward and topNav.historyBackward logic more straightforward

Work for a future PR

• We're currently showing the route.meta.title, which is far less informative than the <title> attribute we set in various places. The main issue with doing that is that it's pretty onerous to do it at the moment because many of our routes asynchronously change the <title> attribute. I don't know the best solution, so let's see if Cunningham's Law works here: the future PR should use IPC or VueX to fire an event whenever a title is set, then we update the entry to switch from a placeholder route.meta.title to the newest <title> attribute value. Such a PR should also remember to test longer inputs (e.g., very long user playlist names), which is not as relevant now with the more limited range of possible field values.
• "Pull down" to open + pointerup after on the corresponding history entry to navigate to it.
• Right-click + pointerup after on the corresponding history entry to navigate to it (Note: seems to be FF-specific; this behavior is not in Chrome)

Screenshots

Testing

• Check that the result ordering behavior works correctly:

If at the 7th entry from start/last, show results from the start/last. Otherwise, show 7 earlier entries & 7 later entries.

• Check that navigating to any arbitrary history entry works
• Check that both right-click and long-press work to trigger the navigation history dropdown
• Check long-press on mobile

I wouldn't recommend testing these ones for the sake of your time, but just to demonstrate that I have tested these:

• (REG, optional) w.r.t. d18b549, check that focusout / Esc / keyboard navigation with ft-icon-button dropdowns still work as intended
• (REG, optional) Check no weird behavior with custom landing page selection
• (REG, optional) Check navigation arrow buttons appear the same with Match Top Bar with Main Color setting active
• (REG, optional) Check that navigation history is still not shared between separate windows
• (optional) Check that navigation history entries are re-translated after changing the language

Desktop

• OS: OpenSUSE
• OS Version: TW

[PikachuEXE]

It doesn't feel like web browser UX:

• Showing all entries when long press on either back / forward button, expect to see only previous / next entries
• Expect not to see entry for current page

[kommunarr]

It doesn't feel like web browser UX:

• Showing all entries when long press on either back / forward button, expect to see only previous / next entries
• Expect not to see entry for current page

I'm not sure what browser you use, but the implementation is the same behavior as Firefox:

I wouldn't say it's the only way to do it, but it's a major browser

[PikachuEXE]

Even that's the case Firefox does show which one is the current entry which I don't see in this PR

[kommunarr]

Even that's the case

'Tis!

Firefox does show which one is the current entry which I don't see in this PR

Two visual indicators here, my friend! I can add a checkmark on top of that if desired, but please look at the PR & description in closer detail before formulating your criticisms.

[PikachuEXE]

I am sorry that I didn't provide screenshot when providing my opinion

A more accurate description would be the
Firefox does show which one is the current entry in darker themes which I don't see in this PR

[PikachuEXE]

Additionally the colors for back / forward button are now inconsistent with other top-nav buttons in themes like light, pastel pink

[kommunarr]

Firefox does show which one is the current entry in darker themes which I don't see in this PR

This is more of a pre-existing problem with certain themes like Dark not having a visually distinctive --side-nav-hover-color, which results in the top & side navs conveying less information, but I will add a checkmark to make it clearer.

Additionally the colors for back / forward button are now inconsistent with other top-nav buttons in themes like light, pastel pink

I think you're on an older version. I fixed this in an earlier commit. That also added the font-weight change.

[PikachuEXE]

With checkmark it seems better
However I re-tested after checking out Add checkmark icon to active history entry and the inconsistent button color is still an issue

[kommunarr]

You might need to rebase then, as I cannot replicate:

[PikachuEXE]

Using theme pastel pink for testing:

What I see in this PR

development

[kommunarr]

Ah, it's not happening to me with hot pink, but I can see it with red as main color. Looking into it now, thank you

[PikachuEXE]

All issues resolved, pending idea from others especially on mobile

[kommunarr]

I had no idea there was a NavigationHistory class in Electron until @absidue pointed it out in the Matrix chat, so it depends if we want to put more eggs into this PR or save that refactor for a separate PR that adds title support, as this is currently functional as-is. That's more of an organizing question than a substantive one, so I'm fine with whichever choice. I will say the suggested change to using a context menu is probably a lot more lateral, so I would prefer if that one was kept to a follow-up PR.

With all that said, I would advise that any reviewers prioritize the higher-salience PRs first if possible. We're a lot closer than we think, and we're reaching a critical mass of feature requests for features we've already merged.

[kommunarr]

Here's where I'm at after looking into it some more.

I can see what was being gotten at with using a context menu as an easy way to grab the current browserWindow.webContents.navigationHistory, but I don't like that we have less control over the styling of the popup. We can discuss that aspect some more, but I'm not sure if that's something we would want, so I'm going to leave that as a separate future effort.

The NavigationHistory API as we're using it is very new to Electron, so I would imagine it's subject to change some. My current idea for how we would integrate with it today:

• We use an ipcMain.handle call on each route navigation to get the navigationHistory.getActiveIndex() and navigationHistory.length() values, and use those to track the navigation arrow buttons' forward/backward state in lieu of our navigateHistory() function call and isForwardOrBackward logic, thus fixing [Bug]: Page navigation arrow indicators not updated by mouse buttons #4408.
• When long-clicking or right-clicking on a navigation arrow, we can replace our sessionNavigationHistory logic with an ipcMain.handle call that gets the getEntryAtIndex(index) for the up to 15 entries that we want, and then we can get the corresponding title property for those. When one is clicked, I believe we should still be able to use window.history.go() to navigate to them without issue.

Note that the above implementation would be easier & improved if these properties were to be exposed to developers:

In a separate PR, duplicate and move other navigationHistory related endpoints like CanGoBack, GoBack, CanGoForward, GoForward, CanGoToOffset, GoToOffset, CanGoToIndex, GoToIndex to the new namespace after the first PR merges.

Because of that, it may be reasonable to wait on the NavigationHistory side of things until it's fleshed out some more with those utilities that would simplify the implementation.

[ArthurKun21]

Would it be possible to have an alternative way to open it like a very small arrow down button

Sorry for the bad drawing, just imagine it was small

[kommunarr]

@ArthurKun21 That sounds interesting, although that's a non-standard pattern compared to the way that most browsers do it, so I'd prefer if we could try to meet that same need in more conventional ways. Do the existing ways added in the PR address your usecase? The main thing we're currently missing is "pull down to open," which is similar to what you describe.

[ArthurKun21]

although that's a non-standard pattern compared to the way that most browsers do it, so I'd prefer if we could try to meet that same need in more conventional ways

honestly, I didn't knew there was function like this in browsers until I saw this PR. Probably there are others like me. The alternative way I suggested should help this functionality to be known more.

Do the existing ways added in the PR address your usecase

aside from the current long click or right click on the navigation arrow button that I didn't knew before, yes I like it as I need to press the navigation button multiple times before to return and this will massively help me in the future.

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

The alternative way I suggested should help this functionality to be known more

Imo making the functionality stand out just because to get it more known isnt a stong argument to create a non-standard way of doing it. For things like that we should create a dedicated docs page.

[absidue]

We use an ipcMain.handle call on each route navigation to get the navigationHistory.getActiveIndex() and navigationHistory.length() values, and use those to track the navigation arrow buttons' forward/backward state in lieu of our navigateHistory() function call and isForwardOrBackward logic, thus fixing #4408.

I've opened #5242 which fixes that issue without having to switch existing functionality to an Electron only API, as the Navigation API already provides helpful canGoBack and canGoForward properties.

Note that the above implementation would be easier & improved if these properties were to be exposed to developers:

In a separate PR, duplicate and move other navigationHistory related endpoints like CanGoBack, GoBack, CanGoForward, GoForward, CanGoToOffset, GoToOffset, CanGoToIndex, GoToIndex to the new namespace after the first PR merges.

They are already exposed to developers on webContents objects, hence the duplicate and move part of the message that you quoted, I use the goBack and goForward methods in the pull request that I opened.

As for why I would suggest an Electron API for the dropdowns after advising against using an Electron API, earlier on in this message, firstly the dropdowns are new functionality, so you wouldn't be breaking any existing functionality in the Android version the unofficial FreeTubeAndroid fork by using an Electron API for them and secondly the Android WebView has a navigation history API, which is slightly more powerful, WebBackForwardList which can be obtained by calling copyBackForwardList() on the WebView that could be used to implement the dropdowns on Android.

[kommunarr]

Not sure if I understand the suggestion in full - use the Electron NavigationHistory class for the dropdown logic, right? Or is it that + use an Electron context menu instead of the ft-icon-button dropdown?

[absidue]

Although a context menu is probably a lot easier to implement, there is some merit to using the icon button drop down, as it matches the style of the rest of the app. The only thing that we need to look out for, is that we only display the dropdowns in Electron and that outside of Electron they just act like back and forward buttons with no extra functionality (just like before this pull request) to avoid the user getting confused by things breaking, because the Electron API isn't available.

[github-actions]

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