qutebrowser/qutebrowser

A keyboard-driven, vim-like browser based on Python and Qt.

qutebrowser

A keyboard-driven, vim-like browser based on Python and Qt.

website | blog | FAQ | contributing | releases | installing

qutebrowser is a keyboard-focused browser with a minimal GUI. It’s based on Python and Qt and free software, licensed under the GPL.

It was inspired by other browsers/addons like dwb and Vimperator/Pentadactyl.

qutebrowser’s primary maintainer, The-Compiler, is currently working part-time on qutebrowser, funded by donations. To sustain this for a long time, your help is needed! See the GitHub Sponsors page or alternative donation methods for more information. Depending on your sign-up date and how long you keep a certain level, you can get qutebrowser t-shirts, stickers and more!

Screenshots

Downloads

See the github releases page for available downloads and the INSTALL file for detailed instructions on how to get qutebrowser running on various platforms.

Documentation and getting help

Please see the help page for available documentation pages and support channels.

Contributions / Bugs

You want to contribute to qutebrowser? Awesome! Please read the contribution guidelines for details and useful hints.

If you found a bug or have a feature request, you can report it in several ways:

• Use the built-in :report command or the automatic crash dialog.

• Open an issue in the Github issue tracker.

• Write a mail to the mailinglist at [email protected].

Please report security bugs to [email protected] (or if GPG encryption is desired, contact [email protected] with GPG ID 0x916EB0C8FD55A072).

Alternatively, report a vulnerability via GitHub’s private reporting feature.

Requirements

The following software and libraries are required to run qutebrowser:

• Python 3.8 or newer

• Qt, either 6.2.0 or newer, or 5.15.0 or newer, with the following modules:

  • QtCore / qtbase

  • QtQuick (part of qtbase or qtdeclarative in some distributions)

  • QtSQL (part of qtbase in some distributions)

  • QtDBus (part of qtbase in some distributions; note that a connection to DBus at runtime is optional)

  • QtOpenGL

  • QtWebEngine (if using Qt 5, 5.15.2 or newer), or

  • alternatively QtWebKit (5.212) - This is not recommended due to known security issues in QtWebKit, you most likely want to use qutebrowser with the default QtWebEngine backend (based on Chromium) instead. Quoting the QtWebKit releases page: [The latest QtWebKit] release is based on [an] old WebKit revision with known unpatched vulnerabilities. Please use it carefully and avoid visiting untrusted websites and using it for transmission of sensitive data.

• PyQt 6.2.2 or newer (Qt 6) or 5.15.0 or newer (Qt 5)

• jinja2

• PyYAML

On Python 3.8, the following backport is also required:

• importlib_resources

On macOS, the following libraries are also required:

• pyobjc-core and pyobjc-framework-Cocoa

The following libraries are optional:

• adblock (for improved adblocking using ABP syntax)

• pygments for syntax highlighting with :view-source on QtWebKit, or when using :view-source --pygments with the (default) QtWebEngine backend.

• On Windows, colorama for colored log output.

• asciidoc to generate the documentation for the :help command, when using the git repository (rather than a release).

See the documentation for directions on how to install qutebrowser and its dependencies.

Donating

qutebrowser’s primary maintainer, The-Compiler, is currently working part-time on qutebrowser, funded by donations. To sustain this for a long time, your help is needed! See the GitHub Sponsors page for more information. Depending on your sign-up date and how long you keep a certain level, you can get qutebrowser t-shirts, stickers and more!

GitHub Sponsors allows for one-time donations (using the buttons next to "Select a tier") as well as custom amounts. For currencies other than Euro or Swiss Francs, this is the preferred donation method. GitHub uses Stripe to accept payment via credit cards without any fees. Billing via PayPal is available as well, with less fees than a direct PayPal transaction.

Alternatively, the following donation methods are available — note that eligibility for swag (shirts/stickers/etc.) is handled on a case-by-case basis for those, please get in touch for details.

• Liberapay, which can handle payments via Credit Card, SEPA bank transfers, or Paypal. Payment fees are paid by me, but they are relatively low.

• SEPA bank transfer inside Europe (no fees):

  • Account holder: Florian Bruhin

  • Country: Switzerland

  • IBAN (EUR): CH13 0900 0000 9160 4094 6

  • IBAN (other): CH80 0900 0000 8711 8587 3

  • Bank: PostFinance AG, Mingerstrasse 20, 3030 Bern, Switzerland (BIC: POFICHBEXXX)

  • If you need any other information: Contact me at [email protected].

  • If possible, please consider yearly or semi-yearly donations, because of the additional overhead from many individual transactions for bookkeeping/tax purposes.

• PayPal: CHF, EUR, USD. Note: Fees can be very high (around 5-40%, depending on the donated amounts) - consider using GitHub Sponsors (credit card), Liberapay (credit cards, PayPal, or bank transfer) or SEPA bank transfers instead.

• Cryptocurrencies:

  • Bitcoin: bc1q3ptyw8hxrcfz6ucfgmglphfvhqpy8xr6k25p00

  • Bitcoin Cash: 1BnxUbnJ5MrEPeh5nuUMx83tbiRAvqJV3N

  • Ethereum: 0x10c2425856F7a8799EBCaac4943026803b1089c6

  • Litecoin: MDt3YQciuCh6QyFmr8TiWNxB94PVzbnPm2

  • Others: Please get in touch, I’d happily set up anything supported by Ledger Live

Sponsors

Thanks a lot to MacStadium for supporting qutebrowser with a free hosted Mac Mini via their Open Source Project.

(They don’t require including this here - I’ve just been very happy with their offer, and without them, no macOS releases or tests would exist)

Thanks to the HSR Hochschule für Technik Rapperswil, which made it possible to work on qutebrowser extensions as a student research project.

Authors

qutebrowser’s primary author is Florian Bruhin (The Compiler), but qutebrowser wouldn’t be what it is without the help of hundreds of contributors!

Additionally, the following people have contributed graphics:

• Jad/yelo (new icon)

• WOFall (original icon)

• regines (key binding cheatsheet)

Also, thanks to everyone who contributed to one of qutebrowser’s crowdfunding campaigns!

Similar projects

Various projects with a similar goal like qutebrowser exist. Many of them were inspirations for qutebrowser in some way, thanks for that!

Active

• vimb (C, GTK+ with WebKit2)

• luakit (C/Lua, GTK+ with WebKit2)

• Nyxt browser (formerly "Next browser", Lisp, Emacs-like but also offers Vim bindings, QtWebEngine or GTK+/WebKit2 - note there was a critical remote code execution in 2019 which was handled quite badly)

• Vieb (JavaScript, Electron)

• surf (C, GTK+ with WebKit1/WebKit2)

• wyeb (C, GTK+ with WebKit2)

• Chrome/Chromium addons: Vimium

• Firefox addons (based on WebExtensions): Tridactyl, Vimium-FF

• Addons for Firefox and Chrome: Surfingkeys (somewhat sketchy…​), Link Hints (hinting only), Vimmatic

Inactive

• dwb (C, GTK+ with WebKit1, unmaintained - main inspiration for qutebrowser)

• webmacs (Python, Emacs-like with QtWebEngine, unmaintained)

• vimprobable (C, GTK+ with WebKit1)

• jumanji (C, GTK+ with WebKit1)

• conkeror (Javascript, Emacs-like, XULRunner/Gecko)

• uzbl (C, GTK+ with WebKit1/WebKit2)

• xombrero (C, GTK+ with WebKit1)

• Cream Browser (C, GTK+ with WebKit1)

• Firefox addons (not based on WebExtensions or no recent activity): Vimperator, Pentadactyl, VimFx (seems to offer a hack to run on modern Firefox releases), QuantumVim, Vim Vixen (ESR only), VVimpulation, Krabby

• Chrome/Chromium addons: ViChrome, Vrome, Saka Key (unmaintained), cVim, vb4c (fork of cVim, unmaintained), GleeBox

• Addons for Safari: Vimari

License

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/gpl-3.0.txt.

pdf.js

qutebrowser optionally uses pdf.js to display PDF files in the browser. Windows releases come with a bundled pdf.js.

pdf.js is distributed under the terms of the Apache License. You can find a copy of the license in qutebrowser/3rdparty/pdfjs/LICENSE (in the Windows release or after running scripts/dev/update_3rdparty.py), or online here.

qutebrowser's Issues

Bookmarks

We should have bookmarks or improved bookmarks. This means:

• No name, or a default generated one (from URL/title).
• Possibly a hierarchy

Missing dwb keybindings

This is a meta-issue to keep track of dwb keybindings which aren't in qutebrowser yet - mostly because the features are missing at the moment.

tab-handling

[n]xd
Lock tab [n]. Locking a tab will lock this tab to the current domain, it’s not possible to navigate to another domain until unlocked. lock_domain, aliases: dlock).

[n]xu
Lock tab [n]. Locking a tab will lock this tab to the current uri, it’s not possible to navigate to another uri until unlocked. lock_uri, aliases: ulock).

Blacklisting

CC
Allow persistent cookie for the current website. The domain will be saved in cookies.allow. Cookies that are allowed by the cookies.allow whitelist are stored in $XDG_CONFIG_HOME/dwb/$profilename/cookies. (command allow_cookie, aliases: cookie).

CS
Allow session cookie for the current website. The domain will be saved in cookies_session.allow. This is only useful if cookies-store-policy is set to never, see cookies-store-policy for details. (command allow_session_cookie, aliases: scookie).

CT
Allow session cookies for the current website temporarily. Only first party cookies are allowed. The domain is not saved to a whitelist and the cookies will not be saved persitently. (command allow_session_cookie_tmp, aliases: tcookie).

Show

Sk
Show keys (command show_keys, aliases: skeys).

eu
Show and execute userscripts (command execute_userscript).

Sd
Show download (command show_downloads, aliases: sdownloads).

Other

W
Next navigation action will be opened in a new window (command new_win).

[n]gc
Clear tab n or of current tab, clears the history of the tab and loads about:blank. (command clear_tab, aliases: clear).

c/
Find forward, ignore case (command find_forward_ic, alias: iffind).

c?
Find backward, ignore case (command find_backward_ic, alias ibfind).

gZZ
Save current session with name and exit (command save_named_session, aliases: wqn).

gs
Add a searchengine. Textfields can be chosen with tab and a keyword must be specified. The first defined searchengine will be the default searchengine. The keyword can be used in all open commands, e.g. :open (command save_search_field, aliases: search).

C-p
Toggle proxy (command proxy).

V
Next navigation action will be opened in a new tab (command new_tab).

g.
Toggle hidden files when browsing local filesystem. (command open_editor, aliases: editor).

F12
Toggle presentation mode. (command presentation_mode, aliases: present).

xv
Toggle visibility of a tab. (command visible, aliases: vis).

Completion for quickmarks

The completion should complete quickmarks.

uMatrix

There should be something like uMatrix / RequestPolicy / ContentBlockHelper.

Invalid paths shouldn't kill downloads

When the user enters an invalid path, they should be re-asked instead of cancelling the download immediately.

Option "ask" for network->ssl-strict

The ssl-strict setting should have an option ask which uses the statusbar to ask the user if they want to proceed. This should be the default.

Note the user should only be asked once if there are subsequent SSL errors for the same host. The users decision also should be saved somewhere, but we'll do that with per-domain settings when they are ready.

Easy way to show all keybindings

There should be a command or page to show keybindings, to get an easy overview.

Sane default for editor

We should have some sane default (rather than vim) for general -> editor.

Some ideas:

• Use QDesktopServices to decide.
• Maybe there's some XDG tool.
• notepad.exe on Windows
• Some other default editor on Mac
• List of editors to try?
• $EDITOR and $VISUAL probably won't work as they aren't GUI editors typically

utils.debug.qenum_key is broken

In some cases, qenum_key and qflags_key don't really return the expected values.

Show keybinding for commands in command completion

We could use the "misc" column in the command completion model to show the configured keybindings.
The idea was suggested by konubinix on IRC.

This might be more difficult now that we have arguments for commands, but it'd still be possible to at least show some overview.

Add command which closes other tabs in a direction

We already have :only, but egan on IRC suggested a command to close all tabs to the left or to the right of the current one.

debug command to change ramhandler capacity

A :debug-capacity 1000 would be useful to tell people when they report a crash which needs some more backlog.

More completions

More things should be supported for the completion, for example:

• URLs (history)
• Flags for commands
• Choices for commands
• Choices for flags with arguments (#1532)
• Userscript in userscript paths with :spawn --userscript (#1543)
• Keys for :bind
• Existing bindings for :unbind
• Commands for :bind, aliases, etc.
• Tabs (with a :buffer command)
• Tabs in current window for :tab-focus
• Aliased commands
• Commands after ;;
• File paths for download, etc. (done for :open via #6038)
• Closed tabs for :undo
• back/forward history for :back/:forward (#1561)
• Search engine names (PR at #2191, after SQL completion)
• Search engine results/suggestions? - split off to #6049
• Saving and suggesting prior search terms after specifying a search engine in :open (e.g. after :open -t gmaps new york, the completion after :open -t gmaps would suggest that).
• Downloads for download-{open,delete,remove,retry}
• Commands from command history
• Existing quickmark names when saving a quickmark
• Elements for list/dict settings
• Anchors for :scroll-to-anchor
• Available fonts for font settings
• Commands and their arguments with :later / :repeat / :run-with-count (see comment below)
• Arguments for :hint

Internationalization / translations

If there are people willing to translate, maybe support for i18n should be added.

Set as default browser

There should be an easy cross-platform way to set qutebrowser as the default system browser.

Implementation:

• There's xdg-mime for some distros, but there's also xdg-settings, not sure what's the difference. Archwiki says xdg-mime, but xdg-settings set default-web-browser sounds good as well.
• Debian uses sensible-browser and their update-alternative stuff.
• There are some places suggesting KDE does something different as well.
• On Windows you have to edit like 10 registry keys - which ones depend on what version of Windows (though we probably should drop <= XP support)
• No idea about OS X

User interface:

A new command would be over the top, and adding a setting is confusing as well. Probably just a commandline argument, and maybe a hidden command.

• Windows
• OS X
• Linux

Change search engine syntax

The current searchterm[ !engine] syntax is bad because it (for example) doesn't allow DuckDuckGo hashbangs.

We probably should use dwb's [engine ]searchterm syntax instead.

History

There should be a global (rather than per-tab) history.

For v0.1 we probably only will record history (to help with crashes etc.), but somewhen later we also should have completion in there.

Improve -m error message inside qutebrowser dir

We currently output an error message when the user didn't start qutebrowser as a module (via python -m).

However if python -m qutebrowser is executed inside the qutebrowser/ dir, the same error message is displayed, which might be confusing. Maybe we can check __file__ or so to tell them apart?

Also, we probably could use Tk to display a simple GUI error message.

debug command to change loglevel

A :debug-loglevel {debug,info,...} would be handy sometimes.

Ability to toggle settings

Some ideas:

• :set --cycle to cycle setting between multiple values - for example, you could bind a key to :set --cycle tabs position right top.
• Maybe also some special PREVIOUS value which goes back to the previous state.
• bool settings toggleable with :set sect opt!
• When saving last state (see bullet 2) we could also toggle between "false-value" and "last truth-y value" for settings which are nearly boolean (several true but one false state)

Files are in wrong places

There are some files in the config directory which would belong in the data directory.

~/.config/qutebrowser/state should be in the data directory instead.

Also, if QStandardPaths gives us the same path for data/config/cache, we should create subdirectories (e.g. on Windows).

Better Content-Disposition support

We should support some optional stuff from the RFC6266 testcases, e.g. setting file date/time, or giving a filename with inline.

Downloads should remember last path

If the user has set an absolute path for a download, the next time when the prompt shows, the same path should be pre-filled.

Sessions

There should be support for named sessions (session: URLs for all tabs and their tab-history).

User interface:

• Argument -s/--save to :quit (aliased to :wq) which saves as the default session.
• Optional argument to save under a session name.
• Commandline argument to select a session.

Ideally we'd like to save session files in a good plain text format, but unfortunately Qt makes this very hard - QWebHistory only has binary serialisation (with <</>>), but no way to load history from plain text. There was a patch against QtWebKit which added functionality to do that, but it was rejected by upstream because "the binary format should suffice".

Other ideas to work around the binary format:

• Use python's struct module to read the binary format - this is rather fragile though, and looking at the Qt sources it seems rather complicated.
• Reimplement the history ourselves - this probably has its own problems, as it'll be rather hard to catch all link navigations (e.g. via javascript). QWebHistoryInterface also won't help because that's global, not per tab.

Maybe some other browser has some approach I didn't consider yet?

zoom with ctrl + mousewheel

Private browsing not honoured everywhere

There is currently a general -> private-browsing setting, but the setting is just passed to webkit.

We should make sure we don't forget to handle it somewhere (cache, cookies, etc.)

Modular rendering engine support

We want support for QWebEngineView and maybe QGraphicsWebView (to fix performance issues on Github) at some point.

Because of that, we should split out WebView in a way so it's modular enough to be replaced, and define an interface.

Handle exception with open() calls

All open(...) calls could raise certain exceptions (e.g. permission errors).

Currently none of these are handled.

quit confirmation

There should be a confirmation on quit in some scenarios:

• There are still downloads running.
• There are unsubmitted form fields.

Auto-save open tabs

A list of open tabs should be auto-saved from time to time to recover when there's a segfault in Qt.
When sessions are implemented this should also work per session.
The same thing should also work for things like the config.

autocmds (expose signals and call userscripts on them)

It'd be cool to be able to call userscripts from certain signals (e.g. load finished).

From IRC:

konubinix The-Compiler: Do you plan to add event support like uzbl does ?
konubinix It allows to launch a command when something happen
konubinix IIRC, it is the way they handle history, the event LOAD_FINISH triggers history.sh that records history
The-Compiler konubinix: something like?
konubinix The design is really simple, you associate some scripts to be launched at specific events like LOAD_FINISH, AUTHENTICATE or GEOMETRY_CHANGED
konubinix The script is launched with some environment variables indicating the context (like the current URI)
The-Compiler hmm, I like the idea
konubinix This allows the user to provide his own hooks on the events
The-Compiler I won't handle stuff in scripts only (like, I want to have a built-in history, etc.), but it'd be a nice way so user could write simple extensions in any language
The-Compiler s/user/users/
konubinix :-)
konubinix For the complete example of the handling of the history in uzbl
konubinix In the config file, there is "@on_event LOAD_FINISH spawn @scripts_dir/history.sh"
konubinix Indicating to launch history.sh whenever the LOAD_FINISH event happens
konubinix And history.sh is only one line of code
konubinix echo "$( date +'%Y-%m-%d %H:%M:%S' ) $UZBL_URI $UZBL_TITLE" >> "$UZBL_HISTORY_FILE"
konubinix This is utterly awesome!
konubinix Hum... in my opinion
The-Compiler konubinix: as said, I like the idea, but I still want everything which is useful in a browser built-in - but still, the hooks sound nice :)
konubinix The-Compiler: Yeah I understand
konubinix The-Compiler: Will the built-in be able to be disabled though? So that I would be replaced by the hook
The-Compiler konubinix: hmm, maybe

Logo

qutebrowser still needs a logo!

Some random ideas:

• qutebrowser in some "cute" (fur?) font
• A q which is composed of a globe (because browsers need a globe) and a snake "hanging" around it. Ideally with either the snake or the globe being cute. 😁

Widget size issues with long URL in status bar

With a long URL, typing in the commandline should reduce the space the URL gets.

(Also suggested by invalido in IRC)

website

We should have some basic webpage for qutebrowser (see dwb/luakit/etc.)

Validate full command (with arguments) in config

Manpage

The manpage probably needs some love (and reviewing according to manpage standards) before v0.1

First run page

There should be a "first run" website with some guidance before qutebrowser gets too popular

Add `CACHEDIR.TAG` to cache

A CACHEDIR.TAG should be added to qutebrowser's cache directory.

See http://www.brynosaurus.com/cachedir/spec.html

abort() in ModeManager eventfilter

@smalltock reported http://paste.the-compiler.org/view/2c5a23ce

qutebrowser 861933c
Qt: 5.3.1
runtime: 5.3.2
SIP: 4.16.3
PyQt: 5.3.2
Archlinux

faulthandler log:

Fatal Python error: Aborted

Thread 0x00007fe28f2c6700 (most recent call first):
  File "/usr/lib/python3.4/site-packages/qutebrowser/keyinput/modeman.py", line 314 in eventFilter
  File "/usr/lib/python3.4/site-packages/qutebrowser/qutebrowser.py", line 115 in main
  File "/usr/bin/qutebrowser", line 9 in <module>

Context:

 297     def eventFilter(self, obj, event):
...
 308         if self.mode() is None:
 309             # We got events before mode is set, so just pass them through.
 310             return False
 311         typ = event.type()
 312         if typ not in [QEvent.KeyPress, QEvent.KeyRelease]:
 313             # We're not interested in non-key-events so we pass them through.
 314             return False

He said he was idling on some page, don't know which one yet.

Per domain settings

For all settings where this makes sense, the setting should be configurable per domain (or probably even protocol/domain/port triple).

This will make a lot of things easier:

• NoScript is essentially done then
• RequestPolicy is a lot easier
• etc.

Proper debug log

The debug log should be a real widget, with capabilities like filtering (instead of HTML).

Extension (plugin) support

There should be support for writing plugins which are more complex than the simple (non-js) userscripts. Python plugins are the way to go.

FAQ

What's the current state of this issue?

September 2018: I'm working on this as a student research project. The main focus is designing a clean plugin API which can then be used to move internal qutebrowser parts to "plugins". As soon as this work is done (late 2018), the next step is gradually opening up the plugin API to third-party plugins.

March 2019: The research project went quite well (paper), but also was quite academic - not that much time was actually spent on implementation. As a result, there's now an initial extension API used internally in qutebrowser, but it's far from finished and not open to third-party extensions yet.

I likely won't have much time to continue working on extensions until my bachelor thesis is finished in mid-June (see the announcement mail for details), but after that I plan to launch another crowdfunding focused on long-term donations (Patreon/OpenCollective). This should allow me to work 2-3 days per week on qutebrowser for a longer time, primarly focused on finishing extensions.

September 2019: See this announcement mail for a longer recap of how the research project went. I finished my Bachelor thesis and had my final exams in late August. This means my studies are now finished and I finally have more time for qutebrowser on my hands again. Like outlined in that announcement mail, I'm now employed around 16h/week, while I plan to spend the rest of the time on qutebrowser and some freelancing work. At the moment, I'm planning the next crowdfunding campaign (also see the related survey) and getting things set up. After things are rolling, there are some things which are currently more urgent than plugin support: Making sure things continue to work with the latest Qt 5.13/5.14 versions and taking care of a lot of contributions. Once that backlog is down and some other work I started is finished, I finally plan to get back to extension support again, this time with enough resources to get things to a working state!

October 2019: See the recent roadmap mail for more details on what's going on in qutebrowser development - this definitely isn't forgotten, there are just some more important things to look at first. I also launched the next crowdfunding which will allow me to work on qutebrowser part-time (without having to write a research paper this time 😆) and hopefully accelerate things a lot.

How can I get updates?

Subscribe to this issue. You might also want to subscribe to the qutebrowser-plugins repository and the qutebrowser-hsr-sa repository where the related university documentation will land (also check the releases if you're curious).

What about JavaScript plugins / WebExtensions?

Support for WebExtensions is currently out-of-scope for qutebrowser. It's hard to even evaluate to which extend support for them would be possible, but if possible, it's going to be a lot of work. Partial support for often used plugin APIs (i.e. some WebExtensions) might happen some day, but currently it's too early to say if/when. The main focus is on a Python plugin API right now. Related QtWebEngine issues which might make this easier: QTBUG-51185, QTBUG-61676.

Also, a Python plugin API will allow for more freedom, since we treat plugins as trusted code.

Why don't you just allow people to inject Python code into qutebrowser?

Firefox had the issue of having a plugin API which tightly integrates with its internals, and had to drop it because it made further Firefox development harder, and bigger changes impossible. Also, every Firefox update broke a lot of plugins. This is not what I want things to end up like with qutebrowser.

In theory, you can do some things via a config.py file, like done in the qutenyan project. However, this is entirely unsupported and discouraged.

Do you call them plugins or extensions?

They used to be called plugins - however, since that term is often used to refer to NPAPI/PPAPI plugins (like Flash) in the context of web browsers, they were later renamed to extensions.

Plugin ideas

• uMatrix: #28
• More sophisticated adblocking: #29 (host-blacklist based adblocking is implemented in qutebrowser's core)
• HTTPS everywhere: #335
• Ghostery/Disconnect
• Certificate Patrol
• (random) user agent switcher
• Mouse gestures (can be done via easystroke to some degree)
• Remove google redirects
• Integration with LanguageTool
• Filling forms (e.g. password management with KeePassX/gnome keyring/passwordstore/... - as in #180, also form filling as in #695)
• HoverZoom
• speed dial
• periodic auto-reload
• detailed page loading bar (like otter/opera)
• automatically spawn mpv on video pages
• Find video URLs on a page, like Media Sniffer or Video DownloadHelper
• copy URLs of all pages or write them to a file
• DownThemAll
• Google Cloud Print (devguide)
• Rewriting URLs to their .onion equivalents based on a list
• Chromecast integration? (#1319)
• autoscroll
• decentraleyes
• URL rewriting like PureURL for Firefox (removing things like utm_foo)
• Open certain links (like youtube) in a handler application automatically instead of following it
• Adding a "real" address bar
• Adding a bookmarks bar
• Yanking a short URL (e.g. youtube has a shortlink ref for youtu.be links)
• Restarting failed downloads after a timeout (with bad internet connection)
• alternative stylesheet selector
• A way to show md5/sha/etc. for downloads or even enter the correct one.
• Plasma Shell browser integration (#3996)
• Exposing the plugin API as an RPC interface usable from other languages
• Integrating Wallabag or other bookmark managers
• Back/Forward by domain instead of page
• Controlling Spotify/Youtube via MPRIS: #5023
• Middle-click scrolling (like on Windows), also see #7215
• Noiszy (Background tab creating "browsing noise")
• also see existing dwb userscripts
  • Arch wiki
  • tlvince/dwb-userscripts
  • dwb-extensions on GoogleCode
  • built-in extensions
  • dwb-extensions repo
• Hooking into notifications
• Showing the current mode in something like i3bar
• Prompting for redirects (?), see #4534
• TabFS
• Mouse navigation similar to keynav, see #6169

Abilities that plugins should have

• Interact with the WebElements on the page (e.g. make non-clickable links clickable) - or maybe only do this via JS, e.g. Linkify.
• Add widgets to the statusbar. (e.g. RSS or search engine symbol)
• Register new commands (with capital letter, like vim)
• Register new settings (in a special [plugin.foo] section probably)
• Subscribe to Qt signals (QWebPage/QWebView)
• Add new completions, e.g. with an external bookmark manager like cym13/bookmark
• Create widget-tabs when #724 is done, so someone could theoretically write an RSS reader or mail client or whatever
• Adjust page content, like Detox (and many others)
• Maybe make it possible to interact with the command input so that adding www. and .com to an URL like in #1749 would be possible.
• Maybe bind keys with prefixes, e.g. g# with any number
• Use acceptNavigationRequest, e.g. to automatically open mpv if a YouTube link is opened.
• Custom URL schemes
  • IPFS (#1314)
  • Gopher (#321)
  • dat
  • FTP for QtWebKit (#235)
• Custom completions (see #3376)
• There might be some more ideas in https://omar.website/tabfs/, as a power user focused interface to the web
• provide custom hinting logic (some ideas in #674)
• Cloudflare Privacy Pass (#7945)
• Provide custom format strings for commands and tab/window titles, and replace/modify existing format strings (eg a possible solution to #7685)

Libraries

• Yapsy
• straight.plugin
• stevedore
• pluggy
• PluginBase
• A simple plugin framework
• Plug n' play
• anki.hooks
• pike

Resources

• Fundamental concepts of plugin infrastructures
• The little manual of API design
• Python API checklist
• http://sedimental.org/plugin_systems.html
• Initial WebExtension support in Epiphany

Javascript plugins

• Javascript: QJSEngine
• PyV8 would probably work as well for javascript extensions (and maybe be easier/more pythonic), but it's another dependency and a different javascript engine.

It's probably not possible to directly use QtWebEngine's JavaScript engine, as that's tightly connected to QWebEnginePage actually showing a website.

Possible API inspirations

• WebExtensions API in Chrome/Opera/(soon) Firefox
  • Mozilla Wiki
  • Chromium docs
  • Opera docs
• splinter driver API
• dwb's javascript API
• Spyder IDE:
  • https://github.com/spyder-ide/spyder/blob/master/spyder/api/plugins.py
  • https://github.com/spyder-ide/spyder/blob/master/spyder/otherplugins.py
  • https://github.com/spyder-ide/spyder/tree/master/spyder/plugins
  • https://github.com/spyder-ide/spyder/wiki/User-plugins
  • https://github.com/spyder-ide/spyder/wiki/Writing-Plugins
  • https://github.com/spyder-ide/spyder-plugin-cookiecutter

Other interesting links

• ghacks-user.js and its wiki for privacy related features.
• Another user.js, dito.

First ideas

Separate namespace for plugins

There should be a new qutebrowser.pluginapi namespace. Everything outside of that namespace is to be considered to be "private" for plugins, and will likely break at some point.

Only some stuff (like possibly utils.urlutils) will be exposed directly - everything else will be exposed through a wrapper, for various reasons:

• I can change stuff without breaking plugins, if I update the wrappers accordingly.
• The wrappers will be easier to expose to a javascript plugin API
• They will be less complex than the qutebrowser internals, so it should be easier to get started

If something is missing from the wrappers, it should be trivial for a plugin author to open a feature request to have it added - this should be encouraged in the docs.

Qt signal based workflow

I don't think using something like pluggy will be neccessary (especially because pluggy is still expected to undergo changes, and is not packaged).

Instead of that, there's a simple function (say, plugin_init) which gets called when a plugin is loaded. The plugin gets a PluginContext object with some version information and a signals attribute.

The signals object then has many signals (perhaps also in sub-objects), like started, cmd.entered, etc. etc. Such a signals object also exists per-tab and per-window. The plugin will get the window-specific object with a global new_window signal (and something similar for new tabs).

Those events/signals are the main entry point for plugins. There will also be APIs for certain tasks (like adding an icon to the statusbar), but the majority of tasks should be possible using those signals.

For most actions, an API to call commands nicely (i.e. as functions rather than as strings) would probably already suffice.

Exposing plugin signals to userscripts

This is related to #902 - the signals mentioned above should be written to userscript FIFOs so those can react on the events - similar to herbstluftwm's hooks and herbstclient --idle.

This could possibly be implemented as a plugin by itself, which binds to all available signals - some layer to transform the signal arguments to strings will be needed either way.

A line written to the FIFO could look like this:

category sender signalname arg1 arg2 ...

• category: For extensibility - currently always signal
• sender: A dotted path of the sender of the signal, i.e. which signal object from above emitted the signal:
  • global: A global signal, like started
  • win0: A signal from the window with win ID 0
  • win0.tab1: A signal from the tab 1 in window 0
• signalname: A dotted path of the signal, e.g. started or cmd.entered, etc.
• arg1, arg2: Arguments which were passed to the signal, which need to be converted to a string in some way. Either there's a plugin which handles this argument for argument, or there's type-checking:
  • str: passed through
  • int, float: str() called on them
  • QUrl: url.toString() called on them
  • window objects -> win0
  • tab objects -> win0.tab1

Resources from BPL

resources

• http://www.se-radio.net/2008/07/episode-104-plugin-architectures/
• #30
• http://www4.in.tum.de/~blanchet/api-design.pdf
• http://eli.thegreenplace.net/2012/08/07/fundamental-concepts-of-plugin-infrastructures/
• http://martyalchin.com/2008/jan/10/simple-plugin-framework/
• https://www.sublimetext.com/docs/3/api_reference.html
• https://ep2015.europython.eu/conference/talks/the-hook-based-plugin-architecture-of-pytest
• https://www.sk89q.com/2010/03/a-first-class-extensible-python-plugin-framework/
• https://trac.edgewall.org/wiki/TracDev
• http://docs.openstack.org/developer/stevedore
• http://aroberge.blogspot.com.es/2008/12/plugins-part-1-application.html
• https://pymotw.com/2/abc/
• http://virtualplants.github.io/latest/dev/peps/pep_plugins.html

libraries & apps

• https://pypi.python.org/pypi/extensions
• https://www.riverbankcomputing.com/software/dip/download
• https://github.com/kovidgoyal/calibre
• http://yapsy.sourceforge.net/
• http://pluginbase.pocoo.org/
• https://github.com/benhoff/pluginmanager
• https://github.com/daltonmatos/plugnplay#readme
• https://github.com/ccoughlin/NDIToolbox
• https://github.com/dae/anki/
• https://github.com/ironfroggy/straight.plugin
• https://pypi.python.org/pypi/pluggy
• https://github.com/edgewall/trac
• https://github.com/HackEdit
• http://docs.enthought.com/envisage
• https://github.com/openstack/stevedore
• https://picard-docs.musicbrainz.org/en/appendices/plugins_api.html
• https://github.com/PyUtilib/pyutilib/ <----

cookies in netscape format

For some actions I'd be useful to have cookies in the standard netscape format:

• External download handler (e.g. wget)
• Userscripts

We don't really want to save them that way, but we should be able to export and maybe import it.

References:

http://www.cookiecentral.com/faq/#3.5
https://docs.python.org/3.4/library/http.cookies.html
http://qt-project.org/doc/qt-4.8/qnetworkcookie.html

Notes:

• Second column (flag): TRUE if domain starts with ., else FALSE
• if a cookie is a http-only cookie domain is prepended with a #HttpOnly_
• Python's http.cookiejar.MozillaCookieJar might help

Crash when closing tab on Windows

This is a reminder to myself - there was a crash when closing a tab on windows, I should take a closer look at that and probably do some longer tests on Linux.

More sophisticated adblocking

There should be an adblocker.

edit: A host-based adblocker which is sufficient for most cases is implemented since a long time already, this issue is still open because it could be improved by implementing ABP-like filterlist support.

The eric IDE helpviewer does have one (in Python), which might be a good inspiration

Open files from downloads

The user should be able to open files directly from qutebrowser (rather than downloading).

The associations should be made via QDesktopServices or overridden per mimetype.

Create XDG directories if they don't exist

As mentioned in the XDG basedir spec, the XDG directories (e.g. ~/.config, etc.) should be created (with the correct mode!) by qutebrowser if they don't exist.

Segfault when closing

We still have some segfaults when closing, usually with a corrupted stack trace:

#5  0x00007fffde97a700 in ?? ()
#6  0x00007ffff57573be in ?? () from /usr/lib/libQt5Core.so.5
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

There's an user who can reproduce it by letting qutebrowser run on duckduckgo for ~10 hours and then closing it with the "x"-button in his window manager.

Maybe a solution is to delete the QApplication object properly.

References:

http://python.6.x6.nabble.com/Application-crash-on-exit-under-Linux-td5067510.html
http://stackoverflow.com/questions/5506781/pyqt4-application-on-windows-is-crashing-on-exit
http://qt-project.org/forums/viewthread/27196
http://stackoverflow.com/questions/11945183/what-are-good-practices-for-avoiding-crashes-hangs-in-pyqt
https://github.com/Xinkai/XwareDesktop/issues/25

single-instance

After the multiwin branch is merged, there should be IPC to force running a single instance.
This avoids many problems (e.g. writing cookies, config files, etc.).

Sadly this also means the user won't be able to start a second instance which is likely to crash (maybe we should allow that when chosing a different data dir?).

Another solution would be a client-server model, with a server running which manages global state, and then "dumb" clients which all connect to the server, but this increases complexity a lot.

Useful links:
http://developer.nokia.com/community/wiki/Qt_IPC_using_QLocalSocket_%26_QLocalServer
https://www.mail-archive.com/[email protected]/msg22736.html
http://stackoverflow.com/a/8795563/2085149
http://nullege.com/codes/show/src%40n%40i%40ninja-ide2-2.1.1%40ninja_ide%40core%40ipc.py/20/PyQt4.QtNetwork.QLocalSocket/python
http://nullege.com/codes/show/src%40t%40a%40taurus-3.0.0%40lib%40taurus%40qt%40qtgui%40container%40taurusmainwindow.py/780/PyQt4.QtNetwork.QLocalSocket/python
http://nullege.com/codes/show/src%40h%40e%40Heliotrope-HEAD%40purple_server.py/95/PyQt4.QtNetwork.QLocalSocket/python
http://qt-project.org/doc/qt-4.8/qlocalserver.html
https://gitorious.org/qsingleapplication/qsingleapplication/source/ca13324b0f5bdfcaf4e379a78108f0bd85fed98a:qSingleApplication.py#L49
http://www.dallagnese.fr/en/computers-it/recette-python-qt4-qsingleapplication-pyside/
http://stackoverflow.com/questions/8786136/pyqt-how-to-detect-and-close-ui-if-its-already-running
http://stackoverflow.com/questions/12712360/qtsingleapplication-for-pyside-or-pyqt

Random notes:

• We use QLocalSocket to communicate with another instance
• TODO: find out why many apps just use QLocalSocket as a control channel, and shared memory for data.
• Max data size might be 8k, but this is enough for commandline args.

tab groups / tagging of tabs

For people with many tabs, it might make sense if they'd be able to tag/label them and filter them.