Improve new tab page experience for Vimium users

[philc]

Hey folks, I thought now would be a good time to check in on the state of new tab pages in browser extensions and discuss what Vimium should do.

Summary: the browsers' new tab experience has gotten more constrained and less Vimium-friendly with time: the address bar always has the keyboard focus on new tabs; new tab extensions can't redirect to file URLs in Firefox; there isn't a UI for setting which extension controls the new tab page in Chrome. We should consider what solutions we can implement in Vimium to improve the UX.

Research notes on the browser new tab UX

• The browsers I tested on were Chrome 138.0 and Firefox 141.1, on Mac.
• For my own usage, I've used @smblott-github's new tab extension for a decade to redirect my new tab page to a blank html file hosted on disk. Chrome's address bar did not get focused. Vimium has access to file:// URLs and so I could open the Vomnibar on this local page. This stopped working in a recent version of Chrome, possibly as part of their final rollout of disabling manifest V2 extensions. @smblott-github's extension can be updated to use the chrome.tabs.update API which will allow it to redirect to a file URL (in Chrome, but not in Firefox!), but the address bar will be focused each time a new tab is opened, which isn't a good UX.
• Using the new tab API for extensions ("chrome_url_overrides" in manifest.json) always gives focus to the address bar
  • Neither the extension, nor the page being loaded, can programmatically take focus from the browser's address bar. Presumably this is to provide a consistent experience for users that can't be mangled by extensions.
  • To give focus to the page, the user can type ESC once, or tab several times, or use the mouse.
  • It would be nice to see some authoritative discussion on the Chromium issue tracker about why this UX decision was taken and how permanent it is, because it's pivotal and greatly constrains the options for which path Vimium should take. I couldn't find such an issue.
    • Here's Firefox's Bugzilla bug about this.
  • Workarounds:
    • Use document.location.href
      • In Chrome (but not in Firefox), changing the URL of a new tab page via document.location will take focus away from the address bar.
    • Use an interstitial tab
      • The new tab page provided by the extension can open yet another new tab, and close the previous new tab. The second opened tab will not have the focus in the address bar.
      • This causes visual flicker in the tab bar, but in my testing the flicker was fairly minimal, especially if the intermediate page and the final page look identical.
      • This is implemented by the newtaboverride extension, here
      • I would think this approach would leave the temporary tab in the new tab history which is undesirable, but at least in Chrome, the first tab didn't show up when reopening closed tabs. Apparently it does in Firefox; see this issue
• Survey of capabilities for new tab extensions, and how they relate to Vimium
  • Redirecting to file:// URLs as the new tab page
    • Extensions cannot set document.location.href to a file:// URL, even if they've been given the "allow access to file URLs" permission in the extension settings.
    • Chrome will allow an extension to navigate to a file if using chrome.tabs.update(). However, this does not work in Firefox and fails with the error "Illegal URL: ..."
  • Redirect to an extension page packaged within the extension
    • Vimium cannot run on pages hosted by other extensions.
  • Redirect to a page hosted on the web
    • Vimium can run on such pages.
    • But this requires an internet connection and introduces lag. If the page takes a second to load, Vimium won't have loaded yet, and the vomnibar shortcut will do nothing. One expects to be able to type immediately after opening a new tab.
    • As a workaround, a "blank page" site could be hosed on the web, with offline support implemented via a service worker, so after it's fetched once, there is no latency on subsequent fetches because it's fully cached by the browser and available offline. This page could be hosted on vimium.github.io.
  • What happens when multiple extensions want to control the new tab page
    • If the user has multiple extensions which want to control the new tab page, in Chrome, generally the last one installed wins.
    • The first time a user opens a new tab, Chrome and Firefox will prompt the user as to whether they want the extension to take over their new tab page. If they decline, I believe the extension remains enabled, but doesn't get invoked when a new tab is opened.
    • In Firefox, there is a nice UI in about:settings which lets you pick which of multiple extensions you want to control your new tab experience. Chrome doesn't have this UI. Here are two old Chromium bugs (one, two) related to this.
    • This UX confusion is one of the reasons why we've never changed Vimium to request to control the new tab page. (The other reason is that we can't unfocus the address bar).

Ideas to improve the situation for Vimium users

Because any extension (including Vimium) that uses the chrome_url_overrides feature will have the address bar retain focus, that path is a non-starter unless Chrome and Firefox decide to change this UX.

Vimium has a new tab page experience via the createTab command, bound to t. It will open a new tab by default to about:blank, which will resolve to the browser's default new tab page or the new tab page of an extension that's overriding the default new tab page. The URL of the new tab that Vimium opens is configurable in Vimium's settings; it can be set to "pages/blank.html" which will open a blank page that Vimium has permissions to run on and which is available offline.

What's lacking with Vimium's t shortcut is that the browser's Cmd-T new tab shortcut works on every tab, even ones where Vimium is not allowed to run (like chrome:// URLs), where Vimium is disabled by the user (e.g. often on docs.google.com, gmail.com), or when Vimium is in insert mode.

As a result, I've always preferred Cmd-T rather than Vimium's t shortcut.

Approaches we can take

• (1) Use a global Vimium new tab command instead of browser's new tab commands
  • We would add a "createTab" global extension command for Vimium.
  • This allows one to open a tab where the Vomnibar and other Vimium commands can be run, even on pages where the Vimium extension is disabled. It will have the same effect as calling Vimium's "createTab" command. This will use the chrome.commands API.
  • This has the advantage that we're entirely opting-out of Chrome's new tab UX, and hopefully can avoid future UX evolution related to the new tab page.
  • I don't like that this creates two ways to open a Vimium tab (via the global command, and via the t keybinding); it's confusing.
  • Can we bind Vimium's "new tab" command to cmd or ctrl-T?
    • No; the browsers don't let extensions override shortcuts which are already used by the browser.
    • On Mac, Vimium's new tab command can be bound to Cmd-T in Chrome if Chrome's default keybinding for New Tab is assigned to some other hotkey. This can be done in the System Settings app in Keyboard > Keyboard Shortcuts > App Shortcuts. This trick does not work in Firefox because Firefox does not integrate with Mac's keyboard shortcut remapping; see this bug.
  • Update: on MacOS, if all Chrome windows are closed, but the app is still open and activated, then no extension commands bound to shortcuts will work. When typing an extension shortcut, the system issues a "blip" sound. Chrome's native commands, like "open a new window", still work. Once a window is opened, then the extension's commands work again. I couldn't find a Chromium bug which documents whether this is intended. Because of this limitation, Vimium can't entirely replace Chrome's "new window" command; it's a pretty broken UX. Firefox has the same behaviors.
    • To explore a workaround to this, in the new-tab branch, I've added a command "replace current tab with Vimium's new tab page." This is useful for getting off of any Chrome-controlled page (e.g. chrome://extensions) and back to the Vimium new tab page. I've bound this to Cmd-H. The workflow is: use Chrome's default new window / new incognito window shortcuts, and when the new window is opened, switch to Vimium's new tab page by hitting Cmd-H. It works, but it's not perfect: if the address bar is focused when navigating to the new tab page (as it is right after opening a new window), then it will remain focused. Typing ESC once will unfocus the address bar and put the focus in the Vimium new tab page.
• (2) Have Vimium override the new tab page
  • This leverages the browser's "approved pathway" for replacing the new tab page and so is less likely to break in the future.
  • The drawback is that the Chrome UI for controlling which extension handles the new tab page is not good. Most extensions that take over the new tab page have that as their main feature, so it's expected to happen once you install the extension. This is not the case with Vimium. Handling the new tab page is not Vimium's headliner feature, and many would want to use Vimium without disrupting overriding their new tab experience.
• (3) Have a companion extension override the new tab page
  • This would be a second extension that users would have to install if they want to have Vimium control their new tab page. It would be called "Vimium New Tab Page".
  • It would redirect to a page hosted on the web by setting document.location.
  • In Chrome, keyboard focus will be on the new tab page. In Firefox, it will be in the address bar, and the user will have to type "ESC" once to give the page keyboard focus.

Related discussions

• Vimium on new-tab page #1515
• Make Vimium work on the New Tab Page #531
• [Solved] Use a file:///*.html page as new tab on Firefox gdh1995/vimium-c#980

Feedback

I've prototyped approach (1) in this branch, and I'm using it in Chrome with the Mac keyboard shortcut remapping trick (i.e. Vimium creates a new tab in Chrome when Cmd-T is pressed).

I'd love feedback and discussion on these areas:

• Validation or invalidation of the new tab experience you're currently using in Chrome or Firefox.
• Thoughts on the what the general new tab experience should be, given the constraints.
• Are people happy using Chrome's address bar for navigation, and so this new tab issue isn't a big problem? I prefer using the Vomnibar for its keyboard ergonomics, but I don't know how many people actually use Vomnibar over the address bar.

[fldc]

First of all, great extension! I’m a new user coming from Tridactyl and Firefox, and this was the first thing I started Googling trying this extension out. I’m finding this behavior much better. In a perfect world, I’d never see the Chrome address bar at all, consistency is key. I hope you decide to go this route.

Here’s a 3 file extension you should look at @philc for help with this project!

😃 https://github.com/BachoSeven/startpage/tree/master/ext

I found the link here hiding in a comment by @BachoSeven here in this repo!

😉 #3598 (comment)

I am using this little extension and it works perfectly to open a new tab page to my local html file via file:/// protocol, and the omnibar is not focused on page load.

After ctrl-t the page has focus, and I can instantly use Vimium!

This is the magic line, coupled with “host_permissions”: [ "file:///*" ], in manifest.json:

😄 https://github.com/BachoSeven/startpage/blob/master/ext/r.js#L11

Here is the documentation (sparse as it is) for why it works:

• https://issues.chromium.org/issues/40693812#comment27
• https://issues.chromium.org/issues/40660393

[philc]

See #4795 for the implementation.