Packaging request #2165
[Iceweasel-UXP] Add UXP-based firefox fork to repos
Since icecat has been updated to version 60, it no longer supports XUL, losing support for some popular addons such as Vimperator and DownThemAll. The Hyperbola project is developing their UXP-based(see https://github.com/MoonchildProductions/UXP) basilisk fork which in turn is a fork of firefox 52 (https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp).
Wouldn't a more proper approach be to bring the plug-ins forward rather than drag the browser backwards?
It's a maintenance challenge just keeping up with the browsers we currently have. I'm not sure adding yet another browser to maintain is the best idea.
In principle, yes, that would be the ideal solution. However, the number of such plug-ins is not small, the refactoring/rewriting effort required in many cases is substantial, and in some cases equivalent WebExtension APIs simply don't exist. A few have been slowly added, but some important ones have not (or may not ever be added, due to inherent changes of architecture).
Of course, that is not to say maintaining browsers is an easy/trivial task.
#3 Updated by bill-auger 15 days ago
i would consider it a pretty poor assessment to say this is "dragging the browser backwards" - that is a hard fork (the "Pale Moon"/"Basilisk" browser) that was forked when that firefox (~v52?) was current - it is actively developed by that upstream and moving "forward" in its own direction - the hyperbola iceweasel version is mostly likely just some FSDG modifications to that
as eli suggested, many addon devs prefer the extra capabilities of the classic XUL system, which enjoyed a very long and fruitful life - the concept in of itself has merit, in that it would bring some unique capability to parabola - what remains to be seen is how widely the demand is for those "legacy" addons and the longevity of this browser strain
#4 Updated by bill-auger 15 days ago
another thing i could say is "yes, parabola has too many browsers already" that is true; but this one does bring something unique to the table - if that is the main concern stopping this from being adopted; i would suggest dropping some of the others such as midori, qupzilla, epiphany, or any of several others that are all essentially webkit/webengine clones that offer nothing unique
i would suggest dropping some of the others such as midori, qupzilla, epiphany, or any of several others that are all essentially webkit/webengine clones that offer nothing unique
qupzilla(falkon) could very well be removed as it depends on webengine and qutebrowser will very soon drop support for webkit.
#10 Updated by bill-auger 7 days ago
or, as i suggested, whether or not we do add this one, we could actually drop a number of others from the workload without sacrificing any use-cases, namely the numerous, barely distinguishable, light-weight graphical web browsers (mostly webkit/webengine clones), all of which are in [pcr] or being re-built in [libre]
of those above, only konqueror has dependents
note that the arch builds of the following apparently meet the FSDG:light-weight graphical web browsers: