Doing so causes QtWebEngine to load its own view-source: page even if we supply
custom data.
Instead we pass the original page's URL (to not regress #2948).
This partially reverts #3521 and reintroduces TabData.viewing_source.
However, on QtWebEngine we can still ":view-source --pygments" and then
":view-source" (with or without "--pygments") again, because the bit gets
cleaned in _on_load_started.
See #3654.
This codepath may trigger a crash which was fixed by
0e75f3272d.
However, this commit does not make it more likely to happen, and this
patch was backported into arch (at least).
In the future, we may be able to use <enter> on qtwebkit with js,
without triggering this crash
It looks like chrome-error://chromewebdata/ triggers another invalid scheme
load which is why the endless loop happens. When we install a custom scheme
handler for chrome-error:// we can at least show an error page.
This issue was probably introduced in 545539f28d
- with JavaScript, we can't "click" on an external link.
There might be a better solution using
QWebEngineSettings::setUnknownUrlSchemePolicy(QWebEngineSettings::AllowAllUnknownUrlSchemes)
temporarily when using hints with PyQt 5.11.
Fixes#2833
This reverts commit 1956590df84a72c7f9a516e805d01529291fccf8.
Turns out the actual issue wasn't due to *invalid* links - it's with links
which have an unknown scheme.
There's still a change in behavior between Qt 5.10 and 5.11 though: Invalid
links are apparently not passed to acceptNavigationRequest (sometimes?) so we
don't show an error message. Instead, we just load about:blank. However,
Chromium does that too and we can't handle a real click easily, so let's just
ignore that one.
See #3661
This reverts commit 6cc920472ee4170b257a0b588687b175162e83df.
Since self._widget can go stale in the layout, we need to somehow solve this differently...
