With QtWebEngine, handling a click (e.g. createWindow being called)
happens some time after a click event has been handled.
When setting override_target, that means we don't know when to set the
override target back, and we can't simply only unset it in createWindow
as elements not causing a new tab to be opened (like an input field) can
be hinted too.
Instead, we now only use override_target with QtWebKit, and simply
generate fake key events with the right modifiers to do the right thing
in createWindow for QtWebEngine.
Fixes#2119.
Before, we used the same logic for QtWebKit and QtWebEngine, where we
simply set an attribute on the tab on a mousePressEvent and then handled
opening links in acceptNavigationRequest.
However, this caused random links to pop up in new tabs (probably to
things being much more async?) on QtWebEngine, so we now handle those
cases in createWindow and only use override_target from the tab there.
Fixes#2102.
We had some funny segfaults reported during scrolling (i.e. with
QApplication.sendEvent), and some code already had to use postpone=True
so there was no segfault...
So now we're back to postEvent again, and eliminated the main reason for
segfaults with it, which was re-using (and -posting) events which had
already been posted.
At least during tests this seems to run stable, let's hope it helps for
the people having crashes as well.
When we hide the context menu on QtWebEngine, we get a mouse event
relative to the QMenu in the filter, which means tab.elements.at_pos
will get called with a negative position (and thus assert) or at least a
wrong position.
From the QApplication.postEvent docs:
http://doc.qt.io/qt-5/qcoreapplication.html#postEvent
The event must be allocated on the heap since the post event queue
will take ownership of the event and delete it once it has been
posted. It is not safe to access the event after it has been posted.
We can't reliably guarantee that from Python, so we need to use
sendEvent instead.
This moves creating the HintManager to AbstractTab, and lets
TabData (which is now a QObject) handle the start_hinting/end_hinting
signal.
For the mouse_event signal of HintManager, we now have a slot in
AbstractTab too, though that might actually be moved to
WebKitTab/WebEngineTab later when needed.
This moves various stuff around and out of QtWebKit code:
- open_target and hint_target are now in TabData, not on the WebPage
- As much as possible got extracted from WebPage.acceptNavigationRequest
to AbstractTab._on_link_clicked, with a new link_clicked signal added
to WebPage. However, we need to decide whether to handle the request
in this tab or not inside acceptNavigationRequest, so we have some
code duplicated there and in WebEnginePage.acceptNavigationRequest.
- _mousepress_opentarget (i.e., setting the open_target) is now handled
in MouseEventFilter, not in WebView.
For some reason, when e.g. visiting duckduckgo and then heise.de,
QtWebEngine suddenly gets a new QOpenGLWidget as focusProxy.
We install an extra eventFilter observing the ChildAdded event and
re-adding the MouseEventFilter when that happens.
It doesn't actually work yet (as it claims the field is not editable),
but at least does not crash when the backend limitation for the command
is removed.
Per one of the diff comments on #1597:
> I used to use a tuple for constant things, but nowadays I'd actually
> prefer a list as a tuple is something more heterogeneous (i.e. it
> makes sense to have a `(x, y)` point as a tuple, but a list of points
> would be a list).
> At some point I should probably change it to a list everywhere 😉
