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.
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.
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.
Since the bug was fixed in qtbase it shouldn't matter what version of
PyQt (or webengine for that matter) you are running against. So pass
`compiled=False`.
Also expand the docstring of `check_version()` to explain a little more
what the `compiled` kwarg does. Based on a discussion here:
https://github.com/qutebrowser/qutebrowser/pull/7933#issuecomment-1732400960
What's still not clear to me is when the runtime and compiled Qt
versions can differ. I always have to rebuild PyQt when I switch Qt
versions, but maybe I'm doing something wrong there.
toofar
Florian Bruhin
dependabot[bot]
qutebrowser bot
arza