Make sure webenginesettings.default_profile is set before creating a
webengine tab. The webengine_tab fixture is used in the web_tab and
tabbed_browser fixtures.
Previously when `WebEngineView.__init__()` ran default_profile was set
to None which was causing the tabs to be created pointing to the Qt
default profile. Which was working fine until I moved the common JS
scripts used for hint mode etc up to the profile, now they just weren't
getting run.
Unfortunately using a fully set up default profile was too tricky for
me. The stuff in webenginesettings around setting up the default profile
is written specifically for setting up global stuff when the real
application. Apart from init_profile() depending on a bunch of other
global singletons (more to set up) the user agent setting is hard to
work with. There is an assert in `_init_default_profile()` if the global
user agent string is already set. If you bypass the global user agent
string then websettings chokes on it not being set (websettings is
called from webenginesettings).
That's probably all possible to unpick, just need to go through the
codepaths noting down what the regiments for the application path are
and what needs to be operable for tests. We will probably make it a bit
better when moving more towards containers anyway.
Alternatively we could have a session/request scope autouse=True fixture
to set up all the real global stuff. That might be benefitial to make
the tests faster anyway. Going through the full profile setup stuff for
every test might make them a bit slower.
A couple of the caret tests are still failing. Not sure why.
Qt had a regression relating to injecting scripts in 6.5. This only
applied to QWebEngineScripts in a page's collection, ones in a
profile's collection where fine. Since QWebEngineScripts learnt about
greasemonkey compatible metadata (a few years ago now) Qt manages when
scripts are injected and into what sites. So from that point of view all
we have to do is make sure scripts are registered with Qt when a profile
is initialised and then forget about them. So moving up to the profile
level fits that lifecycle better.
This is an initial, low effort, attempt at moving script registrations
to be up in the profile. Here's what I've done:
* move everything around QWebEngineScript out of webenginetab up to
webenginesettings
* injecting greasemonkey scripts
* injecting site specific quirks (the site specific part is actually
managed by greasemonkey metadata)
* injecting global JS that is used on every page like hint, caret
and stylesheet utility code
* move JS_WORLD_MAP up to qtutils alongside MAX_WORLD_ID
* this now introduces backend specific code into this module
* move greasemonkey initialisation to be earlier so the singleton
manager exists when webenginesettings are initialized
* I haven't looked at what dependancies the grasemonkey module has,
if this causes issue we could split the greasemonkey
initialization up (part one: create singleton, part two: read
all scripts + fire reloaded signal)
* the profile level stylesheet is still overriden in the tab when a) a
search is started or ended, to show/hide the scroll bar b) when the
user stylesheets setting changes, so you don't have to reload the page
Moving everything up off of an object, in webenginetab, up to module
level function in webenginesettings meant removing a bunch of references
to "self" and using functools.partial to retain references to profiles
for signals. Subclassing QWebEngineProfile would probably help make that
stuff a little more robust, and would help us move towards having an
arbitrary number of profiles. But the only downside I can think of right
now is that signal connections wont get cleaned up when profiles are
deleted because they aren't connected to bound methods. But we aren't
currently deleting profiles (apart from at shutdown).
I left a couple of comments in around possible improvements. The
interface for the change_filter decorator surprised me a bit.
`_inject_greasemonkey_scripts()` might be able to be made smaller by
re-using the script factory. Or moving the world validation out.
Regarding the original regression in 6.5, regarding all the global
scripts like stylesheet, hint, caret etc. That issue can also be worked
around by injecting them twice (at document created and deferred). They
all have guards in the code so should be idempotent. That doesn't help
greasemonkey scripts though which are also affected.
I haven't tried running the tests :)
ref: #7662
- Make sure we still test Python 3.7 and 3.8 after dropping old PyQt
versions in c5a51eb0bc
- Keep a modern Python version (3.11) with Qt 5 around, however
- Make sure we still test Python 3.10 too
- Also start testing the Python 3.12 alpha
For unknown reasons, on nightly CI we now get TWO errors:
<qutebrowser.browser.webkit.certificateerror.CertificateErrorWrapper errors=['NoPeerCertificate', 'SelfSignedCertificate'] string='The peer did not present any certificate\nThe certificate is self-signed, and untrusted'>
Looks like we have some failing smoke tests with:
[6636:16643:0329/041427.206197:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
TL;DR: I think I stabilized a couple of hinting iframe tests and applied
that change to all the iframe usages in the end2end tests in the hopes
that it would resolve some other flaky tests.
I was facing some tests that hinted elements in iframes failing
intermittently recently. They were most consistently failing on the
windows runner. This is similar to the trend described in the comment
linked from #1525.
The tests failing recently where:
tests (py39-pyqt515, windows-2019, 3.9)
test_using_hintfollow_inside_an_iframe
test_using_hintfollow_inside_an_iframe_button
tests (py311-pyqt515, ubuntu-20.04, 3.11)
test_using_hintfollow_inside_an_iframe
test_using_hintfollow_inside_an_iframe_button
They are failing because hints don't get generated for the elements in
the iframe. I can see hints do get generated for the iframe itself
though.
Examining the logs in 5.15 it seems that there is a
`cur_load_finished(True) (tab *)` log line after we run :hint. I suspect
that this is the load finished signal for the iframe.
I attempted to change the bdd open_path function to wait for the current
message it's looking for and then additionally look for that
cur_load_finished signal, but then it starts failing locally when the
iframe load signal actually comes before the parent frame one. Just
looking for the cur_load_finished signal itself also always found it
immediately ("already found"), probably from the parent frame.
So instead of trying to deal with that indeterminate ordering or
trying to change the signals to say what frame they are coming from, I
added javascript to all the pages used in iframes that run on load, and
changed all the tests to watch for log messages from the JS.
It's not the most maintainable solution, perhaps if we generated our
test files with jinja we could have some "subframe loaded" boilerplate,
get a message to log from a query param, look at metadata from test
files for the open_path checking etc.
I then searched for all the iframe usages in the test data and applied
that change to all of those files and all the tests that used them. A
few of those tests also had `flaky` annotations on them. I removed those
annotations for now in the hopes that there were affected by the same
problem. And that I actually managed to work around it correctly.
ref: #7621
This was first introduced in adbdfcbad3,
most likely because we got logging from the built-in Werkzeug webserver.
It doesn't seem to be needed anymore, possibly since
41c4ee3e2f where we started using CherryPy
for the SSL server too.
This should fix nighly bleeding tests, because the before_first_request
decorator got removed in Flask:
https://github.com/pallets/flask/pull/4621https://github.com/pallets/flask/pull/4995
toofar
Florian Bruhin
qutebrowser bot
ugla
dependabot[bot]