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
This exposes all possible values, but before
https://codereview.qt-project.org/#/c/240121/ we won't be able to change those
at runtime (or enable URL patterns, which thankfully weren't enabled for the
old setting).
In theory, it'd be possible to handle the "public-interface-only" value via
QWebEngineSettings without requiring a restart, but it isn't worth the trouble.
Closes#4201
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.
Resolves#4199.
To avoid accidentally highlighting characters that were introduced by
html escaping the text before feeding it to setHtml, we can't just
escape the whole string before adding the highlighting. Instead, we need
to break the string up on the pattern, format and escape the individual
parts, then join them back together.
re.escape includes empty strings if there is a match at the start/end,
which ensures that matches always land on odd indices:
https://docs.python.org/3/library/re.html#re.split
> If there are capturing groups in the separator and it matches at the
> start of the string, the result will start with an empty string. The
> same holds for the end of the string
Resolves the example case in #4199, but not the larger problem. We don't
need to escape quotes as we don't put the string in an attribute value.
From the docs at
https://docs.python.org/3/library/html.html#html.escape:
> If the optional flag quote is true, the characters (") and (') are also
> translated; this helps for inclusion in an HTML attribute value
> delimited by quotes, as in <a href="...">.
Escaping quotes means we end up with a literal ' in the completion
view wherever there is a quote in the source text.
However, problem in #4199, where unexpected parts of the text are
highlighted, can also happen with '<', '>', and '&', which still must be
escaped.
There were no unit tests for this whole module. It is difficult to test
due to all the private logic and Qt dependencies, but with a lot of
mocking we can at least validate some of the text handling.
This is a setup to start testing the solution to #4199.
I picked '{' and '}' as placeholders in the test data because they draw
the eye to the 'highlighted' part, and vim even highlights them with
python syntax highlighting. It could be confusing though, as they look
like format strings but are not used that way.
