Version 1.0.0 was released today, check it out! This is definitely the best hackable browser out there. It combines QtWebEngine and Python, which are incredibly stable yet fast to develop in.
It's a great alternative to what's left of the Firefox genocide of extensions, where only VimFX and Saka Key exist.
> The systematic and planned extermination of an entire group.
Sure, technically it only applies to an ethnic/political/racial/etc group of humans, but it's not _that_ far-fetched to apply it to the systematic and planned extermination of an entire group of software (in this case Firefox add-ons).
i think maybe we should keep "genocide" reserved for people, or at least wait on applying it to software till we think that software might be sentient. linguistic inflation sort of sucks [0].
It has some negative connotations worth disagreeing with, though. I for one am pro-Webextensions (WE) because the legacy APIs gave all addons unlimited privileges and kept Firefox internals from improving. WE apis have come miles; even Tree Style Tabs has a WE alternative.
I am hopeful for Qutebrowser, though; the dev is working on an interesting approach to extending the browser without WE support by allowing "userscripts" (not the Greasemonkey-esque ones). They can be written in tons of different languages. [Relevant documentation](https://qutebrowser.org/doc/userscripts.html).
Exaggeration is very common to provide color to otherwise boring language. In this case, it personifies Firefox plugins to describe exactly what is happening to them, to avoid saying something like "makes them incompatible with future releases" which doeosn't do enough grace to represent the amount of work plugin developers have put into the these plugins to have them no longer supported.
I think the intent is clear, it’s the word choice which some may find tasteless.
For example, a person who survived an actual genocide may find your analogy to be shallow because where you’ve lost some extensions due to a browser upgrade, they’ve lost everyone they love due to them having been hacked to death with machetes, or gassed, or worked to death in forced labor camps.
I don’t know, maybe they just need to get over it?
If you or someone else took offense to my word choice because of having personal connections with genocides, and that the horrible concept is brought to their mind after reading my post, I would have happily changed it during the editable time to prevent others from having similar negative thoughts. However, I do not give a bit of concern to people who get offended for others and have no actual personal connection with the word and thus have no real negative thoughts. They are as privileged as I am for being able to say the word and not be bothered by the connotations.
By the same token, there exist many people who seek reasons to be offended. They will find offense no matter what you say. They will clamor in groups to be more outraged than the last. I try to disengage from those types of people.
I'm reluctant to use the term, but it applies. It's 'virtue signaling' and I presume it gives people an ego boost or a rush of endorphins. I doubt they really care, or have any true investment, they just want you to know they are morally superior and their peers to see them standing up for a cause, no matter how absurd.
My conclusion is, if you seek umbrage, you will find it.
A capacity for empathy, and a greater capacity for putting words in people's mouths. The assumed offense is what needs to be proven, not the lack of it.
I personally didn't take 'offence'. That would be objection in the domain of social manners, which was considered important in the Victorian era schools, but has somewhat dropped in esteem since.
My objection is in the domain of ethics, as I think taking genocide lightly is an ethical problem for all of us (that is, for humanity, which I take to include you).
> I am ... able to say the word and not be bothered by the connotations.
Rather off-topic question: aren't WebExtensions meant to work on all browsers? I don't see either Chrome extensions working with Firefox 57 or the reverse.
Some WebExtensions will work in all browsers. Other WebExtensions will only work in certain browsers that offer a capability that the extension needs. Kind of like webstandards have always worked.
For example, Opera and Firefox support the Sidebar API, which allows essentially arbitrary HTML pages to be placed in, you guessed it, a sidebar. Chrome does not support this, because they supposedly just don't want to have sidebars in their browser (it's not exactly an unsolvable task to implement).
Overall, Firefox will support the most extension APIs, but even there not all extensions will work, because there's always going to be some APIs that only make sense in one specific browser.
Lastly, it is necessary for the extension authors to port their extension. The work they have to do for porting might often be as minimal as just repackaging, testing and then uploading to the other browser's extension webpage, but they do have to do it.
So, this is going to cut off many extensions, too. If they're unmaintained, no one's going to port them. And Mozilla has much stricter policies for telemetry, ads etc. in extensions, too, so another chunk of extensions won't get ported for that reason.
If there is a specific Chrome extensions that you care for getting ported and it's unmaintained, then you can try it with Chrome Store Foxified [1], which will do the repackaging automatically. The testing you'll have to do yourself and then the fixing of potentially broken things and uploading, that depends on the license of the extension, if you're allowed to do that.
Firefox and Chromium will never support full keybinding-driven navigation. WebExtensions severely limits when keys can be captured, so there are many cases where they cannot be used: when the addressbar is focused, while pages are loading, etc.
Qutebrowser keybindings essentially have full control over the page at all times.
We're aiming to get Tridactyl to feature-equality with Vimium and Saka-Key by the end of this weekend. (We are runnable now, but it's not a fantastic UX)
We hope to match or exceed the current WebExtension state of the art (cVim) by the FF57 release date (Mid November).
Our longer-term roadmap depends on how responsive Mozilla are to our feature requests. They've suggested that our two most important API extensions could be merged in FF58 (Jan 2018? I forget), but we'll have to see.
If you don't want to run other WebExtensions or Firefox, Qutebrowser offers a really good solution :)
Saka Key seems to be using different keybindings than VimFx, Vimium, Vimperator, etc. For example, Saka Key uses `n` to open a new tab[1] whereas others use `t` to open a new tab. I am more used to the latter. So I decided to ignore this and try Vimium instead.
Vimium is good but one thing about Vimium annoys and I don't know a good workaround for it. If I create a new tab, the focus goes to address bar and then there is no convenient way to escape back to normal mode. I know this is a restriction due to the new webextensions. Anyone got any ideas to overcome this limitation?
Just wanted to mention, one of the unique features of Saka Key is that it lets you define keybinding profiles that are easy to switch between, and there are multiple profiles built in, including one that mimics Vimium.
The address bar autofocusing is annoying. Best advice I have is to replace your new tab page with a URL or a custom new tab extension.
Also, I devised the default keybindings with three goals in mind.
1. Common keys should be easy to reach.
2. Users unintentionally trigger dangerous commands (like close the current tab). To prevent this, I bind dangerous commands to 2 key sequences.
3. Users not being able to remember keybindings. To help users remember, I try to associate commands with an intuitive key, e.g. Zooming is mapped to z.
I've been using Vimium [1] for years now to browse the web (almost) entirely via the keyboard and couldn't live without it. It's incredibly easy to use once you become familiar with the shortcuts. You can even change the bindings to more closely match Emacs [2] if that's your editor of choice.
I also use Vimium and can't live without it, then switched to Qutebrowser which solved some issues that were always annoying me with Vimium, specifically:
1) Vimium key bindings don't work on the new tab page, and don't work until a web page finishes loading. The Qutebrowser key bindings are more first class and built in to the browser, so you can fully trust them to work all the time.
2) Qutebrowser is much better with webpages that also implement their own key bindings. There is pass-through mode which disables all Qutebrowser key bindings (except escape to leave pass-through mode) and lets the web page interpret all keystrokes.
Unfortunately I still keep the other browser around because of compatability, but I have much more hope that Qutebrowser will eventually render pages better rather than Chrome/Vimium ever getting a better interface.
Problem #1 can be fixed by making the Vimium blank page your newtab page.
Vimium comes with a blank .html file; IIRC it's what opens when you issue a command to open a new tab by pressing `t`.
I'm spending more time with FF 57 (it's really great for my needs) so I don't remember how you would set a URL for chrome//:newtab. I think you have to write an extension that redirects (with an inline script) to the Vimium blank page. I'm on mobile so I can't confirm that.
Unfortunately it seems that in WebExtensions, or at least Firefox and Chromium's current implementations of it, keybindings can only be captured by a plugin while a page is finished loading, and while the address bar is focused. There is also no way to do things like focus/defocus the addressbar, autohide the addressbar, autohide the tab bar, and many other small details that Qutebrowser effortlessly achieves.
Obviously a hack, and only addresses one of your points, but the following works pretty well if you wanna focus / defocus the address bar in chrome with a shortcut:
The workaround for 1) was already posted, but for 2), you can use Vimium's "insert mode" by pressing `i` to do the same thing. I use it regularly for Reddit with the enhancement suite.
Copy-pasting an answer I've given about Vimium earlier:
I've used Vimium for some months myself, and wasn't really happy with it. The reasons why mainly boil down to how Vimium is quite limited in what it can do. For example:
- It can't change the user interface at all - qutebrowser has a much more minimal UI.
- It can't spawn external processes. In qutebrowser, you can simply hit ctrl-e while editing some text input, to edit it in e.g. Vim. Or you can use :bind ,v spawn mpv {url} to add a keybinding which spawns mpv with the current page, to watch YouTube videos in a real video player.
- As soon as you are on some special page (like the Chrome extension store, or the "new tab" page), it stops working, because it can't intercept keypresses there. (yes, I've read the other answers about that now)
- In general, qutebrowser is much more configurable and extensible. You can easily integrate it with shell or Python scripts via userscripts, and soon-ish there'll be a Python plugin API as well.
I don't do ETAs for hobby work - possibly in my next summer holidays (~July 2018). I probably won't get to it before that, but I have no idea what I'll do in the holidays yet.
I couldn't figure out how to use vimium in "view source" mode and suspect that its an unsupported feature. That's rather surprising. You don't happen to know how to do this, do you?
An incredible project considering the average longevity of other vim key browsers and their limited communities. This one is loads better with a good renderer unlike most light weight browsers. (Qtwebengine which is just qt for blink because webkit is old now). It even has adblock.
Also, QtWebEngine isn't just Blink. It's basically a stripped down version of Chromium as a library, also containing things like the network stack, the JS engine (V8), etc.
Not all systems support qtwebengine (by support I mean: have the current version of qt), and the developer still has qtwebkit as a fallback. Both implementations differ a lot, and I'm happily impressed to see support for both at the same time!
uMatrix is basically a superset of RequestPolicy - a stripped down version will work soon after per-domain settings, but I also plan on having a GUI similar to uMatrix:
I operate a laser cutter so do a bit of 2D CAD work. Along with my 22 button gaming mouse, AutoHotKey is a massive productivity booster. I have a script compiled to exe running on the laser control console PC to make it more user friendly too.
scroll wheel can be pushed left and right - 17 + 2 = 19
two addition buttons below the scroll wheel - 19 + 2 = 21
Every button I've listed is programmable. I made the left mouse button do something else by mistake once. That was awkward.
Also, the software it comes with allows you to program in 8 keymaps over many profiles, and it can change the profile based on what program has focus. I typically just use 2 keymaps in one profile across the few programs I have to use at work.
Just having enter, delete, backspace, tab keys, whatever on the mouse is amazing, but I also have macros programmed in for various tasks in the CAD program. I use AutoHotKey for most of the automated tasks in the proprietary software for the laser cutter.
I'm liking this trend of keyboard focused browsers on HN. It feels like I complained once and suddenly everyone has a pet-browser-project that's been in the works for a year or two that addresses a little problem here or there that we all complain about.
At first I think that this would be some kind of terminal browsers with very limited number of features, but after few minutes of using it looks very impresive. I'll try to move all my dayly programming browsing and see how it will work.
The display of TLS vs non TLS makes me a little nervous. A lot of thought has gone into those little lock icons. They can instill a false sense of security -- but it is also important to make TLS issues obvious. Can anyone comment on the handling and display of site certificate info?
The nice thing about lock icons is that they can indicate EV certificates (extended validation, where the organization basically paid some more to be verified more thoroughly). Unfortunately that's not something I can do with qutebrowser because of missing QtWebEngine API to get that information.
Another feature is to make it obvious whether you're connected via plaintext HTTP or HTTPS. qutebrowser solves that by showing the whole URL in white/green respectively.
When you see a "broken lock" icon (i.e. when there was an actual TLS issue), you did already get a big error page you had to confirm, or (in case of qutebrowser) a prompt, so you already know there's no TLS going on, right? In that case, qutebrowser shows the URL in orange.
I find this project very interesting. But for those of you who need chrome I highly recommend using SurfingKeys extension, which is a relatively new ext.
You can stick to Firefox 52 ESR until June 26, 2018, if you want. Mozilla is still working on a more powerful keyboard extension API for WebExtensions and I imagine some extension will be leveraging this at that point.
No, it won't be as powerful as Vimperator, but should be a good bit more powerful than for example Vimium.
When I last tried, the adblocker wasn't as good as ublock. If I were to switch now, I would miss easy access to my passwords, referrer control, zotero, and RES (a bit, a userscript would do).
Some of the adblock issue is possibly an engine problem (there's some pre-script hooks that Webkit-forks don't support).
Password autofill is something I want to take care once there's a plugin API, but there are ways to make it work (the password_fill userscript, autotyping in KeePass*).
Referrer control unfortunately isn't possible with QtWebEngine's API for now...
Zotero won't be possible, but I guess that won't exist any longer with WebExtensions either?
The zotero main program is now a standalone thing, but there's a webextension that lets you add things to your library. Looking into it, it seems you can get a rudimentary experience with a bookmarklet/jseval:
I'm glad that Greasemonkey support is coming, though. Will the GM scripts run in the same JS scope as page scripts?
Webkit forks also render text slightly worse for HiDPI screens and don't seem to support CSS `hyphens: auto`. Which is annoying because I really like justified text.
It's a great alternative to what's left of the Firefox genocide of extensions, where only VimFX and Saka Key exist.