Age | Commit message (Collapse) | Author |
|
Fails without the fix on main on QtWebEngine 6.4 (works on 6.2).
Works fine after the fix.
See #7820
|
|
Don't rely on the global QApplication.focusWidget()
See #7820
|
|
Fixes #7820
|
|
Shows objectName() and the metaObject().className() if available.
More debug info for #7820
|
|
This partially solves #7820. The web view still loses focus for an unknown
reason (apparently when swtiching out the rendering process?), but at least it
regains focus now when the window is unfocused and then focused again.
|
|
|
|
Looks like the version check was wrong
|
|
See https://github.com/python/mypy/issues/15870
|
|
Seems to show as 50 instead of 65 somehow...
|
|
|
|
qutebrowser/feat/mac_sandbox_pre_release_pyinstaller
Feat/mac sandbox pre release pyinstaller
|
|
The CheckPlatform macro will prompt the user user to use the 32bit installer
if they are on a 32bit system. But we don't provide a 32bit installer anymore.
This commit changes the OS version check for Qt5 builds to be based on checking
version numbers ourselves too, so that we can have our own error message.
Also moves the Qt5 conditionals to be compile time ones.
|
|
|
|
We dropped 32bit support in #7804 and as a result removed the arch
suffix from the binary that pyinstaller produces. This commit removes it
form the lookup path in the installer too.
Note that we are leaving the arch string in the installer itself for
now. Mostly because it'll be removed as part of a later change when the
installer itself is refreshed. But it might also be useful to clarify in
the installer names what the arch is? Maybe, that reasoning might not
fit with the previous change to remove the arch strings.
|
|
The Qt docs for 6.5 say that the minimum supported version is Windows 10
1809.
Experimentally it seems qutebrowser and it's dependencies work fine on a
version as early 1607.
There should be no change in OS version requirements for the Qt5 build,
although we've dropped 32 bit support already and in a future version of
the installer we may bring the minimum OS version support in line with
the Qt6 requirements for simplicity too.
Added a new QT5 version into the NSIS scripts so we can do the different
version check per installer build. It just uses the python bool
serialization format so should always be "True" or "False", but I've
added a fallback anyway for consistency.
|
|
Reproducers:
python3 -c 'from qutebrowser.extensions import loader'
python3 -c 'import qutebrowser.commands.command'
Specifically the first on was being called from misc/qutebrowser.spec in
the nightly installer build jobs.
Running the full application still works fine somehow. So it might be
possible to import things in the right order to avoid the loop. But
since this is part of our API we probably don't want to require too much
juggling.
|
|
feat/mac_sandbox_pre_release_pyinstaller
Only conflict was the removal of support for 32bit builds in
build_release.py
|
|
This reverts commit 8715263c757072fcca14d4e543efa631fda149cd.
ref: #7803
|
|
Restored from dd2fc8e10bb9d4a1bd0158110173793a18736d6b
Now that we are putting our data files in the qutebrowser/ directory
again pkgutil/importlib is getting confused by that dir existing and
returning us a FileLoader for `qutebrowser.components`, I think that's
what's happening anyway. Should try reverting that and this commit and
see if extensions get loaded right again.
So bring back this workaround of using the toc on the PyInstaller loader
to get the list of component modules for now.
ref: #7803
|
|
Trying to switch the bundle ID again and see if that makes things work.
Will need to check 5.15 too.
ref: https://github.com/qutebrowser/qutebrowser/pull/7803#issuecomment-1657106925
Closes: #5180
|
|
I don't want to deal with having to review development changes of
pyinstaller every week. So pin to one commit for now that we can
actually test. I'm subscribed to release notifications on github so I'll
manually change this back to point to the pyinstaller pypi package ones
it does.
|
|
|
|
Until we look at #7220 proper (thus splitting this into a qute-start:// which
could probably have more permissions to do remote requests), we'll need to do
with somewhat of a hack to allow this even if QtWebEngine does not.
Given the very limited scope (only from qute://start, only opening the search
engine URL, only with a form submitted request), this should be acceptable
without compromsing security in any way.
Fixes #7790
|
|
With Qt 6.3+, user interaction is required to navigate outside of qute:// from a
qute:// page.
Fixes #7815
See #7220 - should be revisited once we have a qute-bookmarks:// instead where
we can adjust permissions when registering the URL handler.
|
|
Needed mostly for urlmarks BDD tests so they can clear things between tests.
Hopefully with --all, this won't be accidentally triggered by users.
Preparation for #7815
|
|
While not documented that way:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/cwait?view=msvc-170
It looks like that Windows sometimes sets errno to EACCES here (causing a
PermissionError):
> os.waitpid(pid, 0) # pid, options... positional-only :(
E PermissionError: [Errno 13] Permission denied
I have no idea why it happens, but it results in flaky tests on CI.
We aren't particularly interested in this (we just want to make sure the process
is cleaned up before the next test runs...), so let's just ignore this.
|
|
Run package building on CI with warnings turned into errors
|
|
Drop 32bit Windows release support
|
|
See https://github.com/python/mypy/issues/2087
|
|
We got a `DeprecationWarning` during the package build, which we were not able to
reproduce locally. For now we just don't turn this particular `DeprecationWarning` into
an exception to not fail CI.
|
|
We want to run a package build in CI with warnings turned into exceptions, in order to
catch issues in CI (e.g. DeprecationWarning).
|
|
This is still *very* basic, but it serves its purpose of failing for warnings during
package build.
I verified that `tox -e package` is failing by introducing some warnings with this change:
```diff
diff --git a/setup.py b/setup.py
index feb949595..6810eaf1e 100755
--- a/setup.py
+++ b/setup.py
@@ -51,8 +51,7 @@ def _get_constant(name):
try:
common.write_git_file()
setuptools.setup(
- packages=setuptools.find_namespace_packages(include=['qutebrowser',
- 'qutebrowser.*']),
+ packages=setuptools.find_namespace_packages(include=['qutebrowser']),
include_package_data=True,
entry_points={'gui_scripts':
['qutebrowser = qutebrowser.qutebrowser:main']},
```
|
|
See #7801
|
|
|
|
|
|
Catches issues with invalid URLs early instead of later in the code (e.g. when
the brave adblocker runs on the URL).
Hopefully helps catch issues with broken config.py hacks calling redirect().
|
|
If a server gets fixed and now advertises spec 1.2, there is no reason we should
complain about things.
See https://github.com/phuhl/linux_notification_center/commit/5427acd551ce6dc4c74bdf8090904c6d254b74f1
|
|
Update dependencies
|
|
|
|
|
|
|
|
Now that we aren't patching the build we shouldn't have to try to
re-sign in.
|
|
Update dependencies
|
|
When handling the automated dependancy update PR GH warned on push of a
low priority security issue with cryptography. So updating that now.
Rich has an update available too.
ref: https://github.com/qutebrowser/qutebrowser/security/dependabot/32
ref: #7807
|
|
Seems the new flake8 release is pulling down a (somewhat) new
pycodestyle that prefers is/is not over ==/!= when comparing exact
types. They should behave the same.
ref: #7807
|
|
|
|
In the past various workarounds have been put in place to move/copy/symlink
files in the macOS app build to make PyQt work and let us sign it.
As of https://github.com/pyinstaller/pyinstaller/pull/7619 our downstream
patching should not be required.
The application seems to run fine.
The app size is 155 MB.
Signing is still to be verified.
|
|
|
|
It's a change from before but it's strictly more accurate anyway, in the
application we are always using sip from under the PyQt module, even if
PyQt5 registers it as the plain `sip` too. And now it's consistent with
what we have to do for PyQt6.
|
|
Fixed:
* The `PyQt{5,6}.sip` version is now shown correctly in the
:version|--version output. Previously that showed the version from the
standalone `sip` module which was only set for PyQt5.
|