You are not logged in.

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

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

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

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


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

Offline

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

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

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

Hey, thanks for taking a look at it!

Trilby wrote:

TransientFor windows should never be given input focus.

Ah - learned something new today smile 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.


pkgshackscfgblag

Offline

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

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 748

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

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.

Offline

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

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 748

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

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

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

Offline

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

stupidus
Member
Registered: 2012-02-27
Posts: 124

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

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.

Offline

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

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

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

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.


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

Offline

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

apl
Member
Registered: 2015-01-21
Posts: 13

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

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.

Offline

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

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

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

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?


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

Offline

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

apl
Member
Registered: 2015-01-21
Posts: 13

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

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.

Offline

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

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

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

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.


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

Offline

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

apl
Member
Registered: 2015-01-21
Posts: 13

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

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.

Offline

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

Henkm
Member
From: Dutch living in Malaysia
Registered: 2015-11-11
Posts: 21

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

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)

Offline

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

0mark
Member
From: earth
Registered: 2010-06-09
Posts: 162
Website

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

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 smile


Ceterum autem censeo Systemdinem esse delendam

Offline

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

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

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

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)


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

Offline

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

parchd
Member
Registered: 2014-03-08
Posts: 421

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

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.

Offline

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

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

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

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.


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

Offline

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

bstaletic
Member
Registered: 2014-02-02
Posts: 658

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

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?

Offline

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

lahwaacz
Wiki Admin
From: Czech Republic
Registered: 2012-05-29
Posts: 748

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

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.

Offline

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

0mark
Member
From: earth
Registered: 2010-06-09
Posts: 162
Website

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

Im going to try the git version. Sorry that i missed that ticket. My google skillz are not my strong side wink
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)


Ceterum autem censeo Systemdinem esse delendam

Offline

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

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

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

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.


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

Offline

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

0mark
Member
From: earth
Registered: 2010-06-09
Posts: 162
Website

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

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

Thanks then, thats exactly what i wanted big_smile


Ceterum autem censeo Systemdinem esse delendam

Offline

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

parchd
Member
Registered: 2014-03-08
Posts: 421

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

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

Offline

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

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

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

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


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

Offline

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

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

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

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.


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

Offline

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

wkd
Member
Registered: 2016-04-04
Posts: 23

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

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.

Offline

Board footer

Powered by FluxBB