| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- Drop trailing comma inside trivial tuple
- Use r"""...""" for string containing ", as \" inside r"..." is taken literally
(I'm surprised it works!)
- Use ['"] instead of ('|")
- Also adjust the inner [^'] to [^'"] for consistency
|
|
This reverts commit 7144e7211689938392c0abc469c26ddfe2a6ae7a.
Turns out this adds complexity, but doesn't really help with debugging that
much, and also needs us to guess what the correct ID might be.
We should rather go for a nicer (but more invasive) cleanup by having a separate
IPCConnection class that stores a socket and ID, see #8208.
|
|
As of at the very least the latest version the version string looks
like:
const pdfjsVersion = "4.2.67";
So change the regex to allow double quotes too.
|
|
It's needed for both the main page (which we generate using jinja) and
the worker script.
Closes: https://github.com/qutebrowser/qutebrowser/issues/8170
|
|
The `test_cleanup()` test for guiprocess was triggering the early timer
warning messages because it was using a VeryCourse timer with a 100ms
interval. Changed it to to a normal Course timer (the default) for that
test.
For the `ipc-timeout` timer we know that is happening in the tests on
windows. It's being logged in lost of e2e tests, the elapsed times it's
logging are between 0 and 0.020s. I'm not sure if it's the right thing
to be changing the log level in production code or marking the messages
as expected in test code.
|
|
|
|
Since we are now checking for early timer firings in usertype.Timer I
figured why do it in two places, lets call the check method on Timer in
the handler in the IPC class too.
I also removed the platform and version check because while the bug only
happens under those conditions the check to ensure a timer event was
valid should work everywhere. Right? We can add them back of someone
wants but I'm not sure I see a point.
It would be nice if we could filter out invalid timer events in
usertypes.Timer and not require the consuming code to have to do
anything. But that would be more work, so lets wait until more places of
code actually need to care about it, chances are it'll be fixed in Qt
soon enough anyway.
I also think usertypes.Timer should be restarting the time so it gets
called at the proper time. But if we aren't filtering the events that
would mean it gets called twice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Add a couple new "raise utils.Unreachable" to avoid
possibly-used-before-assignment issues.
- Simplify an "if" for the same reason
- Remove an unneeded "return"
- Use "NoReturn" to prepare for pylint knowing about it in the future:
https://github.com/pylint-dev/pylint/issues/9674
- Add some ignores for used-before-assignment false-positives
- Ignore new undefined-variable messages for Qt wrapers
- Ignore a new no-member warning for KeySequence:
https://github.com/pylint-dev/astroid/issues/2448#issuecomment-2130124755
|
|
This makes things significantly slower
|
|
Change `CompletionView.on_clear_completion_selection()` to call the Qt
selection model getter, instead of our one. Since it can be called when the
selection model has already been cleared and our one asserts that there
is a selection model to return.
Back in the distant past there was a change to handle the completion widget's
selection model being None when the `on_clear_completion_selection()` slot was
called: https://github.com/qutebrowser/qutebrowser/commit/88b522fa167e2f97b
More recently a common getter for the selection model was added so we could
have a single place to apply type narrowing to the returned object from the Qt
getter (the type hints had been updated to be wrapped in `Optional`): https://github.com/qutebrowser/qutebrowser/commit/92dea988c01e745#diff-1559d42e246323bea35fa064d54d48c990999aaf4c732b09ccd448f994da74cf
It seems this is one place where it does, and already did, handle that
optional. So it didn't need to change to use the new getter. This is called
from the `Command.on_mode_left` signal, not sure why the selection model is
None here. Perhaps it already gets cleared by the effects of the `hide_cmd`
signal that gets fired earlier, or perhaps even from the `self.hide()` on the
line before. Anyway, this was working for several years and seems harmless
enough.
|
|
I was getting crash reports from someone about this. Not sure what's going wrong
there (hence the additional information in the exception).
What's clear however is that we're raising ParseError, but only handling that
when actually parsing. The code calling copy_/_find_webengine_resources only
handles OSError. So let's raise a FileNotFoundError instead.
|
|
|
|
Dynamic dark mode
|
|
|
|
|
|
See #3636, #5542, #7743
|
|
We already had all this information in a comment anyways.
I made it machine-readable using:
s/#\s+(\d*)\.(\d*)\.(\d*): Security fixes up to ([^ ]*)\s+\((.*)\)/utils.VersionNumber(\1, \2, \3): (_BASES[XX], '\4'), # \5
plus some manual post-processing.
Thanks to that, we can now get the security version from that data even on
QtWebEngine < 6.3, if that information is known. When we fall back to a base
version (e.g. 6.7.99 -> 6.7), we make sure to not pretend that we have the .0
state of things, though.
Finally, we cross-check the information against the current Qt version if we
have the API, which mostly ensures the data is accurate for human readers.
See #7187 and #8139.
|
|
Mostly based on CHROMIUM_VERSION in QtWebEngine
and chromereleases.googleblog.com.
|
|
|
|
More readable now that we have more information in it.
Also always show the source, now that we have the space for it, and "UA" isn't
the obvious default anymore anyways.
|
|
Update dependencies
|
|
With pytest 8.2, pytest.importorskip(...) now only considers ModuleNotFoundError
rather than all ImportErrors, and warns otherwise:
https://github.com/pytest-dev/pytest/pull/12220
While we could override this via
pytest.importorskip(..., exc_type=machinery.Unavailable)
this is a simpler solution, and it also makes more sense semantically:
We only raise Unavailable when an import is being done that would otherwise
result in a ModuleNotFoundError anyways (e.g. trying to import QtWebKit on Qt
6).
|
|
When qutebrowser is running but its installation has been deleted/moved, it
fails in somewhat mysterious but predictable ways. This is e.g. the case
currently, when people upgrade their Archlinux packages and upgrade from Python
3.11 to 3.12. When doing that with qutebrowser open, on the next page load, it
will:
- Have a crashed renderer process, because (assumingly) the process executable
is gone on disk.
- Which then causes us trying to render an error page, but that fails due to
broken_qutebrowser_logo.png being gone from disk.
- The FileNotFoundError then causes jinja2 to import jinja2.debug at runtime,
but that *also* fails because the jinja2 package is gone.
We work around this by loading the PNG into RAM early, and then using the cached
version instead. This amends b4a2352833bfb06c86c1afb8b088cead0ef7c6d5 which did
the same with HTML/JS resources, but never for this PNG, which (looking at crash
logs) seems to be a somewhat common breakage.
Alternatives I've considered:
- Catching the FileNotFoundError and not showing an error page at all.
- Generating a PNG with an explanatory text via QPainter and returning that.
However, with the renderer process crash happening in the first place for
unknown reasons, it's unclear if the error page ever gets actually displayed...
Let's roll with this for now, and if this causes a repeating renderer process
crash, fix that separately (also see #5108).
|
|
By returning early, we can move the logic up a bit and handle the normal case after.
|
|
mypy:
Mypy knows about the QDataStream.Status.SizeLimitExceeded attribute now,
so we can remove the ignore. But mypy for pyqt5 doesn't know about it,
so put the whole graceful block behind an additional conditional as well
to hide it from pyqt5 mypy.
cheroot:
looks like the format of the error message we are already ignoring
changed slightly. The `ssl/tls` bit changed to `sslv3`, at least in our
setup.
|
|
Previously (a209c86c55a4) I've added a delay in browser code before sending
events to the page to account with a race condition where events weren't
processed after navigating. Then I had to add extra checks to tests that had
tight timing requirements.
That was for click-element, this commit reverts an attempt at the same
strategy for fake-key and instead adds wait statements in the tests that where
hitting the original race condition (sending events "too soon" after a
navigation).
The reason for the different approach here is that after adding the delay in
fake-key I had to add an extra "wait for log line" message to a few tests with
tight timing requirements to watch for a Tab key press. That worked great for
webengine but it made some tests start failing on webkit. We don't seem to get
that log message on webkit. I've got no-idea why and frankly think I've spent
way too much time on just a handful of tests already.
It's unfortunate we have to add manually delays in the e2e tests. It makes me
think if anyone else adds a test in the future with this combination of steps
(open page, run fake-key) they'll run into the same issue and it'll be hard to
spot. Oh well, we'll deal with that when it comes up.
The tests that where failing on webkit are the ones in caret.feature
touched in this commit.
Reverts included in this commit:
Revert "Delay fake-key events by 10ms"
This reverts commit 9f050c7460c42f317ceaa20b320e97d371a2c0a0.
Revert "Wait for evidence of Tab key press in tests before proceeding"
This reverts commit d47d247941c4b1fe3adac0dae8be301b36aec85b.
|
|
Similar to a209c86c55a4 "Delay QEvent driven mouse clicks by 10ms" it seems
that sending fake-key QEvents immediately after a navigation causes the events
to not be processed.
This is causing e2e tests in keyinput.feature to fail in a flaky, but
frequent, manner. This can also be resolved in some other ways like putting
a wait in the e2e tests like so:
When I open data/keyinput/log.html
And I wait 0.01s
And I run :fake-key <Escape>
But relying on maintainers to remember to do that seems error prone. If this
10ms delay turns out to be something to get rid of we could try keep this
delay to be used in less cases:
1. add some magic to e2e tests where it compares the previous and current line
and if it sees an open and a click-element or fake-key line next to each
other it delays for a bit
2. in the application code in tab.send_event() store the time of last
navigation and queue events for sending till after that
The affected tests in this case where:
tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_key_to_the_website
tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_special_key_to_the_website
tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_keychain_to_the_website
|
|
On CI with Qt 6.7 we are seeing several tests failing in a flaky, but
frequent, manner. These tests all seem to be doing :click-element and
sending a "fake" click, as in one driven by QEvents, to a button on the
test page after opening the page in an existing tab. In the logs we see
that the element was identified with JS correctly but we don't see any
evidence of the actual click after that.
I've been testing locally with `python3 -m pytest
tests/end2end/features/test_prompts_bdd.py -k test_javascript_confirm`.
Delaying the click event by as little as 5ms seems to make the tests
consistently pass. I'm setting it to an arbitrary 10ms here for no good
reason. It's unfortunate that we have to change production code to make
tests pass, it's unlikely that a 10ms window will affect real usage, and
the problem is only immediately after a navigation. If we can't find a
better way to resolve this and want to get rid of the 10ms delay when no
needed we could maybe look at when the last navigation time for the tab
was to decide whether to delay or not.
I also tried changing all the "open in" lines in the failing tests to be
"open in new tab" and that seemed to make the flaky tests pass
consistently too. But relying on people writing tests in a specific way
wouldn't really be fixing the problem.
Additionally, running just one test at a time (with `taskset -c 1 ...`)
made all the tests pass consistently. So it seems like the root cause
could have something to do with that, somehow. Or maybe just running the
pytest process and the browser process on the same CPU causes enough of
a delay to not trigger it.
I don't know what the root cause of this change is, or if we can use a
more event based way of knowing when the page (or its focus proxy) is
ready to receive events. I've tried digging through events and debugging
webengine and haven't got anywhere, hopefully this delay is painless
enough that it'll do. To summarize, the page, or focus proxy, doesn't
process events (all events, just mouse events?) immediately after
navigating.
I initially tried delaying all events in `tab.send_event()`, but that
caused some caret tests to fail (the `selectionfollow_with_link_tabbing`
e2e ones), not sure why. So I walked back to just delaying click events.
I've seen some intermittent flakyness in
`test_misc_bdd.py::test_clicking_on_focused_element` and
`tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_keychain_to_the_website`
which may indicate that `:fake-key` needs the same treatment. We'll see
how things stand once it's been stable on the main branch for a while
instead of being muddled up in this investigation branch.
I thought the issue might be that the RenderWidgetHostViewQt was being swapped out
on the new page load and the old one being sent the event. So I added a bunch
of debug logging to try to get a better view of that. None of this debug
logging is showing up when the tests fail so it seems that isn't the case.
The tests failing in the last four bleeding edge qt6 tests before these
changes were (test, count):
('tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_special_key_to_the_website', 2),
('tests/end2end/features/test_prompts_bdd.py::test_using_contentjavascriptalert', 2),
('tests/end2end/features/test_editor_bdd.py::test_select_two_files_with_multiple_files_command', 2),
('tests/end2end/features/test_misc_bdd.py::test_clicking_first_element_matching_a_selector', 2),
('tests/end2end/features/test_misc_bdd.py::test_clicking_on_focused_element', 2),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_prompt_with_default', 2),
('tests/end2end/features/test_prompts_bdd.py::test_using_contentjavascriptprompt', 2),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_confirm__aborted', 2),
('tests/end2end/features/test_editor_bdd.py::test_file_selector_deleting_temporary_file', 1),
('tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_keychain_to_the_website', 1),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_confirm__no', 1),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_confirm_with_default_value', 1),
('tests/end2end/test_insert_mode.py::test_insert_mode[100-input.html-qute-input-keypress-awesomequtebrowser]', 1),
('tests/end2end/features/test_misc_bdd.py::test_clicking_an_element_by_position', 1),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_confirm__yes', 1),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_confirm_with_invalid_value', 1),
('tests/end2end/test_insert_mode.py::test_insert_mode[125-input.html-qute-input-keypress-awesomequtebrowser]', 1),
('tests/end2end/features/test_editor_bdd.py::test_select_two_files_with_single_file_command', 1),
('tests/end2end/features/test_keyinput_bdd.py::test_fakekey_sending_key_to_the_website', 1),
('tests/end2end/features/test_misc_bdd.py::test_clicking_an_element_by_id_with_dot', 1),
('tests/end2end/features/test_prompts_bdd.py::test_javascript_alert_with_value', 1)
For debugging in GBD under test I ran the test process under GDB and
passed a script to GDB to print out a message, and then continue, when
it hit a breakpoint. Unfortunately, the tests always passed when run
under GDB.
For that I changed `_executable_args()` in quteprocess to return `"gdb",
"-q -x handleMouseEvent-breakpoint -args".split() + [executable] + args`
where `handleMouseEvent-breakpoint` is:
set breakpoint pending on
set debuginfod enabled off
break RenderWidgetHostViewQtDelegateClient::handleMouseEvent
commands
call (void) fprintf(stderr, "Entering handleMouseEvent\n")
continue
end
run
The tests were consistently passing, but erroring on the invalid gdb log lines.
|
|
qutebrowser/feat/7187_chromium_security_patch_in_version
Show chromium security patch version in :version
|
|
See https://bugreports.qt.io/browse/QTBUG-124386
Fixes #8143
|
|
flake8 got a new warning about a module name shadowing a builtin module: https://github.com/gforcada/flake8-builtins/pull/121
Probably would have been safe enough to ignore it. But I don't think
moving it is that hard anyway. Hopefully I didn't miss anything!
|
|
See https://www.reddit.com/r/qutebrowser/comments/1bomb3h/closing_popups_within_a_webpage_and_toggling/
|
|
|
|
|
|
|
|
|
|
Fixes #8145, see #5390.
As long as we don't have a solution to get notified about focus happening
(#2471 possibly?), it looks like there is no better way to get notified
about this, so a delay will need to do for now.
|
|
Starting with PyInstaller 6.5.0, it imports Qt bindings early, due to
this change: https://github.com/pyinstaller/pyinstaller/pull/8315
We warn about this in order to avoid unintentional early Qt imports in
qutebrowser. However, in the case of using PyInstaller, we just suppress
the warning now, as it's not us to blame.
See https://github.com/qutebrowser/qutebrowser/pull/8123
|
|
|
|
This is going to be default behavior in mypy 2.0, see:
- #8123
- https://mypy-lang.blogspot.com/2024/03/mypy-19-released.html
- https://mypy.readthedocs.io/en/stable/command_line.html#cmdoption-mypy-local-partial-types
|
