| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Opening a download in a new tab leaves a "dead" tab (see example of a "dead" tab below)
behind. When saving a session containing such a "dead" tab, we end up with entries in
the session like this one:
```yaml
- active: true
history:
- active: true
last_visited: '1970-01-01T02:00:00'
pinned: false
scroll-pos:
x: 0
y: 0
title: ''
url: ''
zoom: 1.0
```
When loading a session containing such a "dead" tab, qutebrowser does not restore any
history of that session and logs the following error:
```
ERROR: Failed to load session default: PyQt6.QtCore.QUrl('') is not valid
```
As pointed out by @The-Compiler in this comment[1], the behavior of
`QWebEngineHistoryItem::isValid()`[2] changed somehow between Qt 6.4 and 6.5.
`QWebEngineHistoryItem::isValid()` now returns `True` for "dead" tabs, even though the
history item is not valid (i.e. `url().isValid()` returns `False`).
To fix this we simply add an additional check if the URL is valid before adding a tab to
the session to be saved.
[1] https://github.com/qutebrowser/qutebrowser/issues/7696#issuecomment-1672854592
[2] https://github.com/qt/qtwebengine/blob/v6.5.2/src/core/api/qwebenginehistory.cpp#L69-L75
|
|
|
|
|
|
Follow-up to #7809, see #7214
|
|
|
|
|
|
|
|
Hopefully makes it more reliable
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fails without the fix on main on QtWebEngine 6.4 (works on 6.2).
Works fine after the fix.
See #7820
|
|
See https://github.com/pallets/werkzeug/commit/5ff0a573f4b78d9724f1f063fb058fd6bc76b24d
With that commit, encoding the header ourselves means that we'll actually be
navigating to the path `/b'data/...'` instead of `/data/...`.
|
|
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.
|
|
Group commands related to commands/commandline by prefixing them with `cmd-`. In this
case we additionally renamed the command slightly to fit better with the `cmd-` prefix.
|
|
Group commands related to commands/commandline by prefixing them with `cmd-`. In this
case we additionally renamed the command slightly to fit better with the `cmd-` prefix.
|
|
Group commands related to commands/commandline by prefixing them with `cmd-`.
|
|
Group commands related to commands/commandline by prefixing them with `cmd-`. In this
case renaming the command slightly was a better fit.
|
|
Group commands related to commands/commandline by prefixing them with `cmd-`.
|
|
Grouping commands related to commands/commandline by prefixing them with `cmd-`.
|
|
|
|
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
|
