| Age | Commit message (Collapse) | Author |
|---|
|
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 4 to 5.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/v4...v5)
---
updated-dependencies:
- dependency-name: actions/setup-python
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
|
|
|
|
|
|
|
|
Almost 7 years ago, it was observed that hiding the status bar causes some
websites being scrolled to the top: #2236.
Back then, it never really was clear why this happens. However, with the v3.0.0
release, we had a regression causing the same thing to happen when leaving
prompt mode: #7885.
Thanks to "git bisect", the culprit was found to be 8e152aa, "Don't give
keyboard focus to tab bar", which was a fix for #7820. However, it still wasn't
clear why this phenomenon happens.
What made things clearer to me was a combination of debugging and an old comment
by pevu: https://github.com/qutebrowser/qutebrowser/issues/2236#issuecomment-337882102
> Chromium-browser has the same issue. When you open lipsum.com, scroll down,
> then focus the location bar (url box), then press Tab, it will jump to the
> top of the page and focus the first link. This doesn't happen when you
> switch focus using the mouse.
>
> It seems to be an issue of how the view containing the website is focused
> when all qutebrowser ui elements disappear.
And indeed, tabbing into the web contents from the UI elements via the tab key
in Chromium causes the website to start at the top, presumably as an
accessibility feature?
Essentially, this is also what happens in qutebrowser when an UI element is
hidden while it still has focus: In QWidget::hide() (or, rather,
QWidgetPrivate::hide_helper()), Qt moves the focus to the next widget by
calling focusPrevNextChild(true):
https://github.com/qt/qtbase/blob/v6.6.1/src/widgets/kernel/qwidget.cpp#L8259-L8271
And apparently, focusPrevNextChild() basically does the same thing as pressing
the tab key, to the point that there is some code in Qt Declarative actually
making tab keypresses out of it (which I'm still not sure is related, or maybe
just the cause of #4579):
https://github.com/qt/qtdeclarative/blob/v6.6.1/src/quickwidgets/qquickwidget.cpp#L1415-L1429
Some debugging confirms that this is exactly what happening:
1) We hide the status bar (or prompt) which has keyboard focus
2) Qt focuses the web view, which triggers the Chromium feature (?) scrolling it
to the very top.
3) Only then, in TabbedBrowser.on_mod_left(), we noticed that the command or
prompt mode was left, and reassign focus to the web view properly.
In step 2), before this change, Qt happened to focus the tab bar (before we set
the focus manually to the web contents), and thus this didn't happen.
Not sure why it didn't focus the tab bar when we hid the status bar (maybe
because how our widget hierarchy works with TabbedBrowser?).
Python stacktrace of hiding prompt:
Traceback (most recent call first):
<built-in method hide of DownloadFilenamePrompt object at remote 0x7fffb8bc65f0>
File ".../qutebrowser/mainwindow/prompt.py", line 204, in _on_mode_left
self.show_prompts.emit(None)
File ".../qutebrowser/keyinput/modeman.py", line 434, in leave
self.left.emit(mode, self.mode, self._win_id)
File ".../qutebrowser/keyinput/modeman.py", line 445, in mode_leave
self.leave(self.mode, 'leave current')
C++ stacktrace, with the focus change presumably being passed of to Chromium
here: https://github.com/qt/qtwebengine/blob/dev/src/core/render_widget_host_view_qt_delegate_client.cpp#L714
#0 QtWebEngineCore::RenderWidgetHostViewQtDelegateClient::handleFocusEvent(QFocusEvent*) () at /usr/src/debug/qt6-webengine/qtwebengine-everywhere-src-6.6.0/src/core/render_widget_host_view_qt_delegate_client.cpp:708
#1 QtWebEngineCore::RenderWidgetHostViewQtDelegateClient::handleFocusEvent(QFocusEvent*) () at /usr/src/debug/qt6-webengine/qtwebengine-everywhere-src-6.6.0/src/core/render_widget_host_view_qt_delegate_client.cpp:705
#2 0x00007fffe5fea70c in QtWebEngineCore::RenderWidgetHostViewQtDelegateClient::forwardEvent(QEvent*) () at /usr/src/debug/qt6-webengine/qtwebengine-everywhere-src-6.6.0/src/core/render_widget_host_view_qt_delegate_client.cpp:300
#3 0x00007fffe4dd5c79 in QQuickItem::event(QEvent*) (this=0x555556b6cd20, ev=0x7fffffffa320) at /usr/src/debug/qt6-declarative/qtdeclarative-everywhere-src-6.6.0/src/quick/items/qquickitem.cpp:8871
#4 0x00007ffff1f7318b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=<optimized out>, receiver=0x555556b6cd20, e=0x7fffffffa320)
at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qapplication.cpp:3290
#5 0x00007ffff295e4a7 in () at /usr/lib/python3.11/site-packages/PyQt6/QtWidgets.abi3.so
#6 0x00007ffff59626d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x555556b6cd20, event=0x7fffffffa320) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/corelib/kernel/qcoreapplication.cpp:1118
#7 0x00007ffff596271d in QCoreApplication::sendEvent(QObject*, QEvent*) (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/corelib/kernel/qcoreapplication.cpp:1536
#8 0x00007fffe4f33f15 in QQuickDeliveryAgentPrivate::setFocusInScope(QQuickItem*, QQuickItem*, Qt::FocusReason, QFlags<QQuickDeliveryAgentPrivate::FocusOption>)
(this=<optimized out>, scope=<optimized out>, item=<optimized out>, reason=<optimized out>, options=...) at /usr/src/debug/qt6-declarative/qtdeclarative-everywhere-src-6.6.0/src/quick/util/qquickdeliveryagent.cpp:439
#9 0x00007fffe4dd348a in QQuickItem::setFocus(bool, Qt::FocusReason) (this=0x555556b724d0, focus=<optimized out>, reason=Qt::TabFocusReason) at /usr/include/qt6/QtCore/qflags.h:73
#10 0x00007fffe4e7239b in QQuickWindow::focusInEvent(QFocusEvent*) (this=<optimized out>, ev=<optimized out>) at /usr/src/debug/qt6-declarative/qtdeclarative-everywhere-src-6.6.0/src/quick/items/qquickwindow.cpp:231
#11 0x00007ffff1fc3a05 in QWidget::event(QEvent*) (this=0x555556457b50, event=0x7fffffffa770) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qwidget.cpp:9111
#12 0x00007ffff1f7318b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=<optimized out>, receiver=0x555556457b50, e=0x7fffffffa770)
at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qapplication.cpp:3290
#13 0x00007ffff295e4a7 in () at /usr/lib/python3.11/site-packages/PyQt6/QtWidgets.abi3.so
#14 0x00007ffff59626d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x555556457b50, event=0x7fffffffa770) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/corelib/kernel/qcoreapplication.cpp:1118
#15 0x00007ffff596271d in QCoreApplication::sendEvent(QObject*, QEvent*) (receiver=<optimized out>, event=<optimized out>) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/corelib/kernel/qcoreapplication.cpp:1536
#16 0x00007ffff1f7f1b2 in QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) (focus=0x555556457b50, reason=<optimized out>) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qapplication.cpp:1538
#17 0x00007ffff1fca29d in QWidget::setFocus(Qt::FocusReason) (this=0x555556b1ceb0, reason=<optimized out>) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qwidget.cpp:6580
#18 0x00007ffff1fb4f1b in QWidget::focusNextPrevChild(bool) (this=<optimized out>, next=<optimized out>) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qwidget.cpp:6844
#19 0x00007ffff298d0ac in () at /usr/lib/python3.11/site-packages/PyQt6/QtWidgets.abi3.so
#20 0x00007ffff298d0ac in () at /usr/lib/python3.11/site-packages/PyQt6/QtWidgets.abi3.so
#21 0x00007ffff298d0ac in () at /usr/lib/python3.11/site-packages/PyQt6/QtWidgets.abi3.so
#22 0x00007ffff1fbdb76 in QWidgetPrivate::hide_helper() (this=this@entry=0x55555646a360) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qwidget.cpp:8271
#23 0x00007ffff1fbf158 in QWidgetPrivate::setVisible(bool) (this=0x55555646a360, visible=<optimized out>) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.0/src/widgets/kernel/qwidget.cpp:8447
[...]
We fix this problem by explicitly handling focus before hiding the UI elements.
This is done with a new TabbedBrowser.on_release_focus() slot, which is bound to
signals emitted just before things are hidden: The existing Command.hide_cmd()
for the status bar, and a new release_focus() signal for prompts.
Additionally, we make sure to not double-handle hiding in the statusbar
code when it's already handled separately for comamnd mode.
Unfortunately, no tests for this, as application window focus is required to
reproduce the issue. In theory, a test in scroll.feature could be added though,
which loads simple.html, scrolls down, shows/hides a prompt or the status bar,
and then checks the vertical scroll position is != 0.
Fixes #2236
Fixes #7885
|
|
See #7854
|
|
See #7837
|
|
|
|
Fix docstrings
|
|
|
|
Closes #7814
|
|
|
|
|
|
|
|
|
|
See #7646
|
|
Makes the lambdas more flexible, e.g. mapping a single key to a different flag depending on Chromium version. Ended up being unneeded for reading from canvas flag, but still useful.
|
|
Implemented as a separate setting in Chromium, but exposed to qutebrowser users
as a value for `policy.images`, as it's a simple toggle that does not have any
effect when `policy.images` is not set to `smart` anyways.
To support this, the _Settings.mapping value now supports None values,
which leads to _Setting.chromium_tuple to return None, which means that
no switch is added in this case.
See #7646
|
|
Closes #7929
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Given that the two branches share rather little, it seems simpler to separate the two tests. Also use monkeypatch, since we don't use any of unittest.mock's complexity
|
|
|
|
This was fixed up in https://github.com/qutebrowser/qutebrowser/pull/8006
after a mypy update caused us to examine the typing.AnyStr thing a bit more.
But both overloads got set to have a `str` return type, so the possible
bytes return type got lost. Mypy didn't pick that up because `binary=True` is
only used in `qutebrowser/browser/webkit/cookies.py` which probably isn't
being type checked.
I had to remove the default from the binary arg of the bytes version (the ` =
...` bit) because if both overloads have the kwarg as optional mypy doesn't
know which to match a call with just one positional argument against. Eg
`savefile_open('some_file')` would match both.
I checked with reveal_type:
diff --git i/qutebrowser/utils/qtutils.py w/qutebrowser/utils/qtutils.py
index 89175ca4ee60..5b86e441a1bc 100644
--- i/qutebrowser/utils/qtutils.py
+++ w/qutebrowser/utils/qtutils.py
@@ -290,6 +290,20 @@ def savefile_open(
raise QtOSError(f, msg="Commit failed!")
+def test_savefile_types() -> None:
+ from typing_extensions import reveal_type
+
+ maybe_str_default = savefile_open("/tmp/string_file")
+ # note: Revealed type is "contextlib._GeneratorContextManager[typing.IO[builtins.str]]"
+ reveal_type(maybe_str_default)
+ maybe_str_explicit = savefile_open("/tmp/string_file", binary=False)
+ # note: Revealed type is "contextlib._GeneratorContextManager[typing.IO[builtins.str]]"
+ reveal_type(maybe_str_explicit)
+ maybe_bytes = savefile_open("/tmp/bytes_file", binary=True)
+ # note: Revealed type is "contextlib._GeneratorContextManager[typing.IO[builtins.bytes]]"
+ reveal_type(maybe_bytes)
+
+
def qcolor_to_qsscolor(c: QColor) -> str:
"""Convert a QColor to a string that can be used in a QStyleSheet."""
ensure_valid(c)
|
|
This is just to get the CI to re-trigger.
Apparently the checkout action doesn't actually checkout the branch
being proposed for merge but checks out an actual merge commit. So if
you push a PR while main is broken it'll say changes from main are on
your branch. That's a little unexpected.
main is fixed now and I tried re-running the CI jobs from the web UI but
they are still failing with the same errors. Hence this merge of main
just to get a change on the branch. I could have gone and found a typo
to fix instead. I know I've left enough of them around.
ref: https://github.com/actions/checkout/issues/881
|
|
We thought #7489 would be fixed on chrome 112 but it appears to still be
an issue. As discussed on the issue, it's not clear how many workflows
would be affected by accelerated 2d canvas and we don't have enough data
to detect the affected graphics configurations. So lets just disable
accelerated 2d canvas by default and users who want it turned on can do
so via the setting.
If some major use case pops up to enable this by default where possible
we can revisit and think of more nuanced feature detection.
I've kept the handling of callable values of `_WEBENGINE_SETTINGS`
because I don't like have to have something like
`--disable-accelerated-2d-canvas` written in code twice. The setting
above this one could probably be changed to use it too.
|
|
read back the manifest inside the context manager so we can find the
work dir.
|
|
|
|
|
|
Makes things easier if we get build/ right with the return value
|
|
|
|
pdfjs.get_pdf_basename() returned None, causing in a TypeError. Instead of
throwing mocker.patch at it, fix the underlying issue.
Given we made the same mistake in three places:
- :version
- test_real_file for PDF.js
- is_available() in pdfjs.py (calls the function but doesn't use the result, so
is a nop now, even if PDF.js wasn't found)
...evidently we need to change the API so it still raises an exception if no
PDF.js is available.
Amends 0144ae3576aaecde295d40e22d636f04240d6761.
|
|
html.escape is not needed after latest toofar changes
|
|
Otherwise, doing :restart fails because it tries to copy quirk dir to quirk dir.
QtWebEngine reads the env var in resourcePath() in
src/core/web_engine_library_info.cpp. That only seems to be called from
WebEngineLibraryInfo::getPath(), and that in turn gets called from
ResourceBundle::LoadCommonResources() in src/core/resource_bundle_qt.cpp.
Finally, that only seems to be called during Chromium initialization, so it
seems alright for us to unset this as soon as we initialized the first profile.
It also seems to work fine in my testing on Google Meet, and indeed fixes
:restart.
|
|
Update dependencies
|
|
|
|
Now we aren't using it for the patching we don't need it in this function.
Move the `get_pdfjs_basename()` call into `is_available()` too since having to
call two methods to check everything is there sounds like a pain.
|
|
We are setting window.Response to undefined to cause certain versions of
pdf.js to detect that fetch() isn't available and to fall back to XHRs. In
more recent versions of pdf.js the HTML string we were matching against has
changed, it has a 'type="module"' attribute now, so we need to change the
pattern we match against.
I don't think it matters where we put this mocking though, so I've just put it
after '<head>', which should hopefully be less fragile than matching against a
'<script>' element.
Note that this workaround isn't even relevant for the latest versions of
pdf.js (4+). It doesn't seem to use a check on `window.Response` as part of
fetch feature detection anymore (instead it uses fetch() for https? urls and
XHR otherwise). But I figured it was better to have the workaround applying
consistently, and not having an effect, vs having the workaround silently fail
to apply. Don't have a strong opinion on it though.
The other way to fix this would have been something like:
attrs = ""
if pdfjs_name.endswith(".mjs"):
attrs = ' type="module"'
pdfjs_script = f'<script src="../build/{html.escape(pdfjs_name)}"{attrs}></script>'
|
|
Now that pdf.js could be shipped with either js or mjs file extensions we
shouldn't hardcode the filename. Call the function for detecting the filename
instead. And make it public.
|
|
On CI now the sandbox test is failing on windows when we pop the header
line with an index error. It looks like the only line present on the
page is "Sandbox Status". It was working on CI the other day! Grrr
Hopefully it's a timing issue and the JS just hasn't finished running
yet? Not sure if just loading it again is the most reliable. Ideally we
would be listening for some event...
Pretty low effort but if this makes the test stop being flaky and we
don't have to look at it again that's fine with me.
|
|
|
|
|
|
See https://bugreports.qt.io/browse/QTBUG-112017 and #5390
|
|
|
|
|
