Roughly eight months after closing of the previous thread regarding this Qt/KDE Web Browser issues topic, there are some news on the topic I find worth to share.

I'll keep it short:

While all the other web browsers for KDE struggle to render Flickr pages correctly, I found that the Otter browser has made strides since that above mentioned discussion. Some months ago it was hardly usable and crashed a lot, but now it appears to be leading the pack of Qt based web browsers. As I said, it's easy to find out, if you have a Flickr account. Otter is the only one to show all the menus and buttons on all pages I tested it with.

Now, there's a simple reason for that: It's the only browser that was developed based on Qt5 from scratch. All the others are obviously struggling with several challenges regarding the migration to Qt5. One thing is the new, largely asynchroneous API of the Blink rendering engine, as explained in the Qupzilla FAQ.

Especially for the Konqueror developers these must be hard times. First they put a lot of effort in KHTML, and did such a great job that Apple forked it and developed Webkit based on it, without giving back what they added to the community for quite some time. Finally, Webkit was open sourced, but when that happened it was too advanced to port Apple's enhancements back to KHTML. So the Konqueror developers made a smart and pragmatic decision: They enabled Konqueror to use both KHTML and Webkit, and left the choice up to the user.
However, the version of Webkit supported by Konqueror depends on the version supported by Qt. Unfortunately, the rendering engine included with Qt4 is already a bit outdated and lags some modern capabilities of upstream Webkit. However, with some codecs available from SBo, Konqueror was a viable browser, again, and in recent KDE4 incarnations it renders most pages quickly and correctly, with Flickr being one of very few exceptions.
But now, Qt5 has made yet another switch, away from Webkit towards Blink. And as the Qupzilla FAQ says, this imposes new challenges.

Having said that, I am pretty confident that the Konqueror developers will master that task and come up with a convincing and user-oriented solution, as before. It's just a matter of time, as the task is definitely rather involved this time.

This is not to forget all the other promising projects, like Qupzilla and Rekonq. Let's see, what they are capable of, but it looks like by some point in 2016 we'll have Qt/KDE web browsers galore, all supporting Blink or Webkit, with different UIs and features, so that we can choose based on the concrete task, which one we'll use.

In the meantime, Otter browser is lighting the way, regarding Qt/KDE web browsers, and demonstrates, what's possible with Qt5. The version available at SBo has proved to be very stable, here, and the UI is pleasingly uncluttered.

One final question is left though, just out of curiosity, and because I am also a big fan of Seamonkey: Is anyone aware of a Qt/KDE based web browser using Mozilla's rendering engine Gecko? There were some projects in the past, one of them driven by Nokia, but they are probably now abandoned. But if anyone knows of an active project, I'd appreciate if you would share a link.

gargamel

BTW, I am using Otter browser with Qt 5.4.2, both from SlackBuilds.org, in Slackware64-14.1 and Slackware64-current with Alien BOB's KDE 5.
I also should mention that Seamonkey is still the browser I use most of the time. As good as Otter is, now, Seamonkey is still "smoother" with some pages. One example: If you enlarge a photo in Flickr, so that is bigger than the browser window, there is a vertical scroll bar. This allows you to smoothly scroll with Seamonkey, but is a bit "shaky" sometimes and just not functional the next time, with Otter. This is definitely a minor issue, and Otter browser is quite suitable for daily use, and so are Konquerer and Qupzilla and Rekonq, just that they struggle with a couple more pages than Otter or the Mozilla suite of web browsers.

I have never used Chromium or Chrome myself, BTW, so I cannot compare them with the above mentioned browsers. The reasons are:

• I don't like Chrome, because it is known to "phone home" occasionally, and no-one knows what it it actually tells...
• I am looking for a browser that integrates as smoothly as possible with KDE 4/5. As far as I know, Chromium isn't any better at that than Seamonkey, but then lacks the e-mail client and the other nice tools of Seamonkey.
• The speed advantage of Blink compared to Gecko some people and benchmarks claim to see depends on the web pages. I mostly use pages with a lot of text, and these are rendered quickly enough by all modern browsers. I wouldn't say that there were no speed differences in my tests, but they were practically irrelevant, to me.

gargamel

1 members found this post helpful.

I'm also a big fan of SeaMonkey. It has been a more than adequate replacement for Opera 12.16, and I use it 99 percent of the time, but as it has not been updated in over 5 months I'm getting concerned regarding security.

Comparatively, SeaMonkey vs. Konqueror, the latter is more difficult to use. If you want to delete your private data you have to launch "sweeper." If you want to download something, you launch a download manager, etc.

I've found that, in Slackware64, Konqueror behaves, i.e., displays pages, better and faster using WebKit vs. KHTML, BUT when supposedly running the "same" Konqueror in FreeBSD, KHTML works just fine. Who tweaked what, I don't know.

BTW, isn't "blink" more spyware from google?

1 members found this post helpful.

Regarding security, it's always a matter of trust. No updates could mean no security holes, and because Seamonkey doesn't clone or inherit each and every feature of Firefox, it is quite possible that it is not affected by some issues that require fixes in FF. I haven't looked into all Mozilla Foundation Security Advisories, but a quick check of the most recent ones seems to indicate that the known issues affect FF and FF ESR, but not Seamonkey.

Regarding Blink: No, it's not spyware AFAIK. Chrome is, but Chromium, the opens-source browser from Google, on which Chrome is built, is not, and it also uses Blink. Spyware would send data "home", and Chrome, like Microsoft Internet Explorer, is known to do so, but Chromium, like all open source browsers, is not. To be a bit more precise: FF is phoning home by default, too, but (1) you can deactivate this "feature" and (2) it is no secret what data are transferred. With MSIE and Chrome the problem is not, that they connect to some server per se, but that their makers refuse to disclose what data are transferred.

gargamel

Regarding KHTML vs. Webkit, I found some pages that are rendered better by KHTML, but the ratio is >85:15 in favour of Webkit, here. Could it be, that the better performance of KHTML in some other systems is due to the fact that these other systems include some codecs by default that you have to install from SBo in Slackware? One example is the GStreamer "ugly" package, which really makes a difference, if it is installed.

Of course, it might well be that the other distributors also tweak a bit with KHTML, but I doubt it. Firstly, because a web browser rendering engine is a beast of complexity, and noone will start fiddling with it, easily. Secondly, if distributors like Red Hat or SUSE were in your list, I would think that there are some resources (people and money) to take on such a task, but I'd be surprised, if the BSD's would have such resources available. It's, of course, not impossible, though.

gargamel

Hi,

Maybe a bit out of topic, but I read the thread and gave SeaMonkey a go.
And since I was able to install Greasemonkey I said: goodbye Firefox.

Thanks!

--
Best regards,
Andrzej Telszewski

1 members found this post helpful.

According to http://www.cvedetails.com/vendor/452/Mozilla.html, for 2015 we have:

(Since Seamonkey = Firefox + Thunderbird, it has only 8.3% of their CVE.) What is also interesting are the year-to-year trends, even though we can't know what bugs are still outstanding. Still, our browser choice should also consider vulnerabilities and not just what rendering engine, etc.

Years ago there was a firewall for Xp called, The Keiro Personal Firewall, version 2.1.5. It had a nice, easy to use GUI that popped up when there was any attempt to call from or to your computer, including those from the operating system, and asked you what should be done. You could deny or allow for the moment, or make a rule to deny or allow in the future should the same call be made again.
I would love to have something like this for Slackware64 Linux, but have yet to find it.


I have the "ugly" and other GStreamer packages installed in Slackware64, but they don't improve Konqueror's performance.

There's also qutebrowser https://github.com/The-Compiler/qutebrowser

May be I used "performance" incorrectly. What I mean is that with some additional codecs Konqueror can render a lot more pages and doesn't crash or freeze far less often (and it doesn't freeze or crash frequently, anyway, to be clear). If you take performance as a synonym for speed, additional codecs won't help that much, of course.

gargamel

This one looks quite interesting, thanks! I'll definitely have a closer look at this one. Unfortunately there seems to be no binary or SBo package for it, yet, and currently I am quite busy with my daytime job. But I'll try it, soon.

gargamel

I'm not sure if that is correct. IIRC, the "new" opera is "blink" based and the last
time I tried it, in ms-windows, if you didn't let it "call home" it refused to work. That might be something the opera people did for their own tracking purposes, but I really don't know.
Ditto, Vivaldi.

I have compiled otter-browser-0.9.07 on slackware64-current, using qt-5.5.0, and I get a segmentation violation error each time I try to run it.
With gdb, I get
Program received signal SIGSEGV, Segmentation fault.
0x00007fff901321ba in ?? () from /usr/lib64/libkdecore.so.5

Umm... what? Go to "V-menu → Tools → Settings (Alt+p) → Privacy → Third Party Services" and uncheck whatever you don't like.

1 members found this post helpful.

what about arora? thats a qt browser