| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Update dependencies
|
|
|
|
|
|
Update dependencies
|
|
Add `utm_name` to URL params that are stripped
|
|
|
|
|
|
Update dependencies
|
|
Was due to https://github.com/pytest-dev/pytest/issues/10896
|
|
This reverts commit ee40046faf8643046cebf98784d06b9aca671d6b.
|
|
|
|
See https://github.com/pytest-dev/pytest/issues/10875
|
|
Uncovered in Python 3.12
|
|
|
|
- Make sure we still test Python 3.7 and 3.8 after dropping old PyQt
versions in c5a51eb0bcbab0b68cdfbf3eba2e681cff2adf7a
- 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
|
|
See https://codereview.qt-project.org/c/qt/qtbase/+/325414
|
|
This reverts commit 681f7ffc579a8e1e7b28abe64da364c1c4d853e1.
|
|
See #7624
|
|
Apparently Windows CI is real slow on GitHub currently...
|
|
See #7624
|
|
CodeQL only needs about 7 minutes, but Windows needs >45
|
|
qutebrowser/dependabot/github_actions/peter-evans/create-pull-request-5
build(deps): bump peter-evans/create-pull-request from 4 to 5
|
|
This reverts commit 485f1c5fbc54ecf40c45e73216f32b8d870000cb.
|
|
Update dependencies
|
|
Looks like 45mins is too tight for GHA on Windows with heavy load...
|
|
Bumps [peter-evans/create-pull-request](https://github.com/peter-evans/create-pull-request) from 4 to 5.
- [Release notes](https://github.com/peter-evans/create-pull-request/releases)
- [Commits](https://github.com/peter-evans/create-pull-request/compare/v4...v5)
---
updated-dependencies:
- dependency-name: peter-evans/create-pull-request
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
|
|
Similar issue as with ab7245732e04c86aabc5497b279c3a28fe945836
|
|
|
|
See https://github.com/qutebrowser/qutebrowser/issues/7624
|
|
Update dependencies
|
|
|
|
|
|
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.
|
|
I saw this test fail on windows at some point with what looked like the
same issue. (Couldn't find an element to click.)
ref; #7621
|
|
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
|
|
|
|
|
|
See https://github.com/qutebrowser/qutebrowser/issues/7202#issuecomment-1481877459
|
|
Without this wait, the test is flaky, because sometimes the keys are pressed
before qutebrowser has entered insert mode.
When running:
tox -e py311-pyqt64 -- tests/end2end/features/test_hints_bdd.py -k undoing --count 100
around 30% of the runs, we get:
============================== :click-element id qute-input-existing ==============================
[...]
----> Waiting for 'command called: *' in the log
[...]
17:56:54.042 DEBUG commands command:run:549 Calling qutebrowser.components.misccommands.click_element(<qutebrowser.browser.webengine.webenginetab.WebEngineTab tab_id=197 url='http://localhost:50977/data/hints/link_input.html'>, 'id', 'qute-input-existing', target=<ClickTarget.normal: 1>, force_event=False, select_first=False)
17:56:54.043 DEBUG ipc ipc:_get_socket:373 In _get_socket with None socket!
----> found it
============================== :fake-key -g something ==============================
[...]
----> Waiting for '[*] contents: existingsomething' in the log
17:56:54.062 DEBUG modes modeman:_handle_keypress:290 got keypress in mode KeyMode.normal - delegating to <qutebrowser.keyinput.modeparsers.NormalKeyParser>
[...]
17:56:54.111 DEBUG modes modeman:_handle_keypress:290 got keypress in mode KeyMode.normal - delegating to <qutebrowser.keyinput.modeparsers.NormalKeyParser>
[...]
17:56:54.112 DEBUG modes modeman:_handle_keypress:290 got keypress in mode KeyMode.normal - delegating to <qutebrowser.keyinput.modeparsers.NormalKeyParser>
[...]
17:56:54.113 DEBUG commands command:run:535 command called: quickmark-save
[...]
17:56:54.143 DEBUG webview webenginetab:_js_cb_single:766 Got element from JS: {'attributes': {'id': 'qute-input-existing', 'value': 'existing'}, 'caret_position': 0, 'class_name': '', 'id': 0, 'is_content_editable': False, 'outer_xml': '<input id="qute-input-existing" value="existing">', 'rects': [{'bottom': 143, 'height': 21, 'left': 8, 'right': 166, 'top': 122, 'width': 158}], 'tag_name': 'INPUT', 'text': '', 'value': 'existing'}
17:56:54.143 DEBUG webelem webelem:click:422 Clicking <qutebrowser.browser.webengine.webengineelem.WebEngineElement html='<input id="qute-input-existing" value="existing">'> with click_target ClickTarget.normal, force_event False
17:56:54.143 DEBUG webelem webelem:is_editable:257 Checking if element is editable: <qutebrowser.browser.webengine.webengineelem.WebEngineElement html='<input id="qute-input-existing" value="existing">'>
17:56:54.143 DEBUG webelem webelem:click:434 Clicking via JS focus()
17:56:54.144 DEBUG webelem webelem:is_editable:257 Checking if element is editable: <qutebrowser.browser.webengine.webengineelem.WebEngineElement html='<input id="qute-input-existing" value="existing">'>
17:56:54.144 DEBUG modes modeman:enter:366 Entering mode KeyMode.insert (reason: clicking input)
With the change, the test passes 100/100 times.
|
|
|
|
|
|
|
|
See https://github.com/PyCQA/pylint/issues/8487
|
|
This was first introduced in adbdfcbad32c5ddd7692f55704a3ba9be235ca6b,
most likely because we got logging from the built-in Werkzeug webserver.
It doesn't seem to be needed anymore, possibly since
41c4ee3e2fa4ebf1d2827ed0824a9c78e94069c4 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/4621
https://github.com/pallets/flask/pull/4995
|
|
See https://www.reddit.com/r/qutebrowser/comments/11w1agq/matrix_theme/
|
