Some questions inspired by Mozillazine discussion

[dr_st]

Greetings, forumers.

A brief introduction - I've been using Pale Moon for a couple of years (don't remember exactly when I switched, but I think it was towards the end of the 3.6.x era, probably right after Mozilla started with the rapid version number bumping approach, but before 3.6.x was EOLd). I've been happy with it ever since, and the general development approach of the Pale Moon team appeals to me more than that of Mozilla at this point, so I'm here.

I've been following the forums but only registered recently, after the PM25 release, and all the heck that followed. PM25 works fine for me for now, and all the issues that I experienced in the beginning I worked around using the methods outlined here and on the main site.

However, with FF and PM diverging, I'd like to understand more what to expect in the future in regards to website/extension compatibility and the like.

I stumbled upon a split thread in the Mozillazine forums, where some technical points/questions about Pale Moon were brought up by the participants, which I thought were important. There seemed to be no consensus on some of them, so I thought I better ask directly here, at the source.

The thread is this one:
Pale Moon has changed its GUID

First, this post by LoudNoise:

Actually, at this point there shouldn't be any -- there hasn't been that much change from V 24. If something as complex as AdBlock is fixed by using a version that still supports 24 and changing GUID then everything else should also.

What is interesting is that only one theme is listed as working. Considering that most of them worked with version 24 I am curious what happened.

My questions: Is it really only the GUID, or have some functional changes been made that may have made certain extensions/themes truly incompatible? In the list of currently unsupported extensions - have all these been working on V24? If so, what broke?

From this post by patrickjdempsey:

In the case of Themes, the source code may be freely licensed, but the imagery may not, and any Theme specifically supporting current versions of Firefox is not likely to work, AND older versions of Themes and Extensions designed for pre-Austrailis Firefox may be already starting to run into issues with CSS, XUL and XBL changes in Gecko.

While it is obvious that anything specifically using/coded for Australis is not going to work, I'm curious about the last part of the comment about pre-Australis extensions running into issues with changes to the Gecko back-end.

My questions: How do you see the future of extension support in Pale Moon? With Mozilla EOLing pre-Australis Firefox, it is conceivable that eventually extension developers will stop catering to those versions. However I assume that at least some of them will continue to support the Classic Theme Restorer, since many mainstream Firefox users still don't like Australis. Is Classic Theme Restorer expected to continue to work? Will extensions that work well with this mode in FF, also work well in PM, which completely lacks Australis, or will PM be stuck with older versions of extensions, the pre-Australis ones? And assuming PM continue to update the Gecko back-end, to stay up-to-date on features and security, is it foreseeable that those pre-Australis extensions do run into issues, as Patrick predicts?

Then there is this post by LoudNoise:

Like it or not, most of the code in PM is still from Fx 24. PM did not magically rewrite the browser overnight.

And this post by patrickjdempsey:

Based on digging around the supported features in the Release Notes page for PM 25, as well as the very silly Gecko build-date in your UA string, it is clear to me that PM 25 is based on Firefox 31 ESR. Abandoning Firefox/Gecko's numbering scheme is risky. Another thing I notice in your UA string and the Release Notes:

"Disable Firefox Compatibility mode by default.
This means Pale Moon will no longer have a Firefox/xx.xx indicator in its UserAgent string."

This is pretty much browser suicide. SeaMonkey users can attest to how bad of an idea this is. If PaleMoon is based on Firefox 31, it needs to advertise that it's based on Firefox 31. Period. Maybe it's not a huge huge issue right now, but next spring if they release PM 26 based on ESR 38 then there will almost certainly be major problems with website support for new technologies.

Dropping XP support is also likely not a good move. There's also so technical aspects of telling extensions that they are seeing Firefox 24 that is a bad idea. I also have to wonder what services.appInfo.version reports? There's going to be some very confused extensions from all of this I think.

My questions:What is PM25 really mostly based on? FF24 or FF31? What does it advertise to websites when FF user agent compatibility mode is turned on, and what does it advertise to extensions? What is the rationale behind this, and what do you plan to do in the future as the divergence continues?

Comment: Turning on FF user-agent compatibility is one of the first things I had to do, to continue using PM25 normally. As much as I agree that UA sniffing may be bad practice, it is a fact, and Pale Moon being still very much a minor browser in the field, it is very naive to think that PM developers/users will manage to convince all the "bad" websites (which include Google, as we all know) to stop it, or to add special treatment for PM, in the foreseeable future. Therefore this option must stay, probably indefinitely, and maybe even should be enabled by default.

Question: do you foresee that in time the code bases diverge so much that it will be impossible to present a reliable Firefox compatibility string, i.e., PM will not be sufficiently close to any FF version to be able to "spoof" it and have everything "just work"?

[Moonchild]

There seemed to be no consensus on some of them, so I thought I better ask directly here, at the source.

No real surprise, since the staff at MozillaZine seems to be terribly uninformed about Pale Moon's status, code, changes and approach. Thanks for taking the correct step to ask here!

My questions: Is it really only the GUID, or have some functional changes been made that may have made certain extensions/themes truly incompatible? In the list of currently unsupported extensions - have all these been working on V24? If so, what broke?

It's not only the GUID, although the GUID (and extensions targeting specifically only the Firefox GUID - often even when it's not needed) is the biggest issue here, and the main cause of the breakage. We don't know yet if all of the mentioned extensions have been working on v24.* or not, since we have to work through the list one extension at a time to evaluate, fix, test and release.

In the case of Themes, the source code may be freely licensed, but the imagery may not, and any Theme specifically supporting current versions of Firefox is not likely to work, AND older versions of Themes and Extensions designed for pre-Austrailis Firefox may be already starting to run into issues with CSS, XUL and XBL changes in Gecko.

To clarify this quote from Mozillazine, consider the following:

• The imagery is an inherent part of what is released. Just like the imagery in the Pale Moon browser is an inherent part of what is released. In general, in this case, use of the imagery is "fair use" - this is also why specific exceptions have to be stated for trademarked or otherwise protected images that are part of these kinds of Open Source licensed software. So it's perfectly fine to adapt the themes to specifically work for Pale Moon.
  Of course we strongly encourage the original theme designers and authors to support Pale Moon by adapting their themes themselves, but it should not be an issue if one of the Pale Moon staff or community members does it.
• Most full themes do not work out-of-the-box in Pale Moon because there are some specific elements that won't necessarily be included in the "skin", like the RSS icon. Of course "Australis skins" will not work, period, because they are of a different design altogether in many cases.
• Themes and extensions designed for pre-Australis Firefox will only start to run into issues if you attempt to use them on a post-Australis based browser. Pre-Australis themes and extensions will continue to work on Pale Moon because Pale Moon will never adopt Australis or its limited, Australis-focused APIs and changed XBL and XUL handling. So, the problem indicated there is not a problem for Pale Moon, but instead it's a problem for Firefox!

How do you see the future of extension support in Pale Moon?

Future extension support for Pale Moon will be what we are aiming for here: A collection of Firefox extensions (pre- and post-Australis) that "just work", a collection of extensions that specifically target Pale Moon in addition to Firefox (similar to ones that currently target e.g. Firefox and SeaMonkey), and a collection of extensions that are exclusively for Pale Moon.
Also: just because Pale Moon-exclusive extensions might be based on older versions of Firefox extensions doesn't mean they won't keep pace with Australis versions. An additional point being that many extensions in the past year or so have only been updated to "make sure it worked again in the next 6-week iteration of Firefox" without actual core changes to the extension: Once an extension does what it was designed to do, it doesn't necessarily need to be updated. This is also why you can find a good number of them that were designed in the Firefox 4 (or even Firefox 2) era, that to this day still work fine.

Is Classic Theme Restorer expected to continue to work?

You misunderstand: CTR is a totally non-applicable extension! Pale Moon does not and will not use the "CustomizableUI" system. If CTR stops working, it means absolutely zilch for Pale Moon users. The UI we use is not dependent on layering "corrective extensions" on top of an otherwise ruined UI; that would just add unnecessary complexity (and bugs!).

EDIT: I understand where this question is likely coming from. Other "Firefox alternatives" (which are mainly re-configured rebuilds, like Waterfox, Cyberfox, etc.) have gone through following the mozilla-release branch, rebuilding from whatever is the latest Mozilla Firefox code, and layering on or pre-installing extensions to restore functionality that was lost in Australis (well, to the extent possible, anyway). Pale Moon does not work that way.

Then there is this post by LoudNoise:

Like it or not, most of the code in PM is still from Fx 24. PM did not magically rewrite the browser overnight.

Of course we did not.
Pale Moon is still a Mozilla-based browser and as such draws heavily on the Mozilla code that lies at its roots. LoudNoise clearly does not understand anything beyond black or white. Yes, this has likely never been done before by anyone.
Also, Pale Moon has been around for a while. Given, the changes and diverging have taken an accelerated pace more recently, but nothing has been done "overnight" and it's still a Firefox fork. Maybe LN would understand better if he'd imagine a fork - go on, grab one from the kitchen - see that long handle? That is the common root. See the relatively small head with prongs? That is divergent code paths.

My questions:What is PM25 really mostly based on? FF24 or FF31? What does it advertise to websites when FF user agent compatibility mode is turned on, and what does it advertise to extensions? What is the rationale behind this, and what do you plan to do in the future as the divergence continues?

Neither, really. Pale Moon 25 includes code from 24, 25, 26, 27, 28, (not so much) 29, 30, 31, 32, 33 and 34. More from all these versions will be cherry-picked if found desirable in the future. In addition, there is plenty of Pale Moon-specific code. As stated elsewhere it is a hybrid. It is its own thing, hence the absolute need to stop carrying the Firefox GUID because it would enforce this kind of comparison and would prevent us from individual development if we at all times have to keep a parallel with a specific version of Firefox.

What does it advertise to websites when FF user agent compatibility mode is turned on, and what does it advertise to extensions?

It currently advertises Firefox/24.9 to websites if compatMode is enabled - but that will be changed in the near future.
It advertises the same to extensions, although from an extension point of view this only applies to the installation routine. Pale Moon's front-end is "most compatible" with 24ESR as far as UI elements go. This is a temporary situation though, and only in place to allow Mozilla Firefox extensions to continue running on Pale Moon in an "extension compatibility" mode.

As much as I agree that UA sniffing may be bad practice, it is a fact, and Pale Moon being still very much a minor browser in the field, it is very naive to think that PM developers/users will manage to convince all the "bad" websites (which include Google, as we all know) to stop it, or to add special treatment for PM, in the foreseeable future. Therefore this option must stay, probably indefinitely, and maybe even should be enabled by default.

The option will stay, and in fact will be made easier to access in the next point release. Whether to enable it by default is a different matter and something I've been giving a lot of thought. It's maybe naive to think that the currently continued bad trend can be broken, I admit, but it certainly serves to create a situation where more light is cast on it. Yes, it'll be inconvenient because people expect stuff to "just work", even if it's caused by 2-decade old, and currently wholly unnecessary product detection scripts on the visited sites that should have long since been replaced by capabilities-detection scripts. If websites have no trouble updating their entire visual designs every year or two, to follow the current visual trends on the web, then they should take the opportunity to get rid of what is generally considered bad practice (without quotes) instead of forcing web clients to lie about themselves all the time.

Enabling it by default (like before) would just maintain the status quo (see other posts on this forum what I mean with that). By taking the first step, this likely reflects bad on Pale Moon. But just sitting back and perpetually waiting will not improve anything, as well as the increasing problem of there being a less "perfect match" as to what Pale Moon should "pretend to be" instead of itself as time goes on, and slowly break more websites instead of the initial bump here.

You might also ask yourself: why make all these changes in one go? I think it's better to have one rough spot, get it over with, than disappoint people again and again (You see where that has left Firefox users). After this change, Pale Moon will have a solid base once more, but with a difference: it will have its own place on the browser market - might be small, but present. Continuing to dangle off the fox like a surplus tail is just not good in the long run.

[Sajadi]

In short words, Australis extensions which explicitly need the Australis Chrome clone UI will not work on PM, and while the base code is of ESR 24 origin, it will be additionally enhanced with picked features if they make sense to have them in Pale Moon and all necessary security fixes from later versions.

[dr_st]

Thanks for the detailed answer, Moonchild.

Themes and extensions designed for pre-Australis Firefox will only start to run into issues if you attempt to use them on a post-Australis based browser. Pre-Australis themes and extensions will continue to work on Pale Moon because Pale Moon will never adopt Australis or its limited, Australis-focused APIs and changed XBL and XUL handling. So, the problem indicated there is not a problem for Pale Moon, but instead it's a problem for Firefox!

I'll try to focus my question a bit more. Granted, that pre-Australis extensions will run into issues on post-Australis browsers (if they rely on the UI in any serious way). But let's assume there is a good stable pre-Australis extension that we want to continue to use (even if the developer abandoned it), or even let's assume the developer wants to continue supporting the pre-Australis version.

Is it conceivable that back-end changes to the engine (which Pale Moon wants to bring in, to stay up-to-date and secure), and are not directly related to the Australis UI, will break compatibility with such extensions, which would force the developer (or whoever picks up the work) to explicitly add non-trivial code to support Pale Moon (which as you put it, will become a hybrid browser).

I can guess that the general answer is going to be "it may happen to some extensions, not to others". But perhaps you have an opinion, or gut feeling, if you will, as to how serious this problem likely to be.

You misunderstand: CTR is a totally non-applicable extension! Pale Moon does not and will not use the "CustomizableUI" system. If CTR stops working, it means absolutely zilch for Pale Moon users. The UI we use is not dependent on layering "corrective extensions" on top of an otherwise ruined UI; that would just add unnecessary complexity (and bugs!).

EDIT: I understand where this question is likely coming from. Other "Firefox alternatives" (which are mainly re-configured rebuilds, like Waterfox, Cyberfox, etc.) have gone through following the mozilla-release branch, rebuilding from whatever is the latest Mozilla Firefox code, and layering on or pre-installing extensions to restore functionality that was lost in Australis (well, to the extent possible, anyway). Pale Moon does not work that way.

I actually come from a slightly different angle. I fully understand that CTR is not relevant and not needed for Pale Moon because Pale Moon has no Australis. My question was actually - do you expect it will continue to be supported on Firefox (sorry for not being clear about it).

You may wonder why we should care about it. The answer (in my mind) is that as long as it is supported, and at least some people want and can use FF with a classic theme, there will be some interest among mainstream extension developers to support the classic UI. And if they do, then PM support can be got for free or almost for free. However, if it stops being a viable option, I believe eventually a lot of the developers will stop caring for the classic UI, and then good luck convincing them to explicitly support PM (sadly, we've seen how it's going so far).

We may still have the option to use an older version, which ties this question to the previous one.

The appeal of FF is the extensions. The appeal of PM (to me at least), is that it's FF with all the extensions supported and none of the stuff I don't like with the new FF. I imagine many feel this way. The community is behind the mass of extensions, and I believe it will be very difficult for the PM team if the full burden of maintaining its own extensions falls on you guys.

The option will stay, and in fact will be made easier to access in the next point release. Whether to enable it by default is a different matter and something I've been giving a lot of thought......
......Enabling it by default (like before) would just maintain the status quo (see other posts on this forum what I mean with that). By taking the first step, this likely reflects bad on Pale Moon. But just sitting back and perpetually waiting will not improve anything, as well as the increasing problem of there being a less "perfect match" as to what Pale Moon should "pretend to be" instead of itself as time goes on, and slowly break more websites instead of the initial bump here.

I kind of agree with you, after some more pondering. I believe most PM users are power users (otherwise they would probably not even explore enough to learn of its existence), and as such can take care of themselves, as long as they know this option exists. Whether it defaults to on or off is a minor point, and as long as there is a FAQ entry on it, it should be good enough.

You might also ask yourself: why make all these changes in one go? I think it's better to have one rough spot, get it over with, than disappoint people again and again (You see where that has left Firefox users). After this change, Pale Moon will have a solid base once more, but with a difference: it will have its own place on the browser market - might be small, but present. Continuing to dangle off the fox like a surplus tail is just not good in the long run.

I agree with you on this point as well.

Pale Moon is an ambitious project. More ambitious than most Firefox clones / niche builds. I think some people don't understand it (and don't understand why PM has to make so much "noise", which annoys them). Some others do understand it, and think that it is doomed to fail, because it is so ambitious (the "a small team will not be able to keep up with hundreds of programmers at Mozilla" argument).

Being a software developer myself (although working on much more modest things ), I often hear this argument, and I know that it does not always hold, although often it does. IMO, you got a great thing going here, but I think the challenges are going to get harder now. I believe you can do it, if you stay as dedicated and focused as you have been so far. This is the key and the one great advantage a small team can have over a large organization.

So I'll continue using Pale Moon and hope I can be useful to the project from time to time.

[Moonchild]

I can guess that the general answer is going to be "it may happen to some extensions, not to others". But perhaps you have an opinion, or gut feeling, if you will, as to how serious this problem likely to be.

I don't expect this to be a serious problem. At all.
Unlike MozCo, I'm not going to be in the habit of arbitrarily removing or changing APIs, renaming functions or "refactoring" parts of the browser code that are exposed to the front-end and extensions.
Basically, because Pale Moon doesn't try to be something else. It's a web browser. It's not a Skype client, pseudo OS, image editor, PIM, "game platform", dedicated media player, DRM-aware streaming application, web developer IDE, or whatever else Mozilla is trying to stuff into Firefox these days.

I fully understand that CTR is not relevant and not needed for Pale Moon because Pale Moon has no Australis. My question was actually - do you expect it will continue to be supported on Firefox (sorry for not being clear about it).

You are asking the wrong people

You may wonder why we should care about it. The answer (in my mind) is that as long as it is supported, and at least some people want and can use FF with a classic theme, there will be some interest among mainstream extension developers to support the classic UI.

And this is a different question altogether. We still wouldn't care in that case since the "classic ui" (mind the quotes) as it is "restored" by CTR is most definitely not the actual classic UI. It is a visual emulation, but the actual UI and underlying routines will be Australis -- this is also the reason why CTR can't do everything and is lacking functionality for people who want the classic UI as-it-was. Other extensions will not be talking to CTR, they will be talking to the Australis UI and the result will then be fed through CTR's presentation. So, if an extension is made to be run on "Australis+CTR" it will very likely also run on "Australis without CTR" -- the extension will not care if CTR is installed or not. The level of abstraction present in the browser UI allows for this, and allows for the same extension to run on the actual classic UI in many cases without specialized code as well, unless they are made specifically for Australis exclusively (which might be the case for jetpack add-ons that use specific, new, Australis-only SDK calls).
So, no, we really don't care if CTR is going to see perpetual support or not. The only thing we care about is if extensions are pre-Australis compatible.

I believe most PM users are power users (otherwise they would probably not even explore enough to learn of its existence), and as such can take care of themselves, as long as they know this option exists. Whether it defaults to on or off is a minor point, and as long as there is a FAQ entry on it, it should be good enough.

After some more feedback and research, I've had to revise my approach. The default will be on, because many more things than expected are problematic - even router firmware. The minor point will be in the favor of poor web design, but with an easy toggle for the people who wish to make the choice of running Pale Moon as-intended (and switch the mode on and off any moment). See viewtopic.php?f=1&t=6200

Some others do understand it, and think that it is doomed to fail, because it is so ambitious (the "a small team will not be able to keep up with hundreds of programmers at Mozilla" argument).

I don't think it's necessarily ambition, it's just "try to do things right". And what are those hundreds of programmers at Mozilla working on, exactly, anyway? Creating an ever-less-stable product just so it has more "shinies"? Don't forget that we as a small team can, thanks to Open Source, draw upon the Mozilla code and adapt what we want, when we want, if we want, to our own code base. Sure, it won't be written by us, initially, but isn't that the beauty of FOSS? Similarly, Mozilla is just as free to take our ideas and code and incorporate it back into Firefox, although they don't seem terribly interested, unless I were to actually become an employee of them (yes, I've been asked a few times, and gracefully declined because of their general direction - I prefer my freedom of choice and being able to pass on that freedom to our users).

[Pnume]

I'd known about Mozillazine for some years and have seen it come up in Google searches over the years but hadn't ever read anything there. But now, after having finally read some threads there, I can't help but wonder if one criterion for becoming a staff member there is to be a complete wanker. LoudNoise in particular seems like a total douche-bag. And it would seem that Mr. High and Mighty has much time on his hands to have made 36859 posts there. I realize that most of us, including myself, are geeks. But, seriously—36859 posts on a forum where the discussion revolves around an internet browser seems rather excessive.

Anyway, that place is a disgusting shit-hole full of staffers who lack integrity and class and, because of this, I've no intention of ever posting there.

[dr_st]

There definitely seems to be a lot of hostility towards Pale Moon on Mozillazine. Their claim, as I understand it from that thread and a few others, is that Pale Moon groupies/affiliates used to spam their forums asking for too much attention, and that is the cause of said hostility.

I don't know how true it is, and frankly I don't care for any silly "you did it!", "no, you started it!" games. But the situation being as it is, I also don't feel like registering there just to talk about Pale Moon, or to try to correct someone's misconceptions about it.

It is a bit unfortunate that the situation is as it is, because there are some folks there with good technical knowledge, and some interesting points are brought up here and there. Apparently, the discussion in the MZ thread continued after someone linked to this thread. So at least there is some form of communication going on, even if it's indirect and awkward.

In particular, this post by Frank Lion seemed interesting to me:
http://forums.mozillazine.org/viewtopic ... #p13836179

It seems that his premise is that the main goal of Pale Moon is to be Firefox without Australis, and he is of the opinion that it is completely overkill, as it is possible to build a theme on top of Australis that will look exactly like pre-Australis Firefox. I'll have to take his word for it , but the key point here is that folks that have only recently heard of Pale Moon are likely to get this impression. And there is no doubt, that many Australis-disappointed customers have found refuge in Pale Moon, in fact I've introduced some such customers to the browser.

One interesting question is how to convince potential users (as opposed to those who have been with the browser way before Australis) that Pale Moon has additional value as well.

[Sajadi]

Even if one would do that, it still means you face the restrictions of Mozilla's wanna-be-like-Chrome monstrosity, which.. for quite a high number of persons is just unacceptable. Just take a look at Firefox marketshare, this alone should make that clear.

That dreamers, guys caught in illusions at Mozillazine can do nothing as bashing Pale Moon, because they can not accept that there is no official other method of "recreating" the old UI with stuff like Classic theme restorer.

Fact is, Classic theme restorer is NO clean solution to recreate the old UI. Customizations are only emulated and Mozilla constantly breaks add-ons and themes again. People have also omplained that even with CTR they had to readjust things on a regularly base when the browser has updated.

And if that is already not enough for a critic of Australis to avoid Firefox, how about then that: DRM, ads in the newtab page, Google stuff more and more implemented!

Australis Firefox and recent Mozilla has become a pseudo Google bought utterly disgusting company which only cared to be as much as close to Google Chrome! And that is something an even higher number of people can and will not accept! Sadly i have to give that strange Mozillazine guys in one point a credit... that Seamonkey is indeed an option to avoid Australis. But in all other points, that guys are just so full of illusions and wrong believes that it hurts it to write down!

Of course the guys from Mozillazine have one more reason to speak in a bad way about Pale Moon - these guys are so full of brand loyalty that it also almost hurts! But everyone who values reason AND morality (in terms of discrimination against Conservatives and Christians by the side of Mozilla) and puts not something like brand loyalty higher as moral values, has and will jump ship!

Mozilla was perhaps once one of the good, but under Google guidance they have become at least partly as corrupted and stupid as their mother company! Guess i have to visit a bucket because i feel suddenly sick.....

[Davesnothere]

As much as I agree that UA sniffing may be bad practice, it is a fact, and Pale Moon being still very much a minor browser in the field, it is very naive to think that PM developers/users will manage to convince all the "bad" websites (which include Google, as we all know) to stop it, or to add special treatment for PM, in the foreseeable future. Therefore this option must stay, probably indefinitely, and maybe even should be enabled by default.

The option will stay, and in fact will be made easier to access in the next point release. Whether to enable it by default is a different matter and something I've been giving a lot of thought. It's maybe naive to think that the currently continued bad trend can be broken, I admit, but it certainly serves to create a situation where more light is cast on it. Yes, it'll be inconvenient because people expect stuff to "just work", even if it's caused by 2-decade old, and currently wholly unnecessary product detection scripts on the visited sites that should have long since been replaced by capabilities-detection scripts.

If websites have no trouble updating their entire visual designs every year or two, to follow the current visual trends on the web, then they should [also] take the opportunity to get rid of what is generally considered bad practice (without quotes), instead of forcing web clients to lie about themselves all the time....

I thought that the section of your post which I quoted (especially the bolded and underlined part) was important enough to deserve its own separate post.

I sincerely feel that many website devs (and their bosses) do not have their priorities straight.

Cheers !

[dr_st]

I sincerely feel that many website devs (and their bosses) do not have their priorities straight.

This is actually quite easy to explain.

1) Everybody sees the shiny new design, and nobody sees what's under the hood. Very few people understand it, and so very few people care.

For a good explanation, read this: http://www.joelonsoftware.com/articles/ ... 00356.html
(specifically the part starting with "Now, I promised to tell you a secret...").

2) People, especially people in large organizations, especially people working on long-standing, big projects, are very reluctant to make any changes that are not part of the overall development strategy, unless things are broken badly enough, for sufficiently important clients.

The reason for this reluctance is the simple "I can't be sure it won't break something else somewhere else for someone else, and then things might get worse, so why would I risk it".

[Jonguy30]

Then there is this post by LoudNoise:

Like it or not, most of the code in PM is still from Fx 24. PM did not magically rewrite the browser overnight.

Of course we did not.
Pale Moon is still a Mozilla-based browser and as such draws heavily on the Mozilla code that lies at its roots. LoudNoise clearly does not understand anything beyond black or white. Yes, this has likely never been done before by anyone.
Also, Pale Moon has been around for a while. Given, the changes and diverging have taken an accelerated pace more recently, but nothing has been done "overnight" and it's still a Firefox fork.

I just want to add that we have been rewriting this browser in 4-5 years now. It's most certainly not "overnight". In my opinion he should read a little about Pale Moon's history, it's been here since the Firefox 3.x days. Also Pale Moon has not always been based on ESR builds. It's just that ESR 24 gave us the time to think about how to move forward with the browser. And suddenly when that happened everyone now thinks it's a rebuild of 24 ESR.

And they still think Pale Moon's code base is the outdated firefox 24.

Considering the security and website compatibility implications, I'm not terribly surprised that MoonChild isn't overly forthcoming about the fact that PM is being built on top of the very out-of-date Firefox 24 code base. But it seems to me like a VERY important thing for users to know before installing it.

May I show you the latest security fixes from the version 25.0.1 changelog:

[*]Fix for VP9 decoder vulnerability security fix
[*]Fix for direct access to raw connection sockets in http security fix
[*]Fix for unsafe conversion to JSON of data through the alarm dom element security fix
[*]Update of NSS to 3.16.2.2-RTM security fix

Those are security fixes. It's not "outdated".

Also there's this thread in the "Firefox builds" section talking about the announced official Firefox 64 bit: http://forums.mozillazine.org/viewtopic.php?f=23&t=2876519

And the following quote(s)

So, will this spell the end of The Waterfox Project and\or firefox64bit.com?

You would need to ask them. I would doubt it. Most of these projects are more than just recompiling Firefox.

So he thinks waterfox and similar projects are "more than just rebuilding Firefox"? But he doesn't hold that opinion about Pale Mon?

[dr_st]

As you may have seen, I joined the discussion in the MZ thread, and there were a couple of points raised there which I personally found interesting, so I'll bring them up here. I am addressing them first and foremost to Moonchild, of course, but anyone's inputs are welcome.

Indication of sources for patches ported from main-line Firefox code

It appears that in the past there was a more rigorous listing of the bug fixes (esp. security) that were ported from Firefox (including bug number), whereas now it is more limited. I see references to some CVE entries, and a few bug numbers here or there, but not as much as before. Mostly it just says "Security fix".

Assuming that many of the changes (whether bug fixes or new features) follow from main-line Firefox, and would have an entry in the Mozilla database, is there a reason not to list the source for each and every one in the release notes? It doesn't sound like a lot of work (compared to actually porting the patch), it will make it easier for advanced users to cross-reference PM and FF features and key fixes, and as PM incorporates more patches from modern FF versions, will help refute claims of PM being outdated.

Long-term validation of security fixes

The key premise of Pale Moon staying up-to-date is porting / reimplementation of security fixes from main-line Firefox. A point has been raised that as the code bases diverge, it will not always be enough to merely compile in the fix to know that the vulnerability has been eliminated. Furthermore, it is conceivable that not all fixes will be able applicable "as is" (as you mentioned elsewhere - things routinely need to be reimplemented now).

How does one test that the vulnerability is closed? Is there always functional testing against the specific flaw? Are such tests typically internal synthetic ones, or "real system" tests such as the POODLE test?

Basically, how is testing for successfully patching against a known issue currently handled in Pale Moon, and how do you expect it to be done in the future, as the browser becomes more independent?

[Moonchild]

I would appreciate it if cross-posting of concerns between this forum and MozillaZine is kept to a minimum. If people at MozillaZine are genuinely interested in knowing more about Pale Moon and its process, they should come here and discuss it here.

For the people interested in the actual fixes, we have a live github repo that clearly indicates all the fixes implemented with readily available code diffs. There regularly isn't a 1:1 bugzilla bug anymore because things are re-implemented, sometimes a different approach is used altogether, as well as those bugzilla bugs not being accessible to users to begin with, so they are completely pointless to list (since nobody can verify them without sec access).
Where CVE reports are available and known at the time of posting, they are listed in the release notes. Descriptions of sec bugs are kept concise on purpose, as to not paint a bullseye on related products.

Long-term validation of security fixes is not an issue. Fixing a sec bug routinely involves analyze-port-patch-verify. Once a sec fix is verified, that is the end of the process. Most sec patches are trivial in implementation, and unless you're going to touch the code afterwards (e.g. by refactoring the code section in question which would need a re-evaluation of what is done anyway) there is no need for elaborate post-fix testing.

Please also note that most sec fixes that are not in new code are usually only theoretical vulnerabilities (e.g. found through ASAN testing etc.) and do not have "real system" tests available since no known practical exploit exists.

[dr_st]

I would appreciate it if cross-posting of concerns between this forum and MozillaZine is kept to a minimum. If people at MozillaZine are genuinely interested in knowing more about Pale Moon and its process, they should come here and discuss it here.

And they think you should come and discuss it there. I too would prefer a single discussion, but with the current state of affairs it seems unlikely.

Nonetheless, I am not "the people at MozillaZine", and represent nobody but myself. If I ask something (even if it was raised by someone else somewhere else), it's only because it's interesting/important to me .

For the people interested in the actual fixes, we have a live github repo that clearly indicates all the fixes implemented with readily available code diffs. There regularly isn't a 1:1 bugzilla bug anymore because things are re-implemented, sometimes a different approach is used altogether, as well as those bugzilla bugs not being accessible to users to begin with, so they are completely pointless to list (since nobody can verify them without sec access).
Where CVE reports are available and known at the time of posting, they are listed in the release notes. Descriptions of sec bugs are kept concise on purpose, as to not paint a bullseye on related products.

I understand your point. A reasonable approach, I think, is that in cases where the bugfix/new feature is specifically a Firefox one and/or the change in PM is largely derived from the change in FF, the relevant FF bug number would be mentioned. Maybe something like "Based on Bugfix #xxx".

If it's a security issue, there would be no extra exposure, since the Bugzilla details will not be viewable by most people anyways. It is still informative, since in many cases people don't care about the actual code changes (or don't even understand them), but still want to know "Is this issue fixed? Has that feature been added?", and it generally easier to compare numbers than descriptions. And it will guard you from accusations of "taking credit for other people's work".

Please also note that most sec fixes that are not in new code are usually only theoretical vulnerabilities (e.g. found through ASAN testing etc.) and do not have "real system" tests available since no known practical exploit exists.

Good to know. So the verification procedure for such patches would be based on the same technique that originally found it, is that the case? Are these largely automatic or manual?

[Jonguy30]

Also, why are these guys so concerned about security issues? I mean how often are you going to be exploited during normal browsing? Why are they making such a big issue out of this?

[New Tobin Paradigm]

It is a straw that can be grasp. Same deal as not a true fork or can't ever succeed without big corp backing. That non-sense.\

As for bug numbers.. We are under no obligation to connect our development with that of Firefox or lead people from A to B to C. If you are interested in what has changed that is still described on the release notes and the repo has all the commits. Stop thinking of Pale Moon as anything else but its own thing.

Pale Moon is not Firefox and never will be again.

[dr_st]

Also, why are these guys so concerned about security issues? I mean how often are you going to be exploited during normal browsing? Why are they making such a big issue out of this?

Because security is a big deal in the minds of people. And it's probably good that it is. Most security issues may be minor, theoretical, exploits may not exist, or may require some extraordinarily dumb action to activate etc, but - the non-technical user does not know how to differentiate, and cannot be trusted to never make stupid mistakes (frankly, no one can). And sometimes it's enough to get hit once by a security hole to be completely compromised. Nobody wants that.

Even though personally I am not overly concerned about security, I assure you that "all these security concerns are minor issues" is a card you do not want to play. There may never be a single user who will ever be exploited even once while using Pale Moon, but if at any future date the PM team stops rigorously patching security, to the standard of the "big guns" in the browser business, or even just gives such an impression - this will spell doom for the browser there and then. People will steer clear, even if it's just to feel that they are being reasonable, and no matter how irrational their fears may be.

Weren't these security issues a key point in the recently issued notes about End of XP support in the main build, explaining why it is not recommended to stay with XP, and even less recommended to stay with PM 24.7.2?

As for bug numbers.. We are under no obligation to connect our development with that of Firefox or lead people from A to B to C. If you are interested in what has changed that is still described on the release notes and the repo has all the commits. Stop thinking of Pale Moon as anything else but its own thing.

Obligation is not the issue here. I understand the desire of forking away from Firefox, and making Pale Moon its own thing. Nobody expects Pale Moon to match 1:1 the development of Firefox. However, as long as you are still Mozilla-based, drawing from Firefox code, and as long as in some cases patches are still implemented as-is or almost as-is (and I know that this still happens), I don't think it's right to avoid disclosure of this, or to obfuscate this in any way. I see absolutely no advantage for the Pale Moon project to try to hide its ties to Firefox where they still exist. Perhaps there are valid reasons not to post direct Mozilla bug numbers in every applicable case, but please don't create an impression (intentionally or not) that Pale Moon is completely independent and original development, when it is obviously not the case.

[New Tobin Paradigm]

The Moment Pale Moon 24 was released was the last time (aside from uplifted sec updates during ESR24) that we wholesale brought in Mozilla code. Since that point the codebase has evolved in its own direction completely independent of Firefox's development (and the mozilla codebase broadly). Yes we have a HISTORICAL connection but as this past year progressed the divergence between what we have done and what Mozilla has done is become so great that most MozCo bugs/patches now essentially inspire or outline implementations in our codebase. That plus original code justifies the distinction.

Also know that Firefox != the mozilla codebase despite the marketing perceptions passing it off as such. The code in the codebase that makes the browser what it is instead of say an email client or chat client is surprisingly small but important. That is why i say, Pale Moon is not Firefox and never will be again. These distinctions must be made for complete understanding of what our codebase is.

[Moonchild]

And they think you should come and discuss it there.

I will not go to MozillaZine to discuss anything there, because I would be met with drama and outright hostility, because that is how they tick over there whenever anyone even remotely associated (or assumed associated) with Pale Moon posts anything. No thanks, I have better things to do with my time.

I see absolutely no advantage for the Pale Moon project to try to hide its ties to Firefox where they still exist.

Pale Moon is not trying to hide anything, nor hide its ties with Mozilla developed patches (see the Pale Moon repo where applicable patches that are ported as-is are properly credited to their original authors in the Mozilla community). Regardless, it's absolutely pointless to mention bug numbers when people cannot possibly verify the content of these bugs.

I don't think it's right to avoid disclosure of this, or to obfuscate this in any way. I see absolutely no advantage for the Pale Moon project to try to hide its ties to Firefox where they still exist. [...] please don't create an impression (intentionally or not) that Pale Moon is completely independent and original development, when it is obviously not the case.

Insinuating that there is deliberate obfuscation going on here is typical "pull something out of thin air to have an argument" assumption-based material and is something I take offense to. Please do not do this. I have no desire of being drawn into that kind of MozillaZine drama on my own forum.
As for independent development, you will have to understand that Pale Moon development is completely independent. Mozilla bugs and code patches are pretty much 100% incompatible with the Pale Moon code base. Of course it doesn't prevent us from using that code as a basis to create our own modifications (that is Open Source at work, right there!) and in some cases they can be really close to the original patches as applied to the Firefox or Mozilla Core code base, of course. That doesn't mean we are saying that "we did it all from scratch" because we didn't. Neither did MozCo, in many cases, for their own patches.
The same way, MozCo can use pale Moon specific code for their own projects, but I really doubt we will get credit for any of that or for what has inspired them to write code in a certain way or approach a problem in a certain way.

Obligation is not the issue here. [...] However, as long as you are still Mozilla-based, drawing from Firefox code, and as long as in some cases patches are still implemented as-is or almost as-is (and I know that this still happens), I don't think it's right to avoid disclosure of this

"Obligation is not the issue here" but in the same breath mentioning that I should feel obligated to provide disclosure of every change (with hard links to existing bugs even if they are only tangentially related to the work done for Pale Moon) in excruciating detail in release notes that are supposed to be accessible material for non-technical users?... yeah, about that.

if at any future date the PM team stops rigorously patching security, to the standard of the "big guns" in the browser business, or even just gives such an impression - this will spell doom for the browser there and then.

Why are you assuming that we would ever stop being rigorous about security? The fact that I tend to call things out as to what they really are does not mean they are not addressed. Even if called theoretical vulnerabilities doesn't mean that Pale Moon doesn't patch them where they apply to Pale Moon's code - All I'm saying is that people tend to blow things out of proportion whenever "security" is mentioned as a keyword. Not every potential vulnerability can be exploited, and as such not every potential vulnerability is given maximum priority just because it's a "sec"-flagged issue.

No, I think I'm about done with this thread, since I really do have bigger fish to fry than to satisfy the curiosity of people who aren't even willing to put in the effort to come here to discuss our product themselves, and assume we are going to enter a very hostile environment where serious and honest discussion is locked, deleted or ridiculed in a matter of minutes. No offense to the interest you personally have in this discussion but especially the last post had the strong flavor of MozillaZine "regular poster" assumptions and accusations.

[dr_st]

"Obligation is not the issue here" but in the same breath mentioning that I should feel obligated to provide disclosure of every change (with hard links to existing bugs even if they are only tangentially related to the work done for Pale Moon) in excruciating detail

I didn't say it, did I? Nowhere did I try to suggest to refer to Firefox changes which are only tangentially related. I think I used phrases like "largely derived" and "ported as is / almost as is". I do think it's proper to refer to the original change / credit the author in cases such as this. Proper, not obligatory (it is open source, after all, as you say, and everyone digging deep enough can find all the information he wants). That is all I meant. You say it's already being done in the Github, so OK - let's drop it.

Why are you assuming that we would ever stop being rigorous about security? The fact that I tend to call things out as to what they really are does not mean they are not addressed.

Why are you assuming that I assumed you would ever do such a thing? I merely answered Jonguy30's question and explained why in my opinion it would be a very bad idea, not that I thought you were going to do this.

I'll say it again - IMO too security issues are often blown out of proportion. But that's just how it is. If you ask people about the things that are important to them in a web browser, besides the fact that it should work at all, security will likely be right there at the top. Therefore I think that supporters of Pale Moon (or any other similar browser for that matter), if they wish their browser to be considered a serious alternative to the major players, should probably avoid steering discussion of security in the direction of "how important is it anyway?", lest they create an impression they are trying to cover up the fact that the browser is insecure, even if it's completely untrue. Perhaps it was too wild a tangent, and I did not properly explain it.

No, I think I'm about done with this thread, since I really do have bigger fish to fry than to satisfy the curiosity of people who aren't even willing to put in the effort to come here to discuss our product themselves, and assume we are going to enter a very hostile environment where serious and honest discussion is locked, deleted or ridiculed in a matter of minutes. No offense to the interest you personally have in this discussion but especially the last post had the strong flavor of MozillaZine "regular poster" assumptions and accusations.

I regret that it came across as accusative.

While I understand your position on MozillaZine, you surely know that the way you describe their community is exactly how they feel about yours, sometimes down to the same words you used. Someone like myself, who has just joined this "scene", and is not familiar with the rich history that undoubtedly exists has no way to know who's right, and even if one side is indeed more "right" than the other. What is true is that calm and open discussion between the communities seems impossible at this point.

My goal was to try to figure out the technical aspects (as much as a non-developer can), understand the claims made by the various parties, and figure out how I feel about those claims. And the only way to do this seemed to get involved in this cross-posting, and be caught in this cross-fire. Believe me, it's no fun. You just told me I came across as a MozillaZine regular poster, and over there I was called a Pale Moon fanboy.

But, I do feel now that I got the information I was looking for, and see no point in drawing this further. We all have other stuff to do, after all. Thanks for answering my questions.