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

progandy · 2021-02-25 15:56:48

SataMaxx wrote:

I had the following user agent:
c.content.headers.user_agent = 'Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/68.0'
Reverting to the default one fixed this. (I chose to "advertise" myself as using Firefox to prop up the little guy, but it seems reCaptcha doesn't like this user agent)

It would have probably worked if you updated rv:31.0 to rv:68.0. Firefox v31 would be from 2014, google might not like that.

Last edited by progandy (2021-02-25 15:59:52)

SataMaxx · 2021-02-28 21:33:05

Ha! Nice catch!
I don't remember how I ended up with a mismatched user agent… but it works now! Thanks!

cajm · 2021-04-18 15:57:45

Last night I commented on a bug report. This morning when I opened my laptop I pressed 'r' to see if there were any more comments. To my surprise it duplicated the comment. I didn't quite believe my eyes so I tried it again to be sure, and there popped a third copy of the comment. Has anyone else had that happen? Is that expected?

Trilby · 2021-04-18 16:35:27

That would likely happen in most browsers - it is mostly an issue with the website, not the browser as the page uses the same url for submitting comments as for viewing the bug (i.e., it doesn't redirect on accepting the POST data). So when you refresh, if your browser resends the data, you just get a new comment. It's generally considered good practice for web pages to *not* do this and rather use a different url for submission and presentation - or have some other guard against duplicate POSTs. Some browsers may also warn about a refresh that would resend POST data - but it's not really the browser's job to do so.

cajm · 2021-04-18 17:29:29

Okay, makes sense. Now that I think of it firefox would probably have had a 'confirm resubmission' popup.

Xyne · 2021-12-23 00:10:36

Usescript to revert the Arch Wiki layout back to a desktop version following a discussion here.

anarki@buttereblume · 2021-12-23 10:16:11

This site embeds a 3D visualization of a cabinet.
https://tylko.com/shelf/commode/318747/ … l__id_4285

The rendering flickers on my machine. Looks fine using chromium. Can somebody reproduce?

qutebrowser 2.4.0-2
python-pyqt5-webengine 5.15.5-3
mesa-21.3.1-1
5.15.10-arch1-1
Thinkpad X280 w/ Intel hd620

Edit 2021-12-25: Using qutebrowser, the redering flickers quickly and the whole website from time to time. Using weaver, only the redering flickers.

Edit 2022-01-03: After upgrading to mesa-21.3.3-2, the flickering only occurs while moving the mouse and generally seems less agressive.

Last edited by anarki@buttereblume (2022-01-03 09:28:44)

Dieter@be · 2022-01-09 15:43:31

Hello, i'm having a look at qutebrowser. it certainly looks interesting.
My main concern now is making sure i would be using a current - secure - version of the chromium engine. I read https://qutebrowser.org/doc/faq.html but it seems that qutebrowser uses qt5, and according to
https://wiki.qt.io/QtWebEngine/ChromiumVersions the newer chromium versions only go to qt6. do i understand this correctly? i did read something about backporting security fixes but not sure if that applies here?

Trilby · 2022-01-09 16:10:41

qt5-webengine imports from chromium version 87, and qt6-webenegine imports from version 90. Neither of these are the newest. Chromium's versions are very fast moving while qt imports whatever the most current is at the time before their own qtwebengine release. Qt also strips out a fair bit of the chromium code, so some security issues are removed in that process. They also backport security patches, though I don't know if they get 100% of them. That said, webengine will always be behind chromium ... both in bug fixes, and in new bug vulnerabilities.

I switched a project of mine to qt6-webengine because the API was so much nicer, but I don't see it as at all more "secure" or safe. All browsers have vulnerabilities, I highly doubt qt5-webengine has systematically more than qt6-webengine (again, it's only 3 versions difference in chromium code). At least not yet I see no difference, at some point maintenance of qt5 will decline, but that's likely a long way off.

Last edited by Trilby (2022-01-09 16:11:21)

Dieter@be · 2022-01-10 22:21:36

so do i understand correctly then, that as long as people maintain qt5-webengine, the qt5 (and also qt6) keep basing off the latest and greatest chromium version at each point of release? so either qt5 or qt6 may use the newer chromium depending on which of them happens to have received a more recent release?

Trilby · 2022-01-10 23:13:41

Well, no. I'm not sure if there are going to be more releases of qt5-webengine. And the qt-webengine devs do not import wholesale new versions of chromium code without reason. But they do backport bug fixes. For example, a recent commit note in qt5-webengine's git repo:

upstream wrote:

Based on Chromium version: 87.0.4280.144
-Patched with security patches up to Chromium version: 96.0.4664.45
+Patched with security patches up to Chromium version: 96.0.4664.93

So the last versions of qt5-webengine were based on chromium 87 code but have bug fixes from up to version 96. I highly doubt any new version of crhomium will be imported into the qt5-webengine code even if there are new point releases of it - but backported bug fixes would be expected.

My major point was that you are focused on the wrong thing. You have some arbitrary focus on chromium code version numbers which don't represent anything in terms of security or safety of the code. What CVEs are you concerned about? You can check whether they've been patched for in qt{5/6}-webengine code. And I am quite sure that CVE-mediating patches will not be applied in qt6-webengine without also being applied in qt5-webengine (unless they are irrelevant due to only being created by vulnerabilities in the newer chromium code base).

This is why I say I'm confident there is no reason to suspect qt6-webengine will be any more secure than qt5-webengine (with respect to CVE issues) at least not until qt5-webengine is EOLed which will not be anytime soon (at least not before mid 2023).

Last edited by Trilby (2022-01-10 23:21:32)

Dieter@be · 2022-01-11 19:47:20

Trilby wrote:

My major point was that you are focused on the wrong thing. You have some arbitrary focus on chromium code version numbers which don't represent anything in terms of security or safety of the code. What CVEs are you concerned about? You can check whether they've been patched for in qt{5/6}-webengine code.

Thanks, this makes sense. As someone not familiar with the exact CVE's, the level of issue reporting nor the quality in which the process of backporting fixes gets applied in practice, knowing that the whole version gets bumped regularly would be an unambiguous (though indeed, limited) signal that contributes to overall confidence in the project, but it's only one of many. Accounts of more experienced people closer to qt development, certainly help too. The compiler mentioned similar things as you did. For a topic as important as security, i think it's useful to combine multiple factors / sources. So.. thanks!

Arch Linux

#676 2021-02-25 15:56:48

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

#677 2021-02-28 21:33:05

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

#678 2021-04-18 15:57:45

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

#679 2021-04-18 16:35:27

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

#680 2021-04-18 17:29:29

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

#681 2021-12-23 00:10:36

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

#682 2021-12-23 10:16:11

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

#683 2022-01-09 15:43:31

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

#684 2022-01-09 16:10:41

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

#685 2022-01-10 22:21:36

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

#686 2022-01-10 23:13:41

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

#687 2022-01-11 19:47:20

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

Board footer