Update: Sorry I didn't understand it well. I'll take a try and if it's possible, it may be added in Vimium C v1.76.2.

But I have to prompt you that goBack and goForward is not "globally usable" until Chrome 72, and never on Firefox - in order to do this on an extension's background process, there're two methods:

• since Chrome 72, there's chrome.tabs.goBack to do so
• before Chrome 71 (not including 71), chrome.tabs.update accepts "javascript:history.goBack",
  • but this requires Vimium C has access permissions to a target page, AND the page is not in a very begining stage of loading.

There have been 4: leftTab, rightTab, createTab, reloadTab, so if a page is broken, you may at least reload it or create a new tab to use Vimium C.

BTW, if you really need, I can add a new syntax for key mappings to re-map the 4 commands to some others.

Compared with #56, here're my some ideas:

• add 2 commands of goBack / goForward, and modify code in main.ts to make them independent of ports
  • this change could be ready on v1.76.2 / v1.76.3
• add 2 "custom" commands, and allow you to "re-map" them to some other commands as you like
  • before one "re-map"s it using shortcut customCommand1 command=nextTab ... in key mappings,
    it would act as a "blank" command.
• a real re-mapping will be checked to see if the command is in some limited commands
  • before this lands, only the current 4, the 2 new and "blank" are accepted.
  • this check will land before or on v1.77, and then you may re-map more commands.

If there're more needs than 4+2+2 global commands, let's discuss here again.

Added:

1. I'm sorry that I didn't know a user may specify more than 4 commands, which made us have different base assumptions.
2. there's a plan to implement vimium://toggle next, and it may take a global command name.
3. after thinking for a while, I think Vimium C should not "grab shortcuts like <c-*> in its InsertMode" using its content scripts

• if <c-w> is needed to hook, then it must be done through the feature of global commands, to get highest priority we can get
• some web pages have their own online rich editor, and they may have provided many useful commands like advnaced copying and pasting, and by default Vimium C should make these unknown commands work well.
  • for example, on this page, GitHub's editbox supports <c-b> to add Markdown's "blod" marks.

Well, the roadmap looks promising! Custom commands are definitely a great idea, because you can assign multiple shortcuts to a single command.
But I just spent a few minutes looking through my list of global commands and assigned a few more: <C-n> nextTab, <C-p> previousTab, <M-w> switchFocus. I want them to be global, i.e. have highest prority! That's especially important for switchFocus, it just doesn't work if you do a regular map and I don't want to reach for the F2 key.
So there's already more than 2, and I haven't yet spent a few hours to remap everything.
I don't think there's any point in making the amount of "custom commands" less than total amount of

limited commands

I think it should be at least 1:1 or maaybe 1:1.5 so we can assign every available custom command to a shortcut, and still have some space to make use of "assigning multiple shortcuts to a single command".

Will it be OKay if I creates a new extension to hold such tons of global mappings, and make it forward all command requests to Vimium C?

Sure, whatever works 👍
I just want to make all commands not related to page content global, such as manipulating tabs. Because It hurts my workflow when they fail to trigger on chrome:// or .jpg, .svg, etc. pages.

BTW, thank you for the awesome work on this extension!

EDIT: Seems like it works on .jpg and .svg pages but not on data:image/png;base64,

data: and about: have some different permissions, compared with http:// and ftp:// , and Vimium C is not allowed to run content scripts on "top level frames of about:*" and "top frame and iframes of data:".

I've created a base version of "many customized shortcuts", and 3rd-party extensions may use chrome.runtime.sendMessage("ext-id-of-vimium-c", {handler: "shortcut", shortcut: "userCustomized***"}) to Vimium C to run commands.

Current limits:

• for 3rd-party extensions, it's only allowed to send a shortcut name like "userCustomized***" and "nextTab"
  • its extension id MUST BE in the extension whitelist on Vimium C options page
• shortcuts can only be configured in "Custom key mappings" on Vimium C options page
  • the syntax is shortcut userCustomized*** command="goBack" other-options=...
  • all shortcut names except those in Vimium C's manifest.json must start with "userCustomized"
• for unknown (not configured) shortcut names, Vimium C does nothing.
• for customized ones, "command" option is necessary
• for those like "createTab" shortcut names, the "command" option is optional
  • if the option exists, it will override the default shortcut name
  • so that there're already 8 shortcuts for users to customize

v1.76.2 has been released with basic support for shortcuts named "userCustomized*", so you may write another extension to declare as many shortcuts as you like ^_^

Update: v1.76.2 is being reviewed by WebStore and has a serious bug, so I'll replace it with v1.76.3 today.

Works like a charm!
Thank you.

Oh well, moveTabLeft and moveTabRight don't work on chrome:// and data: tabs ;-(
Probably many others too...

Um, sorry I forgot a tip: currently if you want to trigger "any background command", you need to execute localStorage.acceptAllShortcuts = true on Vimium C Options page and then reload the background page (or reload the whole extension).

When I add more safety checks, then this hidden option might be removed (in months?) .

Update: this limitation will be removed in v1.77 .

I've published a new extension: https://chrome.google.com/webstore/detail/shortcut-forwarding-tool/clnalilglegcjmlgenoppklmfppddien . Although it will work well with Vimium C v1.77+, you may take a try with Vimium C v1.76.3 - it should still work then (please ignore some errors on its options page).