You are not logged in.

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

freq
Member
From: web
Registered: 2016-03-05
Posts: 11
Website

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

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.


I run Debian, btw.

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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. wink


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

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

null
Member
Registered: 2009-05-06
Posts: 398

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

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 smile
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.)

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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 smile

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 smile

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.


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

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

null
Member
Registered: 2009-05-06
Posts: 398

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

Thanks a lot smile

Offline

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

tedbell
Member
Registered: 2012-08-04
Posts: 167

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

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

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

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

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)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

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.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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 smile

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.


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

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


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

The Compiler wrote:

Likely fixed in 1.2.1 already

Sadly, no. Still broken.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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 big_smile

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


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

The Compiler wrote:

Luckily I had an IBM Model M nearby


much envy tongue


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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.


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

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/


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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/


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

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

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)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

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

mdf1979
Member
Registered: 2018-03-20
Posts: 12

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

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

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

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.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

mdf1979
Member
Registered: 2018-03-20
Posts: 12

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

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?

Offline

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

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).


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,783
Website

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

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.


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Online

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

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

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

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.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

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

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

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

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)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

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

The Compiler
Member
From: Switzerland
Registered: 2011-05-01
Posts: 214
Website

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

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! wink

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.


>>> from __future__ import braces
  File "<stdin>", line 1
SyntaxError: not a chance

Offline

Board footer

Powered by FluxBB