Compatible "Incompatible Add-ons"

[riiis]

The latest version of FoxClocks, version 4.2.3, runs fine on Pale Moon 25 to Pale Moon 27. Yet, this add-on is shown as incompatible to Pale Moon at AMO (e.g. "Not available for Firefox 27.9"). This add-on also can not be installed, by Pale Moon, based on the same incompatibility claims.

FoxClocks-4.2.3 on Pale Moon 27

To install and run this add-on in PM25 to PM27, only a simple change to the add-on's install.rdf file is required. This change to install.rdf does not need to be done at AMO. In fact, this change to install.rdf doesn't fully solve the problem, if only done at AMO. But instead, the change must be made by Pale Moon, and the resulting FoxClocks xpi file also hosted at Pale Moon add-ons. The simple required change, to the FoxClocks install.rdf file, consists of adding the following 8 lines to FoxClocks install.rdf. The FoxClocks GUID should not be changed; the name of the add-on also should not be changed.

Code: Select all

		<!-- Pale Moon -->
		<em:targetApplication>
			<Description>
				<em:id>{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}</em:id>
				<em:minVersion>25.0</em:minVersion>
				<em:maxVersion>*</em:maxVersion>
			</Description>
		</em:targetApplication>

After adding this FoxClocks version 4.2.3 to APO, FoxClocks (Pseudo-Static) should be deleted from APO.

Mozilla has already done something similar, numerous times at AMO (that is, changed an add-on's install.rdf file and xpi file). For example, line 8 of install.rdf for foxclocks-3.4.14 appears to have been
Changed from:

Code: Select all

<em:version>3.4.14</em:version>

Changed to:

Code: Select all

<em:version>3.4.14.1-signed</em:version>

At the same time as the change to install.rdf, a new folder ("META-INF"), containing 3 files, was also added to the foxclocks-3.4.14 xpi file.

The FoxClocks author has already made his add-on compatible with Pale Moon (in bootstrap.js beginning at line 42):

Code: Select all

			'{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}': { // Pale Moon
				overlay:	{	'chrome://browser/content/browser.xul': 'chrome://foxclocks/content/foxclocksoverlay.xul' },

				stylesheets:{ 	'chrome://global/content/customizeToolbar.xul': ['chrome://foxclocks/skin/foxclocks.css'] }
			}

So, adding Pale Moon as a target application and then hosting FoxClocks version 4.2.3 at APO-- these two simple steps appear to be the only remaining to-do's. Following is a FoxClocks xpi file with the required install.rdf changes:

foxclocks-4.2.3-sm+tb+fx+pm.xpi

(737.58 KiB) Downloaded 46 times

[GreenGeek]

IMO, you're wrong. It would be creating problems by uploading a modified version that isn't identified as such. It would get overwritten by updates for one thing. Another is it would be difficult for the average user to tell what he has installed. Mozilla's changes are different - they didn't change how it works, but they did update the ver #. (I however hate seeing that .1-signed.1-signed string in Addons Manager as much if not more than pseudo-static.) That's exactly why the quirky pseudo-static labelling and associated changes were implented. In most cases, forking is better, even a static-fork, if the license allows it (most do).

[riiis]

It would be creating problems by uploading a modified version that isn't identified as such.

This is not a modified version. All that was done was add Pale Moon as a target application. However, if adding Pale Moon as a target application is of concern, one has only to change version number from "4.2.3" to say "4.2.3.1". One may also want to disclose the change at APO, such as "Version 4.2.3.1 adds Pale Moon as a target application."

It would get overwritten by updates

Updates would fail, because newer versions from AMO would be incompatible with Pale Moon (for the same reasons that the current version 4.2.3 from AMO is identified as "incompatible" with Pale Moon). Adding the Pale Moon GUID, as a target application to the AMO version of the updated add-on-- this would help the user to manually update FoxClocks (which would be a good thing), but AFAIK automatic updates would continue to fail. Anyway, all consideration for updates of xul add-ons may be moot shortly, as Mozilla deprecates existing xul add-ons, and stops accepting new ones.

Mozilla's changes are different - they didn't change how it works

Mozilla's signing requirements changed "how it works" bigtime. Adding Pale Moon as a target application does not change "how it works" at all.

[New Tobin Paradigm]

The Add-ons Team shall not highjack a GUID using the Pale Moon Add-ons Site's Automatic Update Service as long as AMO is still being used as a fallback without developer consent. It would set a very bad precedent if that were to happen.

The proper course of action is to fork the extension with different branding and then submit it to the Add-ons Site or any of the approved options there-in.

Please do NOT link or attach rogue edited extensions to the forum. Even if it is just editing install.rdf. Do it properly or not at all.. This also goes for JustOff an his PMKit extensions.

Disclaimer: This has been a friendly reminder from the New Tobin Paradigm.

[JustOff]

The proper course of action is to fork the extension with different branding and then submit it to the Add-ons Site or any of the approved options there-in.

Could you please list all the "approved options there-in"?

Please do NOT link or attach rogue edited extensions to the forum. Even if it is just editing install.rdf. Do it properly or not at all.. This also goes for JustOff an his PMKit extensions.

I'm always trying to do things properly and either change GUID (sorry if I missed it ever, I'll take special attention to it) or propose PR to original code (1, 2, 3, 4 etc). But what if I need to make some public testing before PR? I hope it's not violate any rules?

[New Tobin Paradigm]

According to the policies I originally set.. If you change the GUID and rebrand as in fully properly forking (as long as the license allows it make sure the extensions aren't All Rights Reserved or some insane license) then it is your extension.. You become the developer thus what I said above isn't an issue.

Now if you are submitting pull requests to the original developers and post it here then until such time that developer releases the update or a test version them selves it would be a rogue edited add-on.

One must stay on the up and up or else developers as well as some other groups can claim Pale Moon and/or their users are just stealing code, violating people's rights, or are untalented bastards doomed to failure...

[JustOff]

Now if you are submitting pull requests to the original developers and post it here then until such time that developer releases the update or a test version them selves it would be a rogue edited add-on.

So, what is the right way to do public testing in this case?

[New Tobin Paradigm]

Why are you trying to conduct public testing for an extension you aren't the developer of and don't have the rights to distribute? However, you could always recruit people and do things via PM.. The main goal is to not distribute rogue edited add-ons to the pubic.

EDIT - Do you guys not get that you may be violating at the VERY LEAST personal copyright and trademarks of other people? Just because something is GPL or MPL doesn't mean you have the right to take someone elses work with their name and logo and edit it and distribute it.. Did you get permission to do so? Did you even check the license if any?

Also what happens like stated above with GUID collisions with AUS etc. I and others have also repeatedly stated for 2 and a half years not to do this and yet people still do.. I can only assume you guys aren't considering these aspects. What did you think I meant by staying on the up and up? Just because I am not in direct authority over anything anymore doesn't mean I am not absolutely correct.

If you guys continue to do these shady activities it is gonna bite someone or everyone in the ass eventually.

[riiis]

From FoxClocks (Pseudo-Static)

This Pseudo-Static release provides users of Pale Moon a fully functional experence [sic] while we work with the developer to get Pale Moon officially supported.

The FoxClocks author has already made his add-on compatible with Pale Moon (in bootstrap.js beginning at line 42):

Code: Select all

			'{8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}': { // Pale Moon
				overlay:	{	'chrome://browser/content/browser.xul': 'chrome://foxclocks/content/foxclocksoverlay.xul' },

				stylesheets:{ 	'chrome://global/content/customizeToolbar.xul': ['chrome://foxclocks/skin/foxclocks.css'] }
			}

So, the FoxClocks developer has added full support for Pale Moon in his add-on. But apparently now, more is needed?

The Add-ons Team shall not highjack a GUID

I agree. The Add-ons Team should not fork an active extension, which add-on already fully supports the Pale Moon browser version 25 through version 27. And, by the way, listing this add-on at APO should not be called "highjacking". It should be called by a more proper term, such as "add-on distribution".

as AMO is still being used as a fallback

If AMO is merely a fallback (that is, AMO is searched for updates only when the add-on is not found at APO)-- that is even more reason, not less reason, for listing the version of the add-on at APO, that actually works in Pale Moon (instead of linking to some other version of the add-on, at AMO, known to not work in Pale Moon).

[GreenGeek]

It would be creating problems by uploading a modified version that isn't identified as such.

This is not a modified version. All that was done was add Pale Moon as a target application. However, if adding Pale Moon as a target application is of concern, one has only to change version number from "4.2.3" to say "4.2.3.1". One may also want to disclose the change at APO, such as "Version 4.2.3.1 adds Pale Moon as a target application."

No, that's what you do if you're doing it for your own use. I do that all the time because it's the easiest way, but I don't post them.

It would get overwritten by updates

Updates would fail, because newer versions from AMO would be incompatible

There's no way to know that for sure. I remember one pseudo-static that I thought was surely abandoned was updated by the original developer soon after the PM version was posted.

Adding the Pale Moon GUID, as a target application to the AMO version of the updated add-on-- this would help the user to manually update FoxClocks (which would be a good thing), but AFAIK automatic updates would continue to fail.

A manual update is the user's choice (but maybe you mean automatic notification while applying update manually). What would help is changing things the user can see in the addons manager, e;g. name, ver #, description. GUID is hidden from the user and affects only if (or rarely how, if code for PM is different) a manual installation can complete and work (just like ver #). Because of Pale Moon's dual GUID system, there is not normally any difference in function for adding GUID versus adjusting Firefox version #. But there potentially could be if the developer uses different code for Firefox and Pale Moon (that's not common though except when dealing with SeaMonkey).

Mozilla's signing requirements changed "how it works" bigtime. Adding Pale Moon as a target application does not change "how it works" at all.

Mozilla didn't change the target app or version. When you allow PM without changing anything else you are changing which applications the extension works with which can create all kinds of issues. And some devs don't like you making them responsible for application support on an application they didn't design it for.

[GreenGeek]

So, the FoxClocks developer has added full support for Pale Moon in his add-on. But apparently now, more is needed?

No. You're not understanding what the code change does. That's one of those cases like I mentioned above where the developer puts in different code for PM. That has nothing at all to do with making it install. He did not add the PM GUID in install.rdf, as would have been best since he has PM specific code, probably because he knew all that was needed was a compatible Firefox version #. The compatible min/max # changed with 27, so that's a good example of where a PM target app section is best, and even that may have to be updated.

The Add-ons Team shall not highjack a GUID

I agree. The Add-ons Team should not fork an active extension, which add-on already fully supports the Pale Moon browser version 25 through version 27. And, by the way, listing this add-on at APO should not be called "highjacking". It should be called by a more proper term, such as "add-on distribution".

Also could be called "hacking."

as AMO is still being used as a fallback

If AMO is merely a fallback (that is, AMO is searched for updates only when the add-on is not found at APO)-- that is even more reason, not less reason, for listing the version of the add-on at APO, that actually works in Pale Moon (instead of linking to some other version of the add-on, at AMO, known to not work in Pale Moon).

It is not however a good enough reason to do things wrong. Unless you take charge you can't make the rules.

[New Tobin Paradigm]

The only way an extension could be listed on the site like that is as an external which means it is merely a redirect to the official place to get an extension. AMO in most cases. This does not get said extension an entry in AUS because we do not highjack extensions.

This was a decision made at the founding of the Add-ons Site during v25 and the Adblock Plus situation. Additionally, the Pseudo-Static scheme was discontinued at that point (despite a select few still existing).

Bottom line, because it needs to be said and reiterated, do NOT post rogue extensions on this forum it causes confusion, issues, and though may not be enforced, is immoral and irresponsible if not illegal.

Just do things properly or do it elsewhere. If my successor, Andy, or Moonchild needs to say it to make it official.. I am sure that can be arranged.

[JustOff]

If you guys continue to do these shady activities it is gonna bite someone or everyone in the ass eventually.

I think I'm safe while I follow the rules of fair use, but thanks for the warning.

[New Tobin Paradigm]

That isn't how how fair use works... Are you serious?!

[Moonchild]

I remind you of: viewtopic.php?f=46&t=13655

Taking someone else's work as-is and releasing it as your own is not "fair use", it is plagiarism. It doesn't matter if it's released under a permissive open source license or not.

"Pseudo-statics" are, purposefully, stated to be one-time modified original versions, and are already skirting fair use to be honest. It's a practical band-aid that was needed at the time.
EDIT: Also meaning that the moment the original author makes them unnecessary, they should be discontinued.

If you want to properly fork something, then you must change the branding, change the ID, adhere to the license terms regarding mentioning your original code source, and take ownership of development for your fork from that point forward. If you're not satisfying all of that then you're doing it incorrectly.

By default, use of graphics and similar if they are distinctive to the program will not fall under a code license and will default to standard copyright and similar author's rights. You can't just use them (unless they have been explicitly released in the public domain).

[riiis]

Date Picker/Calendar 2.1.73.1-signed.1-signed installs from AMO, and runs out-of-the-box in Pale Moon version 24 thru Pale Moon version 27. Thus, the purpose of Date Picker (Pseudo-Static) is unclear.

Date Picker/Calendar 2.1.73 was released in July 2009. And, according to its install.rdf file, this add-on is only compatible with Firefox minVersion 3.0 to Firefox maxVersion 3.5.*. Regardless of these install.rdf settings, this add-on installs in later versions of Firefox and in PM24 thru PM27. Since all add-ons at APO are compatible with known versions of Pale Moon, can something similar be done with these add-ons in respect to Pale Moon capatibility. That is, can these add-ons listed at APO be installed in Pale Moon as compatible, ignoring whatever target applications and minVersion's and maxVersion's are listed in the add-on's install.rdf file? If possible, this practice would permit listing of otherwise compatible add-ons, without needing to first change the add-on's install.rdf.

[New Tobin Paradigm]

The pseudo-static on our add-ons site haven't been touched for years and need audited.

You guys need to stop argueing. As you don't seem willing to learn the facts of the matter let alone obey proper procedure.

Sometimes, actions have consequences.. Sometimes...

[GreenGeek]

Regarding Date Picker, since pseudo-statics aren't done anymore, taking it down shouldn't be an issue. We could always create a similar one fairly easily (there's a Mozilla tutorial that has some/most of the needed code already laid out).

As far as all the extensions on APO working on PM, that is a bit too vague. A lot of them aren't updated for 27 or at least the descriptions don't indicate so yet. Maybe the work could be divided up somehow so the manager just has to make the changes based on tests by trustworthy users.

[TerryBB]

I'm just a user. I tried to follow the arguments above.
But all I can say is that the version posted above by riis worked on my machine. I downloaded it from that link. I installed it from my hdd. I'm happy again.
The version on the PM/FF addons site(s) don't work. I'm puzzled as to why the riis version, or something of the same sort, isn't apparently the "official" one since that one patently wasn't working and this one does.
So I've downloaded the version there and now I have my Foxclocks back.
To me it seems simple. Old version doesn't work. riis' version does. And the problem seems to be that some technical argument about how to install it stops the version that works replacing the one that doesn't.

[TerryBB]

I should add, among the welter on acronyms above was a concern about reputation. Well having an extension that ceases to work being available when the one that functions isn't is hardly going to add to any reputation.