Dahan Gong comments

Results 737 comments of


                                            Dahan Gong

When grouped tabs get in the way of other tabs

> _previousTab_ and _nextTab_'s default action to ignore the collapsed groups (blue arrow); > New commands or parameters to consider groups (red arrow); Got > like _collapseGroup_, _renameGroup_, or _shiftGroups_...

When grouped tabs get in the way of other tabs

> ignore the collapsed groups Sad - the "collapsed" status requires Chrome's "tabGroups" permission and new V3 format. I can not work around it.

When grouped tabs get in the way of other tabs

But there's no way to call "Ctrl+Tab"...

When grouped tabs get in the way of other tabs

I mean Vimium C can not "tell Chrome to run Ctrl+Tab", while it can only call `chrome.tabs.update(tabId, { active: true })` to select another tab... What're your `mapkey` lines?

When grouped tabs get in the way of other tabs

Then Shift+F should work if you has `map createTab` (or another command)

When grouped tabs get in the way of other tabs

> as if I pressed _f11_ and then into fullscreen No, `mapKey` can not affect how your browser handles the first key. It just let Vimium C treat a first...

When grouped tabs get in the way of other tabs

1. There's neither API to trigger "tab-level" fullscreen, nor API to get the window status (size) before entering fullscreen. 2. There's no API to let browser work "just as it...

When grouped tabs get in the way of other tabs

If you need such behavior, then AutoHotKey may help. On macOS and Linux there're also some similar system-level tools.

When grouped tabs get in the way of other tabs

`Tab::groupId` can be read, so `moveTab` has just been updated to keep a tab in its group. Others are impossible.

When grouped tabs get in the way of other tabs

Reopened because this issue will be fixed, and is a necessary task in Manifest V3.