| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This should be a feature option, not a bool option.
Anyway, it doesn't matter, since it's redundant with the API key option.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It isn't clear whether the API/ABI of libportal are entirely stable yet
(https://github.com/flatpak/libportal/issues/33) so it is not necessarily
appropriate for longer-term-supported OS distributions to include it.
When building a version of epiphany for a distribution package, which is
only intended to be packaged in a format other than as a Flatpak app,
libportal isn't necessary anyway.
libportal is also Linux-specific, so non-Linux OSs will likely want to
disable it (even if it might compile successfully).
Signed-off-by: Simon McVittie <smcv@debian.org>
|
| |
|
|
|
| |
In case we cannot provide a gsb api key, we should disable the service entirely and
hide the config option in preferences window.
|
| |
|
|
|
|
| |
Move gsb_api_key to meson_options.txt so we can provide the necessary support within flatpak, but can disable it for the rest.
Fixes: https://gitlab.gnome.org/GNOME/epiphany/-/issues/682
|
| |
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/epiphany/issues/20
|
| |
|
|
|
| |
This could break anyone currently using -Dunit_tests=false, but probably
not many people choose that.
|
| |
|
|
|
|
|
|
| |
Require opt-in to run network tests.
Our CI has network, so we'll run it there.
Fixes #684
|
| |
|
|
| |
Fixes: https://gitlab.gnome.org/GNOME/epiphany/issues/586
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's experimental and not supposed to be enabled, but got turned on in
Arch, so best move it to a sidebranch for now. I'm not sure if we'll
ever bring it back, though. HTTPS Everywhere was a great idea a few
years ago, when it was common for websites to offer experimental support
for HTTPS but not redirect users to it automatically. Nowadays, such
websites almost always problems, such as blocked mixed content or invalid
HTTPS certificates, or have disabled HTTPS since the ruleset was
written. That means, to do this right, we have to ignore TLS errors --
including in subresources -- and disable mixed content blocking. This
scheme to preserve web compatibility needs to be implemented before we
consider bringing it back.
Meanwhile, more and more websites are redirecting to HTTPS and are
nowadays configured to handle this correctly, so the necessity of HTTPS
Everywhere is lower now than ever before, and decreasing fast. Moreover,
if a website implements its own proper support for HTTPS and starts
automatically redirecting users to it, but the ruleset is not updated,
then under the scheme I propose above, the ruleset would become a way of
*reducing* security for websites once they've begun to support HTTPS. So
I'm skeptical that we should bring this back at all. Times, they are
a-changing.
https://bugzilla.gnome.org/show_bug.cgi?id=794803
|
| |
|
|
| |
This reverts commit 3d674bbdf9713a2ea7bdeead6bee9e4c8e337b19.
|
| |
|
|
|
|
| |
Probably a recipe for disaster, but half the tests are already broken
and disabled, why not disable even more? But really, I just don't want
to reinstall JHBuild in order to do a release.
|
| |
|
|
|
| |
And use git describe to compute the version, so I can tell which commit
I'm using.
|
| |
|
|
|
|
|
|
|
|
|
| |
The Meson developers have recommended that we omit enable/disable
prefixes from option names, as it's redundant with the boolean value.
Note that we intentionally retain underscores, rather than hyphens.
There doesn't seem to be a convention for Meson, but this is suggested
by the Meson documentation, looks nicer, and matches the convention in
CMake world, which is the only other major build system to use -D
notation for defining options.
|
| |
|
|
|
| |
All our debug stuff has been enabled in release mode since switching to
meson. Time to fix that.
|
| | |
|
| |
|
