Konqueror

• Konqueror can now be configured to restore the last tabs and window state when starting
• Improved the algorithm which chooses which window to use when Konqueror is called externally to open an URL. Now the most recently-used window in the current activity will be used
• The ability to change the browser identification is back, even if in reduced form. Due to the limitations of the web engine currently used by Konqueror, you can't change the browser identification depending on the URL of the page being visited, but only globally.
• Add new actions to Akregator plugin menu. Now you can copy the RSS Url to clipboard and directly display the RSS file

In T12472#281200, @kossebau wrote:

Curious: how do the settings in Plasma SystemSettings>Network>Setings (Proxy, Connection Preferences, Cookies) make it at least to Qt/KF-based applications? Is there a chance this config data is only picked up by KIO classes, and thus only when KIO::AccessManager is hooked into the QtNetwork logic?

Asking because https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/142 says

KIOAccessManagerFactory does not seem to be needed either

and the "not seem" triggers my curiousity if someone actually knows?

I tried using dialog->setFaceType(KPageDialog::Tree) and I think it could work, even if it's not as nice as the current version. Something must be done for the ordering: one problem is that the .desktop files don't all belong to Konqueror (for example, some are from dolphin).

In T14501#262376, @alex wrote:

I just realized that Konqueror uses the hierarchical view too, just like Kontact did before the classes were imported there.

@stefanocrocco Not sure what to make of this. Could the settings dialog just be flattened? Then the issue would go away without the need to adjust anything in frameworks.

In T13806#253395, @dfaure wrote:

Unless someone is interested in redesigning the whole mechanism, I'd say we should go with "moving" the code (copying and deprecating).
Opinions?

I'm all right with both approaches. My only worry with the more radical one is that going that way, you'll take away the option to use KParts plugins from future applications. If you think it unlikely that there'll be other applications needing this feature, however, I'm not against it.

I think it would be worth to put it back. I think QtWebEngine already provides support for doing something like it using QWebEnginePage::save() (even if I never tried using it), however a solution which didn't rely on a specific part would be, in my opinion, even better. I remember that when I ported the webarchiver plugin to KF5 (before switching to QtWebEngine) I wondered why it didn't use wget instead of doing all the work manually. Of course, this requires having wget installed, but I don't think it would be an issue.

In D29066#675219, @bcooksley wrote:

@stefanocrocco Can you please confirm you have uploaded your SSH Keys to https://invent.kde.org/?
This has to be done separately to the upload on Identity (which no longer has any effect)

In D29066#675217, @dfaure wrote:

In the repo where your git push fails, what does git remote -v say?

David, sorry to disturb you but I'm having trouble while pushing this. I think it's related to the GitLab migration. I had to run git kclone in my local clone to pull the latest changes. Now, I can't use arc land because it complains that

• Improve the message text
• Only ask about invalid proxy settings for QtWebEngine if it's the default engine

In D26253#675165, @rjvbb wrote:

Anyway, as David says, you could just align Konqueror's Qt requirement with the stricter one from its KF5 dependencies. There is little point not to, after all. Rather spend your time getting rid of the inappropriate errors about a missing konq slave. David already explained why the konq: stuff cannot be implemented upstream from the kparts in Konqueror itself (invoking binaries), but maybe an actual KIO slave could do everything you want too while still serving standard HTML to the kparts doing the rendering?

I'll ping you if I do decide to implement konq: support in kwebkit_part and run into something similar there.

In D26253#675109, @rjvbb wrote:

I can't really reproduce this issue. Which Qt version are you using?

I don't really expect you did a full build of Qt, the frameworks etc. into a parallel prefix like I do, or did you?

Hum, yes, I did backport the code so it builds against Qt 5.9 but

The way Konqueror has QWebEngine handle local resources has changed radically from Qt 5.12 onwards.

just how would that explain that the generated html code opens just fine when I save it to a .html file first?
I can understand you need to intercept links that require actions not implemented by the engine but why would you need to do that for CSS and image resources?

Does this radical change depend on new QtWebEngine APIs not in 5.9? I do have a Qt 5.12 build installed with a wrapper script causing my KDE builds to use that Qt version. I get the same issue then, which would be expected if my backport shoehorning missed something crucial.

BTW, when I run against Qt 5.12 I see this additional output on the terminal when I switch to the WebEngine mode:

Please register the custom scheme 'error' via QWebEngineUrlScheme::registerScheme() before installing the custom scheme handler.
Please register the custom scheme 'konq' via QWebEngineUrlScheme::registerScheme() before installing the custom scheme handler.
Please register the custom scheme 'help' via QWebEngineUrlScheme::registerScheme() before installing the custom scheme handler.

David, have you had time to check the changes I made to this?

In D26253#675085, @rjvbb wrote:

This is exactly what I do:

I tried setting the default engine to WebKit, restarting Konqueror, then, from the strarting page, switching to WebEngine using the View Mode menu.

No need to do anything else. Here's the full output when I launch konqueror (with WebKit as the default engine) and then switch it to WebEngine (after the slave error message):

org.kde.kwindowsystem: Loaded plugin "/opt/local/share/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so" for platform "xcb"
kf5.kio.core: couldn't create slave: "klauncher said: Unknown protocol 'konq'.\n"
[12814:12972:0612/220936.807589:ERROR:nss_util.cc(808)] After loading Root Certs, loaded==false: NSS error code: -8018
QFSFileEngine::open: No file name specified
js: Not allowed to load local resource: file:///opt/local/share/kf5/infopage/kde_infopage.css
js: Not allowed to load local resource: file:///opt/local/share/konqueror/about/konq.css
QFSFileEngine::open: No file name specified
js: Not allowed to load local resource: file:///usr/share/icons/Ciment/32x32/places/user-home.png
js: Not allowed to load local resource: file:///usr/share/icons/osx/places/48/user-trash-full.png
js: Not allowed to load local resource: file:///usr/share/icons/osx/places/32/folder-remote.png
js: Not allowed to load local resource: file:///usr/share/icons/oxygen/32x32/places/bookmarks.png
js: Not allowed to load local resource: file:///usr/share/icons/Ciment/16x16/actions/go-next.png
QFSFileEngine::open: No file name specified

In D26253#675051, @rjvbb wrote:

It took me way too long to figure out that this is the source of the regression below, and not a missing "konq:" kioslave ...

For me, the main interest in Konqueror lies in its ability to use WebKit2 (with the rebooted QtWebKit version, evidently), so I can use it in a more or less modern browser interface. (There's just no need for yet another grass-roots wrapper around Chromium IMHO but that's a different issue.)

When I do activate the WebEngine backend I see this on the terminal:

js: Not allowed to load local resource: file:///opt/local/share/kf5/infopage/kde_infopage.css
js: Not allowed to load local resource: file:///opt/local/share/konqueror/about/konq.css
js: Not allowed to load local resource: file:///opt/local/share/icons/Ciment/22x22/places/user-home.png
js: Not allowed to load local resource: file:///opt/local/share/icons/osx/places/48/user-trash-full.png
js: Not allowed to load local resource: file:///opt/local/share/icons/osx/places/22/folder-remote.png
js: Not allowed to load local resource: file:///opt/local/share/icons/oxygen/base/22x22/actions/bookmarks.png
js: Not allowed to load local resource: file:///opt/local/share/icons/Ciment/16x16/actions/go-next.png

but pasting the URL into the konqueror address bar opens the files just fine.

• Don't attempt to use WPAD or PAC proxies
• Offer the user the ability to immediately display the proxy settins dialog

In D29066#654708, @dfaure wrote:

Note that KProtocolManager also supports per-host proxies (via KPAC which runs javascript). This obviously won't work here.

In D19622#648533, @dfaure wrote:

@stefanocrocco do you want to test this and integrate it if it works? Looks like it got rather forgotten over time.

Only create the action collection when using KBookmarks 5.69.0

In D28789#647331, @dfaure wrote:

git checkout release/20.04
git cherry-pick -x 078f357bc
git push
git checkout master

In D28789#647294, @arojas wrote:

Can you push this to 20.04 too please?

• Remove empty line

In D26428#604690, @dfaure wrote:

In D26428#604662, @stefanocrocco wrote:

In D26428#589235, @dfaure wrote:

I could help you with progress notifications (see KJob), but "download the file to a temporary location" is a big no no. Think of a 4GB video file...

I think I'm missing something here. Isn't this how things usually work, both in Konqueror and in other browsers? When I click on a link to a PDF file in Konqueror, the file is downloaded to a file in /tmp which is then opened. When I clicked on a link to a MPG video in Firefox, it downloaded it to a file in /tmp, then opened it with another program.

Possibly correct about Firefox, because it doesn't know better.
Wrong about Konqueror and okular. When you click on a link to a PDF in konqueror, it first determines the mimetype (application/pdf), then looks up the associated application (okularApplication_pdf.desktop), and then KRun looks into that and notices that it says Exec=okular %U, which means it supports URLs. So konqueror calls okular with the URL as argument, and okular decides how to handle this. Usually this allows the receiving application to download into memory rather than using a temp file. For apps that can edit files, like kate, this even allows saving back onto the actualy remote location (which would be unknown if the app was called with a temp file as argument). The kioexec hack (download + start app + wait for it to finish + offer to upload) is only used for apps that don't support URLs (no %u/%U in the exec line).
This isn't KDE specific, it's the freedesktop standard for application desktop files. With the problem of the supported schemes not being 100% the same, but I'm going offtopic.
For instance, xine says Exec=xine %U because it can stream from HTTP, you definitely don't want to download a huge video to a temp file before looking at the first few seconds of it.

In D26428#589235, @dfaure wrote:

I could help you with progress notifications (see KJob), but "download the file to a temporary location" is a big no no. Think of a 4GB video file...

In D26428#590515, @stefanocrocco wrote:

In D26428#589325, @vkrause wrote:

In D26428#589235, @dfaure wrote:

There is one major drawback with this plan though. There were talks about deprecating kio_http for security reasons... Adding Volker as reviewer.

Wasn't the last thing we discussed rebasing kio_http on QNAM, so we can keep the unified KIO interface as well? IMHO the problem is our aging HTTP implementation, not so much the outside interface. In that case this doesn't sound incompatible to me.

The thing I find much more worrying here is the suggestion to decrypt TLS traffic in a proxy :) Does Webengine have an interface to inject custom CA certs? If not, you'd need to install this as a system CA cert, and that's a total no-go.

I'll investigate this as soon as I have some free time. Unfortunately, this week I'm quite busy, so I won't be able to do it at least until Sunday

In D26428#589325, @vkrause wrote:

In D26428#589235, @dfaure wrote:

There is one major drawback with this plan though. There were talks about deprecating kio_http for security reasons... Adding Volker as reviewer.

Wasn't the last thing we discussed rebasing kio_http on QNAM, so we can keep the unified KIO interface as well? IMHO the problem is our aging HTTP implementation, not so much the outside interface. In that case this doesn't sound incompatible to me.

The thing I find much more worrying here is the suggestion to decrypt TLS traffic in a proxy :) Does Webengine have an interface to inject custom CA certs? If not, you'd need to install this as a system CA cert, and that's a total no-go.

Thinking about how to force QtWebEngine to integrate with KIO, the only idea which comes to me is a crazy one: implement an HTTP proxy inside Konqueror and configure QtWebEngine to use it (QtWebEngine will use a proxy set with QNetworkProxy::setApplicationProxy). The proxy could retrieve the requested URL using KIO and examine the reply before passing it back to QtWebEngine. I believe it should work, even if there are several drawbacks:

• it requires to write an HTTP proxy from scratch. I've never done anything similar, but I think it's not easy
• I think it requires some changes in KIO. I didn't test it, but I believe currently KIO::get only returns the body of the request and not the headers. Maybe it would be possibile to add a signal which is emitted when the headers have been read, like it already does with the mimetype
• it has to decrypt HTTPS requests coming to QtWebEngine and encrypt the replies before passing them back, but I think it could be done. I've seen the mitmproxy proxy (https://mitmproxy.org/) do it using custom certificates which you need to install manually. However, I think that in our case, since the proxy and the client really are the same program, I believe there shouldn't be the need to install the certificate.

• Check whether the default HTML engine is QtWebEngine

In D26428#587865, @dfaure wrote:

I have no solution for issue number 2. It's the main reason why I'm unhappy with QtWebkit being deprecated and why I'm demotivated to maintain konqueror. The ability to integrate with KIO completely disappeared.

I noticed a problem: at startup, when the konq:blank page is displayed, the focus is given to the view rather than to the location bar as it used to be. This doesn't happen if you create new tabs. It seems that KMainWindowFactory::createNewWindow gives indeed focus to the location bar, but the focus is then moved to WebEngineView. I can't find out why. Do you have any idea?

• Add KonqUrl::scheme function and other small fixes

• Remove commented out lines
• Centralize management of konq URLs
• Fix the value of the StartURL option in the user's config file

In D26253#585713, @dfaure wrote:

The first is that if the user's konquerorrc file contains old default value for the StartURL entry, that value will be used instead of the new one, which will result in an error message.

How about this? http://www.davidfaure.fr/2020/replace_about_with_konq.diff

[rebase your changes to master first, I just pushed some cleanups]

• Remove commented out lines
• Centralize management of konq URLs

Keep compatibility with older versions of CMake

• Fix compilation with Qt before 5.13

In D24195#550875, @dfaure wrote:

Reindenting is fine, if needed :-)

I'm not sure what the "no part" bit is about, maybe stefanocrocco knows.

Made the requested changes. I also replaced QList with QVector for CookieUrlList.

In D23376#518013, @dfaure wrote:

OK, then it's not just normalizing, but translating from the HTTP header to the internal representation. That can indeed only happens once.

In D23376#517993, @dfaure wrote:

"if the domain is not empty, add a leading dot to it if it's not there" << that's a weird thing to do, if the spec says leading dots are just superfluous.

In D23376#517889, @dfaure wrote:

I admit that I'm quite lost between the Qt/KDE differences, what normalization does, and what a dot in front means. Something sounds fishy if normalizing twice isn't a no-op, indeed.

Use QFlags::testFlag

• Test both if path is empty and if path is /

Fixed spaces and replaced foreach with range-for as requested