Opening a new tab is one of the most frequent things browser users do. In early Firefox (1.x, 2.x), the default new tab behavior was either a blank page or your homepage — with no granular control over which. If you wanted a new tab to open to something specific — a bookmarks page, a particular dashboard, or a custom start page — you needed an extension. TabHomePage was the straightforward solution.

Part of the Palancar extension suite hosted at palancar.net, TabHomePage let users configure exactly what URL (or about: page) loaded when they opened a new tab. It was a simple preference that Firefox didn’t expose directly, and for several years it was the standard way Firefox power users solved this problem.

What TabHomePage Was

TabHomePage added a preference pane to Firefox’s options that let users specify a URL for new tabs. The options were simple:

  • Blank page (the Firefox default)
  • Your homepage (whatever was set as the browser’s main homepage)
  • A specific URL — any URL the user chose, entered in a text field

When the user opened a new tab (Ctrl+T, or clicking the new tab button), Firefox would load the configured URL instead of showing the default blank or about:blank page.

The use cases were practical. In the mid-2000s, start pages were a real category of web product. My Yahoo, iGoogle, Netvibes, Protopage, and dozens of similar services offered personalized dashboard pages that users set as their default entry point. Configuring these as new-tab destinations rather than having to navigate to them manually was a meaningful convenience.

Power users also used TabHomePage to load frequently-used bookmarked sites, internal work tools (accessible via intranet URLs), or Firefox’s own about:bookmarks page. The extension also enabled about:sessionrestore as a new-tab target — useful for users who wanted to quickly access recently closed tabs from every new tab.

TabHomePage was listed on addons.mozilla.org, referenced in Firefox setup guides, and remained in regular use through Firefox 3.x. The palancar.net page received backlinks from Firefox tips sites and browser customization guides throughout this period.

How It Worked Technically

TabHomePage modified Firefox’s tab-opening behavior by overriding the browser.newtab.url preference — a hidden about:config setting that Firefox exposed internally but didn’t surface in its preferences UI.

In the XUL/XPCOM architecture, modifying browser preferences was done through the nsIPrefService XPCOM component:

// Simplified XUL extension approach
var prefs = Components.classes["@mozilla.org/preferences-service;1"]
            .getService(Components.interfaces.nsIPrefBranch);

// Set the new tab URL
prefs.setCharPref("browser.newtab.url", userConfiguredURL);

The extension also needed to override the actual tab-opening behavior to ensure the preference was read correctly when the new tab opened. This was done by overlaying the browser’s tabbrowser.xml binding and intercepting the openUILink call that Firefox made when opening a new tab.

Some versions of TabHomePage included the ability to set different pages for new windows versus new tabs — a distinction that became more meaningful as tabbed browsing became the dominant mode.

The XUL overlay system made this kind of deep browser preference modification straightforward. Extensions had essentially the same access to browser internals as Firefox’s own built-in code. This was powerful, but it also meant that poorly written extensions could easily conflict with each other or with Firefox updates — a persistent problem in the XUL era.

Historical XUL documentation from this period is preserved at web.archive.org.

The New Tab Page Evolution

The “new tab page” concept evolved significantly during TabHomePage’s active period and beyond, eventually becoming one of the most-competed-over pieces of browser real estate.

Firefox 13 (2012) introduced a native new-tab page showing thumbnails of recently visited sites, making the blank new-tab a thing of the past and directly exposing browser.newtab.url in the UI for the first time. This addressed the core need TabHomePage served.

Chrome’s new tab page, introduced with Chrome 1.0 in 2008, immediately set a high bar — the thumbnail grid format became the industry standard. Firefox’s native new-tab page (now called Firefox Home) has evolved continuously since.

The extension ecosystem fragmented. As browsers added native new tab pages, a different category of extension emerged: replacements for the browser’s own new tab page with more features — weather widgets, clocks, to-do lists, news feeds, and custom wallpapers. This was a different product category from TabHomePage’s simple URL redirect.

Firefox 41 (2015) locked down new tab URL changes as a security measure — requiring extensions to use the browser.newtabpage.url API rather than directly modifying preferences. This was aimed at malware that hijacked new tabs by force-setting the preference.

Why It Was Discontinued

TabHomePage faced the same XUL end-of-life that retired other Palancar extensions. Firefox Quantum (version 57, November 2017) removed XUL/XPCOM support, and the extension wasn’t updated for the WebExtensions API.

Additionally, by 2017, the use case was well-handled natively. Firefox had exposed new tab URL configuration through its settings UI, and the remaining users who wanted sophisticated new tab pages had migrated to purpose-built WebExtension replacements with features far beyond what TabHomePage provided.

The simple problem TabHomePage solved — “I want my new tab to open to this URL” — was now a first-class browser setting.

What Replaced It

Browser native settings. All current browsers include new tab URL configuration in their settings:

  • Firefox: Settings → Home → New Windows and Tabs → Custom URLs
  • Chrome: Settings → On startup → Open a specific page or set of pages (also controls new tabs in many configurations)
  • Edge: Settings → New tab page — offers full configurability including custom URLs

Firefox also maintains the browser.newtabpage.url about:config entry for users who prefer direct preference editing.

Current WebExtension new-tab replacements:

For users who want more than a URL redirect, the modern extension ecosystem offers extensive new-tab customization:

  • New Tab Override — direct URL configuration for new tabs, the closest functional equivalent to TabHomePage
  • Tabliss — customizable new tab with widgets, backgrounds, and focus tools
  • Momentum — productivity-focused new tab with daily goals, weather, and focus timers
  • nightTab — highly configurable new tab with speed dial, bookmarks, and theming

For intranet/internal pages. If your use case is loading a specific work tool or intranet URL in new tabs, Firefox’s native “Custom URL” option under Home settings handles this directly without any extension required.

If You’re Building Something Similar Today

WebExtensions can replace the new tab page using the chrome_url_overrides manifest key:

{
  "manifest_version": 2,
  "name": "Custom New Tab",
  "version": "1.0",
  "chrome_url_overrides": {
    "newtab": "newtab.html"
  }
}

This completely replaces the browser’s new tab page with your extension’s own HTML page. From newtab.html, you can redirect to an external URL or build whatever UI you want directly.

For a simple URL redirect, newtab.html can be minimal:

<!DOCTYPE html>
<html>
<head>
<script>
const userURL = 'https://your-configured-url.com';
window.location.replace(userURL);
</script>
</head>
</html>

For storing the user’s configured URL, browser.storage.sync is recommended over storage.local so it syncs across the user’s Firefox devices.

Note that only one extension can override the new tab page at a time. If the user has another extension that replaces the new tab, there will be a conflict. Firefox handles this by applying whichever extension was most recently granted the override permission.

The newtabpage override documentation at developer.mozilla.org covers the full API with cross-browser compatibility notes.

Simple Solutions That Last

TabHomePage is a good example of an extension that solved a small, precise problem and did it well. It didn’t try to replace the browser’s new tab experience with something elaborate — it just gave you the preference that the browser had internally but hadn’t exposed.

When Firefox eventually exposed that preference natively, TabHomePage’s job was done. That’s a healthy lifecycle for a browser extension: exist while the browser lacks a feature, support its users well, and become unnecessary when the browser catches up. Not every extension needs to grow into a platform.

The original TabHomePage extension page at palancar.net is preserved at web.archive.org.