| Age | Commit message (Collapse) | Author |
|---|
|
On CI I'm seeing:
No such file or directory: '/Users/runner/work/qutebrowser/qutebrowser/.tox/py39-pyqt515/lib/python3.9/site-packages/PyQt5/Qt5/resources'
Downloading the PyQt6_WebEngine_Qt6 wheel for mac from PyPI I can see the pak
file is at:
./PyQt6/Qt6/lib/QtWebEngineCore.framework/Resources/qtwebengine_resources.pak
And on a qutebrowser install made by pyinstaller it is at (symlinks in curly
braces):
/Applications/qutebrowser.app/Contents/{Resources,Frameworks}/PyQt6/Qt6/lib/QtWebEngineCore.framework/{Resources,Versions/A/Resources}/qtwebengine_resources.pak
And the Qt data path for reference is:
/Applications/qutebrowser.app/Contents/Frameworks/PyQt6/Qt6
So it looks like essentially we need to add a "lib/QtWebEngineCore.framework"
in there and capitalise "Resources".
A bit annoying to have the special case and hardocde paths like this. But it
should be pretty stable? I had a look at importlib_resources to try to see if
it could fine this stuff for us but I don't think it can.
I've checked with the pyinstaller windows builds and with the windows wheel
from PyPI and neither seem to need any special handling.
|
|
There is one test which does does the whole run through with the real
resources file from the Qt install, patches is to the cache dir, reads
it back and checks the json. All the other tests either use constructed
pak files or stop on earlier error cases.
For testing the actual parsing of the pak files I threw together a quick
factor method to make them.
I went back and forth over the parse code and looked for more error
cases, but it looks pretty solid to me
|
|
The "doesn't exist at expected location" error message is a bit
misleading, it actually prints the location in the directory we copied
stuff to instead of the source one. Oh well, it's good enough.
|
|
Fixes lint: shadows variables, docstrings, unused attribute
Move resource dir copying to its own method:
* will probably help with unit tests
* allows for cleaner overriding of what file to patch (instead of a big
nested block)
Adds a sneaky `assert` statement in there because the pak file should
definitely exist at that location. Although it not existing shouldn't
really be fatal...
Maintains the thing in `__main__`, although I'm not sure if we need to
keep that?
|
|
Update dependencies
|
|
|
|
The only affected version is 6.6.0. I'm passing `avoid_init` because
this patching is done right before the user agent is parsed (which only
happens on Qt5).
It's been proposed that we don't need to do this patching for users
running on distros that backported the fix to their webengine. Which I
think means that we would only do the patching on our bundled installer
version for window and mac. But I'm not sure I agree with that. I would
rather not have had to re-compile the fix into my build, and I don't
know what other distributors position on backporting patches is either.
For example I'm on debian, if they had 6.6.0, would they have backported
this fix? It looks like they've only got build related patches on the
current version for example: https://sources.debian.org/patches/qt6-webengine/6.4.2-final+dfsg-12/
And there's the flatpak version etc.
Anyway, if we want to add that check in too I think it would look like:
if not hasattr(sys, 'frozen'):
# Assume if we aren't frozen we are running against a patched Qt
# version. So only apply this quirk in our bundled installers.
return
|
|
We need to set the environment variable before webengine reads the
resources file. It could be unhelpful to do the patching before the IPC
/ open-in-existing-instance stuff, because that could lead to removing
the resources file the running instance is using, any later than that is
just down to developer preference I think. I chose to move it as late as
possible for now, just for clarity on where in the lifecycle it's
necessary. (This also means we can skip the separate backend check, but
that is pretty minor.)
I moved the patching later and later at init and verified that if it is
done before the profiles are initialized it successfully prevents the
crash. If done after the profiles are initialized we still crash. I do
remember looking at the profile initialization when trying to disable
extensions so that makes sense.
|
|
For windows I'm getting a "Module not found." error, which I suspect is
it not finding qutebrowser itself, but lets see.
ref: https://pyinstaller.org/en/stable/spec-files.html#giving-run-time-python-options
|
|
This reverts commit 6042fccbf58955dba251e833d3ed4d66d79102e9.
|
|
This reverts commit 64af5f0e264f5a79dc474838603f584b346f6ac4.
|
|
ref: #7806
|
|
It all just works!
Changes from the `__main__` implementation down below:
* copy the whole resources directory instead of just the one file:
looking at the implementation around QTWEBENGINE_RESOURCES_PATH it
uses the main resources file to find the one directory and then loads
the other resources from that dir. So I'm assuming it was crashing
because it couldn't find the other resources. Stack trace was:
#1 0x00007fffe95f1dca in content::ContentMainRunnerImpl::Initialize(content::ContentMainParams) ()
from /usr/local/Qt-6.6.0/lib/libQt6WebEngineCore.so.6
#2 0x00007fffe628cf09 in QtWebEngineCore::WebEngineContext::WebEngineContext() ()
from /usr/local/Qt-6.6.0/lib/libQt6WebEngineCore.so.6
#3 0x00007fffe628dfa4 in QtWebEngineCore::WebEngineContext::current() ()
from /usr/local/Qt-6.6.0/lib/libQt6WebEngineCore.so.6
#4 0x00000210b845c780 in ?? ()
#5 0x00000210b845c780 in ?? ()
#6 0x00007fffffffd480 in ?? ()
#7 0x00007fffe62391bb in QtWebEngineCore::ProfileAdapter::ProfileAdapter(QString const&) ()
from /usr/local/Qt-6.6.0/lib/libQt6WebEngineCore.so.6
* write stuff to our cache dir, not tmp ;)
I haven't actually checked this fixes an affected version of Qt (need to
rebuild or get from riverbank pypi). But I unpacked the pak file and it
has the right fake URL in it.
|
|
We need to pass objects, not indexes. Test with Qt 6.5 to exercise this
path.
|
|
|
|
|
|
|
|
qutebrowser/dependabot/github_actions/actions/setup-node-4
build(deps): bump actions/setup-node from 3 to 4
|
|
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 4.
- [Release notes](https://github.com/actions/setup-node/releases)
- [Commits](https://github.com/actions/setup-node/compare/v3...v4)
---
updated-dependencies:
- dependency-name: actions/setup-node
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
Update dependencies
|
|
|
|
|
|
if -> is
where -> were
|
|
(cherry picked from commit f4ba52d33fb73a44a9298098d062987f23fb79db)
|
|
|
|
(cherry picked from commit b3b1384037f0717a1905c67c69b887034345221c)
|
|
|
|
This reverts commit 597873286c78c1a998367c565125d0c0cb45b905.
|
|
|
|
Not needed on CI for a reason I don't quite understand, but needed locally for things to run.
|
|
|
|
Update dependencies
|
|
|
|
|
|
See https://riverbankcomputing.com/news/SIP_v6.7.12_Released
|
|
|
|
|
|
See https://mypy-lang.blogspot.com/2023/10/mypy-16-released.html
|
|
|
|
Update dependencies
|
|
https://pylint.readthedocs.io/en/stable/user_guide/messages/refactor/prefer-typing-namedtuple.html
Says to using the class based typing.NamedTuple instead of
collections.namedtuple, which just constructs a class based off of
strings.
Here we are creating a dynamic class based on the fields in the SQL result.
It's only called once for a query, so I don't think speed is an issue.
Also it's not used by the completion, looks like just :history
|
|
With pylint 3 there is a new option: https://pylint.readthedocs.io/en/latest/user_guide/messages/convention/use-implicit-booleaness-not-comparison-to-zero.html
It's disabled by default but we enable all warnings and disabled them as
desired.
This one is of the opinion that:
if x == 0:
is bad and
if x:
is good.
I feel that the first one (x == 0) is more clear. We aren't checking for
truthiness here, we are checking for a literal value, its very
intentional.
One might argue that being precious about making the type here is
redundant in current year with type checking tooling and all that. But
there are like a hundred of these checks in the code base so it seems a
well established pattern anyhow.
In summary, the new warning doesn't have a very strong use case and we
would prefer to stick with out established pattern.
|
|
Was getting R0913: Too many arguments (14/10) (too-many-arguments)
no idea what that is just showing up now
|
|
|
|
|
|
Slack now requires chrome 112+. At least one user says it still works
with 108 based. Although they did just do a UI refresh so I wouldn't be
surprised if something was broken with older versions.
Note that I'm not 100% sure that slack is actually doing a strict check
for 112, but based on their prior behaviour I assume so (they are
definitely checking for >99 so our old quirk is unhelpful at this
point).
Since I've told people to add ua-slack to their disabled quirks, should
I change the name of it now to make sure it gets re-enabled? Eh, they
can manage their own quirks.
|
|
We only want to be faking a newer chrome version, if we are already on a
newer one, we don't want to be faking an older one!
Another scenario is that we might want to fake a perpetually newer
version for some site. But that seems like a very problematic scenario
and I hope that never comes up.
|
|
Changelog: https://pylint.pycqa.org/en/latest/whatsnew/3/3.0/index.html#summary-release-highlights
remove `__implements__`:
That attribute is apparently from a rejected PEP. They say to inherit
from BaseChecker, which we are already doing.
https://github.com/pylint-dev/pylint/pull/8404
check_messages -> only_required_for_messages:
Seems straightforward instructions. I haven't actually tested it.
https://github.com/pylint-dev/pylint/pull/8409
remove emptystring extension:
Looks like this has been replaced by https://pylint.readthedocs.io/en/stable/user_guide/messages/convention/use-implicit-booleaness-not-comparison-to-string.html
Which is disabled by default but we have `enable=ALL`, so I guess that means
we indeed have it enabled.
And update changelog URLs.
|
|
|
|
|
