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

apl · 2017-01-28 15:18:11

I'm using qutebrowser, although I'm not sure this is a qutebrowser issue. I'm getting a 404 error for plus.goolgle.com community pages. Any help would be very appreciated.

Trilby · 2017-01-28 15:38:26

That is not a qutebrowser issue. Confirm by trying another browser. Can you give an actual url that is failing? I gather the domain in your post was a typo.

apl · 2017-01-28 16:27:01

I didn't think it would be a qutebrowser issue. Yes that is a typo. I get the 404 when I go here:

https://plus.google.com/

I installed dillo just as a quick way of checking and get the 404 there as well, while this page opens on my partners chromebook. Not sure how to figure this out....

nassi · 2017-01-28 17:12:15

apl wrote:

I didn't think it would be a qutebrowser issue. Yes that is a typo. I get the 404 when I go here:
https://plus.google.com/
I installed dillo just as a quick way of checking and get the 404 there as well, while this page opens on my partners chromebook. Not sure how to figure this out....

Seems like I also get a 404 error when opening said link with qutebrowser. On Chrome it works fine and redirects me to https://plus.google.com/collections/featured, but even that link doesn't work in qutebrowser. Doesn't work with lynx either it seems.

Similar behaviour on my laptop: works fine on Chromium, but displays a 404 error on qutebrowser.

Trilby · 2017-01-28 18:59:16

Qutebrowser with webkit redirects as noted above. Qutebrowser with webengine doesn't redirect. Niether one produces a 404 for me.

But in any case, this seems like a server side issue. It is selectively redirecting based on the user agent ... which is just silly.

apl · 2017-01-28 22:47:35

Thanks Trilby, you set me on the right path. Installed Chromium - link worked. Copied the Chromium user-agent string, pasted it into qutebrowsers user-agent setting and all now works fine. Silly is right, I hate it when something makes me waste my time this way, Thanks again

WorMzy · 2017-01-29 15:35:25

WorMzy wrote:

Is there a hidden setting or something that stops the browser entering input mode when textboxes/areas are focused, and only enters input mode when explicitly told to (by pressing 'i')?
Something in my .cache/qutebrowser folder seems to be causing this behaviour, since starting the browser with a fresh cache restores the normal behaviour (lets me enter input mode on textbox/area focus again without having to press 'i'). I have a suspicion that my cat accidentally (or purposely, who knows with cats?) hit a key combination when walking accross my keyboard that toggled *something*, but nothing under :set input seems relevant to the problem (and starting with a fresh config did not resolve the problem, although a fress config did start with my old session, so perhaps there's a session-specific option for this behaviour?).
EDIT: the old cache folder is now working, so I can't check if this is a session-specific behaviour at the moment.

Just as a follow-up to this, I re-encountered the problem after upgrading to qt 5.8. No matter what I removed (cache/config/shared), the problem remained. However, if I opened qutebrowser with --debug, I could not reproduce the behaviour. A new user did not have the same problem, and a qutebrowser instance in a stand-alone X session under the affected user also did not suffer from the problem.

I can only assume at this point that something in my dotfiles is causing problems, and not something in qutebrowser. I'm currently in the process of migrating my dotfiles to a fresh profile, so if I identify what was causing the problem, I'll post it in this topic. EDIT: was using the webkit backend by mistake.

Last edited by WorMzy (2017-01-30 16:25:06)

Baryon · 2017-01-29 17:12:00

I've just started using qutebrowser and really like it!

But there is an issue when I run it with the qt-webengine backend: it doesn't auto-login to websites (e.g. this forum) when I restart the program. However this works fine using the webkit backend. I'm just wondering if it's supposed to work at this stage or is that just not yet implemented?

Trilby · 2017-01-29 17:16:14

Baryon, it works fine for me. However, cookies are stored separately for webengine and webkit. So the first time you visit sites like this one with webengine you will need to log in - and just like webkit or any other browser, you need to select the "remember me" or "keep me logged in" option on the website.

Baryon · 2017-01-29 17:30:55

Trilby wrote:

Baryon, it works fine for me. However, cookies are stored separately for webengine and webkit. So the first time you visit sites like this one with webengine you will need to log in - and just like webkit or any other browser, you need to select the "remember me" or "keep me logged in" option on the website.

Thanks for the reply. Yes I've checked the checkbox and I've tested with multiple sites, but every time I restart the browser I have to log back in to everything I had been logged in to. It saves the session, just not the logins.

What I have noticed is that every time I start the program, the .local/share/qutebrowser/webengine/Cookies file reduces in size, and also the Cookies-journal file is always empty.

Trilby · 2017-01-29 17:39:54

@Baryon, have you checked the cookie settings in your config?

@WorMzy, the update to qt5-webengine 5.8.0 has led me to struggle with the issue you seem to be dealing with. For me it is now with every input field on every website I've been able to find. I have the autoinsert setting enabled, so if there is a focused text field when the page loads, I can enter text (e.g. google.com, duckduckgo.com) but if I hit 'esc' or click anywhere else on the page, then click back on the text field, I cannot enter text until I explicitly hit 'i' first.

On pages where no input field is focused on load, clicking on a text field is similarly insufficient: I must hit 'i' before I can type anything.

This can be really frustrating especially when what you are tying starts with bound keys. I just came here to edit the draft of this post to add "duckduckgo" after "google" in the paragraph above. I clicked on the text box and started typing 'duck...' but the d closed the page!

EDIT: this is webengine specific for me. I'm going to try the above-mentioned "--debug" flag in a moment.
EDIT2: no difference with "--debug" for me. I still have to explicitly hit 'i' to type in any input field.

I do get the below debug output from clicking on a text field (this was from clicking on a text field on these forums):

12:43:26 DEBUG    misc       app:on_focus_object_changed:768 Focus object changed: <PyQt5.QtWidgets.QWidget object at 0x7fe781035438>
12:43:26 DEBUG    misc       app:on_focus_object_changed:768 Focus object changed: <PyQt5.QtCore.QObject object at 0x7fe781035438>
12:43:26 DEBUG    modes      modeman:_eventFilter_keyrelease:211 filter: False
12:43:26 DEBUG    mouse      mouse:eventFilter:213 Ignoring QMouseEvent to <PyQt5.QtWidgets.QWidget object at 0x7fe781035438> which is not an instance of <class 'PyQt5.QtWidgets.QOpenGLWidget'>
12:43:26 DEBUG    mouse      mouse:eventFilter:213 Ignoring QMouseEvent to <PyQt5.QtWidgets.QWidget object at 0x7fe781035438> which is not an instance of <class 'PyQt5.QtWidgets.QOpenGLWidget'>
12:43:28 DEBUG    modes      modeman:_eventFilter_keypress:166 got keypress in mode KeyMode.normal - delegating to <qutebrowser.keyinput.modeparsers.NormalKeyParser>
12:43:28 DEBUG    keyboard   basekeyparser:_debug_log:112 Ignoring only-modifier keyeevent.
12:43:28 DEBUG    keyboard   basekeyparser:_debug_log:112 Got key: 0x1000023 / text: ''
12:43:28 DEBUG    keyboard   basekeyparser:_debug_log:112 Ignoring, no text char
12:43:28 DEBUG    modes      modeman:_eventFilter_keypress:191 handled: False, forward-unbound-keys: auto, passthrough: False, is_non_alnum: True --> filter: False (focused: <PyQt5.QtWidgets.QWidget object at 0x7fe7810354c8>)
12:43:29 DEBUG    misc       app:on_focus_object_changed:768 Focus object changed: None

Those lines saying it ignored the mouse click because it was not an instance of an OpenGLWidget seem odd to me.

Last edited by Trilby (2017-01-29 17:41:29)

WorMzy · 2017-01-29 17:45:57

@Trilby: Yes, that's exactly the behaviour I've been having, so I'm glad it's not just me. I didn't try downgrading anything since new users and dedicated X servers don't seem to be affected, but perhaps there is a problem with qutebrowser or qt5-webengine after all. EDIT: disregard, was using the webkit backend by mistake.

Last edited by WorMzy (2017-01-30 16:18:10)

lahwaacz · 2017-01-29 17:50:29

Yep, the 'Ignoring QMouseEvent' message is the problem. Commenting out these lines fixed the problem for me, as well as this one. But I'm sure they are there for a reason...

Baryon · 2017-01-29 17:58:30

Trilby wrote:

@Baryon, have you checked the cookie settings in your config?

Yes. cookies-store is true and I've tried cookies-accept=no-3rdparty and cookies-accept=all, but cookies still aren't saved. As soon as I switch to webkit then the logins from my last webkit session are there.

(And FWIW the auto-insert works fine for me.)

lahwaacz · 2017-01-29 18:04:00

@Baryon, there is also general->private-browsing - though if that is the culprit, the option must be completely broken on webkit.

WorMzy · 2017-01-29 18:05:11

Whelp, disregard my previous messages, I wasn't running with the webengine backend. I forgot that I created a .desktop file to override the system one so that webengine was always used.

On a side note: webkit's gotten better at displaying flex boxes, I didn't even notice I was using that backend.

Baryon · 2017-01-29 18:41:34

So the problem was that I didn't have the latest versions of qt5 and qt5-webengine. So now the cookies problem is fixed and I get the auto-insert problem instead. But at least I'm up to date

stupidus · 2017-01-29 22:42:01

I have a sort of general question about qutebrowser and more specifically the webengine backend. The way I want my browsers to work is that all the browsing data (history, cookies, cache etc.) is deleted whenever I close the browser. Up to now I was using a script that deletes the contents of the cookie and history files. However, one of your comments above about the webengine backend storing its own cookies got me thinking. A quick test with a login on this forum showed, that the corresponding cookie actually seems to be deleted after restarting qutebrowser. However, I am not sure how, considering that it is not in the ~/.local/share/qutebrowser/cookies file and that was up to now the only cookie related file I was deleting.

Anyway, I modified my qutebrowser startup script to look like this now:

#!/bin/bash

function finish {
    echo > ~/.local/share/qutebrowser/history
    echo > ~/.local/share/qutebrowser/cmd-history
    echo > ~/.local/share/qutebrowser/cookies
    rm -r ~/.local/share/qutebrowser/webengine/*
}

qutebrowser --backend webengine

trap finish EXIT

Can you think of any negative consequences of deleting the contents of the webengine folder everytime I close qutebrowser?

Trilby · 2017-01-29 23:51:15

I don't see a problem with that. However, that got me to clean up my cookies. Unfortunately, I removed one that I wanted. I found I couldn't add it back ... through some experimenting I found that the webengine backend is completely unable to store any new cookies now. Along the way to discovering this, I cleared out the ~/.local/share folder, so all my old cookies are gone and no matter what I do, no new cookies will be saved with webengine.

I did find a likely relevant problem: qutebrowser with backend=webengine does not seem to exit cleanly regardless of how I close it. It segfaults on shutdown every time. When run from a terminal I get this output:

Current thread 0x00007f572e763400 (most recent call first):
  File "/usr/lib/python3.6/site-packages/qutebrowser/app.py", line 122 in qt_mainloop
  File "/usr/lib/python3.6/site-packages/qutebrowser/app.py", line 112 in run
  File "/usr/lib/python3.6/site-packages/qutebrowser/qutebrowser.py", line 169 in main
  File "/usr/bin/qutebrowser", line 11 in <module>
Segmentation fault (core dumped)

I suspect the unclean shutdown is the reason for the cookies to not be saved to disk. I'll try again in a moment with the debug flag to get some more info.

EDIT: debug output actually seems counter to my suspicion: saving cookies fails or is skipped well before the seg fault is triggered:

18:51:45 DEBUG    commands   command:run:509 command called: quit
18:51:45 DEBUG    commands   command:run:524 Calling qutebrowser.app.Quitter.shutdown(<qutebrowser.app.Quitter object at 0x7f152199ac50>)
18:51:45 DEBUG    destroy    app:shutdown:640 Shutting down with status 0, session None...
18:51:45 DEBUG    prompt     prompt:shutdown:127 Shutting down with loops []
18:51:45 DEBUG    destroy    app:_shutdown:667 Stage 2 of shutting down...
18:51:45 DEBUG    destroy    app:_shutdown:673 Removing eventfilter...
18:51:45 DEBUG    destroy    mainwindow:_do_close:503 Closing window 0
18:51:45 DEBUG    misc       app:on_focus_object_changed:768 Focus object changed: <qutebrowser.mainwindow.tabwidget.TabBar count=0>
18:51:45 DEBUG    ipc        ipc:shutdown:398 Shutting down IPC (socket 0x7f152601af00)
18:51:45 DEBUG    save       savemanager:save:97 Save of version requested - dirty False, save_on_exit True, is_exit True, force False -> True
18:51:45 DEBUG    save       savemanager:save:90 Not saving config because autosaving has been disabled by general -> auto-save-config.
18:51:45 DEBUG    save       savemanager:save:90 Not saving key-config because autosaving has been disabled by general -> auto-save-config.
18:51:45 DEBUG    save       savemanager:save:97 Save of state-config requested - dirty False, save_on_exit True, is_exit True, force False -> True
18:51:45 DEBUG    destroy    ini:save:72 Saving config to /home/jmcclure/.local/share/qutebrowser/state
18:51:45 DEBUG    save       savemanager:save:97 Save of command-history requested - dirty False, save_on_exit False, is_exit True, force False -> False
18:51:45 DEBUG    save       savemanager:save:97 Save of history requested - dirty True, save_on_exit False, is_exit True, force False -> True
18:51:45 DEBUG    destroy    lineparser:_after_save:82 Saved to /home/jmcclure/.local/share/qutebrowser/history
18:51:45 DEBUG    save       savemanager:save:97 Save of quickmark-manager requested - dirty False, save_on_exit False, is_exit True, force False -> False
18:51:45 DEBUG    save       savemanager:save:97 Save of bookmark-manager requested - dirty False, save_on_exit False, is_exit True, force False -> False
18:51:45 DEBUG    save       savemanager:save:97 Save of cookies requested - dirty False, save_on_exit False, is_exit True, force False -> False
18:51:45 DEBUG    destroy    app:_shutdown:701 Deactivating crash log...
18:51:45 DEBUG    destroy    app:_shutdown:711 Deactivating message handler...
18:51:45 DEBUG    destroy    app:_shutdown:714 Deferring QApplication::exit...
18:51:45 DEBUG    modes      modeman:_eventFilter_keypress:191 handled: True, forward-unbound-keys: auto, passthrough: False, is_non_alnum: True --> filter: True (focused: None)
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: 0
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: tab
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: hintmanager
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: 0
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: main-window
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: last-focused-main-window
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: last-visible-main-window
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: message-bridge
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: qtnetwork-download-manager
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: statusbar
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: status-command
18:51:45 DEBUG    destroy    objreg:on_destroyed:125 schedule removal: tabbed-browser
Fatal Python error: Segmentation fault

Current thread 0x00007f1526810400 (most recent call first):
  File "/usr/lib/python3.6/site-packages/qutebrowser/app.py", line 122 in qt_mainloop
  File "/usr/lib/python3.6/site-packages/qutebrowser/app.py", line 112 in run
  File "/usr/lib/python3.6/site-packages/qutebrowser/qutebrowser.py", line 169 in main
  File "/usr/bin/qutebrowser", line 11 in <module>
Segmentation fault (core dumped)

I need to check the issue tracker for anything like this and I'll open issues momentarily if these are new.

EDIT 2: I don't see issues for either of these on github. But as I did some repeated tests before opening the seg fault issue, I found it doesn't happen with a current git build, only with the version from [community]. Perhaps this should go to the archlinux bug tracker to get a rebuild of the community package if anyone else can confirm the segfault on exit with [community]/qutebrowser. I did create an issue for the failure to save cookies.

Last edited by Trilby (2017-01-29 23:56:02)

jasonwryan · 2017-02-01 22:03:36

I followed the brief discussion here: https://bbs.archlinux.org/viewtopic.php … 7#p1622537 but I have had no luck handing mailto links off to mutt.

I have a desktop file (that works in, eg. chromium):

xdg-mime query default 'x-scheme-handler/mailto'
mutt.desktop

but qutebrowser keeps defaulting to $BROWSER for those links. Am I missing something obvious?

lahwaacz · 2017-02-01 22:36:55

Does `xdg-open "mailto:jwr"` open up mutt? There is an open_generic function in it which looks somewhat like this:

open_generic()
{
    if is_file_url_or_path "$1"; then
        ...
    fi

    if [ -n "$BROWSER" ]; then
        open_envvar "$1"
    fi

    if [ -n "$DISPLAY" ]; then
        open_generic_xdg_x_scheme_handler "$1"
    fi

    ...
}

Note that the XDG scheme handler is only a fallback after $BROWSER...

Last edited by lahwaacz (2017-02-01 22:42:20)

jasonwryan · 2017-02-01 22:59:49

No, it doesn't. But it should fall through to:

open_generic_xdg_x_scheme_handler()
{
    scheme="`echo $1 | sed -n 's/\(^[[:alnum:]+\.-]*\):.*$/\1/p'`"
    if [ -n $scheme ]; then
        filetype="x-scheme-handler/$scheme"
        open_generic_xdg_mime "$1" "$filetype"
    fi
}

edit: NVM: kept reading and see what you mean. That is stupid...

Changing the order of the tests (DISPLAY before BROWSER) elicits the correct behaviour.

Trilby · 2017-02-02 17:09:59

Are others (in addition to me and WorMzy) affected by the failure to enter insert mode when input boxes are selected (with webengine)?

More specifically, is anyone using webengine and not affected by this? I don't see an issue on the tracker yet and would like to open one if this is a real problem.

WorMzy · 2017-02-02 17:23:09

It's (mostly) fixed in -git (v0.9.0-52-gba2f4fb1b). I've experienced one instance of the behaviour recurring, but that was after enabling plugins and watching a flash video, so I'm not sure it was related, and I haven't been able to reproduce it since.

Trilby · 2017-02-02 17:32:52

Ah, thanks! Indeed it is. I seem to have been just a few commits behind that still. A rebuild has it working fine.

Arch Linux

#401 2017-01-28 15:18:11

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

#402 2017-01-28 15:38:26

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

#403 2017-01-28 16:27:01

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

#404 2017-01-28 17:12:15

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

#405 2017-01-28 18:59:16

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

#406 2017-01-28 22:47:35

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

#407 2017-01-29 15:35:25

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

#408 2017-01-29 17:12:00

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

#409 2017-01-29 17:16:14

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

#410 2017-01-29 17:30:55

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

#411 2017-01-29 17:39:54

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

#412 2017-01-29 17:45:57

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

#413 2017-01-29 17:50:29

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

#414 2017-01-29 17:58:30

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

#415 2017-01-29 18:04:00

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

#416 2017-01-29 18:05:11

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

#417 2017-01-29 18:41:34

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

#418 2017-01-29 22:42:01

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

#419 2017-01-29 23:51:15

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

#420 2017-02-01 22:03:36

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

#421 2017-02-01 22:36:55

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

#422 2017-02-01 22:59:49

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

#423 2017-02-02 17:09:59

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

#424 2017-02-02 17:23:09

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

#425 2017-02-02 17:32:52

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

Board footer