We're deprecating vim modelines in favor of `.editorconfig`.
Removing vim modelines could be done using two one-liners. Most of the vim modelines
were followed by an empty line, so this one-liner took care of these ones:
```sh
rg '^# vim: .+\n\n' -l | xargs sed -i '/^# vim: /,+1d'
```
Then some of the vim modelines were followed by a pylint configuration line, so running
this one-liner afterwards took care of that:
```sh
rg '^# vim:' -l | xargs sed -i '/^# vim: /d'
```
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'>
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
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 151d808940
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 d413b87c3f#7621 and #7624
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.
I don't quite understand why the value changed from #00000 to #121212
there with Qt 6.3, but it looks like the change is here to stay.
Instead of keeping #000000 the default and adding an override for every
new Qt release, let's just switch over and add an override for the old
versions (5.15 and 6.2), so this won't break again for every new release.
See #7624
This reverts commit 47be6f3aeb.
This doesn't really make sense in test files, as the warning would point
inside some internal pytest code, which is not helpful.
Instead, let's just disable the corresponding flake8 warning in tests.
flake8-bugbear B028 No explicit stacklevel keyword argument found. The
warn method from the warnings module uses a stacklevel of 1 by default.
This will only show a stack trace for the line on which the warn method
is called. It is therefore recommended to use a stacklevel of 2 or
greater to provide more information to the user.
Semgrep helped:
semgrep --lang=py -e 'warnings.warn($ARG)' --replacement 'warnings.warn($ARG, stacklevel=2)' $FILES -a
semgrep --lang=py -e 'warnings.warn($ARG1, $ARG2)' --replacement 'warnings.warn($ARG1, $ARG2, stacklevel=2)' $FILES -a
Although it did lose the f-string on one of them.
Mostly pretty lazy fixes. Most of the places in the tests we were
already matching on error message, a couple of places we weren't. The
tick-tock one was the only one that wasn't being used right where it was
raised.
Some of them I just changed to RuntimeError because it was shorter than
adding the pylint directive.
The "Answering a question for a cancelled download" test was flaky,
due to the preceding PDF.js test sometimes not waiting properly for its
download to finish: "I wait until the download is finished" waited for
the initial PDF download above (which causes PDF.js to open), but not
for the real download after clicking the save button.
See #5390
TODO: Cherry-pick to master?
Florian Bruhin
Philipp Albrecht
toofar
Kian-Meng Ang