| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 2bd5b6fa1fb51d6ba80bc5271582b87a58b28ae2.
|
|
|
|
This reverts commit 453836f6976273948f3d2ba8f34723c0bbd6d188.
|
|
|
|
This reverts commit 390caafc8b59aefc085ca81c120c45b65b3f95ba.
|
|
This reverts commit 734ff1c176a5c177f6a788d2eccb52e62906331b.
|
|
|
|
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/
|
|
|
|
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.
|
