Why Firefox is not a good choice of browser for a KDE/Plasma-based product

[Markus Slopianka]

Um, is there a reason why QupZilla <http://www.qupzilla.com/> was not included 
or is this just an oversight?
QupZilla is a Qt-based web browser that currently is better maintained than 
Konqueror and Rekonq together. Konqueror's UI is very cluttered, whereas 
Rekonq's UI is not conforming to KDE standards, eg. no menu bar (not even 
optional), tabs on top (IIRC not configurable), etc.).

As far as I'm aware, Plasma Active has it's own web browser, so no synergy 
effects between it and the Plasma Active browser are to be expected.

QupZilla OTOH visually fits quite nicely into the rest of KDE applications and 
it has KWallet support. It also has good extension support, including support 
for user scripts.
I think in general QupZilla also finds the balance of configurability and ease 
of use that KDE people expect, whereas Konqueror and Rekonq are on opposite 
ends of that spectrum.

A port to the Chromium-based QtWebEngine of Qt 5 is also already under way.
The latest version is packaged in Rawhide. In case you use F19 or F20 and want 
to easily check it out, I've packaged it under
http://download.opensuse.org/repositories/home:/KAMiKAZOW:/Fedora/

Before I switched to Fedora for hardware compatibility reasons, I was 
conducting my own research on that matter to propose a Qt-based web browser
to openSUSE.
I think I went in with an open mind.
Disclaimer: I contributed German translations to all three projects but I do 
not consider myself an active contributor to either.

Markus



On Wednesday 26 March 2014 13:49:13 Kevin Kofler wrote:
> Hi,
> 
> I am going to summarize what I wrote yesterday on IRC so everyone can read
> it.
> 
> The discussion of what should be the default browser on the Plasma Product
> has come up yesterday, and I strongly believe that Firefox is NOT the answer
> (but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
> * We do not control the packaging of Firefox. It is not even open to
> provenpackager! We'd be completely at the mercy of the Firefox
>   maintainers.
> * In particular, the Fedora Firefox package will most likely NOT include the
> KDE integration developed by openSUSE, ever. That means the package will
> integrate extremely poorly into our Plasma setup (e.g., no KDE file
> dialogs).
> * Firefox also has unwanted GNOME dependencies such as
>   (lib)startup-notification.
> * Shipping Firefox means we have to ship a third HTML engine just for
>   Firefox! We already have to ship KHTML and QtWebKit because KDE software
>   requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses
>   QtWebKit. Shipping Firefox means adding Gecko and thus pointless code
>   duplication and more security updates for users to worry about.
> * Users who absolutely want Firefox can simply install it from the
>   repository. Or they could use one of the other spins, which (last I
>   checked) all included Firefox (either as the one default or next to
>   Midori). Users who do NOT want Firefox forced on them will have no option
>   to choose from anymore if we join the monopoly.
> * I don't buy the argument that there is "no alternative" to Firefox. There
>   are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq
> and Konqueror+KWebKitPart just work on almost all websites out there. (And
> even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE
> applications wherever possible. Here, it is clearly possible. Shipping
> non-KDE applications is acceptable if those are specialized applications
> with no KDE alternative (think, e.g., Blender). A browser is not
> specialized, it's a core part of the desktop. And the KDE alternatives
> exist and work.
> * I also don't share the worries about Rekonq's future. The port to Qt 5 +
>   QtWebKitWidget is proceeding well. A switch to QWebEngine will be done
>   only when QWebEngine will be ready, a sound decision. And if this really
>   should become a problem in the future (i.e. AFTER F21), we can always
>   reevaluate the default browser decision at that point.
> * Firefox does not use kioslaves. As such its URL support is inconsistent
>   with the other applications we will ship. In particular, Firefox does NOT
>   support man:foo and info:foo URLs. IMHO, those are by far the most
>   comfortable way to read man and info pages. It also cannot reuse things
>   like kio_gopher, requiring a separate extension (for Gopher, that would be
> OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the
> other kioslave-handled protocols just work.
> * Firefox also has some "features" that are worrisome for Fedora as a whole:
> - The anti-malware and anti-phishing protection (enabled by default!) sends
> a hash of every URL you visit to Google (yes, Google!).
>   - Firefox Health Report sends some additional data to Mozilla. It is also
>     enabled by default!
>   - Mozilla also intends to show client-side advertisements (i.e. ones that
>     are NOT part of a web page you are visiting) by default. This is both an
> added annoyance (as if the ads on the web weren't bad enough!) and a
> privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq
> support ad blocking out of the box, Firefox doesn't.)
>   And the Firefox trademark and packaging situation are such that we have no
> control over these "features", nor any future ones that get added.
> 
> So please consider these points before voting here:
> https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration#Defaul
> t_web_browser (votes please ONLY from Plasma working group members, 4 voting
> members have not voted yet). If you voted for Firefox and these arguments
> convinced you otherwise, it's also not too late to change your mind!
> 
> Let's PLEASE let the Plasma Product be a Plasma product, not yet another
> Firefox product!
> 
>         Kevin Kofler
> 
> _______________________________________________
> kde mailing list
> kde at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/kde
> New to KDE4? - get help from http://userbase.kde.org