# Glide is a Firefox fork where the keyboard and a TypeScript config do the work > Glide is an extensible, keyboard-focused web browser built on Firefox, with modal keymaps, a TypeScript configuration file, web extension support and a fuzzy tab manager. It suits people who want their browsing environment to be a program they edit, and it is not a browser for everyone. **glide-browser/glide** — An extensible and keyboard-focused web browser - Repository: https://github.com/glide-browser/glide - Website: https://glide-browser.app - Stars: 1,506 · Forks: 48 - Language: TypeScript - License: MPL-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/glide-browser-glide ## A browser whose main surface is a keybinding Glide describes itself in one line as an extensible and keyboard-focused web browser built on Firefox. Everything else in the feature list follows from that choice. The first item is navigation with the keyboard alone, and the second is modal based keymaps. Modal means the keyboard has modes, so a prefix key switches the browser into a different set of bindings, the way a text editor does. The documentation site separates hints, keys, config and cookbook into their own pages, and the cookbook entry points at overriding a keymap for a specific website as well as setting a preference for one site. That site-specific layer is what makes the model more than a novelty: the same key does different things on a search engine and on a code host, without you having to think about which site you are on. A fuzzy tab manager sits alongside, and the hint in the feature list gives the invocation as two space presses. Fuzzy matching over open tabs is the feature that converts a keyboard-first browser from a demonstration into something you would keep, because tab switching is where pointer-driven browsers spend a surprising amount of a working day. The claim to a wide audience is not made. This is a browser for people who already want this, and the documentation, not the browser, is the product's front door. ## TypeScript as the configuration language The configuration surface is written in TypeScript, and that is the most unusual decision in the project. Settings are not a JSON file with a schema, and they are not a preferences UI. They are code, which means they can be typed, versioned, diffed and reviewed like any other source file in a repository. The repository layout supports that reading. There is a src directory holding the browser code, a configs directory, a scripts directory with TypeScript scripts written in .mts files, and several tsconfig files, one of them named tsconfig.check.json and another tsconfig.bundled.json for the bundled output. The tooling around it is a modern TypeScript stack: dprint for formatting, oxlint with a plugin file at the root, a pnpm workspace with a lock file, and a Python side managed by uv with a pyproject.toml and a uv.lock. The Firefox build uses Mozilla's own mach tooling rather than a bespoke build system. The scripts include a bootstrap step, a mach bootstrap variant, a dev runner, a build and a package step, and a launch command of mach run with cache purging: ```json "bootstrap": "tsn scripts/bootstrap.mts", "bootstrap:mach": "mach bootstrap --application-choice=browser", "build": "tsn scripts/firefox/build.mts", "package": "tsn scripts/firefox/package.mts", "launch": "mach run --purgecaches", ``` The presence of mach bootstrap and mach run means the working environment is a Mozilla checkout rather than a fresh npm install. The practical consequence is that contributing to Glide means working inside Firefox's own build conventions, which is a large amount of tooling to learn for a patch set of any size. ## Firefox as a substrate, patched and re-exported Glide is a fork, and the repository shows it. There is a patches directory, a firefox.json file at the top level, an infra directory, and a set of scripts dedicated to fetching and patching the upstream browser: ```json "export": "tsn scripts/firefox/export.mts", "firefox:export": "tsn scripts/firefox/export.mts", "firefox:patch": "tsn scripts/firefox/patch.mts", "firefox:download": "tsn scripts/firefox/download.mts", "firefox:version": "tsn scripts/firefox/version.mts", ``` Export, download, patch and version are the four verbs of the relationship with upstream, and they describe a workflow rather than a one-off import. The browser is downloaded, the patch set is applied to it, the result is built and packaged, and the version can be read off. A patches directory checked into the repository means the difference between Glide and Firefox is reviewable as a diff, which is the property that makes a fork maintainable at all. There is also a licence check in the same family of scripts, with a fix variant: ```json "check:license": "tsn scripts/firefox/license-check.mts", "fix:license": "tsn scripts/firefox/license-check.mts --fix", ``` That is a more interesting detail than it first appears. In a fork that vendors upstream source, the licence headers of the imported files are a genuine maintenance obligation, and having a tool that checks and repairs them means the project can absorb upstream changes without leaving licence notices inconsistent. The build also produces a bundle, which is a separate script from the build itself, suggesting that the distributable artifact is assembled from more than the compiled browser output. ## Extensions, the Gemini protocol and the fuzzy tab manager Glide keeps the two features that make Firefox distinctive, and adds its own on top. Web extensions API support is listed as a feature, and this is the part that makes Glide a browser rather than a shell. The extension ecosystem is large, and for a keyboard-driven browser the extensions provide what the core does not: a password manager, a translation tool, a reader mode. Support is described in the documentation as an API support item, which reads as a deliberate promise to keep the Firefox extension interfaces working rather than a partial port. The Gemini protocol is supported, which is a protocol choice that only makes sense for people who read the web closely enough to want a small, text-based, non-JavaScript alternative. A browser shipping Gemini support is making a statement about which readers it wants. The fuzzy tab manager is invoked with two space presses. The description is short, and the design intent is legible: the most frequent navigation in a browser is not typing a URL but returning to a tab you already have, and a modal keymap makes that a two-key operation with a fuzzy matcher rather than a hunt through a tab strip. What the feature list does not say is where these features stop. The README is a page of links to the documentation site, with hints, keys, config, extensions, cookbook and Gemini each getting their own page, and it does not describe any of them in detail here. A reader gets the shape of the project and has to go to the documentation for the substance. ## A 0.1.x version line, a documentation site and a busy main branch The version numbers tell their own story. The published releases are 0.1.64a on 2026-09-06, 0.1.63a on 2026-06-28 and 0.1.62a on 2026-05-24, so the browser is pre-1.0 and the suffix moves with each build. The root package.json reads 1.0.0, which is the version of the package manifest for the extension and tool sources, not of the shipped browser. The last push to the repository was on 2026-10-16, so work is happening on the branch faster than releases are being cut. That gap is expected in a fork whose releases depend on tracking an upstream, but it does mean the built binaries and the source can differ. A user who wants a specific behaviour should check the release list against the branch history rather than assuming the newest commit is what the download contains. Documentation is treated as part of the product, not an afterthought. The build scripts include a whole family of documentation targets, covering HTML output, an API reference, asset hashing and a production build, plus a separate dev script for the docs site and an index step that runs pagefind against the built site. The site itself is served from the same repository, and the top-level entries include a dprint configuration, a flake.nix and flake.lock, a zizmor configuration for the CI workflows, a .python-version file and an .envrc, which describes a development environment pinned across several tools at once. The CI itself is sponsored. The README credits Depot for sponsoring Glide's CI, and the repository has separate workflow files for Linux, macOS and Windows, which is the minimum for a browser that has to build on all three. ## MPL-2.0, and what a fork inherits Glide is licensed under the Mozilla Public License Version 2.0, with the licence file at the root of the repository and the README pointing at it for details. MPL-2.0 is a file-level copyleft licence, which suits a browser fork: modifications to a covered file must be published under the same licence, while larger works that merely link against it are not forced into the same terms. That choice has a direct consequence for a fork of a browser. Mozilla made the same choice for Firefox for the same reason, and Glide inherits the arrangement. A downstream user who takes the Glide source and modifies covered files owes the source of those modifications, and a distributor who ships a binary built from those files carries the obligation to offer the corresponding source. That is a real consideration for anyone embedding the work in a product rather than running it for themselves, and it is a question about the licence text rather than a legal opinion. There is a related point about what the licence does not settle. Glide is a patch set on Mozilla's browser, and Firefox itself ships with a stack of third-party licences covering the code it incorporates. The repository's own licence check script exists precisely because imported files carry their own notices, and the LICENSE file at the root covers the project content rather than the upstream tree it downloads and patches. For a contributor the practical advice is short: read the licence file, and if the change is large enough to matter commercially, read it again with someone qualified to advise on it. ## Conclusion Glide suits a keyboard user who wants their browser configured in a typed file rather than through a settings dialog, and who is willing to maintain that file as Firefox underneath it changes. It is the wrong tool for someone who wants a polished consumer browser out of the box, and for a team that cannot accept that the browser is a patch set on a moving upstream. Before you adopt it, read the configuration and keymap documentation at glide-browser.app, check the release list, where the newest published build is 0.1.64a from 2026-09-06, and confirm that the MPL-2.0 licence at the repository root covers the parts of the tree you intend to modify and redistribute. ## FAQ ### What is Glide and what is it built on? Glide is an extensible, keyboard-focused web browser built on Firefox. The repository works with Mozilla's mach tooling and keeps its changes to the upstream browser as a patch set in a patches directory. ### How is Glide configured? In TypeScript. The configuration surface is code rather than a settings dialog, and the repository also carries site specific settings and keymap overrides so a key or a preference can differ per website. ### How do I open tabs quickly in Glide? The fuzzy tab manager is invoked with two space presses, and it matches tabs fuzzily rather than listing them in order. The project also uses modal based keymaps, so prefixes switch the active binding set. ### Can Glide use web browser extensions? Yes, web extensions API support is listed among the features, and the documentation has its own extensions page. The Gemini protocol is supported as well. ### What licence is Glide released under? The Mozilla Public License Version 2.0, with the licence file in the repository root. The project also ships a licence check script for the Firefox files it patches, since imported files carry their own notices. ## Sources - [glide-browser/glide on GitHub](https://github.com/glide-browser/glide) - [License: MPL-2.0](https://github.com/glide-browser/glide/blob/main/LICENSE) - [Project website](https://glide-browser.app) - [README](https://github.com/glide-browser/glide/blob/main/README.md) - [Releases](https://github.com/glide-browser/glide/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/glide-browser-glide