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.
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.
Fixes#1911.
The bugfix is backported in my qt5-webengine-debug package, and
QUTE_QTBUG54419_PATCHED can be set to force qutebrowser to use
createWindow.
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.
