Pale Moon 27.0.0a2

[sugis]

First Mac Pale Moon 27.0.0a2 "Tycho" build:

Please remember this is an early alpha. Things seem to work well, but expect to find bugs!

http://mac.palemoon.org/dist/palemoon-2 ... .mac64.dmg

Tested:

• Made GitHub PR
• Watched Last Week Tonight on YouTube in 720p
• Submitted this forum post

Please let us know how well this works. Consider launching with a separate profile, so you don't clobber your existing Pale Moon 26 profile, by launching in the Terminal:

Code: Select all

/Applications/PaleMoon.app/Contents/MacOS/palemoon -no-remote -foreground -profile /tmp/scratch_user

[New Tobin Paradigm]

Congrats. Everyone please note that this build despite having the same version number as the Windows and Linux released Alpha 2 version is actually ahead of those releases. Next round will be sync'd though I suspect.

[snowmoon]

Thanx a lot sugis, this works flawlessly! I can only tell for Snow Leopard, but on SL we are in need for a good supported browser anyway, so this is really really great. I checked some news sites, loading/scrolling is fast/normal. Streamed on Soundcloud and Youtube, no problems. One optical glitch maybe, nothing dramatic, but there is no space between icons and text in bookmarks toolbar …

[New Tobin Paradigm]

Likely just a theme glitch.. We have had some major work in that area so there are bound to be some glitches especially on the mac side.

[Pleasureseeker]

No problems noted as yet on macOS Sierra. Loving it on the iMac and MBP that I have around the place
Looking forward to the final release when it is ready

[PRIZZA]

How can I help with plugin integration for Shockwave Player? If this browser was capable of natively playing Director games in both Windows (currently able) and macOS it would be a huge advantage. I'm willing to put in work!

[sugis]

Hi Prizza, unfortunately I have very little experience with either plugins or Shockwave -- but in general Pale Moon is inherited from Firefox, so most information applicable to Firefore 38ESR would also apply to Pale Moon, or at least send you in the right direction. So if you could get it working in Firefox 38ESR and then port that code to Pale Moon it might just work.

[PhilipLewis]

For those that use Ghostery or other add-ons based on the Jetpack/SDK these are unsupported on this release.

[New Tobin Paradigm]

For those that use Ghostery or other add-ons based on the Jetpack/SDK these are unsupported on this release.

This has been covered extensively already.

[bornagainpenguin]

Oh boy...

I just spent an hour combing through the forums trying to find out what was going on with these 'Jetpack' extensions, especially after seeing that the RES extension no longer worked with a message from the browser saying the reason was because it was Jetpack\SDK. Since this has been discussed ad nauseam so I knew I had to hunt around a bit before making a comment like the other guy did.

So, I did and I get it--I really do. I understand why you guys wouldn't want that kind of code littering up the browser making it that much more difficult to maintain and track down issues. What I want to do in this post is two things:

• Signal that I am a RES user on Pale Moon who wants this to work (or a suitable alternative become available)

• Ask if anyone knows any good alternatives?

• Suggest that maybe a sticky might be a good idea because not everyone knows about this.

• Suggest that maybe Bounties might be a way for non-programmers to contribute

I'm a fan of the browser and have been using it ever since the guys at Firefox decided pants made good hatwear but I admit that I knew nothing about this coming and would have probably loaded an earlier version of the browser if I had known while hoping that someone managed to hack out a true extension as a replacement.

For others like myself who came into this blind, here are some posts which explain why Jetpack extensions have to go. They're from threads discussing other extensions but the logic seems to apply to all Jetpack etensions:

None of the code from an SDK extension is useable...On a technical level there is NOTHING jetpack offered that couldn't be done via supported means in Toolkit.

So...Jetpack offered a 100% incompatible way to write the same thing?

Yep.. It was a good idea when it started but that good concept was ruined the moment the UX team got a hold of it and it was integrated into the codebase. In it's orginal form it was both backwards and forwards compatible because every SDK extension shipped with the SDK in it. Only a huge change would be problematic like a huge change in behavior of the underlying code. But then Firefox UX team got a hold of it and treated it as any other part of the codebase making huge incompatible changes from version to version tied directly to Firefox front end and Gecko back end. Defeating the whole point of an SDK.

Sorry if this drifts a little off-topic but it seems to not be entirely clear why SDC isn't compatible with Tycho in its current form and needs rewriting.

None of the code from an SDK extension is useable...On a technical level there is NOTHING jetpack offered that couldn't be done via supported means in Toolkit.

So...Jetpack offered a 100% incompatible way to write the same thing?

I know it's a little bit of an older post in this thread but I'm just taking the opportunity here to explain one thing:
The Jetpack SDK is an abstraction layer.

What does this mean, exactly? It means that people writing SDK extensions are using specific functions that are only defined in the SDK. The SDK translates this to regular Javascript for the browser to use. This also means that the SDK extensions are only compatible with the SDK and for them to be used in a native way they have to be rewritten in regular javascript. It also means that although potentially a bit more involved, code-wise, any SDK add-on can be rewritten to work with the browser directly. Of note: The SDK itself is just Javascript, too.

People who learn to write extensions using the SDK never learn to write code for browser use. The only thing they learn is how to use these abstract functions. This might make the threshold lower for budding extension developers or people just needing a "quick fix" for something, but both limits what you can do (because you can't talk to the browser directly even if you wanted to, and are limited to what the SDK offers) and never teaches you how the browser UI/APIs actually work.

Compare it with webdesign: the SDK is like wordpress, instead of designing your own website with HTML. Even though you can do great things with wordpress, you never learn html, and you are limited to what the framework offers in what you can create.

Example: (warning, gets rather technical)

The SDK has a module for preferences, which abstracts getting a preference to get(name-of-preference) -- after initializing and defining the preferences service as something to use.
This get function in the SDK translates to a wrapper around preferences-service component:

Code: Select all

const prefService = Cc["@mozilla.org/preferences-service;1"].
                getService(Ci.nsIPrefService);
const prefSvc = prefService.getBranch(null);

function get(name, defaultValue) {
  switch (prefSvc.getPrefType(name)) {
  case Ci.nsIPrefBranch.PREF_STRING:
    return prefSvc.getComplexValue(name, Ci.nsISupportsString).data;

  case Ci.nsIPrefBranch.PREF_INT:
    return prefSvc.getIntPref(name);

  case Ci.nsIPrefBranch.PREF_BOOL:
    return prefSvc.getBoolPref(name);

  case Ci.nsIPrefBranch.PREF_INVALID:
    return defaultValue;

  default:
    // This should never happen.
    throw new Error("Error getting pref " + name +
                    "; its value's type is " +
                    prefSvc.getPrefType(name) +
                    ", which I don't know " +
                    "how to handle.");
  }
}
exports.get = get;

This is a generic wrapper to deal with possible preference types, and then just get the preference and return it.
A non-SDK extension would do this directly by defining the preferences service (see first 2 lines) and then using getBoolPref getIntPref or getComplexValue depending on type (or could even include this function itself if it's needed). It means that extension programers will have to actually know how to talk to the browser interfaces instead of just using "get(whatever)" but it's not shockingly difficult either, and certainly a lot more compatible and usable outside of the SDK realm.

That is of course your choice.

Jetpack extensions are a dead end technology any way you look at it from all sides and has been for a while now. MOST developers with an ounce of talent has denounced it and did not rewrite their extensions after a good number of them converted to Bootstrap (Restartless). There was nothing that we could feasibly do about it.. If you want the extension.. You should contact the developer to rewrite SDC to proper Toolkit or Bootstrap using supported technologies for Pale Moon.

I must once again remind users that after Pale Moon 27 releases there will be NO support for Pale Moon 26.x what so ever. You will have lost the ability to have your questions answered or your issues resolved. Anything one may get afterword will be at our sufferance.

I encourage all users to not continue using unsupported versions especially when the codebase it's self will be deemed obsolete in any case. Be it 25.8 or god forbid 24.x..

The future of the extension and general add-on ecosystem is completely in your hands.. I have stated this before and it is more true now than it has ever been. If no one steps up to bring their extensions to Pale Moon and additionally no one else takes the time and forks or rewrites them.. Well, that will be how it is.. This is all in your hands.. We promote choice.. But sometimes choices have consequences and moreso choices have responsibilities.. Keep that in mind.

The great thing about Pale Moon specifically is that WE are the last stop for the potential of all the great extensions you know and love.. There is no such potential in Firefox's future.. Damn sure there isn't in Chrome or Microsoft's Browser. It is time to stop being mere users and consumers.. Time to take action.. Time to make a choice and make a difference. If you all want a bright future for Pale Moon and the add-ons potential that comes with it.. You guys MUST make it happen.

Hope this helps anyone else getting sidelined by this whole thing!

PS: I found the original RES as a userscript for Greasemonkey but I'm honestly not sure it's doing anything. While searching the Git Hub, I came across this post by a guy who has been trying to refactor the current RES to be a Greasemonkey script again for the browser he uses. Found this in his repository but have no idea if it works or does anything at all.

[PhilipLewis]

OK. Saved me doing that research. Cannot imagine the developers of Ghostery will be interested in rewriting their tool for PM's benefit, so I guess it's another add-on that goes the way of the Dodo here.

[bornagainpenguin]

Cannot imagine the developers of Ghostery will be interested in rewriting their tool for PM's benefit, so I guess it's another add-on that goes the way of the Dodo here.

Ghostery I honestly don't care that much about, but I need RES to be able to use Reddit on the laptop so looks like I'll be sticking with the earlier version of Pale Moon for a while until either someone makes a new port or I discover a different browser. I dislike giving up my extensions so I haven't looked into Brave that much, but since it looks like I may be losing them any way there's no reason not to shop around a little while I wait.