| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
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/
|
|
|
|
There's some weird issue with Qt6.4 and 6.5 where a webengine view gets
its widget swapped out when it gets history deserialized into it. While
it's swapping widgets it has no so the focus gets passed to some other
widget should never even have focus.
There's probably more comprehensive ways we could handle this, by
overriding the WebEngineView layout, or by overriding focusNextPrevChild
on the parent to put out own logic into the "child is going, pass focus
to parent" logic chain.
But all that seems like a bit too much of a headache for this very
focussed issue. We want the new tab to get focus, so lets re-focus it.
Technically we could just focus the last tab that we open, if we are
undoing multiple, but the existing logic is to open each of them in turn
as foreground tabs and this reinforces that.
Closes: #7623
|
|
Not sure why its failing on windows, but it only really needs to run in
one environment anyway.
Previously this was using chrome://gpu but that was failing on CI due to
it invoking some vulkan stuff the didn't work without a GPU. I changed
it to chrome://sandbox/ for no good reason, but it seems to be working
fine on ubuntu at least.
Follow up to 151d808940f6
|
|
This one is for 6.5. Interesting that it was fine on 6.4.
I haven't gone and added text to all the test file because I'm hoping
it'll be something that upstream addresses in short order. So I'm only
adding text to files used by failing tests.
See d413b87c3f6 #7621 and #7624
|
|
Error: qutebrowser/browser/webengine/certificateerror.py has 90.91% line and 50.00% branch coverage!
Error: qutebrowser/browser/webengine/darkmode.py has 96.88% line and 100.00% branch coverage!
Error: qutebrowser/keyinput/basekeyparser.py has 97.59% line and 100.00% branch coverage!
Error: qutebrowser/keyinput/keyutils.py has 92.64% line and 96.30% branch coverage!
Error: qutebrowser/utils/debug.py has 94.51% line and 92.19% branch coverage!
Error: qutebrowser/utils/qtutils.py has 98.67% line and 96.74% branch coverage!
Error: qutebrowser/utils/usertypes.py has 99.20% line and 96.30% branch coverage!
Error: qutebrowser/utils/version.py has 97.66% line and 97.83% branch coverage!
Maybe we should open an issue to get them back up.
|
|
|
|
On CI were were getting "Could not import sip" because link_pyqt was
looking for PyQt5.sip.
I made that look at QUTE_QT_WRAPPER since that's being set already on
tox.ini
There are probably a few other changes around link_pyqt and the makefile
etc we need to change when we switch the default wrapper.
I overrode the default `py` tox environment with py-qt6 to override
those wrapper related variables. I probably could have done something
sneaky with curly braces to make it so we don't have to add a few more
lines to the file. But in my opinion in config file is far to obfuscated
and hard to maintain already.
I changed the docker file to call the new py-qt6 env if it's a qt6
container. I'm not 100% sure that is required though since there is also
a tox invocation in the GH action definition, maybe that overrides the
container entrypoint? Also changed the indentation in the dockerfile
template a bit to make it easier to see where the conditionals start and
end.
Speaking of which I changed the matrix definition and tox invocation to
match a later one to hopefully make it so we can invoke different tox
environments in the containers without having to rebuild the containers.
Not sure I did that right, I'll see soon.
I added the unstable-qt6 container generation line so we can use it in
the future, and to match the not-qt6 one. I'm not switching to that in
CI though because the pyqt used by that is broken at the moment
(ref https://www.riverbankcomputing.com/pipermail/pyqt/2023-March/045214.html)
Also fixed the vim modeline in generate.py so my syntax highlighting
works.
|
|
On GH actions I'm seeing an "unexpected line" failure around creating a
vulkan context when loading chrome://gpu
ERROR tests/end2end/features/test_tabs_bdd.py::test_cloning_a_tab_with_a_special_url - end2end.fixtures.testprocess.InvalidLine:
1829
Error: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
1830
at CheckVkSuccessImpl (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/VulkanError.cpp:88)
1831
at CreateVkInstance (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:360)
1832
at Initialize (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:235)
1833
at Create (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:165)
1834
at operator() (../../../3rdparty/chromium/third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:420)
I'm not sure its actually failing the test, we are just seeing the error
in the logs and flagging it.
Instead of adding the logs to an ignore list I'm going to switch the
page we use so that if the error comes up for real we'll be sure to see
the logs.
|
|
With 6.4 and 6.5 it looks like pages without text on them only render
after a delay (on the order of hundreds of milliseconds).
ref: #7621
|
|
6.4 tests should be passing now. 6.5 is still waiting on PyQt on PyPI
getting fixed. That goes for kde-unstable-qt6 too as that's pulling down
6.5.
We should take the opportunity to revisit the test matrix configuration
again when we add 6.5 in there. For example py3.11 on ubuntu 20.04 is a
bit odd as it only got released last year.
|
|
|
|
|
|
See #7202
|
|
|
|
With Qt 6.5, QtWebEngine complains and aborts when it gets an empty argv:
https://bugreports.qt.io/browse/QTBUG-110157
https://codereview.qt-project.org/c/qt/qtwebengine/+/455347
https://codereview.qt-project.org/c/qt/qtwebengine/+/457045
https://www.riverbankcomputing.com/pipermail/pyqt/2023-March/045216.html
However, our custom qapp_args override for pytest-qt *does* return [] as
argv, causing all tests using QtWebEngine to fail.
We might decide to add sys.argv[0] to the given qapp_args in pytest-qt:
https://github.com/pytest-dev/pytest-qt/issues/483
But probably this should be fixed on the application-side, so let's do
exactly that.
See #7624
|
|
PyQt insists using the deprecated signal overload, seemingly nothing we can do
to change that:
https://www.riverbankcomputing.com/pipermail/pyqt/2023-March/045215.html
See #7624
|
