-
Notifications
You must be signed in to change notification settings - Fork 818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigation history dropdowns #5227
base: development
Are you sure you want to change the base?
Conversation
It doesn't feel like web browser UX:
|
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 |
…xt show even when disabled
a81cadf
to
22a1365
Compare
This is more of a pre-existing problem with certain themes like Dark not having a visually distinctive
I think you're on an older version. I fixed this in an earlier commit. That also added the |
With checkmark it seems better |
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 |
All issues resolved, pending idea from others especially on mobile |
I had no idea there was a 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. |
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 The
Note that the above implementation would be easier & improved if these properties were to be exposed to developers:
Because of that, it may be reasonable to wait on the |
@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. |
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.
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. |
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. |
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
They are already exposed to developers on 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, |
Not sure if I understand the suggestion in full - use the Electron |
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. |
Pull request was converted to draft
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Navigation history dropdowns
Pull Request Type
Related issue
closes #2740
Description
route.meta.title
- see "Work for a future PR" below). The history entry dropdown presentation behaviors are taken from FF:@contextmenu.prevent=''
is set on the navigation arrows to prevent the context menu appearing on right-click in dev mode.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.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.top-nav-is-colored
mixin intop-nav.scss
unfortunately is not compatible with the use of:deep
, a selector which is required forft-icon-button
s to actually work styling-wise in the top nav with the legacy non-icon-button-but-almostnavIcon
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:
ft-icon-button
, replaces themouseDownOnIcon
focusout
logic inft-icon-button
in favor of more straightforward logic (adopted from List sorting & display settings #4231)topNav.historyForward
andtopNav.historyBackward
logic more straightforwardWork for a future PR
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 placeholderroute.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.pointerup
after on the corresponding history entry to navigate to it.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
I wouldn't recommend testing these ones for the sake of your time, but just to demonstrate that I have tested these:
focusout
/ Esc / keyboard navigation withft-icon-button
dropdowns still work as intendedMatch Top Bar with Main Color
setting activeDesktop