Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

About this bulletin board and the Pale Moon website

Moderators: FranklinDM, Lootyhoof

Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Poll ended at 2021-03-25, 20:20

Yes
8
20%
No
19
48%
I'm not a programmer.
13
33%
 
Total votes: 40

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10540
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by New Tobin Paradigm » 2021-02-23, 20:20

This is a poll aimed mainly at extension developers and those thinking of becoming one. With the changes set in store for Pale Moon and years of Add-ons SDK controversy with practical limitations of vague and deprecated abstraction layers verses traditional Toolkit and Bootstrapped extensions.. Should we, going forward, permit submission of forks and newly created extensions using this dead-end technology?

Currently the older cfx-generated Jetpack extensions have not been allowed since Phoebus 2.0 only newer jpm-generated.

NOTE: This will not affect the current application support or lack there of in Pale Moon and Basilisk nor will it prevent already established extensions on the site from continuing as normal.
Do not try the patience of wizards, for they are subtle and quick to anger.
Image

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 435
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by RealityRipple » 2021-02-23, 21:00

I think this boils down to capability. It's usually pretty easy to throw out any of that restartless/sdk junk and revert extensions to the clean, classic Overlay-centric addons, so the vital question becomes, is there anything that Jetpack allows for that absolutely can not be accomplished using older, more direct methods? In my experience thus far, the answer has been "no". And thus, the answer to whether they should be allowed also defaults to "probably no". However, if there are any specifically known cases where an add-on can not accomplish its task without Jetpack, then that answer switches to a "certainly yes". But, there aren't... Are there?

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10540
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by New Tobin Paradigm » 2021-02-23, 21:04

Everything Jetpack can do is merely carefully selected abstractions on permitted native functionality. So as you guessed. There is nothing a Jetpack extension can do that a normal one can't and indeed using Jetpack doesn't teach the developer anything about how to create (lowercase-m) mozilla extensions only how to create Jetpack extensions. Deff won't help you understand how things actually work in a way that allows you to progress to bigger and better things. It keeps you distracted by it's abstraction.

In today's terms it would be Mozilla's failed attempt to create a kind of WebExtensions system that no one asked for and no one wanted.
Do not try the patience of wizards, for they are subtle and quick to anger.
Image

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 3413
Joined: 2015-12-09, 15:45
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by moonbat » 2021-02-24, 02:26

Where's the 'Hell, no!' poll option? :twisted:
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 20.1 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30915
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by Moonchild » 2021-02-24, 11:31

moonbat wrote:
2021-02-24, 02:26
Where's the 'Hell, no!' poll option? :twisted:
It's implied in "No" ;P
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

User avatar
jobbautista9
Lunatic
Lunatic
Posts: 370
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by jobbautista9 » 2021-02-25, 03:31

Jetpack should be discouraged for new extensions, so yeah that's a no for me. For forks of classic add-ons though, it might be useful to accept them, but only for use in Basilisk. I heard that Jetpack add-ons break more often in Pale Moon, but is this also the case for Basilisk?

I haven't developed an add-on in Jetpack yet, and from the looks of it, it seems it was trying to simplify and make the development of add-ons easier. Ironically, I find XUL to be simpler and easier to understand and develop for, as a new add-ons developer, despite the incomplete documentation of it.

So XUL of course should be encouraged, and if the forker can do it, they should rewrite it to XUL.
Cyndaquil is the debeste starter.

Developer of Ambassador in Window Menu, BrowserTickTock, CacheSwitch, Chrome Navigator, Cite4Wiki, Clickity Touch 'n Push, ColorPili, EditDatContent, EditDatTitle, Esrever, Go Menu, User Agent Status, Website Navigation Bar, and Yet Another about:config Helper.

My PGP public key (My copy on rw.rs)

Avatar by u/sprouthesprout of r/twitchplayspokemon.

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 3413
Joined: 2015-12-09, 15:45
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by moonbat » 2021-02-25, 03:47

jobbautista9 wrote:
2021-02-25, 03:31
I find XUL to be simpler and easier to understand and develop for
The best thing about XUL is that your UI definition is cleanly separate from the Javascript used to run it. Restartless extensions require you to directly manipulate the DOM to change the UI and that is quite a mess.
"One hosts to look them up, one DNS to find them and in the darkness BIND them."

Image
Linux Mint 20.1 Xfce x64 on HP i5-5200 laptop, 12 GB RAM.
AutoPageColor|PermissionsPlus|PMPlayer|Pure URL|RecordRewind|TextFX

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 30915
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by Moonchild » 2021-02-28, 10:10

Whether one technology or another is "cleaner" isn't the issue here.
"Just because you know something is going to break in the end, doesn't mean that it can't have an effect that lasts into the future. Joy. Wonder. Laughter. Hope. The world can be better because of what you built in the past." -- Tom Scott
Image

riiis
Lunatic
Lunatic
Posts: 470
Joined: 2014-05-17, 15:51
Location: USA

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by riiis » 2021-02-28, 21:33

... so the vital question becomes, is there anything that Jetpack allows for that absolutely can not be accomplished using older, more direct methods? In my experience thus far, the answer has been "no". And thus, the answer to whether they should be allowed also defaults to "probably no". However, if there are any specifically known cases where an add-on can not accomplish its task without Jetpack, then that answer switches to a "certainly yes". But, there aren't... Are there?
There is not just one task that can be accomplished without Jetpack. In fact, there are several tasks that only Jetpack add-ons can accomplish, that XUL and other bootstrap extensions cannot accomplish.

First, Jetpack/SDK/JPM extensions run on code substantially provided by the browser. Accordingly, Jetpack extensions, once successfully installed and running, should require little or no add-on developer maintenance. That is, any required maintenance would be done, wholly or in large part, on the SDK code at the browser-level. For example, the "Autoplay Whitelist" extension depends on the following SDK code obtained from the browser:

Code: Select all

var tabs     = require("sdk/tabs");
var url      = require("sdk/url")
var buttons  = require('sdk/ui/button/toggle');
var ss       = require("sdk/simple-storage");
var page_mod = require("sdk/page-mod");
var pref     = require("sdk/preferences/service");
var data     = require("sdk/self").data;
var sp       = require("sdk/simple-prefs");
var prefs = require("sdk/simple-prefs").prefs;
const path = require('sdk/fs/path');
const file = require('sdk/io/file');
const desktop_path = require('sdk/system').pathFor('Desk');
let _ = require('sdk/l10n').get;
jobbautista9 wrote:
2021-02-25, 03:31
I heard that Jetpack add-ons break more often in Pale Moon, but is this also the case for Basilisk?
Wherefrom did you hear this? Since Jetpack extensions run on browser-furnished code, these Jetpack extensions, once successfully installed and running, should not break (as long as the supporting browser code is appropriately maintained).

Second, Jetpack extensions are restartless add-ons. Thus, Jetpack extensions should be compared more appropriately only to bootstrap extensions, rather than to all XUL extensions. For example, toolbar buttons and user preferences in Jetpack extensions have merely to be declared. AFAIK in XUL-bootstrap extensions, these features are not supported. Accordingly, for bootstrap extensions, toolbar buttons and user preferences and perhaps other features-- such code must be written/coded by the add-on developer from scratch.

Third, unlike localization for bootstrap and XUL extensions, which require setup of separate folders for each language, and an entry is required for each locale in the chrome.manifest file, and each locale/language folder must contain separate entities file{s} and properties file(s). Note that folder names are unique but file names are not. Thus, to ensure that no mistakes were made, each folder and file should be manually opened and reviewed, before submitting the add-on, or new version, to APMO. On the other hand, Jetpack extensions use a simple, single, and uniquely named properties file for each language. And, if mistakes or omissions are made, neither the add-on nor the browser crashes.

Code: Select all

...\locale\ar.properties"
...\locale\be.properties"
...\locale\bg.properties"
...\locale\cs.properties"
...\locale\da.properties"
...\locale\de.properties"
...\locale\el.properties"
...\locale\en.properties"
...\locale\en-GB.properties"
...\locale\en-US.properties"
...\locale\es-AR.properties"
...\locale\es-ES.properties"
...\locale\es-MX.properties"
...\locale\fi.properties"
...\locale\fr.properties"
...\locale\fy-NL.properties"
...\locale\he.properties"
...\locale\hr.properties"
...\locale\hu.properties"
...\locale\id.properties"
...\locale\is.properties"
...\locale\it.properties
...\locale\ja.properties
...\locale\kn.properties
...\locale\ko.properties
...\locale\lt.properties
...\locale\lv.properties
...\locale\nb-NO.properties
...\locale\nl.properties
...\locale\nn-NO.properties
...\locale\pl.properties
...\locale\pt-BR.properties
...\locale\pt-PT.properties
...\locale\ru.properties
...\locale\sk.properties
...\locale\sl.properties
...\locale\sv-SE.properties
...\locale\tr.properties
...\locale\uk.properties
...\locale\vi.properties
...\locale\zh-CN.properties
...\locale\zh-TW.properties
Forth, Jetpack extensions support the localization of "html" files. AFAIK bootstrap and XUL extensions do not. For illustration, see the "Autoplay Whitelist" or "Theme Builder" extensions.

Fifth, let's not forget why SDK extensions were developed in the first place. In the early days of Firefox XUL, whenever the browser was updated, it was common for extensions to fail as a result of these browser changes. A well-designed and maintained browser SDK code should prevent add-ons from being affected by changes in the browser. Accordingly, the question should be what XUL extensions and bootstrap extensions can do that Jetpack extensions cannot do. Not the other way around.
This will not affect the current application support or lack there of in Pale Moon and Basilisk nor will it prevent already established extensions on the site from continuing as normal.
This intent by the OP is somewhat curious. It appears that application support of current SDK extensions in Pale Moon requires that current SDK code in Pale Moon be wholly retained. And, if current SDK code in Pale Moon is wholly retained, what is gained by blacklisting new or forked extensions using this existing code? And, if heretical SDK extensions are to be deleted/cancelled in a few day's\week's\month's time, why not say so now? And, why not accept new SDK extensions in the meanwhile?

vannilla
Board Warrior
Board Warrior
Posts: 1784
Joined: 2018-05-05, 13:29

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by vannilla » 2021-02-28, 22:49

riiis wrote:
2021-02-28, 21:33
Your post is mostly false.
There is not just one task that can be accomplished without Jetpack. In fact, there are several tasks that only Jetpack add-ons can accomplish, that XUL and other bootstrap extensions cannot accomplish.
Jetpack is built on top of existing XUL et al. technologies, so anything Jetpack does, everything else does too.
First, Jetpack/SDK/JPM extensions run on code substantially provided by the browser. Accordingly, Jetpack extensions, once successfully installed and running, should require little or no add-on developer maintenance.
False in every aspect. A normal add-on requires no maintenance either, if it doesn't use undocumented, documented as non-standard or "dark magic" (e.g. tie in "private" parts of the core) features.
If anything, you can say that Jetpack doesn't allow for the exception I mentioned, but then it becomes that Jetpack can do less than the rest.
That is, any required maintenance would be done, wholly or in large part, on the SDK code at the browser-level. For example, the "Autoplay Whitelist" extension depends on the following SDK code obtained from the browser:
And that's bad, because it puts pressure on the developers of the browser when they could use the time to improve web compatibility.
Wherefrom did you hear this? Since Jetpack extensions run on browser-furnished code, these Jetpack extensions, once successfully installed and running, should not break (as long as the supporting browser code is appropriately maintained).
Both you and jobbautista are wrong: the breakage of an extension is proportional to the quality of the code, so being Jetpack or not has nothing to do with how well they perform.
For example, toolbar buttons and user preferences in Jetpack extensions have merely to be declared. AFAIK in XUL-bootstrap extensions, these features are not supported. Accordingly, for bootstrap extensions, toolbar buttons and user preferences and perhaps other features-- such code must be written/coded by the add-on developer from scratch.
This is true only for bootstrap extension. XUL itself was developed for the purpose of defining UI without writing javascript.
Then you got bootstrap, where you can't use declarative XUL but instead have to programmatically change the UI by hand.
And finally you have Jetpack which is built on top of bootstrap (because Jetpack is restartless), which added a declarative syntax to build UI instead of modifying it with javascript. If you look closely you'll notice a certain pattern.

Additionally, preferences using traditional toolkit is also made declaratively:

Code: Select all

pref("foo", 1);
pref("bar", 2);
in a file called "pref.js"

It was once again bootstrap to change this behaviour and made it so preferences had to be defined programmatically, only for Jetpack to make it declarative once again.
Third, unlike localization for bootstrap and XUL extensions, which require setup of separate folders for each language, and an entry is required for each locale in the chrome.manifest file, and each locale/language folder must contain separate entities file{s} and properties file(s).
I can agree with you that there are less steps involved when updating localizations, but otherwise it's literally the same process. Jetpack isn't solving anything.
Forth, Jetpack extensions support the localization of "html" files. AFAIK bootstrap and XUL extensions do not. For illustration, see the "Autoplay Whitelist" or "Theme Builder" extensions.
For the same argument as before, if Jetpack can, then other types of extensions should be able to too.
Fifth, let's not forget why SDK extensions were developed in the first place. In the early days of Firefox XUL, whenever the browser was updated, it was common for extensions to fail as a result of these browser changes. A well-designed and maintained browser SDK code should prevent add-ons from being affected by changes in the browser. Accordingly, the question should be what XUL extensions and bootstrap extensions can do that Jetpack extensions cannot do. Not the other way around.
And once again you are asking for core developers to maintain extensions, instead of having extension developers maintain their own work.
It's you who got it backwards.
And before you go and talk about backward compatibility, let me tell you a story as a user of the following software: GNU Emacs is an extensible editor notorious for its long development time, regarding which a famous mail in the mailing list (which unfortunately I can't find again) stated "20 years are not enough" when discussing wether or not to remove a feature that was used by pretty much nobody.
Despite that, even GNU Emacs periodically removes obsolete features. Indeed, often it's stuff declared deprecated in version 18 and removed in version 25 (i.e. 20 years later), but even that kind of software does break backward compatibility from time to time.

Most of your arguments are uninformed, so I ask you to try developing a toolkit extension before making comparisons.

User avatar
RealityRipple
Lunatic
Lunatic
Posts: 435
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by RealityRipple » 2021-03-01, 00:11

TL;DR: None of those fall into the category of "absolutely cannot be accomplished". They all fall into the category "can easily be accomplished with different paradigms".

User avatar
jobbautista9
Lunatic
Lunatic
Posts: 370
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by jobbautista9 » 2021-03-01, 03:17

Thanks vannilla for your post. In that case, I'm changing my opinion then. No Jetpack add-on should be allowed for submission, whether it's a fork or new. I'd go even further and make Jetpack deprecated right now, and remove support for it in the next milestone release. I can't see any excuse not to rewrite those add-ons in overlay or bootstrap.
Cyndaquil is the debeste starter.

Developer of Ambassador in Window Menu, BrowserTickTock, CacheSwitch, Chrome Navigator, Cite4Wiki, Clickity Touch 'n Push, ColorPili, EditDatContent, EditDatTitle, Esrever, Go Menu, User Agent Status, Website Navigation Bar, and Yet Another about:config Helper.

My PGP public key (My copy on rw.rs)

Avatar by u/sprouthesprout of r/twitchplayspokemon.

User avatar
New Tobin Paradigm
Knows the dark side
Knows the dark side
Posts: 10540
Joined: 2012-10-09, 19:37
Location: The Seriphia Galaxy

Re: Should forks and new extensions using Jetpack Technology be allowed for submission to APMO?

Unread post by New Tobin Paradigm » 2021-03-01, 04:13

jobbautista9 wrote:
2021-03-01, 03:17
Thanks vannilla for your post. In that case, I'm changing my opinion then. No Jetpack add-on should be allowed for submission, whether it's a fork or new. I'd go even further and make Jetpack deprecated right now, and remove support for it in the next milestone release. I can't see any excuse not to rewrite those add-ons in overlay or bootstrap.
I am not willing to go that far for the following three reasons:
ONE, the moment PMKit became a thing after we tried to rid our selves of it it was here to stay in a highly deprecated state. There are a couple legit Jetpack extensions that target Pale Moon and I don't want to punish legit developers who took the time to do it.
TWO, Jetpack is a direct dependency of the Mozilla Developer Tools and unlike Tycho we really don't have an even theoretical replacement for them at this time.
THREE, Basilisk is a thing. Basilisk uses Firefox's original ID and is 98% compatible with the full spectrum of extensions that worked on Firefox 52 including the late model Jetpack ones.

NOW, I don't discount one day in the future that DevTools could be modified, rewritten, or replaced with code to end their direct dependency on Jetpack. So perhaps in two to five years maybe we can get rid of Jetpack in Pale Moon and those handful of extensions would indeed have to change but frankly asking for it to be gone now is going to be too much for the mid-term future of Pale Moon.

That, however, does not mean that we have to encourage use of a virtually abandoned technology by continuing to allow forks or new ones on the Add-ons Site. Just let it rot away until it is safe to be rid of it. What we DO want to foster is the ancient concept of extensions that are multi-application. Ones that can be used across the spectrum of applicable UXP Applications. BinOC Applications do NOT have jetpack (or Mozilla DevTools) included so any jetpack extension for Pale Moon or Basilisk will never work on Borealis or Interlink or even perhaps Ambassador if that situation is ever resolved.

We as a community and as developers also want to focus on what made (lowercase-m) mozilla technology great and in no way, shape, or form was that ever the Add-ons SDK.

NOW AS FOR RIIIS --

Let me also state that extensions relying on an abstraction layer DO BREAK. AS WELL AS the SDK has not remained static and maintenance on the SDK is also a burden. But how about we put that to a test. I can commit right now a patch to change something fundamental about the SDK and break every single Jetpack extension ever created.

One patch. Search and replace to change require() to load() or include() or fuckinMoron() (oh I so want to make it that). Simple eh? But of course for the reasons above I am not actually going to do it or push for it.. But we could.

As for this talk of localization of html.. Well you guys MAY BE IN FOR A SHOCK but but there are examples of both xhtml chrome content that uses xml entities AND js stringbundles. The latter is I am almost positive is what Jetpack is automating. Also, I believe as a generalized developer-base xhtml in-content isn't nearly as popular for extensions as proper xul modification or creation. That is kinda the point of the Unified XUL Platform ain't it fellas?

Also let us NOT forget that while the tools required to do toolkit or even bootstrap requires nothing more than a text editor and a zip archiver.. Jetpack also requires the Add-ons SDK AND the UXP Build System to even build extensions properly.

Anyway, I know what riiis is about and like JustOff I implore you not to fall for his lies, misdirection, and fakery no matter how many extensions he has. Indeed, his views on the Add-ons Site Service are wholly suspect since he lead the charge in 2016 to oust me and has threatened to abuse the service since then by wanting to upload 14 to 19 thousand Firefox extensions to that site. As well has just recently spread even more misinformation on easily proven developmental history and public record.

In any event, seeing as he tends not to even maintain his 50 or so extensions either because he doesn't give a shit OR they haven't busted much tells volumes about how wrong he actually is.

tl;dr Facts are facts and the truth is out there and I remember it all and can cite it at a moments notice if required. Can riiis?
Do not try the patience of wizards, for they are subtle and quick to anger.
Image

Locked