Off-topic:LimboSlam wrote:You know MC, a lot of people don't know the difference between the phrases "forked off from" and "based off from," or the word "FORK" in general! Maybe it's time to take up my suggestion and add the meaning of "fork" in a hyperlink or banner! Though I also have the feeling this won't matter.
Wikipedia has a good explanation of the term. If people don't exactly know what it is, then they can look it up, too!
Honestly, all of this is very exhausting, indeed.
I'm sorry if this addition to the extension blocking list caused inconvenience for some people, but it really was our only recourse with the mounting issues caused by the Firefox-ABP extension and no support by the ABP team for us as a target application.
One can always point a finger at us for "not implementing exactly those parts of a draft that the extension happens to use", of course, and make it sound compelling as an argument. That is, however, not the main issue here. The main issue is simply that ABP does not support Pale Moon as a browser, because it doesn't follow the same development path as Firefox, and no consideration is given to us because we are not keeping exact parity with Firefox (we likely wouldn't be a fork if we did).
It's also an argument you can't win, because something written specifically for Firefox will always have compatibility with Firefox, something that is not guaranteed for us. Whatever the reason for the incompatibility, someone looking from the standpoint of the perfect match will always be able to say it's Pale Moon's fault for "not having feature x or y" and they will be absolutely correct... from
their standpoint. Now what if a Pale Moon extension builds on something Pale Moon has but Firefox does not? Whose fault would it be then if someone on Firefox would want to use the extension but can't? The same people would likely say in that case that it's the extension's fault, not Firefox's. But the situation would be exactly the same, just switched sides. I hope this makes sense to the readers of this long post (sorry about that. Am I rambling? I hope it's not too bad...
). Now, I agree that ES6 is a large task, and very complex to do right since so much hinges on Javascript in this family of browsers and there is no room for error. We could certainly do with more additions and improvements, implementing more parts from the draft, but that development process not being instantaneous is certainly not something you can fault us for, either, which is what Tharn touched on previously. As usual, too, for everyone running into an issue with something not being implemented, or not being implemented as-expected, the thing they would need is always "highest priority" for
them, and wouldn't care much about other parts they don't need themselves.
It seems most people who are really upset by this are the people who were lucky enough to not yet run into the incompatibility issues, who were still using an older (and unmaintained) version of ABP on their system. We've clearly warned about this for many months, but it's apparently been ignored. We put time and effort into ABL, matched specifically to this browser, for a good reason; the refusal to use it, and instead favoring a stale and incompatible ABP version (with the same functionality, mind you) will always strike me as very odd, to say the least. Is it a loyalty issue? Is a different name and different maintaining developers such a hurdle for end-users? I thought most people cared about the end result, in this case...
Even so (And Axiomatic seems to have mid-aired here with me with the same), the ABP devs themselves have advised us to "roll our own". That is what ABL is.
Weird, I thought he would have been on board with us considering he knows first hand how difficult this specific issue is with us! 
