Pale Moon 27/ Tycho support

Issue #39 new
win7-7 created an issue

Hello. Can you make Pale Moon 27/Tycho specific version of your add-on that officially support Tycho/ Pale Moon 27 that is currently in development if you have time to do so and possibility to support other browsers than Firefox? Backend is based to ESR 38 but do notice that front-end is not Australis and it is mostly similar to pre-australis Firefox. While add-on currently works in Tycho official support from you could be nice.

No pressure. If you don't have time then you don't it would be just nice if you could.

If you have time to add official support you could hopefully make XUL/traditional classic toolkit based version as Pale Moon devs like more traditional toolkit based add-ons over bootstrap based.

You can register to forums and ask from Matt A. Tobin if you need more details.

Comments (24)

  1. ungram repo owner

    I'm amenable to retaining ESR 38 support as long as feasible (should be a while, since I'm not adding new functionality which depends on new APIs). Indeed, install.rdf currently has "<em:minVersion>38.0</em:minVersion>", though I've only recently tested back to ESR 45.

    So far as I know, it shouldn't depend either way on Australis or the lack thereof. However, I've not tested it. Conceptually, there's no reason it should. I began this add-on in the pre-Australis period and certainly never intentionally modified it to work with Australis.

    The bootstrap part does contain some important functionality which I'd have to see how would be re-implemented in a more traditional XUL addon. The main two user-visible features/options in the bootstrap half are open automatically on new downloads and remove completed downloads. The former has to live somewhere outside the XUL window definition and the latter causes lots of artifacts if it only works with the window open.

    I'm also puzzled why avoid bootstrap add-ons to begin with, even with Pale Moon's goals (towards which I'm sympathetic). I do see Matt A. Tobin's reponse to his effect at the forum link but he doesn't explain why, so it's hard for me to gauge how to proceed or what the specific objections are.

  2. win7-7 reporter

    You need also add Pale Moon GUID to install.rdf if you add official support in order to Pale Moon users to install add-on without needing to use disable add-on compatibility check ( Currently add-on works well after getting it to install in Pale Moon 27 alpha 2) add-on first because Pale Moon at some time ago already started to have its own GUID.

    Dislike for bootstrap add-ons seems to be personal dislike of Matt A. Tobin and if you properly support Pale Moon 27 then he doesn't have problem with it staying bootstrapped.

    Partial quote from Matt A. Tobin:

    "My general dislike for bootstrap is a personal preference.. If he is going to maintain his extension for Pale Moon then it can stay bootstrap.. We don't really care. To support us directly they would need to add an application block for us in install.rdf as well as likely upload his extension to our add-ons site.. If he wants to actually support us he should get a hold of me in a real time communication medium because forum or issue tracker back and forth can get tedious. Our IRC channel would be a good place."

    IRC channel should be way to go for further communication between Pale Moon devs and you.

  3. Matt A. Tobin


    First I want to thank you for your warm willingness to possibly bring your extension to Pale Moon. Trust me when I say it is exceedingly rare for developers today (the ones that haven't given up yet) to entertain it. So thank you for that.

    it would be helpful if we could speak in a more real-time environment such as the Pale Moon irc channel at #palemoon at some point.. Issue tracker back and forth plus the already present forum thread is a bit tedious.

    However, some points..

    Pale Moon uses it's own versioning scheme that is different from what Mozilla uses. Our Platform version will be 3.0 and our Application version will be 27.x (When Tycho releases as Pale Moon 27).

    You should include a separate application block to target Pale Moon directly in your install.rdf.

        <!-- Pale Moon -->

    As our modification of xpinstall that allows installation of Firefox extensions is set to the last historical and thus frontend compatible (even though Tycho is one last rebase on ESR38 that has already diverged the frontend was ported from a codebase that started life out as ESR24) version of 24.9 so xpinstall rejects the installation as not compatible.

    Additionally, I would request we list your extension on our Add-ons Site for automatic updatability. AMO (even if you lower the Firefox version) will not serve updates to Pale Moon because as far as AMO is concerned we are version 24.9 and a bug in AMO will not send updates out to lower versions of Firefox period if the minVersion was ever higher. Mozilla is aware of this bug and chose not to fix it.

    There are all kinds of annoying details to work out when dealing with Firefox extensions on Pale Moon especially if they intend to use AMO only and continue to support Firefox.

    If I may ask, how did you initially develop this extension? Did you originally take the Toolkit downloader and fix it up or did you take the places version and rework and style it to act like the toolkit version?

  4. Matt A. Tobin

    BTW.. win7-7 deal about us not liking bootstrap has nothing to do with your right to have a bootstrap extension. While I personally dislike what is essentially a big hack in the add-ons internal api and framework it is stable and long supported.

    I only mentioned it in the thread on the forum because people were wanting us to look at the possibility of integrating the extension's code as a replacement for the busted toolkit downloads window in our codebase. Of course bootstrap based code wouldn't work for that since bootstrap is an internal function of xpi provider and it is totally improper (if even possible) to initalize bootstrap code for an integrated component.

    So if you did not want to support us directly then a possibility for integration would obviously mean to make it pure toolkit without bootstrap. He should not have asked you to do that because it simply isn't required for a bootstrap extension not to continue using bootstrap while the code lives in extension space.

  5. win7-7 reporter

    My bad. I misunderstood Matt A. Tobin personal dislike for bootstrapped add-ons as dislike for bootstrap add-ons in general.

  6. Matt A. Tobin

    That build you posted is giving me..

    1474474930791 addons.xpi WARN Exception running bootstrap method startup on {a7213cf2-fa1e-4373-88ff-255d0abd3020}: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://downloads_window/content/modules/watchwindows.jsm :: <TOP_LEVEL> :: line 40" data: no] Stack trace: watchwindows.jsm:40 < startup()@resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///C:/Users/mattatobin/AppData/Roaming/Moonchild%20Productions/Pale%20Moon/Profiles/5g33sp5k.Default%20User/extensions/%7Ba7213cf2-fa1e-4373-88ff-255d0abd3020%7D.xpi!/bootstrap.js:150 < XPI_callBootstrapMethod()@resource://gre/modules/addons/XPIProvider.jsm:4468 < XPI_updateAddonDisabledState()@resource://gre/modules/addons/XPIProvider.jsm:4598 < AddonWrapper_userDisabledSetter()@resource://gre/modules/addons/XPIProvider.jsm:6985 < set_userDisabled()@extensions.xml:1084 < oncommand()@about:addons:1 < <file:unknown>

    Seems to be because of commit cd95ad251e9134529df9fb0cd7cc273508b7a66a

    Where you added a reference to Components.utils.import('resource://gre/modules/Console.jsm'); in content/modules/watchwindows.jsm

  7. Matt A. Tobin

    I found out where Console.jsm lives in Tycho..


    So you may want to use something very much like this...

    var appName =;
    var vcResult =, '44.0');
    if ((appName == 'Pale Moon' || appName == 'New Moon') || (appName == 'Firefox' && vcResult <= -1)) {
    else {

    Right so.. Here is what this does.. Assuming my syntax is correct.. it /SHOULD/ be.

    In Gecko/44 Console.jsm was moved from resource://gre/modules/devtools/Console.jsm to resource://gre/modules/Console.jsm.

    So to support older Firefox and us.. I have set up this code to deal with the change..

    first I query nsIXULAppInfo via Services.jsm for the Application name and also in one swoop query for the platformVersion and compare it with 44.0 where the change took place.. It will result in 0 if the same -1 if older and 1 if newer than 44.0 (I think).

    So we create a conditional.. The conditional will be true if appName is Pale Moon or New Moon OR appName is Firefox and vcResult is less than or equal to -1 which SHOULD mean 43 or older. If one of these two main groups is true then import from gre/modules/devtools/Console.jsm ELSE (as in not Pale Moon and not Firefox 43 and lower..) import from gre/modules/Console.jsm.

    This should be a much more complete solution so you can use Console.jsm in both older Firefox, Pale Moon, or newer Firefox.. Giving you accurate support for 38 to * of Firefox plus Pale Moon codename "Tycho".

    I do hope I have my logic right for vc but one can never be sure until it is tested. I also hope this helps!

  8. Matt A. Tobin

    I am getting this when I click the clear downloads button in the window.. Another code change to deal with newer firefox breaking stuff?

    Timestamp: 9/23/2016 2:51:11 PM Error: TypeError: DownloadsWindow.DPV.downloadsCmd_clearDownloads is not a function Source File: chrome://downloads_window/content/downloadsWindow.js Line: 266

    The clear downloads context menu item however works.. May want to make the code change conditional.

  9. ungram repo owner

    So, apparently I don't get notified via email if you edit a comment (e.g., your September 23rd comment), which is why I missed your edits until your poke just now. I guess if there's substantive new content (vs typos, grammatical editing, etc), it's probably safer to comment again if you want me to see it quicker.

    In any case -- yes, commit a23a709d05719e7c853b8da30c8b2ac4c9994437 introduced that DownloadsWindow.DPV.downloadsCmd_clearDownloads call to address issue #38, in particular M. Gruber's reproducible bug:

    The problem still exists: - go into private browsing mode - download something and cancel it during the transfer - "Clear downloads" won't remove it

    It's wrapped in a try/finally, which limits the damage of its not running, but indeed that would seem not to eliminate the error message, so I'll fix it with a different approach which should run cleanly on old and new FF. Presumably not fixing issue #38 on older FF versions, but that's a lower priority right now.

  10. Matt A. Tobin

    \o/ Seems to do the trick.. As far as I can tell there aren't any other issues I can see.. But I will poke about in normal every day use.

    If you /want/ you can make it conditional between Firefox and Pale Moon to have your cake and eat it too...

  11. Matt A. Tobin

    Again, I want to thank you so much for your continued support! You, sir, are one of the good ones!

  12. ungram repo owner

    Could you verify that, which addresses issue #40, properly localizes on Pale Moon? I did check via the language packs from that it should, because they contain sensible-looking cmd.clearDownloads.accesskey entity defintions in locale/browser/downloads/downloads.dtd, but I've not tried to actually run it.

    Corresponds to commit 1183877318d27741a0c1df2d207686b71d6077e5

  13. Ryan C

    I can confirm this all works as expected.

    It would be amazing also if this were included on the Pale Moon Add-Ons Site, so the wider Pale Moon community can use this extension rather than simply those who are aware it is compatible. If you're interested, let me know and I'll get something set up (though ideally I'd need a private form of communication to relay some information to you in this regard if this were to happen).

  14. Log in to comment