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.
Maybe this fixes issues we had with QtWebEngine segfaults in proxy.py on
Travis?
Note we can't move cookies/cache/network stuff yet as we still need that
for e.g. adblock downloads with QtWebEngine.
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.
It makes a lot of sense for this to be in webkitelem.py, but it should
not be public API as it's only used internally and can't be implemented
here with QtWebEngine.
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 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.
