summaryrefslogtreecommitdiff
path: root/libre/qutebrowser/webkit-warning.patch
blob: e659e68ee3373c436e476c93773d2fbb8da5ec9f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
diff --git a/qutebrowser/html/warning-webkit.html b/qutebrowser/html/warning-webkit.html
index 7fc2290..938762c 100644
--- a/qutebrowser/html/warning-webkit.html
+++ b/qutebrowser/html/warning-webkit.html
@@ -2,81 +2,14 @@
 
 {% block content %}
 <h1>{{ title }}</h1>
-<span class="note">Note this warning will only appear once. Use <span class="mono">:open
-qute://warning/webkit</span> to show it again at a later time.</span>
 
 <p>You're using qutebrowser with the QtWebKit backend.</p>
 
-<p>While QtWebKit has gained some traction again recently, its latest release
-(5.212.0 Alpha 3) is still based on an old upstream WebKit. It also lacks
-various security features (process isolation/sandboxing) present in
-QtWebEngine. From the upstream release notes:</p>
-
 <blockquote>WARNING: This release is based on old WebKit revision with known
 unpatched vulnerabilities. Please use it carefully and avoid visiting untrusted
 websites and using it for transmission of sensitive data. Wait for new release
 from qtwebkit-dev branch to use it with untrusted content.</blockquote>
 
-<p>It's recommended that you use QtWebEngine instead.</p>
-
-<h2>(Outdated) reasons to use QtWebKit</h2>
-<p>Most reasons why people preferred the QtWebKit backend aren't relevant anymore:</p>
-
-<p><b>PDF.js support</b>: Supported with QtWebEngine since qutebrowser v1.5.0.</p>
-
-<p><b>Missing control over Referer header</b>: <span
-class="mono">content.headers.referer</span> is supported with QtWebEngine since
-qutebrowser v1.5.0.</p>
-
-<p><b>Missing control over cookies</b>: With Qt 5.11 or newer, the <span
-class="mono">content.cookies.accept</span> setting works on QtWebEngine.</p>
-
-<p><b>Graphical glitches</b>: The new values for the <span
-class="mono">qt.force_software_rendering</span> setting added in v1.4.0 should
-hopefully help.</p>
-
-<p><b>Missing support for notifications</b>: With qutebrowser v1.7.0, initial
-notification support was added for Qt 5.13.0.</p>
-
-<p><b>Resource usage</b>: qutebrowser v1.5.0 added the <span
-class="mono">qt.process_model</span> and <span
-class="mono">qt.low_end_device_mode</span> settings which can be used to
-decrease the resource usage of QtWebEngine (but come with other drawbacks).</p>
-
-<p><b>Not trusting Google</b>: Various people have checked the connections made
-by QtWebEngine/qutebrowser, and it doesn't make any connections to Google (or
-any other unsolicited connections at all). Arguably, having to trust Google
-also is a smaller issue than having to trust every website you visit because of
-heaps of security issues...</p>
-
-<p><b>Nouveau graphic driver</b>: You can use QtWebEngine with software
-rendering. With Qt 5.13 (~May 2019) it might be possible to run with Nouveau
-without software rendering.</p>
-
-<p><b>Wayland</b>: It's possible to use QtWebEngine with XWayland. With Qt
-5.11.2 or newer, qutebrowser also runs natively with Wayland.</p>
-
-<p><b>Instability on FreeBSD</b>: Those seem to be FreeBSD-specific crashes,
-and unfortunately nobody has looked into them yet so far...</p>
-
-<p><b>QtWebEngine being unavailable in ArchlinuxARM's PyQt package</b>:
-QtWebEngine itself is available on the armv7h/aarch64 architectures, but their
-PyQt package is broken and doesn't come with QtWebEngine support. This
-<a href="https://archlinuxarm.org/forum/viewtopic.php?f=15&t=11269&p=54587">has
-been reported</a> in their forums, but without any change so far. It should
-however be possible to rebuild the PyQt package from source with QtWebEngine
-installed.</p>
-
-<p><b>QtWebEngine being unavailable on Parabola</b>: Claims of Parabola
-developers about QtWebEngine being "non-free" have repeatedly been disputed,
-and so far nobody came up with solid evidence about that being the case. Also,
-note that their qutebrowser package is usually very outdated (even qutebrowser
-security fixes took months to arrive there). You might be better off chosing an
-<a href="https://qutebrowser.org/doc/install.html#tox"> alternative install
-method</a>.</p>
-
-<p><b>White flashing between loads with a custom stylesheet</b>: This doesn't
-seem to happen with <span class="mono">qt.process_model = single-process</span>
-set. However, note that that setting comes with decreased security and
-stability, but QtWebKit doesn't have any process isolation at all.</p>
+<p>If that bothers you, it is recommended that you use another web browser instead,
+such as IceCat, IceWeasel, or Epiphany.</p>
 {% endblock %}