test_caret.py crashes on Travis with this stack:
?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
QSGBatchRenderer::Renderer::renderBatches() () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
QSGBatchRenderer::Renderer::render() () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
QSGRenderer::renderScene(QSGBindable const&) () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
QSGRenderer::renderScene(unsigned int) () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
QQuickWindowPrivate::renderSceneGraph(QSize const&) () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
QQuickRenderControl::render() () from .../site-packages/PyQt5/Qt/lib/libQt5Quick.so.5
?? () from .../site-packages/PyQt5/Qt/lib/libQt5QuickWidgets.so.5
?? () from .../site-packages/PyQt5/Qt/lib/libQt5QuickWidgets.so.5
QObject::event(QEvent*) () from .../site-packages/PyQt5/Qt/lib/libQt5Core.so.5
QWidget::event(QEvent*) () from .../site-packages/PyQt5/Qt/lib/libQt5Widgets.so.5
QQuickWidget::event(QEvent*) () from .../site-packages/PyQt5/Qt/lib/libQt5QuickWidgets.so.5
?? () from .../site-packages/PyQt5/Qt/lib/libQt5WebEngineWidgets.so.5
QApplicationPrivate::notify_helper(QObject*, QEvent*) () from .../site-packages/PyQt5/Qt/lib/libQt5Widgets.so.5
QApplication::notify(QObject*, QEvent*) () from .../site-packages/PyQt5/Qt/lib/libQt5Widgets.so.5
sipQApplication::notify(QObject*, QEvent*) () from .../site-packages/PyQt5/QtWidgets.so
QCoreApplication::notifyInternal2(QObject*, QEvent*) () from .../site-packages/PyQt5/Qt/lib/libQt5Core.so.5
QTimerInfoList::activateTimers() () from .../site-packages/PyQt5/Qt/lib/libQt5Core.so.5
?? () from .../site-packages/PyQt5/Qt/lib/libQt5Core.so.5
g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from .../site-packages/PyQt5/Qt/lib/libQt5Core.so.5
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from .../site-packages/PyQt5/Qt/lib/libQt5Core.so.5
In Qt < 5.10 (and also sometimes on Windows), we get extra spaces or newlines
when moving to the end of the document. However, this only happens *sometimes*,
and manual testing confirms that with the current workaround, we actually lose
the last char in the selection.
I'm not sure what's happening there, but instead of making things worse with
the workaround, let's just be a bit less strict with the checking there and
accept both variants... This seems like some Chromium bug we can't do much
about.
Otherwise, stuff goes haywire when trying to use the caret mode very fast (like
in a unit test), because new stuff runs before we've managed to update the selection.
Before Qt 5.11.2, for unique origins, we always got QUrl() and thus passed it
through.
With Qt 5.11.2, only missing origins (browser-initiated requests) get an empty
initiator, while unique origins get QUrl("null"):
https://codereview.qt-project.org/#/c/234849/https://bugreports.qt.io/browse/QTBUG-69372
In theory, those should be locked down (as an unique origin is e.g. a sandboxed
iframe) and never have access to any other content.
However, thanks to a Qt bug, XHR on qute:// pages has QUrl("null") as origin as
long as the URL scheme is not registered. We can only do the registering once
Qt 5.12 is out.
Since unique origins were effectively already allowed on Qt 5.11.0/.1, we pass
them through here as well until Qt 5.12.
See #4198
