Yes, agreed, it’s an unfortunate bug with the implementation of the Ctrl+Tab cycling.
In my personal opinion, the code adding that feature should be backed out (removed) and ‘Tab Search’ (Ctrl+Shift+A) should be used instead, since it was introduced upstream. The UX is a bit different from the Ctrl+Tab UX of Firefox, but once you get used to it it’s fine.
I have been flamed for this opinion though. So YMMV.
Well, that’s how things work, ctrl (+shift) + tab is doing exactly what you do with ctrl+pageup/down in Brave, so enabling the option is going to change things, it’s the same funcitonality with a different shortcut.
That’s why Brave has to have ctrl+shift+pageup/down to retain going through the tabs in their proper order or something.
I understand that is why those things happen, however, it is a knock-on affect that caught me by surprise.
I believe that brave should have these two things separated, and that the browser should have better first-party support between keymaps and actions for accessibility purposes.
@JimB1 There’s a browser plugin that allows you to remap ctrl+pgup/ctrl+pgdn and it partially works with the setting enabled such that ctrl+tab cycle histories. It isn’t perfect perhaps due to how the history buffer is implemented but for the most part it works for retaining the “where was I at just then?” capability, while still getting to use my existing muscle memory. It would be a huge plus if this extension added history cycling shortcuts as well, if that feature is even exposed.
I’ve been thinking about it, the Ctrl+Shift+A tab search feature is handy but I never use it because the UX is so far out of the way; but that just makes me wonder: why doesn’t the urlbar with “open tabs” or “history” search function identical to the tab search feature when only those indexes are enabled? Surely I want to know if at least one of my tabs matches the given query, all the time?
Back when google introduced this “omnibar” scheme, they did it with the assurance that it wouldn’t cause any ambiguity (it did) and that they could write software to counteract any that it might (they didn’t) – and now we just have a copout hidden secondary search functionality effectively reintroducing a second (but hidden) search bar at the browser’s masthead chrome. We’ve gone in a circle!
I just tested it in Opera and you can set up different shortcuts for so many things:
Cycle forward through tabs
Cycle backward through tabs
Switch to last tab
Switch right through tabs
Switch left through tabs
Select previously active tab
So maybe maybe we should hope Brave will implement a full shortcuts customization like Opera does.
I mean, Opera has so many good things like they are the only ones that tell you if a flags is enabled or disabled by default, and they also let change shortcuts to whatever people want, maybe that would be a better way to fix/separate page up/down working exactly, and fix other shortcuts that for some reason were changes and now they don’t do stuff like Chrome says they should.
About the Search Tabs feature, maybe it would be nice to have a panel like Yandex to browse the tabs instead of being a menu like it is today.
But with Vertical tabs, they are bringing that Search Tabs popup to be in the vertical tabs, so if you use that, it would be closer if you want to use the mouse. Of course, when I press ctrl+shift+a I only use keyboard so I don’t really think it is a problem how far it is.
One thing I found useful about the search tabs and that you could enable the flag to let tabs playing audio show first than other tabs, Chromium 107 and Brave Nightly now has that by default, but I pretty much used it for that when random tabs decided to play audio. Of course you can’t do much with it, in Yandex you can search and mute tabs playing audio in the same panel.
But searching tabs with the address bar, well, there is a flag in Nightly brave://flags/#omnibox-site-search-starter-pack which adds shortcut @tabs to search engine with the brave://tabs/?q=%s value (also adds bookmarks and history) and then you can use address bar to also search tabs by using that. Not great but it is something, maybe a start.
That @tabs feature is actually available in the official build as well, and for anyone else’s sake, adding the searcher manually without adding the flag doesn’t work.
My major problem with the implementation of the omnibox search is that it requires extra keystrokes to narrow a search down to a particular site. I feel as though since we have all those searchers available we should be able to organize and rank them by priority we assign. (With an optional mode for auto-sorting based on usage counts.) This way we can weigh the engines without memorizing a bunch of short-codes. And with that, the tab search should have a great deal of priority as I mentioned before.
I really can’t emphasize enough though that the shortcuts should be a built-in feature. There have been times where I had to drop software over which hotkeys did a common UI operation I was accustomed to, so I can understand the motivation to simply have both do the same thing, because I don’t fare well in situations where Ctrl+Tab is the only way to move between things. I just think it’s time to revisit that decision.
So YMMV.