Since Qt 5.11.2, various crash logs like this popped up after clicking a
<select> element:
Traceback (most recent call last):
File ".../browser/mouse.py", line 239, in eventFilter
return self._handlers[evtype](event)
File ".../browser/mouse.py", line 121, in _handle_mouse_press
self._mousepress_insertmode_cb)
File ".../browser/webengine/webenginetab.py", line 624, in find_at_pos
assert pos.x() >= 0
AssertionError
This is probably caused by https://codereview.qt-project.org/#/c/193908/ in
some way...
There's still much more to do for #1926, but with this we at least handle one
common case gracefully.
No tests because test_sessions.py is still in a kinda bad place...
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
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
If the blacklist is only valid for the completion, the setting should also be
under completion.
This also un-renames history.gap_interval and renames
completion.web_history_max_items.
