On some pages with particular zoom levels, elem.offsetHeight is exactly
one pixel more than elem.scrollHeight when fully scrolled down.
This is probably due to rounding/floats/off-by-one errors somewhere
inside Chromium?
We now instead always clip the displayed percentage at 100% (so we don't
display 101%), and consider the page fully scrolled even if we're
scrolled more than the page.
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 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.
Since we now use QWebEngineScript, we can't easily know when the script
finished running and we can access window._qutebrowser.scroll.
We instead assume the initial position (if we don't get a
scrollPositionChanged) will always be (0, 0), and explicitly set it
to (None, None) (displaying ???) if we can't connect that signal.
We now load the JS code as a QWebEngineScript, which sets up
window._qutebrowser with various "modules". That means we don't have to
pass the whole module every time we want to execute something.
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.
