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

Trilby · 2017-02-13 23:14:40

@Ayekat, that code is pretty cleanly written. I was able to replicate the dropdown window issue with your WM. I tried to trace it, and I ruled out a few of my initial suspicions. In contrast, it seems the client unmaps the window itself when it looses inputfocus. It's hard to trace exactly where this is happening in your code as there are many levels of abstraction and many function calls from one maprequest event to the subsequent arranging of windows.

EDIT: I've confirmed the above suspicion with a crap "fix": comment out the updatefocus calls on lines 810 and 1250. That is not a long term solution, but rather just proof that the problem is the inconsistent focus model. TransientFor windows should never be given input focus. If anything whenever you would assign them input focus you should assign it instead to the parent window that they are "for". I've found it perfectly adequate to simply ignore them for the purposes of input focus.

@stupidus, I've only been able to replicate the DDG issue on webkit.

ayekat · 2017-02-14 00:50:03

Hey, thanks for taking a look at it!

Trilby wrote:

TransientFor windows should never be given input focus.

Ah - learned something new today Perhaps AwesomeWM has the same issue?
But that workaround truly isn't very long term - my focus-follows-mouse no longer works. But as I said, I'm rewriting it entirely.

lahwaacz · 2017-02-14 07:36:23

Trilby wrote:

FWIW stupidus, that behavior only happens on webkit. With backend=webengine duckduckgo works "properly". [...]

It happens to me even with webengine, but duckduckgo has an option (Keyboard Shortcuts) to turn that thing off.

lahwaacz · 2017-02-14 07:39:27

Hund wrote:

The only thing (I think) that's preventing me from ditching WebKit is the horrendous font rendering with the webengine backend. I don't know how to make it as good as with WebKit.

Fonts in webengine look fine on my system, although slightly different from webkit. It all comes down to fontconfig I think...

stupidus · 2017-02-14 09:20:23

I fixed the duckduckgo issue by using the html version of the site (https://duckduckgo.com/html?q={}). However, on google the issue persists if using the webengine backend.

Trilby · 2017-02-14 11:57:32

Oops, lahwaacz is right. I tried qutebrowser with both backends without my keys.conf or qutebrowser.conf, but my cookies were in tact, and I do have persistent settings for DDG including turning off the keyboard shortcuts. Sorry.

apl · 2017-02-16 19:15:40

So I just figured out that the New York Times paywall counts articles I have read from my browser history. It concerns me that my browsing history is public in this way. Turning off javascript gets me passed the paywall, so I am assuming it is a javascript that allows the NYT website to see my history file. Could other files on my computer be accessed this way? Is there anyway to have a history file which cannot be accessed like this in qutebrowser, or for privacy/ security reasons should javascripts be disabled as much as possible?

I use a VPN, and check for DNS leaks, and would like to protect my privacy/security as much as possible, and this feels like a big open door, am I right?
Thanks for any advice.

Trilby · 2017-02-16 20:37:50

Where did you get that it was history? That doesn't make much sense as every browser stores history differently (and some not at all). It seems NTYimes uses cookies.

Also, javascript cannot access your history "file". There may be some javascript calls that can ask the browser for history which the browser itself may store in a file, but javascript cannot just read files on your computer. There is the File API but that does not mean a website can read arbitrary files on your computer. That would be a ridiculous security issue and is not allowed in any browser.

How do you think this relates to qutebrowser as opposed to being a general security question?

apl · 2017-02-16 22:43:47

Thank you for your reply Trilby,
I was not storing cookies the first time the paywall block came up. I was using a VPN, so changed my IP thinking that it might be IP related, but wasn't. There was no cookie file in ~/.local/share/qutebrowser at all (I actually was searching everywhere trying to find one). The block continued to come up until I used vim to remove all the nytimes lines in my history file.
This is definitely an instance in which I would love to be wrong. and I am glad other files/information cannot be accessed.
The reason I posted this here is that I am using qutebrowser and was hoping for qutebrowser specific solutions/insight, in particular if the NYT and other websites are making javascript calls to qutebrowser about my history, how can I have qutebrowser ignore these calls while still recording my history for my own use. Private browsing works, but goes almost too far, in that I'm not worried about my history being recorded/seen on my own computer but being public through these calls.
I will double check this to verify the behavior.

Trilby · 2017-02-16 23:09:07

Hmm. Odd. I'd be curious to know whether removing lines from the history file was a coincidence. Accessing history in javascript is - I believe - limited to the same session and even the same window/tab. Cookies, however, can be persistent and can be accessed by the website that created them. With backend=webengine cookies are stored in ~/.local/share/qutebrowser/webengine/Cookies which is an sqlite database. You can remove a subset of cookies with sqlite3, eg:

sqlite3 ~/.local/share/qutebrowser/webengine/Cookies 'delete from cookies where host_key like "%archlinux.org%"'

That would selectively remove all cookies from our forums, wiki, aur, and (I think) bug tracker.

I actually do the opposite and have a script that periodically removes *all* cookies that are not from a list of domains I've chosen to accept.

apl · 2017-02-16 23:48:52

Hey thanks again. I'm having trouble replicating this. Sorry. it seemed so straight forward but now is behaving differently. But thank you, and I'm sorry if I wasted any of your time. And like I said, really am happy to be wrong.

Henkm · 2017-02-20 03:26:47

Trilby wrote:

Hmm. Odd. I'd be curious to know whether removing lines from the history file was a coincidence.

AFAIK, the New York Times has a limit of 10 articles per month for non-subscribers. apl may have tinkered with the history file just when the counter was 'reset'.

Last edited by Henkm (2017-02-20 03:27:03)

0mark · 2017-02-21 11:14:32

I want to get qutebrowser to go automatically go into insert mode when a form field (like input or textarea) is clicked. I tried "auto-insert-mode", but that only goes to insert mode when a input field is focused after loading, not when clicking an input field. Not sure if thats a bug or intended. Anyway, is there a way to get insert-on-click-on-input-or-textarea?

Oh, and, nice browser btw

Trilby · 2017-02-21 11:18:54

Insert on click of a text field is the intended behavior. If you are not getting that it is a bug. But that was a known bug that has been fixed*. Are you using the git version?

(*See posts 388-426 in this thread)

parchd · 2017-02-21 11:39:07

Hmm, I hadn't noticed that it was meant to be fixed - I also don't always get insert on click on some sites/fields - and I do use the git version. Next time I notice it I will make a note of the page.

Trilby · 2017-02-21 11:48:40

There are a few pages that are still problematic. But to my knowledge these are not using input or textfield tags, but rather some flash or similar junk. You could argue that in a perfect world the browser would work with homemade flash input fields too - but I would argue that in a perfect world, flash would not exist.

bstaletic · 2017-02-21 11:54:34

Trilby wrote:

There are a few pages that are still problematic.

Gmail's hangouts interface comes to mind. Should I report it somewhere if it's a known issue?

lahwaacz · 2017-02-21 12:03:02

In short, qutebrowser enters insert mode if it detects that the clicked element is editable. These are the checks it makes - there are already quite a lot of them. The things that are missing are multimedia (as Trilby and the code comments say) and elements with javascript handlers, which will probably never work.

0mark · 2017-02-21 12:13:46

Im going to try the git version. Sorry that i missed that ticket. My google skillz are not my strong side
But i cant get insert-on-click without insert-on-load-when-input-is-focused, right?

*EDIT*: Awesome! It works with the git Version. I guess for the auto-inser-only-on-explicit-click variant i have to ask the author?

Last edited by 0mark (2017-02-21 12:30:10)

Trilby · 2017-02-21 13:00:29

0mark wrote:

But i cant get insert-on-click without insert-on-load-when-input-is-focused, right?
...I guess for the auto-inser-only-on-explicit-click variant i have to ask the author?

To the first question, yes. Just disable that config option if you don't want to automatically enter insert mode on page load. It's still go into insert mode when an input field is focused (via mouse click, hint, or likely tab focus cycling).

As for the second question - no, just disable the config option you don't like.

0mark · 2017-02-21 13:18:58

Oooh, i get it. Now everything makes sense. Its the default behaviour, only that it did not work

Thanks then, thats exactly what i wanted

parchd · 2017-02-21 15:36:11

lahwaacz wrote:

In short, qutebrowser enters insert mode if it detects that the clicked element is editable. These are the checks it makes - there are already quite a lot of them. The things that are missing are multimedia (as Trilby and the code comments say) and elements with javascript handlers, which will probably never work.

I guess the problems I've had fall into the latter category - just realised that one of the fields that doesn't work is the message entry field in Office 365's Outlook. Luckily none of the keybindings I've accidentally triggered have ever done anything dramatic .

The Compiler · 2017-02-21 21:53:16

Are there people here who have custom scripts interacting with qutebrowser's on-disk data files (history/quickmarks/bookmarks/...) or otherwise rely on them being plaintext (e.g. syncing with git and conflicts)? If so, please participate in the discussion in this issue, I'm trying to get a picture of how feasible it is to switch things to sqlite on-disk (pretty much decided for the history though).

Trilby · 2017-02-21 23:33:07

I'm all for it. Any scripts relying on them to be plain text could be rewritten to use sqlite queries. This would require the script authors know a little sql, but they'd benefit from their scripts likely being faster and/or more efficient (if for no other reason than not being able to get away with ridiculous pipelines of grep -> awk -> sed). I'd be happy to help translate any scripts to use sqlite if needed.

wkd · 2017-02-25 14:27:05

Storing history and cookies in a database would be fine, but bookmarks/quickmarks should remain plaintext. It just makes organizing, editing and transferring them very convenient.

Arch Linux

#451 2017-02-13 23:14:40

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

#452 2017-02-14 00:50:03

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

#453 2017-02-14 07:36:23

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

#454 2017-02-14 07:39:27

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

#455 2017-02-14 09:20:23

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

#456 2017-02-14 11:57:32

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

#457 2017-02-16 19:15:40

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

#458 2017-02-16 20:37:50

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

#459 2017-02-16 22:43:47

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

#460 2017-02-16 23:09:07

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

#461 2017-02-16 23:48:52

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

#462 2017-02-20 03:26:47

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

#463 2017-02-21 11:14:32

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

#464 2017-02-21 11:18:54

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

#465 2017-02-21 11:39:07

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

#466 2017-02-21 11:48:40

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

#467 2017-02-21 11:54:34

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

#468 2017-02-21 12:03:02

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

#469 2017-02-21 12:13:46

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

#470 2017-02-21 13:00:29

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

#471 2017-02-21 13:18:58

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

#472 2017-02-21 15:36:11

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

#473 2017-02-21 21:53:16

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

#474 2017-02-21 23:33:07

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

#475 2017-02-25 14:27:05

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

Board footer