QtWebEngine recieves rogue tab keypresses

[prosoitos]

Version info:

qutebrowser v1.5.2
Git commit:
Backend: QtWebEngine (Chromium 69.0.3497.128)

CPython: 3.7.2
Qt: 5.12.1
PyQt: 5.12

sip: 4.19.14
colorama: no
pypeg2: 2.15
jinja2: 2.10
pygments: 2.3.1
yaml: 3.13
cssutils: no
attr: 18.2.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebKitWidgets: yes
pdf.js: 2.0.943 (/usr/share/pdf.js/build/pdf.js)
sqlite: 3.27.1
QtNetwork SSL: OpenSSL 1.1.1a 20 Nov 2018

Style: QFusionStyle
Platform: Linux-4.20.8-arch1-1-ARCH-x86_64-with-arch, 64bit
Linux distribution: Arch Linux (arch)
Frozen: False
Imported from /usr/lib/python3.7/site-packages/qutebrowser
Using Python from /usr/bin/python3
Qt library executable path: /usr/lib/qt/libexec, data path: /usr/share/qt

Does the bug happen if you start with --temp-basedir?:

Yes

Description

The position on a webpage is sometimes properly maintained and sometimes lost when jumping back and forth between a qutebrowser window and another window.

Details

I jump very often between windows of different applications using keybindings of my window manager (EXWM).

Sometimes the scroll position on a webpage is properly maintained when I jump back to it. Sometimes it is shifted. Quite often the page is scrolled back up to the top and I have to scroll back down to where I was.

I believe that this behaviour is quite recent (maybe a month or two?). I don't remember ever having this issue before.

[jgkamat]

Can you reproduce in kde falkon as well?

…

On February 15, 2019 1:56:12 AM PST, Marie-Helene Burle ***@***.***> wrote: **Version info**: qutebrowser v1.5.2 Git commit: Backend: QtWebEngine (Chromium 69.0.3497.128) CPython: 3.7.2 Qt: 5.12.1 PyQt: 5.12 sip: 4.19.14 colorama: no pypeg2: 2.15 jinja2: 2.10 pygments: 2.3.1 yaml: 3.13 cssutils: no attr: 18.2.0 PyQt5.QtWebEngineWidgets: yes PyQt5.QtWebKitWidgets: yes pdf.js: 2.0.943 (/usr/share/pdf.js/build/pdf.js) sqlite: 3.27.1 QtNetwork SSL: OpenSSL 1.1.1a 20 Nov 2018 Style: QFusionStyle Platform: Linux-4.20.8-arch1-1-ARCH-x86_64-with-arch, 64bit Linux distribution: Arch Linux (arch) Frozen: False Imported from /usr/lib/python3.7/site-packages/qutebrowser Using Python from /usr/bin/python3 Qt library executable path: /usr/lib/qt/libexec, data path: /usr/share/qt **Does the bug happen if you start with `--temp-basedir`?**: Yes **Description** The position on a webpage is sometimes properly maintained and sometimes lost when jumping back and forth between a qutebrowser window and another window. **Details** I jump very often between windows of different applications using keybindings of my window manager (EXWM). Sometimes the scroll position on a webpage is properly maintained when I jump back to it. Sometimes it is shifted. Quite often the page is scrolled back up to the top and I have to scroll back down to where I was. I believe that this behaviour is quite recent (maybe a month or two?). I don't remember ever having this issue before. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #4579

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[prosoitos]

I don't know. I don't have falkon installed. If it is important, I guess I could install it.

[user202729]

On which websites do this happen? All of them?

[The-Compiler]

Would indeed be good if you could try to reproduce this with Falkon, so we know whether it's a QtWebEngine or a qutebrowser issue.

The size of the windows doesn't change when you do this, right? Not sure what's going on, I've never seen this FWIW.

[prosoitos]

On which websites does this happen? All of them?

Not sure whether it happens on all sites as I never really paid attention to that. The behaviour is also very inconsistant (for instance, I can do this jumping back and forth 2 or 3 times in a row fine and on the 4th time it will jump back to the top. On other occasions, it jumps back to the top right from the first time I leave the qutebrowser window and go back to it).

I know for sure that it does it on the Arch Wiki, on the Emacs Wiki, and on the LaTeX Wikibook websites because I do a lot of jumping back and forth from those sites (reading things and implementing them in my files or cli). Can't remember for sure about other sites.

The size of the windows doesn't change when you do this, right?

No, it does not. It's just that the scrolling position is lost. Most often I am back at the top, some other time I am still near-ish the area of the page where I previously was, but not the same place.

Would indeed be good if you could try to reproduce this with Falkon, so we know whether it's a QtWebEngine or a qutebrowser issue.

Ok. Will do.

[prosoitos]

Of note, in case it matters at all: I am using EXWM as my window manager. So the jumping back and forth I do is one of:

• jumping to another workspace, then coming back to the workspace in which qutebrowser is, or

• jumping to another window within the same workspace. EXWM is a tiling window manager and I like my windows big, so I seldom have several windows visible at once. So I jump from only qutebrowser visible in the current window to only some other app visible in the current window, and then back to only qutebrowser visible in the current window.

And I do this with Emacs keybindings. The problem can happen in both situations.

As I wrote earlier, this was not happening until some time ago.

[prosoitos]

Actually, you might have a point @user202729: I am trying to trigger the problem on various sites right now. I am failing to have it happen on this page, but it happens all the time on the Arch Wiki pages. So it seems that it does depend on the website.

That said, because of the inconsistency of the behaviour, it is hard to be sure.

edit: I was wrong. It actually does it on GitHub too. I think that it can do it on any website...

[prosoitos]

Same thing happens with Falkon...

Which is bad news for me I guess as you probably will not be able to do anything about it then. No? Should I close this issue and open an issue on the qtwebengine GitHub? edit: seems that I can't open issues there.

[prosoitos]

As a way to go back to where I was in the page faster, I tried to use set_mark and jump_mark and they work quite poorly. jump_mark gets me kind of in the area of the mark, but it is very far from accurate (I am not talking of a few lines off, but maybe a page or so). I had played with these functions a little when I first started using qutebrowser and I remember them as working much better than this.

Not sure whether there is any link with the current issue or whether I should open a new one.

edit: thanks for @codesections for pointing out that there is already an issue on this at #4013. I now have a HiDPI machine and use a default zoom of 140%. That's what is different from my early tries of these functionalities.

[jgkamat]

Marie-Helene Burle writes:

Which is bad news for me I guess as you probably will not be able to do anything about it then. No? Should I close this issue and open an issue [on the qtwebengine GitHub](https://github.com/qt/qtwebengine)? _edit: seems that I can't open issues there._

qtwebengine isn't developed on github, you'll need to file a qtbug on their issue tracker if you want to properly report an issue. You'll probably want to provide a minimal test-case that dosen't involve exwm though.

[prosoitos]

Mmmm... to do that, I would have to install another Window Manager... I am not sure I want to get into that.

I can run qutebrowser without launching EXWM, but then I cannot jump back and forth between windows, which is what causes the problem behaviour.

And since I seem to be the only one having this problem, it might be that I would not have it with i3, openbox or whatever. It used to work just fine though (and I was already using EXWM).

[prosoitos]

No idea whether this is of any interest, but the same thing happens on a page with a pdf (with pdfjs).

[codesections]

I can add an additional data point here, in case it's helpful.

I am experiencing the same issue, and it appears that it might be triggered by qutebrowser believing it has received an extra <TAB> key press, which modifies the scroll position. (Though other applications do not receive that key press when changing windows).

I can also add some info about the window manager. I do not experience the issue when using dwm, but I do when using stumpwm. Stumpwm, like exwm, is built in Lisp—I note that as an interesting commonality, though I'm not sure how it could be related.

update
I determined that, while this bug does not occur on other browsers, it does occur on webmacs, another qtwebengine browser. In addition to the testing with falcon, this strongly indicates that it is an upstream bug.

2nd update
Running qutebrowser --backend webkit is a (not great) workaround for this issue, which confirms that it's an upstream qtwebengine issue. It would be great to get an bug report opened up there, but I'm not familiar with the Qt bug process, and it looks like reporting issues is a fairly involved procedure (at least compared to opening a github/gitlab issue).

[codesections]

One possible work-around is to use set-mark and jump-mark to return to the previous scroll position (which, depending on the WM, could probably be automated with each window jump). I haven't been able to implement this work around, though, because I ran into #4013, which means that set-mark and jump-mark don't work properly for me.

[prosoitos]

Thanks for your additional info! The Lisp thing is interesting...

I am also using a default zoom different from 100% and that explains my comments above in this thread about set_mark and jump_mark working poorly. I hadn't spotted #4013. Thank you for pointing it out to me. At least, now I know why this is, that it is not related to the current issue, and that an issue is already open.

I would very much love for this to be addressed as I do a lot of this jumping back and forth and this is a rather big issue for me. I am in the same boat re-posting an issue upstream. Keen to help with the process though (if I can).

Glad to hear that I am not the only one affected. At least, your observations seem to rule out that it is something weird in my settings and indicate that it is more likely something to do with my WM (as I kind of suspected).

[user202729]

If that's the case, bind <tab> :nop would be a possible workaround for the issue.

[prosoitos]

If that's the case, bind <tab> :nop KP-FG would temporarily solve the issue.

Would you mind giving a little explanation please? Thanks!

[codesections]

If that's the case, bind <tab> :nop would be a possible workaround for the issue.

@user202729 that does solve it! Thanks so much—I don't know why that didn't occur to me.

Would you mind giving a little explanation please? Thanks!

The work-around is to re-bind the <tab> to do nothing (instead of sending a <tab> to the webpage). To do this, you can enter :bind <tab> nop in qutebrowser's command mode. ("nop" stands for "no operation", that is, do nothing.)

Equivalently, you can add the following to your .config/qutebrowser/config.py file:

c.bindings.commands = {
        'normal': {
            '<tab>': 'nop',
            }
        }

(If you have other bindings set in your config.py file, you'd need to merge this in with that config dict)

[prosoitos]

Should I understand that you are switching windows with Alt+Tab as is the case on Windows? I am still confused.

To unbind a key, one can also do:

config.unbind('<tab>', mode='normal')

But I still don't get the point (unless you use Alt+Tab to switch windows). What am I missing?

In my case, my jumping back and forth occurs with various keybindings set through EXWM and none of them involve the <tab> key.

[codesections]

Should I understand that you are switching windows with Alt+Tab as is the case on Windows? I am still confused.

No, I am not pressing tab at all to switch windows.

I am switching with <C-SPC> + a, actually, but the actual keys aren't important.

What I am saying is

it appears that [the bug] might be triggered by qutebrowser believing it has received an extra <TAB> key press, which modifies the scroll position. (Though other applications do not receive that key press when changing windows).

That is, for some reason, qutebrowser/qtwebengine is acting as though it received a <tab> press, even though we never sent one. Based on thinking it got a tab press, it is changing the scroll position of the page (just as it would if we actually pressed <tab>). Thus, the temporary work-around is to rebind <tab> to nop. That way, qutebrowser still (incorrectly) gets an extra <tab>, but that doesn't change the scroll position at all.

[prosoitos]

Oh, I see. Thank you! I had missed that comment of yours and was totally confused.

I will certainly try this!!

edit: Too soon to be sure, but it seems to have solved it. Thank you sincerely @codesections for pinpointing the problem to an extra TAB sent somehow, to explain to me the advice of @user202729 which I failed to understand (having missed your previous comment) and to explain how to add this to my config file.

Seems that this is also solving #4600 🙂

And thanks @user202729 for suggesting workarounds for both problems!!

[prosoitos]

Out of curiosity @codesections, you don't happen to have any issues on Twitter (if you use that site)? #4108 is closed but I still have the problem. I wonder now whether it could be some other keys being sent when they shouldn't and if it isn't a similar sort of problem...

[codesections]

I don't use Twitter, and haven't encountered any issue like that on Mastodon (the Twitter-like site that I do use). Sounds pretty odd!

[prosoitos]

Closing this as the workaround works (even if it is still unclear what is really going on). It also solved #4600 and #4108.

[prosoitos]

Sounds pretty odd!

Yes, it was totally crazy. But the workaround for this issue actually solved that too (even if the behaviour was very different than what TAB would do, which is quite puzzling).

[amenl]

Here is another finding to that issue.
The tab problem doesn't occur when I open a link/quickmark in a new tab (this was known). But it also doesn't occur when I open the same link in the same tab, whereas if it's a different link, the tab gets sent (which in my case results in tab-next, kind of annoying).

[The-Compiler]

Can people who still see this mention on which Qt versions you are? I still suspect this is due to QTBUG-76268 which means it should be fixed in Qt 5.12.5, 5.13.1 and 5.14.

[amenl]

Most qt5 packages I see show version 5.13.1-1 (arch linux), upgraded some days ago. the problem persists.

[arza-zara]

On archlinux with openbox, upgrading qt5-webengine 5.13.0-4 -> 5.13.1-1 fixes it for me.

[dschrempf]

I am also on archlinux, the problem seems to be gone! Version 5.13.1-3.

[amenl]

I tried every possible qt5-webengine package in the last months and reinstalled all of the packages to no avail. The only thing that works is using webkit as backend. I'm not sure if this is a good solution.
It is a bit unsatisfying.

[amenl]

What's interesting...

I keep 3 machines (all Arch Linux) in sync (config + most packages). All 3 are up to date and show the same erroneous bahaviour.

The only changes that work are following:

• uncommenting tab key binding
  config.bind('<Tab>', 'tab-next')
• setting webkit backend
  config.set('backend', 'webkit')

So I encourage everyone to bind Tab to tab-next and check the result.
(erroneous result would occur when opening a link with a different domain name (!) in the same tab would trigger a tab-next action)

[PluMGMK]

Guys, this is kind of embarrassing, but I figured out what's causing it in my case, and it was kind of obvious. I have had "statusbar.hide" on for years now, and disabling it got rid of this problem.
Seems that the act of hiding the statusbar, when a command is finished, automatically sends a tab to WebEngine…

[The-Compiler]

@PluMGMK You might be seeing #2236.

[amenl]

@PluMGMK Makes no difference for me. Still same ol'..

[PluMGMK]

Yeah, looks like I've been following the wrong issue all along. One would like to think they're related though…

[The-Compiler]

From Reddit, this apparently seems to (differently) affect newer Qt versions as well:

https://www.reddit.com/r/qutebrowser/comments/fkohq7/return_triggers_tabnext_after_keybind_to_tab/

[adigitoleo]

Hi,

So I just switched from i3 to bspwm and am now experiencing this as well. It wasn't happening on i3 (i3-gaps). I think it's only happening in normal mode. Happens when showing the previously hidden qutebrowser window in any way (mod+, rofi, etc.). I have bound to tab-next so it's a bit disorienting.

My qutebrowser info

qutebrowser v1.13.1
Git commit: 
Backend: QtWebEngine (Chromium 80.0.3987.163)
Qt: 5.15.1

CPython: 3.8.5
PyQt: 5.15.1

sip: 5.4.0
colorama: 0.4.3
pypeg2: 2.15
jinja2: 2.11.2
pygments: 2.7.1
yaml: 5.3.1
cssutils: no
attr: 20.2.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebEngine: 5.15.1
PyQt5.QtWebKitWidgets: no
pdf.js: no
sqlite: 3.33.0
QtNetwork SSL: OpenSSL 1.1.1h  22 Sep 2020

Style: Kvantum::Style
Platform plugin: xcb
OpenGL: Intel, 4.6 (Compatibility Profile) Mesa 20.1.8
Platform: Linux-5.8.10-arch1-1-x86_64-with-glibc2.2.5, 64bit
Linux distribution: Arch Linux (arch)
Frozen: False
Imported from /usr/lib/python3.8/site-packages/qutebrowser
Using Python from /usr/bin/python3
Qt library executable path: /usr/lib/qt/libexec, data path: /usr/share/qt

Paths:
cache: /home/leon/.cache/qutebrowser
config: /home/leon/.config/qutebrowser
data: /home/leon/.local/share/qutebrowser
runtime: /run/user/1000/qutebrowser
system data: /usr/share/qutebrowser

Autoconfig loaded: no
Config.py: /home/leon/.config/qutebrowser/config.py has been loaded
Uptime: 0:14:52

[toofar]

I think we can remove these with a patch like this:

diff --git i/qutebrowser/keyinput/eventfilter.py w/qutebrowser/keyinput/eventfilter.py
index 31ffcc7f9b34..30737090d19f 100644
--- i/qutebrowser/keyinput/eventfilter.py
+++ w/qutebrowser/keyinput/eventfilter.py
@@ -85,12 +85,17 @@ class EventFilter(QObject):
 
         Return:
             True if the event should be filtered, False if it's passed through.
         """
         if not isinstance(obj, QWindow):
             # We already handled this same event at some point earlier, so
             # we're not interested in it anymore.
             return False
 
+        if not obj.isVisible() and obj.objectName() == 'QQuickWidgetOffscreenWindow':
+            print(f"Ignoring event from QtQuick offscreen window {event.type()=}")
+            return False
+
         typ = event.type()
 
         if typ not in self._handlers:

Because the KeyEvents (which are the only ones we are handling here) are being sent to the offscreen window. We probably don't need to be handling key events to that? We are only getting them because we have a global event filter.

I'm not sure if we should be returning False here or just not calling out to our handlers.

[The-Compiler]

I think this was fixed in Qt at some point. Can't reproduce anymore even with Qt 5: python3 -m qutebrowser -s qt.chromium.sandboxing disable-all --qt-wrapper PyQt5 --temp-basedir ':bind <Tab> message-info foo'