From me at the-compiler.org Fri May 4 08:29:22 2018 From: me at the-compiler.org (Florian Bruhin) Date: Fri, 4 May 2018 08:29:22 +0200 Subject: [qutebrowser] qutebrowser v1.3.0 released Message-ID: <20180504062919.hnfvh3xw6o43pn77@hooch.localdomain> Hey, I'm happy to announce that I just released qutebrowser v1.3.0! Nothing too spectacular this time, but some smaller stuff. The most important things are probably that Qt 5.11 is mostly supported (with some rough edges), and the macOS release should work on older macOS releases again (thanks to Macstadium's excellent opensource initiative!). Full changelog: Added ~~~~~ - New `:scroll-to-anchor` command to scroll to an anchor in the document. - New `url.open_base_url` option to open the base URL of a searchengine when no search term is given. - New `tabs.min_width` setting to configure the minimal width for tabs. - New userscripts: * `getbib` to download bibtex information for DOIs on a page. * `qute-keepass` to get passwords from KeePassX. Changed ~~~~~~~ - QtWebEngine: Support for JavaScript Shared Web Workers have been disabled on Qt versions older than 5.11 because of security issues in in Chromium. You can get the same effect in earlier versions via `:set qt.args ['disable-shared-workers']`. An equivalent workaround is also contained in Qt 5.9.5 and 5.10.1. - The file dialog for downloads now has basic tab completion based on the entered text. - `:version` now shows OS information for POSIX OS other than Linux/macOS. - When there's an error inserting the text from an external editor, a backup file is now saved. - The `window.hide_wayland_decoration` setting got renamed to `window.hide_decoration` and now also works outside of wayland. - The `tabs.favicons.show` setting now can take three values: `'always'` (was `True`), `'never'` (was `False`) and `'pinned'` (to only show favicons for pinned tabs). - Hover tooltips on tabs now always show the webpage's title. - The default value for `content.host_blocking.lists` was changed to only include https://github.com/StevenBlack/hosts[Steven Black's hosts-list] which combines various sources. - Error messages when trying to wrap when `tabs.wrap` is `False` are now logged to debug instead of messages. Fixed ~~~~~ - Using hints before a page is fully loaded is now possible again. - Selecting hints with the number keypad now works again. - Tab titles for tabs loaded from sessions should now really be correct instead of showing the URL. - Loading URLs with customized settings from a session now avoids an additional reload. - The window icon and title now get set correctly again. - The `tabs.switching_delay` setting now has a correct maximum value limit set. - The `taskadd` script now works properly when there's multi-line output. - QtWebEngine: Worked around issues with GreaseMonkey/stylesheets not being loaded correctly in some situations. - The statusbar now more closely reflects the caret mode state. - The icon on Windows should now be displayed in a higher resolution. - The QtWebEngine development tools (inspector) now also work when JavaScript is disabled globally. - Building `.exe` files now works when `upx` is installed on the system. - The keyhint widget now shows the correct text for chained modifiers. - Loading GreaseMonkey scripts now also works with Jinja2 2.8 (e.g. on Debian Stable). - Adding styles with GreaseMonkey on fast sites now works properly. - Window ID 0 is now excluded properly from `:tab-take` completion. - A rare crash when cancelling a download has been fixed. - The Makefile (intended for packagers) now supports `PREFIX` properly. - The workaround for a black window with Nvidia graphics is now enabled on non-Linux systems (like FreeBSD) as well. - Initial support for Qt 5.11. - Checking for a new version after sending a crash report now works properly again. - `@match` in Greasemonkey scripts now more closely matches the proper pattern syntax. - Searching via `/` or `?` now doesn't handle any characters in a special way. - Fixed crash when trying to retry some failed downloads on QtWebEngine. - An invalid spellcheck dictionary filename now doesn't crash anymore. - When no spellcheck dictionaries are configured, it's now disabled internally. This works around an issue with entering special characters on Facebook messenger. - The macOS release now should work again on macOS 10.11 and newer. Enjoy! Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From me at the-compiler.org Wed May 9 09:51:26 2018 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 9 May 2018 09:51:26 +0200 Subject: [qutebrowser] Held-back messages Message-ID: <20180509075126.unxyqmdqjrknilf2@hooch.localdomain> Hey, I just noticed there are three messages on the qutebrowser mailinglist which are still held back (because they've been posted by non-subscribers) - two of them from early/mid April. If you're getting this, you're either on the list (and you'll get those messages now), or you're one on the Bcc: of this message because you're someone who sent them. Sorry for missing them! Adding you all to the whitelist now. Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From freq at lavabit.com Sun May 6 22:48:20 2018 From: freq at lavabit.com (freq) Date: Sun, 6 May 2018 16:48:20 -0400 Subject: [qutebrowser] Sick Project! Message-ID: <20180506164820.17820b6d4113d9cdafea4488@lavabit.com> I've been able to use tor by tunneling qutebrowser through privoxy, that much is great. I did find there is a webrtc leak and don't know where to start in disabling webrtc. Help? Thanks in advance! -freq From me at the-compiler.org Wed May 9 09:55:20 2018 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 9 May 2018 09:55:20 +0200 Subject: [qutebrowser] Sick Project! In-Reply-To: <20180506164820.17820b6d4113d9cdafea4488@lavabit.com> References: <20180506164820.17820b6d4113d9cdafea4488@lavabit.com> Message-ID: <20180509075520.zprwnoeiothwui3r@hooch.localdomain> Hey, On Sun, May 06, 2018 at 04:48:20PM -0400, freq via qutebrowser wrote: > I've been able to use tor by tunneling qutebrowser through privoxy, that much is great. You can also use it directly via :set content.proxy as it's a SOCKS proxy FWIW :) > I did find there is a webrtc leak and don't know where to start in disabling webrtc. Help? Thanks in advance! See https://github.com/qutebrowser/qutebrowser/issues/2163 - before Qt (and PyQt) 5.11 is out, you're pretty much out of luck unfortunately. Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From me at the-compiler.org Wed May 9 10:00:50 2018 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 9 May 2018 10:00:50 +0200 Subject: [qutebrowser] patch for background window behaviour In-Reply-To: <478a05c4-2628-f7e2-628e-de986e51703b@posteo.de> References: <478a05c4-2628-f7e2-628e-de986e51703b@posteo.de> Message-ID: <20180509080050.ulcfbjthwfcutfto@hooch.localdomain> Hey Eike, On Fri, Apr 13, 2018 at 03:14:44PM +0200, Eike Fokken wrote: > Dear all, > > in issue 818 [1] people (among them me) had the problem that background > windows grab focus and as it were I could only tell the window manager to > unfocus all qutebrowser windows or none. > I wrote a patch that gives background windows the window_role > "qutebrowser_background" so that the window manager can tell them apart and > treat them differently. > > I think this adds functionality without breaking anything for people not > using it. > > Best > > Eike > > [1] https://github.com/qutebrowser/qutebrowser/issues/818 Thanks! I added it as a comment to #3819 because that's a more recent discussion about the same topic: https://github.com/qutebrowser/qutebrowser/issues/3819 There's currently a lot of contributions and things I plan to look at, so it might take me a while to get to it. If you happen to have a GitHub account I'd appreciate getting the same thing as a pull request instead so everything is at the same place - but if not, that's fine as well. :) Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From me at the-compiler.org Wed May 9 10:05:05 2018 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 9 May 2018 10:05:05 +0200 Subject: [qutebrowser] Keybindings reset? In-Reply-To: References: Message-ID: <20180509080505.iolsfiko7e6csym4@hooch.localdomain> Hey, On Tue, Apr 03, 2018 at 10:51:21AM -0400, Jonathan Saunders wrote: > Out of nowhere, "j" and "k" on qutebrowser started working as :tab-prev and > :tab-next instead of scrolling down and up. Then, I pressed another key > ("a", I think) and the browser crashed. Upon re-startup, all my custom > keybindings (of which I have many) were reset! > > Has anyone else experienced this issue? Or, did I not catch the news that > the latest version resets keybindings or something? > > I'm running qutebrowser v1.2.1-1 on Arch Linux. The last update I performed > was a day ago... That sounds weird! No clue what happened there... Did you submit a crash report with that crash? Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ryan at rcorre.net Wed May 9 13:19:01 2018 From: ryan at rcorre.net (Ryan Roden-Corrent) Date: Wed, 9 May 2018 07:19:01 -0400 Subject: [qutebrowser] Keybindings reset? In-Reply-To: <20180509080505.iolsfiko7e6csym4@hooch.localdomain> References: <20180509080505.iolsfiko7e6csym4@hooch.localdomain> Message-ID: <20180509111901.GA632@padavis.localdomain> > Out of nowhere, "j" and "k" on qutebrowser started working as :tab-prev and > :tab-next instead of scrolling down and up. Then, I pressed another key Any chance you had capslock on? > Upon re-startup, all my custom keybindings (of which I have many) were > reset! How did you configure your keybindings? Using config.py or running `:bind` in the browser? -Ryan On Wed 05/09/18 10:05AM, Florian Bruhin wrote: > Hey, > > On Tue, Apr 03, 2018 at 10:51:21AM -0400, Jonathan Saunders wrote: > > Out of nowhere, "j" and "k" on qutebrowser started working as :tab-prev and > > :tab-next instead of scrolling down and up. Then, I pressed another key > > ("a", I think) and the browser crashed. Upon re-startup, all my custom > > keybindings (of which I have many) were reset! > > > > Has anyone else experienced this issue? Or, did I not catch the news that > > the latest version resets keybindings or something? > > > > I'm running qutebrowser v1.2.1-1 on Arch Linux. The last update I performed > > was a day ago... > > That sounds weird! No clue what happened there... Did you submit a crash > report with that crash? > > Florian > > -- > https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From jonathan at saunderstech.org Wed May 9 16:47:19 2018 From: jonathan at saunderstech.org (Jonathan Saunders) Date: Wed, 09 May 2018 14:47:19 +0000 Subject: [qutebrowser] Keybindings reset? In-Reply-To: <20180509111901.GA632@padavis.localdomain> References: <20180509080505.iolsfiko7e6csym4@hooch.localdomain> <20180509111901.GA632@padavis.localdomain> Message-ID: I use :bind in the browser to change my keybindings. It is unlikely that I had capslock on, but even if I did, J and K weren't supposed to be bound to that. I didn't submit a crash report when this happened; can I still do so now? On Wed, May 9, 2018, 7:19 AM Ryan Roden-Corrent wrote: > > Out of nowhere, "j" and "k" on qutebrowser started working as :tab-prev > and > > :tab-next instead of scrolling down and up. Then, I pressed another key > > Any chance you had capslock on? > > > Upon re-startup, all my custom keybindings (of which I have many) were > > reset! > > How did you configure your keybindings? Using config.py or running > `:bind` in the browser? > > -Ryan > > On Wed 05/09/18 10:05AM, Florian Bruhin wrote: > > Hey, > > > > On Tue, Apr 03, 2018 at 10:51:21AM -0400, Jonathan Saunders wrote: > > > Out of nowhere, "j" and "k" on qutebrowser started working as > :tab-prev and > > > :tab-next instead of scrolling down and up. Then, I pressed another key > > > ("a", I think) and the browser crashed. Upon re-startup, all my custom > > > keybindings (of which I have many) were reset! > > > > > > Has anyone else experienced this issue? Or, did I not catch the news > that > > > the latest version resets keybindings or something? > > > > > > I'm running qutebrowser v1.2.1-1 on Arch Linux. The last update I > performed > > > was a day ago... > > > > That sounds weird! No clue what happened there... Did you submit a crash > > report with that crash? > > > > Florian > > > > -- > > https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > > I love long mails! | https://email.is-not-s.ms/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at rcorre.net Wed May 9 19:21:52 2018 From: ryan at rcorre.net (Ryan Roden-Corrent) Date: Wed, 09 May 2018 13:21:52 -0400 Subject: [qutebrowser] Keybindings reset? In-Reply-To: References: <20180509080505.iolsfiko7e6csym4@hooch.localdomain> <20180509111901.GA632@padavis.localdomain> Message-ID: <8E0B0F0F-05A1-4866-8243-1A5919CD5F94@rcorre.net> > J and K weren't supposed to be bound to that tab-next and tab-prev are the default bindings of J and K, so unless you disabled that it sounds like capslock could be the culprit. > I didn't submit a crash report when this happened; can I still do so now? I think you'll get a prompt the next time you open the browser, but if you've already ignored that I'm not sure. Id your systems saves coredumps you might be able to retrieve it, e.g. I see some entries if I run `coredumpctl list qutebrowser`. >I use :bind in the browser to change my keybindings Are the missing keybindings ones you set in the session that crashed? Its possible qutebrowser didn't get a chance to write your config. You don't happen to keep your configs under version control, do you? -Ryan - Ryan On May 9, 2018 10:47:19 AM EDT, Jonathan Saunders wrote: >I use :bind in the browser to change my keybindings. It is unlikely >that I >had capslock on, but even if I did, J and K weren't supposed to be >bound to >that. I didn't submit a crash report when this happened; can I still do >so >now? > >On Wed, May 9, 2018, 7:19 AM Ryan Roden-Corrent >wrote: > >> > Out of nowhere, "j" and "k" on qutebrowser started working as >:tab-prev >> and >> > :tab-next instead of scrolling down and up. Then, I pressed another >key >> >> Any chance you had capslock on? >> >> > Upon re-startup, all my custom keybindings (of which I have many) >were >> > reset! >> >> How did you configure your keybindings? Using config.py or running >> `:bind` in the browser? >> >> -Ryan >> >> On Wed 05/09/18 10:05AM, Florian Bruhin wrote: >> > Hey, >> > >> > On Tue, Apr 03, 2018 at 10:51:21AM -0400, Jonathan Saunders wrote: >> > > Out of nowhere, "j" and "k" on qutebrowser started working as >> :tab-prev and >> > > :tab-next instead of scrolling down and up. Then, I pressed >another key >> > > ("a", I think) and the browser crashed. Upon re-startup, all my >custom >> > > keybindings (of which I have many) were reset! >> > > >> > > Has anyone else experienced this issue? Or, did I not catch the >news >> that >> > > the latest version resets keybindings or something? >> > > >> > > I'm running qutebrowser v1.2.1-1 on Arch Linux. The last update I >> performed >> > > was a day ago... >> > >> > That sounds weird! No clue what happened there... Did you submit a >crash >> > report with that crash? >> > >> > Florian >> > >> > -- >> > https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) >> > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc >> > I love long mails! | https://email.is-not-s.ms/ >> >> >> From jonathan at saunderstech.org Wed May 9 20:47:58 2018 From: jonathan at saunderstech.org (Jonathan Saunders) Date: Wed, 09 May 2018 18:47:58 +0000 Subject: [qutebrowser] Keybindings reset? In-Reply-To: <8E0B0F0F-05A1-4866-8243-1A5919CD5F94@rcorre.net> References: <20180509080505.iolsfiko7e6csym4@hooch.localdomain> <20180509111901.GA632@padavis.localdomain> <8E0B0F0F-05A1-4866-8243-1A5919CD5F94@rcorre.net> Message-ID: I'm pretty sure it was all the keybindings, not just ones set during that session. Capslock may have been involved, I guess. I will say that I haven't had any issues since this, though, so I don't see the need to keep responding over a month-old email! On Wed, May 9, 2018, 1:21 PM Ryan Roden-Corrent wrote: > > J and K weren't supposed to be bound to that > > tab-next and tab-prev are the default bindings of J and K, so unless you > disabled that it sounds like capslock could be the culprit. > > > I didn't submit a crash report when this happened; can I still do so now? > > I think you'll get a prompt the next time you open the browser, but if > you've already ignored that I'm not sure. Id your systems saves coredumps > you might be able to retrieve it, e.g. I see some entries if I run > `coredumpctl list qutebrowser`. > > >I use :bind in the browser to change my keybindings > > Are the missing keybindings ones you set in the session that crashed? Its > possible qutebrowser didn't get a chance to write your config. You don't > happen to keep your configs under version control, do you? > > -Ryan > - Ryan > > On May 9, 2018 10:47:19 AM EDT, Jonathan Saunders < > jonathan at saunderstech.org> wrote: > >I use :bind in the browser to change my keybindings. It is unlikely > >that I > >had capslock on, but even if I did, J and K weren't supposed to be > >bound to > >that. I didn't submit a crash report when this happened; can I still do > >so > >now? > > > >On Wed, May 9, 2018, 7:19 AM Ryan Roden-Corrent > >wrote: > > > >> > Out of nowhere, "j" and "k" on qutebrowser started working as > >:tab-prev > >> and > >> > :tab-next instead of scrolling down and up. Then, I pressed another > >key > >> > >> Any chance you had capslock on? > >> > >> > Upon re-startup, all my custom keybindings (of which I have many) > >were > >> > reset! > >> > >> How did you configure your keybindings? Using config.py or running > >> `:bind` in the browser? > >> > >> -Ryan > >> > >> On Wed 05/09/18 10:05AM, Florian Bruhin wrote: > >> > Hey, > >> > > >> > On Tue, Apr 03, 2018 at 10:51:21AM -0400, Jonathan Saunders wrote: > >> > > Out of nowhere, "j" and "k" on qutebrowser started working as > >> :tab-prev and > >> > > :tab-next instead of scrolling down and up. Then, I pressed > >another key > >> > > ("a", I think) and the browser crashed. Upon re-startup, all my > >custom > >> > > keybindings (of which I have many) were reset! > >> > > > >> > > Has anyone else experienced this issue? Or, did I not catch the > >news > >> that > >> > > the latest version resets keybindings or something? > >> > > > >> > > I'm running qutebrowser v1.2.1-1 on Arch Linux. The last update I > >> performed > >> > > was a day ago... > >> > > >> > That sounds weird! No clue what happened there... Did you submit a > >crash > >> > report with that crash? > >> > > >> > Florian > >> > > >> > -- > >> > https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) > >> > GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc > >> > I love long mails! | https://email.is-not-s.ms/ > >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Tue May 29 12:10:58 2018 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 29 May 2018 12:10:58 +0200 Subject: [qutebrowser] qutebrowser v1.3.1 released! Message-ID: <20180529101058.av6pkm23yl2r3qs3@hooch.localdomain> Hi, I just released qutebrowser v1.3.1 which fixes a couple more issues (mostly with Qt 5.11): - Work around a bug in Qt 5.11 where only the top/bottom half of the window is used. This workaround is incomplete, but fixes the majority of the cases where this happens. - Work around keyboard focus issues with Qt 5.11. - Work around an issue in Qt 5.11 where e.g. activating JavaScript per-domain needed a manual reload in some cases. - Don?t crash when a ? key is pressed (e.g. on AZERTY keyboards). - Don?t crash when a tab is opened and quickly closed again. So, yeah, Qt 5.11 is... difficult. Let's hope most of those bugs will go away fully in Qt 5.11.1. :-/ I'll try to follow up with better workarounds soon (probably somewhen next week), but I'd still appreciate if distributions shipping Qt 5.11 upgraded ASAP (it should be a trivial version bump), as the issues are quite annoying. Thanks! Florian -- https://www.qutebrowser.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: