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

Trilby · 2016-10-21 10:58:10

https://bbs.archlinux.org/viewtopic.php?id=218498
https://bbs.archlinux.org/viewtopic.php?id=218489

NoSuck · 2016-10-23 02:40:11

zuglufttier wrote:

https://www.eff.org/privacybadger

Privacy Badger is a godsend about which I was unaware. I agree this would be nice for qutebrowser.

Hund · 2016-10-23 10:13:50

I added the EasyList, EasyPrivacy and Fanboy's Annoyance List myself.

https://easylist.to/

The Compiler · 2016-10-23 17:31:00

Hund wrote:

I added the EasyList, EasyPrivacy and Fanboy's Annoyance List myself.
https://easylist.to/

How did you convert them to a format qutebrowser can read?

Hund · 2016-10-23 17:48:09

The Compiler wrote:

Hund wrote:
I added the EasyList, EasyPrivacy and Fanboy's Annoyance List myself.
https://easylist.to/
How did you convert them to a format qutebrowser can read?

I didn't. I just assumed it worked like every other adblockers.

Bummer. It's a great web browser but I really miss per-site settings for scripts and cookies, as I really don't like being tracked by Facebook and Google on pretty much every site.

The Compiler · 2016-10-24 09:26:47

Hund wrote:

The Compiler wrote:
Hund wrote:
I added the EasyList, EasyPrivacy and Fanboy's Annoyance List myself.
https://easylist.to/
How did you convert them to a format qutebrowser can read?
I didn't. I just assumed it worked like every other adblockers.

Nope. It currently only supports /etc/hosts-like lists, or one hostname per line.

Bummer. It's a great web browser but I really miss per-site settings for scripts and cookies, as I really don't like being tracked by Facebook and Google on pretty much every site.

FWIW third-party cookies are already blocked by default (content -> cookies-accept = no-3rdparty), and I'd expect the default host block lists to already block known-bad tracking/ad servers.

But I definitely want per-domain script control as well, that'll follow when there are per-domain configs in general

Trilby · 2016-11-16 23:09:38

I just rebuilt from git - and whoa, some nice progress with the webengine backend. Previously I've only tested it out here and there or used it on a few pesky pages that don't like webkit. But user stylesheets are working now so I may switch to the webengine backend for daily use.

However, I am getting an unpleasant jerkiness to the application of the user stylesheet - it looks like the original style is displayed, then the user style settings modify what is already on screen and there is a split second of everything on the screen contorting between the two styles. I've not yet checked whether this has already been reported, nor have I yet investigated at all on my own. So this is just a first reaction thought.

However, the one feature I'm really on the edge of my seat for is fullscreen videos. According to a qt page QtWebEngine should handle fullscreening of HTML5 videos (e.g. youtube) as of version 5.6, but we are on 5.7 and it's not working here. Does anyone know if there is other information on this?

EDIT: oops, I see fullscreen is still incomplete on the webengine tracker issue. But I am still curious if there is a breakdown of what's missing or what's needed for that.

The Compiler · 2016-11-17 05:16:16

Trilby wrote:

I just rebuilt from git - and whoa, some nice progress with the webengine backend. Previously I've only tested it out here and there or used it on a few pesky pages that don't like webkit. But user stylesheets are working now so I may switch to the webengine backend for daily use.

Good timing, that was implemented on Tuesday

Trilby wrote:

However, I am getting an unpleasant jerkiness to the application of the user stylesheet - it looks like the original style is displayed, then the user style settings modify what is already on screen and there is a split second of everything on the screen contorting between the two styles. I've not yet checked whether this has already been reported, nor have I yet investigated at all on my own. So this is just a first reaction thought.

The stylesheet currently works by running some javascript injecting it to the DOM, and that's the earliest injection point where DOM manipulation is possible. So unfortunately, I don't think I can do anything about that until there's a proper API for user stylesheets in Qt.

Trilby wrote:

However, the one feature I'm really on the edge of my seat for is fullscreen videos. According to a qt page QtWebEngine should handle fullscreening of HTML5 videos (e.g. youtube) as of version 5.6, but we are on 5.7 and it's not working here. Does anyone know if there is other information on this?
EDIT: oops, I see fullscreen is still incomplete on the webengine tracker issue. But I am still curious if there is a breakdown of what's missing or what's needed for that.

I think it's basically this:

Display fullscreen permission requests (with a setting to always allow them, like other permission requests)
Have a way to fullscreen qutebrowser completely (i.e. also hiding tab/statusbar)
Have a way to leave fullscreen easily again (probably with another command bound to Escape)

It's probably some 30 minutes of effort, but so are a lot of other things too

Trilby · 2016-11-17 13:48:52

Thanks for the responses, and the continued great work on qutebrowser.

woodape · 2016-11-19 15:58:18

I kept passing by this topic in the arch fourms, but now i'm happy that I stopped. I've been using the browser for only a few days, but with the password_fill userscript this is now my daily driver. Love it, thanks for all the work!

Edit:
I've found one issue. On my github page, if I click the down arrow next to my profile picture it just refreshes my profile instead of dropping down the menu. The spearate hint for the arrow shows up, but selecting it doesn't open the correct menu link. I've just tested and this doesn't happen when using chrome.

Last edited by woodape (2016-11-19 18:24:11)

chickenPie4tea · 2016-11-19 18:51:42

@ woodape mind saying where you got the password_fill userscript ?

woodape · 2016-11-19 19:18:51

chickenPie4tea wrote:

@ woodape mind saying where you got the password_fill userscript ?

Not at all, it's on the qutebrowser gihub. It was mentioned somewhere else in this thread, not sure exactly where though. You'll need pass to make use of it though.

Last edited by woodape (2016-11-19 19:19:09)

The Compiler · 2016-11-22 08:35:55

woodape wrote:

I've found one issue. On my github page, if I click the down arrow next to my profile picture it just refreshes my profile instead of dropping down the menu. The spearate hint for the arrow shows up, but selecting it doesn't open the correct menu link. I've just tested and this doesn't happen when using chrome.

Are you using a custom user-agent by any chance? GitHub breaks in funny ways when doing that with the QtWebKit backend.

Fortunately, QtWebEngine is getting more and more ready

woodape · 2016-11-22 16:14:18

Thanks for the response @The Compiler. I'm using the chrome user-agent in the list given by "set > network > user-agent" but updated for the newest version of chrome. I've just switched to the empty "" user-agent and the issue goes away. I'd like to keep my chrome user-agent, so I'm looking forward to the QtWebEngine even more now

The Compiler · 2016-11-22 16:17:31

woodape wrote:

Thanks for the response @The Compiler. I'm using the chrome user-agent in the list given by "set > network > user-agent" but updated for the newest version of chrome. I've just switched to the empty "" user-agent and the issue goes away. I'd like to keep my chrome user-agent, so I'm looking forward to the QtWebEngine even more now

FWIW you might be happy with installing qt5-webengine and using qutebrowser from git with --backend webengine - the list of missing features is getting smaller and smaller

woodape · 2016-11-22 16:41:53

Just gave it a shot, and the github-page issue isn't there with the webengine background. That feature list currently checks pretty much everything I need out of a browser anyway so I'm mapping my hotkey with the --backend=webengine. I does seem like it is slightly more "choppy" when scrolling with j and k on long pages like the Arch forums active page. With the webkit, it is smooth and very fast, whereas the webengine seems a bit slower and stutters. Do you notice this and is it normal?

Again, thanks for all the work!

Trilby · 2016-11-22 17:07:51

As foreshadowed above, I've just switched to the webengine backend for daily use. There are certainly a few places where it's not as well polished as it's predecessor - but these are now few enough and far between enough that they are trivial compared to the growing barrel of webkit functionality failures (e.g., google docs are nearly unusuable with webkit, google sheets completely crash webkit [I hate google docs ... but I have colleagues ...]).

I suspect some of these "polish" bits that feel off are also likely to user configs. For example, this textbox I'm typing in now has a horrific yellow border when it has input focus. I'm pretty sure this is a qt theme issue that I'm responsible for configuring when I get around to it.

stupidus · 2016-11-23 18:18:45

I just noticed that it is not possible to use :open anymore without an URL.

The error message is:

No URL given, but -t/-b/-w not set!

:open -b/-t/-w without an URL works as expected, opening a blank tab or window. Before it was also possible to open a blank page in the current tab.

The Compiler · 2016-11-24 06:03:22

stupidus wrote:

I just noticed that it is not possible to use :open anymore without an URL.
The error message is:
No URL given, but -t/-b/-w not set!
:open -b/-t/-w without an URL works as expected, opening a blank tab or window. Before it was also possible to open a blank page in the current tab.

I'm pretty sure that was never possible. That error message was added in early 2015, at the same time when :open without an URL was implemented in the first place.

stupidus · 2016-11-24 09:39:11

Ok, maybe I am remembering it wrong then, and it was in some other vim-like browser.
So, let's turn this into a feature request

At least for consistency, it would be good, if a simple ":open" would do the same thing as ":open -t", just in the same tab. I don't know, how difficult it would be to implement this, but I understand, that it is probably very low in priority.

The Compiler · 2016-11-26 11:22:58

stupidus wrote:

Ok, maybe I am remembering it wrong then, and it was in some other vim-like browser.
So, let's turn this into a feature request
At least for consistency, it would be good, if a simple ":open" would do the same thing as ":open -t", just in the same tab. I don't know, how difficult it would be to implement this, but I understand, that it is probably very low in priority.

Hmm, right - I'm not sure why that check was even there in the first place, and it was trivial to remove it - so I did so

stupidus · 2016-11-27 17:06:08

Thanks, it's working great now.

Trilby · 2016-12-14 19:52:16

The Compiler, I found what looks to be a bug in QTWebEngine, but as I'm not at all in the loop with it's development I was wondering if you'd be interested in collecting any other diagnostics to make a better bug report than I could. If not I can send this upstream to the QTWebEngine people:

Today I noticed timestamps on Slack.com (a team message board) were wrong despite my timezone being set properly in their interface. I found the times did display properly with the QtWebkit backend, but seemed to be showing only UTC times under QtWebengine. I tried some other browsers, and tinkered with user-agent settings, but nothing panned out. Then I created my one minimal html page using a variety of methods to get the users local time, timezone, and or offset, and all of them seemed to work except for one:

<!DOCTYPE html>
<script language="javascript">
window.onload = function() {
	 var myDate = new Date();
	 document.write(myDate.getTimezoneOffset());
}
</script>

This appropriatly displays 300 (I'm in UTC-5) with most browsers, and with qutebrowser using webkit. But with Qutebrowser webengine it just shows 0. It would seem that the getTimezoneOffset function is not returning the correct value in WebEngine.

The Compiler · 2016-12-14 20:41:26

Trilby: See QTBUG-55125 - it got fixed in Qt 5.7.1 which got released today and is in [testing].

Trilby · 2016-12-14 20:54:57

Ah, thanks. I'm glad I posted before reporting it.

Arch Linux

#351 2016-10-21 10:58:10

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

#352 2016-10-23 02:40:11

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

#353 2016-10-23 10:13:50

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

#354 2016-10-23 17:31:00

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

#355 2016-10-23 17:48:09

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

#356 2016-10-24 09:26:47

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

#357 2016-11-16 23:09:38

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

#358 2016-11-17 05:16:16

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

#359 2016-11-17 13:48:52

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

#360 2016-11-19 15:58:18

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

#361 2016-11-19 18:51:42

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

#362 2016-11-19 19:18:51

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

#363 2016-11-22 08:35:55

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

#364 2016-11-22 16:14:18

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

#365 2016-11-22 16:17:31

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

#366 2016-11-22 16:41:53

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

#367 2016-11-22 17:07:51

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

#368 2016-11-23 18:18:45

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

#369 2016-11-24 06:03:22

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

#370 2016-11-24 09:39:11

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

#371 2016-11-26 11:22:58

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

#372 2016-11-27 17:06:08

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

#373 2016-12-14 19:52:16

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

#374 2016-12-14 20:41:26

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

#375 2016-12-14 20:54:57

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

Board footer