FlowMouse turns mouse movement into browser navigation

A gesture extension that started from a broken forum login

The story behind FlowMouse is in the README and it explains the design better than any feature list. The author was a long time user of a commercial mouse gesture extension, CrxMouse, and liked what it did for productivity, but disliked one thing about it: it kept requesting advanced feature permissions, which really meant access to browsing history, and the author never agreed. Then a CrxMouse update broke things on a forum, where users could not log in, could not rate posts, and pages stopped redirecting after replying. The author traced the cause to a JavaScript snippet the extension injected, other users reported the same problems thinking the site itself was broken, and it turned out to affect all forums running that forum software. The author expected a quick fix, waited over a month with two updates passing, and started looking for alternatives, finding very few similar extensions on the market and none that met the needs. So the author built one. That origin explains the two things that define the project. The permissions question is why the extension exists at all, and the compatibility question is why it is built around the gesture vocabulary of a browser that does this natively.

What the feature list actually promises

The README describes FlowMouse as an open source mouse gesture extension designed for ultimate smoothness, where you swipe your fingertips and enter the flow, with the goal of helping you enter a focused and productive state. The feature list then breaks that into concrete things. There are 16 built-in gestures plus unlimited custom ones you define yourself. Super drag covers dragging text to search with custom engines supported, dragging images to open, save or reverse search, and dragging links to open or copy. Wheel gestures let you hold the right mouse button and scroll to switch tabs quickly. Rocker gestures hold one mouse button and click the other to go back and forward. Area select is Shift and drag to select links on the page and open or copy them in batch. Command chains run multiple actions from a single gesture. Visual settings cover the gesture trail colour, width and action hints. And there is an interactive tutorial on first install. The two mouse button gestures are the interesting ones, because they are the cases where a browser extension can do something the page cannot intercept. A wheel gesture that opens the context menu is the page's business, but a chord that means back or forward is an input the page never sees, and the same goes for a drag that starts on a link.

Sixteen defaults, and the ones that overlap

The default gesture table is the most useful thing in the README for someone deciding whether to install, because the mapping is a design decision you either like or you do not. The directions are given as arrows, and the actions are the everyday browser ones. Left arrow is back and right arrow is forward, so the horizontal pair carries history. Up and down scroll the page, so the vertical pair carries movement. The diagonals carry everything else. Up-left switches to the left tab and up-right switches to the right tab, so the two diagonals that share the up direction handle tab switching. Right-up opens a new tab and right-down reloads the current page. Down-left stops loading and down-right closes the current tab. Up-down scrolls to the bottom and down-up scrolls to the top. Left-up reopens a closed tab and left-down closes all tabs. And the last row has left-right closing the current tab and right-left reopening a closed tab. Read that last row carefully, because it puts close tab and reopen closed tab on two different diagonals while also listing reopen closed tab on left-up, so three of the sixteen defaults touch tab closing in some form. The table also carries an asymmetry you will feel, since up-left and left-up are different gestures with different meanings. All of this is editable in the options page, and the author says so plainly, but the defaults are what your fingers will learn in the first week.

Installing it on Chrome, Edge or Firefox, and from a release

There is no build step to describe here, because the project ships as a browser extension rather than as a library, and the README's install section is a table of three stores: Chrome from the Chrome Web Store, Microsoft Edge from the Edge add-ons listing, and Firefox from the Mozilla Add-ons site. The homepage of the project points at the Chrome Web Store entry, and the README badges link the Chrome Web Store, the Mozilla Add-on and the GitHub release. For people who do not want a store account, the README says you can also download from GitHub Releases for manual installation. The repository listing shows what a manual install consists of, with a manifest.json at the root, then js/, css/, icons/, pages/ and _locales/ directories, plus a THIRD_PARTY_LICENSES.md file. The _locales/ directory is the localisation layer the browser uses for the extension's own strings, and pages/ holds the extension's own pages, which is where the options page and the tutorial live. The repository is not archived, its last push was on 2026-09-29, and the release list shows v2.5 on 2026-09-29, v2.4.1 on 2026-09-16 and v2.4 on 2026-09-07, so the extension is being released on a short cycle with the change history in a CHANGELOG.md and a separate CHANGELOG.zh_CN.md.

The privacy claim is a design constraint, not a slogan

The privacy section is short and it is the reason the project exists, so it is worth reading precisely. FlowMouse does not collect any browsing history, bookmarks or usage habits. It does not contain any analytics or advertising code. And it does not upload any local data to third party servers. The extension is open source, the code is hosted on GitHub and open to review and contribution, which is the mechanism that makes the three claims checkable rather than merely stated. Settings are stored locally through the browser's own storage API, and there is one honest caveat about sync. If browser sync is enabled, in Chrome Sync or Firefox Sync, the settings are encrypted and synced across your signed in devices by the browser, and that process is entirely controlled by the browser and follows the browser's own privacy and sync settings. So the data never leaves the device except through a channel the user has already turned on for everything else, and the extension does not get a say in it. This is the direct answer to the CrxMouse problem, since the author's objection was to an extension asking for advanced permissions in exchange for gestures.

Where a JavaScript gesture trail will always be behind a native one

The author says this plainly in the story section, and it is the honest limit of the approach. Beyond the core gestures used daily, the remaining gestures were modelled after Edge's built-in gesture set, and the reason is that the smoothness and compatibility of Edge's native gestures is admired, and that compared to drawing trails with JavaScript, native support is in a different league. The technical reason is not hard to reconstruct. A native gesture is recognised before the page is involved, so it works on pages that swallow mouse events, on embedded viewers, inside canvas applications and on sites that rebuild their own pointer handling. An extension that watches for a movement pattern has to infer intent from a stream of events, has to decide when a drag has ended, and has to draw a trail so the user can see what the extension thinks is happening. That is why the visual settings matter more here than in a native implementation, with the trail colour and width configurable so the gesture is legible, and why the action hints exist. The trade is equally plain. A native implementation cannot be extended by a community the way an extension can, and it cannot be installed on a browser that does not ship it, whereas FlowMouse works on the three stores listed and its gestures can be remapped to fit a specific workflow.

Editorial conclusion

FlowMouse suits a browser user who has moved to gestures for navigation and wants the same convenience without an extension that asks for history access, and who is willing to learn the gesture set rather than expect the mouse to behave like a trackpad. It is the wrong tool if your work depends on a specific gesture vocabulary you already have, since all sixteen defaults can be changed but the defaults themselves are the author's design, and the wrong tool if you need gesture support in a browser the extension does not cover. Before you install it, read the default gesture table, because the mapping includes both close tab and reopen closed tab gestures on more than one direction, and check what your browser's own native gestures already do, because the author says the remaining gestures were modelled after Edge's built-in set and that native support is a different league from drawing trails with JavaScript.

Frequently asked questions

Official sources

1. Hmily-LCG/FlowMouse on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases