qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

freq · 2018-01-27 21:37:36

I imagine a browser built on Quantum Web Engine that is just like qutebrowser and has all of the about:config options that firefox does... Let us secure our browsers. Qutebrowser is really nice though! It's super light and unixy.

The Compiler · 2018-02-13 09:12:31

To the gentleman who submitted a crash report with

FUCKING RETARDED PIECE OF SHIT!

as contact info while viewing this thread: While that tells me a lot about you, it doesn't tell me how to contact you - I opened an issue for that crash.

null · 2018-02-14 11:42:41

Thanks a lot for the lazy tab loading feature. I was really missing something like this and it greatly speeds up qutebrowser loading on system start
One question though: is it possible to cange the "Suspended: " string in front of the tab title? I have the tabbar at my left side and this string covers more than half of the area so it's getting rather hard to figure out which tab is which. (I'd love to be able to replace this string by some "colors.tabs.indicator.suspended" color option.)

The Compiler · 2018-02-14 14:04:42

null wrote:

Thanks a lot for the lazy tab loading feature. I was really missing something like this and it greatly speeds up qutebrowser loading on system start

Glad to hear it helps! I plan to improve it in the future by not creating Qt widgets for those tabs at all, but I wasn't involved much in the current implementation

null wrote:

One question though: is it possible to cange the "Suspended: " string in front of the tab title? I have the tabbar at my left side and this string covers more than half of the area so it's getting rather hard to figure out which tab is which. (I'd love to be able to replace this string by some "colors.tabs.indicator.suspended" color option.)

It currently isn't - I opened an issue for it.

null · 2018-02-14 21:16:55

Thanks a lot

tedbell · 2018-02-16 16:08:21

I have now ditched Firefox Quantum and this is now my default browser. AMAZING WORK. THANK YOU

Trilby · 2018-02-17 12:30:12

Hi all, I've got an odd minor issue in qutebrowser that's been nagging at me for a few months. Currently I don't have enough to make any reasonable post on the issue tracker - so I've been hoping to collect more data or at least find some sort of pattern, but I'm not making headway. So I'd like to put this out here to see if others have had a similar symptom - if so, perhaps we can find some pattern.

The odd symptom is that frequently yet inconsistently (perhaps about half the time) when a page loads the first element on the page gets focus: it's highlighted with a border as if it was the focused input box or a selected link. This focus can be changed with the tab key, or by clicking any focusable element. What strikes me as most odd, though, is that it is always the first visible element on the page whether or not it makes any sense for that element to be able to be focused.

For example, on these forums the "Arch Linux Forums" header link is selected. This is not unreasonable as that is a link, and it should be able to get focus (though I'm still not sure why it would get focus inconsistently). But on other pages like mine here the top <h1> element is frequently focused which doesn't make sense. While the "Arch Linux Fourms" link is in the normal tab-stop cycle, the H1 element is not.

I've tried changing the input.inser_mode* settings with no affect. I've also tried to find patterns of when the first element is or is not selected (whether an input element was focused on the last page visited, whether the browser was just opened, etc) but so far I've not been able to find any reliable predictor of when this will happen.

Certainly this is a fairly trivial nit to pick, but if anyone has any insights or suggestions on how to gather useful information of figuring out why this happens (or why it is inconsistent) I'd appreciate it.

Last edited by Trilby (2018-02-17 12:35:24)

jasonwryan · 2018-03-16 05:22:38

Hints are partially broken in 1.2.0-1

I have numeric hints setup, and after the upgrade to 1.2.0-1 the number keys work fine on all my machines, but on both my workstations, the numpad keys trigger random hints.

These keys work perfectly fine if I use them to enter digits in a web form or the terminal, for example, but for hinting they are borked.

Config section:

c.hints.mode = "number"
c.hints.chars = "123456789"
c.hints.min_chars = 1

Can anyone reproduce?

Downgrading restores the correct functionality.

The Compiler · 2018-03-16 07:04:38

jasonwryan wrote:

Hints are partially broken in 1.2.0-1
I have numeric hints setup, and after the upgrade to 1.2.0-1 the number keys work fine on all my machines, but on both my workstations, the numpad keys trigger random hints.
These keys work perfectly fine if I use them to enter digits in a web form or the terminal, for example, but for hinting they are borked.
Config section:
c.hints.mode = "number"
c.hints.chars = "123456789"
c.hints.min_chars = 1
Can anyone reproduce?
Downgrading restores the correct functionality.

Likely fixed in 1.2.1 already - I can't test it as I don't have a numpad

As a workaround, you might be able to do :bind --mode=hint <Num+1> follow-hint -s 1 for all digits - but I can't test whether that works either.

jasonwryan · 2018-03-16 07:26:14

Thanks Florian. I'll wait for Pierre to push the new release.

jasonwryan · 2018-03-18 17:26:47

The Compiler wrote:

Likely fixed in 1.2.1 already

Sadly, no. Still broken.

The Compiler · 2018-03-18 19:08:17

jasonwryan wrote:

The Compiler wrote:
Likely fixed in 1.2.1 already
Sadly, no. Still broken.

Luckily I had an IBM Model M nearby so I could test this time

Indeed, I can reproduce it, and opened an issue for it.

jasonwryan · 2018-03-18 19:36:56

The Compiler wrote:

Luckily I had an IBM Model M nearby

much envy

The Compiler · 2018-03-28 13:20:58

jasonwryan wrote:

The Compiler wrote:
Likely fixed in 1.2.1 already
Sadly, no. Still broken.

Should be fixed in qutebrowser-git now. Not sure whether there will be a v1.2.2, but maybe I'll just release v1.3 soon-ish.

jasonwryan · 2018-03-28 19:53:50

The Compiler wrote:

jasonwryan wrote:
The Compiler wrote:
Likely fixed in 1.2.1 already
Sadly, no. Still broken.
Should be fixed in qutebrowser-git now. Not sure whether there will be a v1.2.2, but maybe I'll just release v1.3 soon-ish.

Victory! \o/

The Compiler · 2018-04-26 08:35:14

Trilby wrote:

Hi all, I've got an odd minor issue in qutebrowser that's been nagging at me for a few months. Currently I don't have enough to make any reasonable post on the issue tracker - so I've been hoping to collect more data or at least find some sort of pattern, but I'm not making headway. So I'd like to put this out here to see if others have had a similar symptom - if so, perhaps we can find some pattern.
The odd symptom is that frequently yet inconsistently (perhaps about half the time) when a page loads the first element on the page gets focus: it's highlighted with a border as if it was the focused input box or a selected link. This focus can be changed with the tab key, or by clicking any focusable element. What strikes me as most odd, though, is that it is always the first visible element on the page whether or not it makes any sense for that element to be able to be focused.
For example, on these forums the "Arch Linux Forums" header link is selected. This is not unreasonable as that is a link, and it should be able to get focus (though I'm still not sure why it would get focus inconsistently). But on other pages like mine here the top <h1> element is frequently focused which doesn't make sense. While the "Arch Linux Fourms" link is in the normal tab-stop cycle, the H1 element is not.
I've tried changing the input.inser_mode* settings with no affect. I've also tried to find patterns of when the first element is or is not selected (whether an input element was focused on the last page visited, whether the browser was just opened, etc) but so far I've not been able to find any reliable predictor of when this will happen.
Certainly this is a fairly trivial nit to pick, but if anyone has any insights or suggestions on how to gather useful information of figuring out why this happens (or why it is inconsistent) I'd appreciate it.

Still no clue what's going on there - but it sounds similar to what someone reported here, right?
https://www.reddit.com/r/qutebrowser/co … cted_link/

Trilby · 2018-04-26 10:30:01

Yes, it sounds the same. Although my symptoms may have changed in the intervening time: I am no longer (or at least much less often) seeing non-selectable (e.g., H1) elements being highlighted, but now only elements that would be in the normal focus cycle. As I can't be 100% sure I didn't just see non-selectable elements on my own website, I can't rule out the possibility that I inadvertently did something odd with the code of my website: so perhaps the non-selectable elements being highlighted was a red-herring.

I have found a bit of a pattern with which I can consistently replicate the behavior. Open any page, hit tab any number of times to cycle through selectable elements on the page, then navigate* to another page with selectable elements and the first one will be selected (with the yellow outline). I'm currently getting perfect repeatability with this between my above-mentioned website and github - and I also just tested by going between archlinux.org and github.com. On github it is particularly notable as the first selectable element seems to be a big blue "skip to content" button in the upper left which is hidden until it gets focused.

Navigating back and forth between these pages (within the same tab/webview) keeps the first element focused on every navigation. It seems visiting a page without *any* selectable elements clears this risidual memory of input focus. It may also be noteworthy that it doesn't seem to matter what the tab-index is on a given page, only the first element is ever selected on the new page. In other words, if I go to archlinux.org then tab a few times to cycle to the third selectable element, then go to github.com (in the same tab) the big blue button (1st element on github.com) is still focused.

I've not looked into the qutebrowser or webengine code at all, but I would speculate that there is a variable for the current tab-index or a pointer to a currently selected element that does not get cleared when a new page is opened within the same tab/web-view.

EDIT:
* I just found that when navigating from one page with a selected element to another, the symptom only appears if that navigation was through one of qutebrowser's mechanisms: e.g. a quick mark, 'back' and 'forward' key bindings, or an ":open ..." command. If I navigate via a link on the page, the target page does not have the first selected element highlighted.

Last edited by Trilby (2018-04-26 14:54:29)

mdf1979 · 2018-05-15 22:17:08

hello guys i fell good with this browser but is flagged out date more than a week now...

jasonwryan · 2018-05-15 23:06:23

mdf1979 wrote:

hello guys i fell good with this browser but is flagged out date more than a week now...

Don't do that. If you can't wait you can build it yourself.

mdf1979 · 2018-05-16 21:12:16

jasonwryan wrote:

mdf1979 wrote:
hello guys i fell good with this browser but is flagged out date more than a week now...

Don't do that. If you can't wait you can build it yourself.

yeah my bad sorry, i got compiled from github. how to become a package maintainer?

jasonwryan · 2018-05-16 21:18:03

You can apply to become a TU if you have a track record of good package maintenance on the AUR and are active in the community (and can find another TU to sponsor you).

WorMzy · 2018-05-21 17:42:59

I dont know where the crash report form fires off to, but if you got a report from me earlier today, The Compiler, please disregard it. Somehow I had two versions of qutebrowser with almost identical names, 1.3.0.r45.ga90a89417 and 1.3.0.r45.ga31542269. I think the former was built while I was trying to compile older versions of qutebrowser to investigate a bug (which turned out to be caused by my VPN), but the version built yesterday (ga31542269) works fine.

jasonwryan · 2018-05-22 22:30:12

With 1.3.0 there is a bug in the settings documentation: tabs.favicon.show is supposed to accept the string: always never or pinned. Actually setting one of those in the conf triggers errors on start.

As do True, False, 0 or 1... Commenting out the setting is the only was, AFAICT, to avoid the error.

Trilby · 2018-05-25 22:29:00

qt5-webengine 5.11 changed the cursor icon used for 'pointer' to something I find rather annoying and distracting, most notably because the active point of the default and pointer icons are on opposite sides so it jumps every time a link is hovered over.

I thought I might be able to change this in my custom css with `a { cursor: default; }` and while this did indeed prevent the new image from showing up when hovering over links, it of course has no impact when a website's own css specifies 'cursor: pointer' on any other element.

Is there any way to change the icon used for 'cursor: pointer' in qutebrowser? Or might there be a way to make qt5-webengine use something different?

For reference, prior to 5.11 the image for cursor pointer was the white gloved hand (which always looked like a mickey mouse hand to me) like the left-most icon here. The new one is a a dark hand pointing up and to the right (so the image is all on the left of the point).

EDIT I'm still curious about this, but I'll postpone working on it as qt5-webengine 5.11 is a complete train wreck here. About 1/3 times a page renders on only half the window, and another 1/3 times I get a "render process crashed" message. I'm downgrading for now. (it seems these are both being tracked in qutebrowser github issues).

Last edited by Trilby (2018-05-26 01:41:33)

The Compiler · 2018-05-30 13:25:37

WorMzy wrote:

I dont know where the crash report form fires off to, but if you got a report from me earlier today, The Compiler, please disregard it. Somehow I had two versions of qutebrowser with almost identical names, 1.3.0.r45.ga90a89417 and 1.3.0.r45.ga31542269. I think the former was built while I was trying to compile older versions of qutebrowser to investigate a bug (which turned out to be caused by my VPN), but the version built yesterday (ga31542269) works fine.

Successfully ignored!

jasonwryan wrote:

With 1.3.0 there is a bug in the settings documentation: tabs.favicon.show is supposed to accept the string: always never or pinned. Actually setting one of those in the conf triggers errors on start.
As do True, False, 0 or 1... Commenting out the setting is the only was, AFAICT, to avoid the error.

The documentation is correct and auto-generated from the same information the code uses. It works fine here - how exactly are you trying to set it?

Trilby wrote:

qt5-webengine 5.11 changed the cursor icon used for 'pointer' to something I find rather annoying and distracting, most notably because the active point of the default and pointer icons are on opposite sides so it jumps every time a link is hovered over.
I thought I might be able to change this in my custom css with `a { cursor: default; }` and while this did indeed prevent the new image from showing up when hovering over links, it of course has no impact when a website's own css specifies 'cursor: pointer' on any other element.
Is there any way to change the icon used for 'cursor: pointer' in qutebrowser? Or might there be a way to make qt5-webengine use something different?
For reference, prior to 5.11 the image for cursor pointer was the white gloved hand (which always looked like a mickey mouse hand to me) like the left-most icon here. The new one is a a dark hand pointing up and to the right (so the image is all on the left of the point).

I can't reproduce this - but I'd hope https://codereview.qt-project.org/#/c/230045/ would help there for Qt 5.11.1

EDIT I'm still curious about this, but I'll postpone working on it as qt5-webengine 5.11 is a complete train wreck here. About 1/3 times a page renders on only half the window, and another 1/3 times I get a "render process crashed" message. I'm downgrading for now. (it seems these are both being tracked in qutebrowser github issues).

Train wreck is pretty accurate. qutebrowser v1.3.1 adds a workaround for the "split page" issue.

Arch Linux

#626 2018-01-27 21:37:36

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#627 2018-02-13 09:12:31

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#628 2018-02-14 11:42:41

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#629 2018-02-14 14:04:42

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#630 2018-02-14 21:16:55

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#631 2018-02-16 16:08:21

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#632 2018-02-17 12:30:12

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#633 2018-03-16 05:22:38

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#634 2018-03-16 07:04:38

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#635 2018-03-16 07:26:14

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#636 2018-03-18 17:26:47

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#637 2018-03-18 19:08:17

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#638 2018-03-18 19:36:56

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#639 2018-03-28 13:20:58

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#640 2018-03-28 19:53:50

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#641 2018-04-26 08:35:14

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#642 2018-04-26 10:30:01

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#643 2018-05-15 22:17:08

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#644 2018-05-15 23:06:23

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#645 2018-05-16 21:12:16

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#646 2018-05-16 21:18:03

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#647 2018-05-21 17:42:59

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#648 2018-05-22 22:30:12

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#649 2018-05-25 22:29:00

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

#650 2018-05-30 13:25:37

Re: qutebrowser - A keyboard-driven, vim-like browser based on PyQt5

Board footer