Web extensions and XUL

General discussion and chat (archived)
John connor

Web extensions and XUL

Unread post by John connor » 2019-01-19, 03:18

Why is it that a browser can't render (for lack of a better word) XUL and web extension add-ons at the same time? Is the limiting factor the core engine its self?

User avatar
Nigaikaze
Board Warrior
Board Warrior
Posts: 1322
Joined: 2014-02-02, 22:15
Location: Chicagoland

Re: Web extensions and XUL

Unread post by Nigaikaze » 2019-01-19, 03:25

Basilisk supports both.
Nichi nichi kore ko jitsu = Every day is a good day.

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Web extensions and XUL

Unread post by vannilla » 2019-01-19, 10:36

It's just that WebExtensions are a subset of XUL extensions, so there's no reason to support both (Basilisk is an exception because it's special.)

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Web extensions and XUL

Unread post by Moonchild » 2019-01-19, 12:23

vannilla wrote:there's no reason to support both
Well, there's still a reason to support XUL extensions if you support WebExtensions -- after all, XUL ones can do more than WE ones ;P

But for the question why Mozilla dropped everything except WE? Most likely the true answer has "Google" in there somewhere.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

New Tobin Paradigm

Re: Web extensions and XUL

Unread post by New Tobin Paradigm » 2019-01-20, 04:59

vannilla wrote:It's just that WebExtensions are a subset of XUL extensions, so there's no reason to support both (Basilisk is an exception because it's special.)
WebExtensions is NOT a subset of XUL Extensions. That is a misconception. It is a Google Chrome based API that Mozilla has been trying to map to the platform. It is an abstraction in much the same way Jetpack was an abstraction. A wholly incompatible one at that. It doesn't matter if the platform has XUL or not it is all how the abstraction is mapped. However, to accomplish the full range of WebExtensions it requires dangerous and annoying compromises only limited in impact by the severely limited abilities WebExtensions can perform. Even despite this they are a security nightmare.

I would not rely on Basilisk's limited and never-going-to-be-finished support of WebExtensions as it could disappear at any time. I feel it was a severe mistake to include it in the first place because people would rely on a temporary window of compatibility with Firefox-targeted WebExtensions. All I managed to do was get it labeled experimental.

There is no future in WebExtension technology here. No other UXP project is interested in the technology and a lot of work to bypass the WebExtensions code in its entirety INCLUDING in Basilisk its self was done so it could be jettisoned at a moment's notice for which I am still pushing for because the technology is regressive and unsupported in its entirety.

It will fall eventually but if you believe as I do YOU should also make your voice heard because the sooner this is done the less the impact will be for everyone. If you, however, disagree with all that then you will be up for a rude awakening eventually even if it is months or years down the road. No one is working on it and no one WILL work on it. It is just a bunch of code that the longer it is there the more people will be outraged when it finally does fall away as the pure cruft it actually is.
Off-topic:
Boy am I gonna get flak for that.. Needed to be said though.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Web extensions and XUL

Unread post by Moonchild » 2019-01-20, 06:34

I'll try to explain where WebExtensions stand and why I chose to include the technology in Basilisk; also for the benefit of Tobin who still seems to be unconvinced Basilisk needed it and what purpose it fills.

UXP's support for WebExtensions is basic support. Even though it's called "experimental" on the Basilisk website, it really is not, but it is incomplete if viewed from a Mozilla perspective. The reason for this is that Mozilla has been adding a few select browser APIs over time to replace what XUL extensions by default have access to in the "chrome://" context (not to be confused with Google's browser technology).
Functionally speaking, in terms of how it can interact with the browser internals, WebExtension APIs are a subset of XUL APIs and as such WEs can be called a functional subset of XUL extensions, which is what was meant with that term -- it was not meant to say that WE extension technology is in any way included in XUL extension technology, because that is incorrect. They are entirely different in the way they interact with the browser.

Why include this basic support in Basilisk? Simple: the cross-browser part of WEs (high-level abstraction) to interact with web content works. This made Basilisk able to use many service-based WEs out of the box that do not try to interact with the browser internals, but with web content. This has, in my understanding, always been the main goal of these types of extensions (see also the very name of them, WEB-extensions, meant to extend functionality on the WEB, and not browser-extensions). Trying to extend this with custom APIs by Mozilla to try and regain some semblance of interfacing with browser internals (so WEs can be given some functionality that was inherently lost) is going beyond that scope, and beyond the scope of this technology in UXP.

Given, this does create a discrepancy as we are using "gecko targeting mode" and authors of WEs will inherently target what, in their knowledge, the "gecko" target pertains -- meaning they may include calls to APIs Basilisk does not have, and as such those WEs might not work. Considering the general market share of UXP applications, asking WE devs to use a custom target for UXP is not going to be fruitful and for good reason; WE developers after all in general moved to it so they could reduce the workload for maintaining their service extensions for different browsers, not increase it. Because of this discrepancy, the targeting mode Basilisk operates in is experimental. If API calls to non-existing APIs are made though, the console will clearly tell the dev and/or browser user that a certain function isn't present in Basilisk or which ever other application may want to use it.

WE technology support in UXP will not be extended with Mozilla-specific APIs beyond what is already there. If for nothing else but for the fact that new APIs implemented by Mozilla will abstract functions that are unlikely to be present in UXP to begin with. That does not, however, mean that the existing web content and service-focused abstractions have suddenly become useless -- far from it. So the dilemma here is: drop WE support and as a result drop all perfectly-functioning web content based service WEs, or keep it with the uncertainty of compatibility with updates to WEs that might start to include Mozilla-exclusive abstractions? As you see it's not as clear-cut, and both choices have their not-insignificant negatives.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

New Tobin Paradigm

Re: Web extensions and XUL

Unread post by New Tobin Paradigm » 2019-01-20, 07:36

Saying Basilisk supports WebExtensions but not going for complete parity with Google or Mozilla WebExtensions is pointless. It is AS CLEAR CUT as it sounds. You have to either support one or the other or none at all. Otherwise, it just looks bad or indeed looks like a false claim. As implemented, the WebExtension support in Basilisk is a joke. What are you supporting here or rather not supporting despite it being a touted feature, anyway? An API based on a regressive technology that isn't even complete.

Still contending that it is a subset of XUL Extension Technology is still incorrect despite how it was half-assed implemented.

All you will ever hear from both sides is a comparison to Firefox WebExtensions. From the Pro-WebEx side, your WebExtension support is old and obsolete. From the Anti-WebEx side you will get like from me that the technology is wrong and should be obliterated with extreme prejudice.

You cannot win and your indifference to doing anything about it is tiring and it makes ALL of us look incompetent.. Additionally, your attempt to justify it rings of trying to justify not pissing the hundred or so Basilisk users or indeed the tiny group of people you created Basilisk to originally serve. Either support Google/Mozilla APIs and keep supporting it or get rid of it. The longer nothing gets done the more trouble it will cause for ALL UXP projects. "Why doesn't Pale Moon support it if Basilisk does", you know like this very thread. ALSO, anyone who WOULD want WebEx for their application would ask "Why should I build an application on UXP when your webex support is such shit?"

On the technical side, we have to deal with the bits and bobs sitting there catering to Basilisk's special status with it's own additional WebEx code and Add-ons Manager. We can't do it and in my opinion, it not only contradicts what we have all, including you, have said in the past but the very nature of them remains a threat or doubt in the back of the minds of Mozilla Refugees that one day we will simply switch and drop XUL like everyone else.

It is CALLED the Unified XUL Platform not the Firefox clone with poor webextensions support platform after all.

John connor

Re: Web extensions and XUL

Unread post by John connor » 2019-01-20, 08:16

Moonchild wrote:But for the question why Mozilla dropped everything except WE? Most likely the true answer has "Google" in there somewhere.

That's my thought.


I see I pretty much let the cat out of the bag so to speak on this one. :lol: Was not my intention. Reading the post's here pretty much go over my head anyway. I'm not a coder and have no idea how it all comes together. Just thought that if a browser was limited to old XUL support add-on capability, why not also write in Web Extension support as well and have the best of both worlds?

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Web extensions and XUL

Unread post by Moonchild » 2019-01-20, 09:12

Well, let's make a clear decision then on this 20th day in the new year: Issue #936 (UXP).

Although the reply from Tobin pissed me off, it does make a few good points and looking long-term, it's indeed better to tackle this now than later lest we end up between the bank and the ship again in terms of extension support.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

New Tobin Paradigm

Re: Web extensions and XUL

Unread post by New Tobin Paradigm » 2019-01-20, 09:32

Moonchild wrote:the reply from Tobin pissed me off
I do do that, however, I was too harsh in several places. Not that this is overall surprising but I could have done a better job in my responses.

Time to hide in the server room again, me thinks.

GigaWatt

Re: Web extensions and XUL

Unread post by GigaWatt » 2019-01-20, 10:54

New Tobin Paradigm wrote: It will fall eventually but if you believe as I do YOU should also make your voice heard because the sooner this is done the less the impact will be for everyone.
I don't think it actually matters whether "your voice is heard" or not... it's either the Google way or the highway IMO. You either get used to what you're served or you just use a "third party" (I believe that's what they're now called, whoever is not on the Google, Mozilla or MS train) browser, like PM. Basically, that's what it's come down to.
Moonchild wrote:Why include this basic support in Basilisk? Simple: the cross-browser part of WEs (high-level abstraction) to interact with web content works. This made Basilisk able to use many service-based WEs out of the box that do not try to interact with the browser internals, but with web content. This has, in my understanding, always been the main goal of these types of extensions (see also the very name of them, WEB-extensions, meant to extend functionality on the WEB, and not browser-extensions). Trying to extend this with custom APIs by Mozilla to try and regain some semblance of interfacing with browser internals (so WEs can be given some functionality that was inherently lost) is going beyond that scope, and beyond the scope of this technology in UXP.
So, essentially, WE support was included in Basilisk to cater to what modern browsers have to offer and PM doesn't (at least not out of the box).

I get it... personally, I don't need it, but I get it... most users would have benefit from WE support. All that DRM content has to be viewed by someone, right :roll:.

Seriously though, having both XUL and WE support in a single browser would be beneficial.

Well, will just have to wait out the vote, see if WE support is dropped.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35474
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Web extensions and XUL

Unread post by Moonchild » 2019-01-20, 11:10

GigaWatt wrote:So, essentially, WE support was included in Basilisk to cater to what modern browsers have to offer and PM doesn't (at least not out of the box).
No, you missed the point completely, there.

WE support was included in Basilisk because service extensions tend to work since they are mostly cross-browser.
And DRM has absolutely nothing to do with this.
GigaWatt wrote:having both XUL and WE support in a single browser would be beneficial.
Only insofar that WEs are available. In all other aspects WE is inferior to XUL extensibility that can do all the web/service stuff WEs can, AND do a hell of a lot more to actually extend browser functionality. Just ask any extension developer who has looked at WEs and decided to discontinue their development because WEs couldn't do what they needed.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Moonraker
Board Warrior
Board Warrior
Posts: 1878
Joined: 2015-09-30, 23:02
Location: uk.

Re: Web extensions and XUL

Unread post by Moonraker » 2019-01-20, 12:10

Mozilla have taken down the classic add on site now..is there any way possible to get to those extensions now and some of the old complete themes.?
user of multiple puppy linuxes..upup,fossapup.scpup,xenialpup..... :thumbup:

Pale moon 29.4.1

User avatar
Sajadi
Board Warrior
Board Warrior
Posts: 1226
Joined: 2013-04-19, 00:46

Re: Web extensions and XUL

Unread post by Sajadi » 2019-01-20, 12:16

In my opinion it is the best decision to get rid of Webextensions - if a not complete set of them is around, people will always ask for completing them, making them more compatible with what Mozilla and Google offers.

The problem is - Webextensions is a beast which requires more people, more work, more effort - big companies can handle such a task, but who would have the time in smaller projects - when both resources and people who will work on it are missing? Seen from that point of view - it is best to make a clear cut and get rid of that incomplete mess - and instead focusing on the already existing strength - XUL

And if it is clear from the start, that neither Pale Moon/Basilisk support Webextensions - that confusing situation can be avoided in the first place. Point is, without someone from the Pale Moon community who has the skills and the knowledge to help maintaining/developing all things Webextensions, it is a technology without a future, because this whole task is way too large to be swallowed by the Pale Moon team on their own without help.

User avatar
rabnbeinn
Lunatic
Lunatic
Posts: 350
Joined: 2011-11-18, 20:38
Location: Scotland

Re: Web extensions and XUL

Unread post by rabnbeinn » 2019-01-20, 12:22

Moonraker wrote:Mozilla have taken down the classic add on site now..is there any way possible to get to those extensions now and some of the old complete themes.?
https://forum.palemoon.org/viewtopic.php?f=46&t=21228&p=159506&hilit=ca+archive#p159506

User avatar
gepus
Keeps coming back
Keeps coming back
Posts: 938
Joined: 2017-12-14, 12:59

Re: Web extensions and XUL

Unread post by gepus » 2019-01-20, 15:12

New Tobin Paradigm wrote:However, to accomplish the full range of WebExtensions it requires dangerous and annoying compromises only limited in impact by the severely limited abilities WebExtensions can perform. Even despite this they are a security nightmare.
Security nightmare, a small foretaste:
Websites can steal browser data via extensions APIs
Researcher finds nearly 200 Chrome, Firefox, and Opera extensions vulnerable to attacks from malicious sites.

User avatar
Nigaikaze
Board Warrior
Board Warrior
Posts: 1322
Joined: 2014-02-02, 22:15
Location: Chicagoland

Re: Web extensions and XUL

Unread post by Nigaikaze » 2019-01-20, 17:06

Moonchild wrote:Well, let's make a clear decision then on this 20th day in the new year: Issue #936 (UXP).
If y'all are going to follow through on this, it might be helpful to post a notice in the Basilisk forum, to give a heads up to the casual Basilisk users that don't read this section and don't look at GitHub issues.
If any villagers are going to raise up torches and pitchforks, better to get that over with sooner rather than later. ;)
Nichi nichi kore ko jitsu = Every day is a good day.

GigaWatt

Re: Web extensions and XUL

Unread post by GigaWatt » 2019-01-21, 01:02

Moonraker wrote:Mozilla have taken down the classic add on site now..is there any way possible to get to those extensions now and some of the old complete themes.?
I actually made a backup for the ones I use... don't use any themes though.

Here's a list of the ones I use. The number is kinda disappointing... from a "heavy extension user" perspective :P :D.
Ant Video Downloader (by Ant R)
Download Manager (S3) (by Oleksandr)
Element Properties (by Geoff Lankow)
Menu Icons Plus (by Justin Rodes)
Menu Wizard (by Oleksandr)
S3.Google Translator (by Oleksandr)
Session Manager (by Michael Kraft)
There is also a more complete list backed up by someone on this link.

http://legacycollector.org/firefox-addons/
There was an extension or two I didn't find in both links... had to dig deeper in order to collect the ones I'm currently using.
Nigaikaze wrote:If any villagers are going to raise up torches and pitchforks, better to get that over with sooner rather than later. ;)
That's one hell of way to look at the user base :wtf:...

User avatar
Nigaikaze
Board Warrior
Board Warrior
Posts: 1322
Joined: 2014-02-02, 22:15
Location: Chicagoland

Re: Web extensions and XUL

Unread post by Nigaikaze » 2019-01-21, 02:43

GigaWatt wrote:That's one hell of way to look at the user base :wtf:...
Just speaking from experience, cuz I've already seen it happen way too many times.
Nichi nichi kore ko jitsu = Every day is a good day.

coffeebreak
Moon Magic practitioner
Moon Magic practitioner
Posts: 2986
Joined: 2015-09-26, 04:51
Location: U.S.

Re: Web extensions and XUL

Unread post by coffeebreak » 2019-01-21, 03:58

GigaWatt wrote:There is also a more complete list backed up by someone on this link.

http://legacycollector.org/firefox-addons/

The Classic Add-ons Archive (CAA) is the more complete repository.

GigaWatt wrote:Here's a list of the ones I use. . . .
Ant Video Downloader (by Ant R)
Download Manager (S3) (by Oleksandr)
Element Properties (by Geoff Lankow)
Menu Icons Plus (by Justin Rodes)
Menu Wizard (by Oleksandr)
S3.Google Translator (by Oleksandr)
Session Manager (by Michael Kraft)
. . .
There was an extension or two I didn't find in both links... had to dig deeper in order to collect the ones I'm currently using.

I found all seven of your extensions in CAA, and all but one (Download Manager S3) on the LegacyCollector site.

Locked