Idea for a new browser product

[greystoke]

Joined forum to join in this thread!

I was hoping to get involved with some coding when I get a Mac again (Whenever the new MBP gets released), though skimming the forum the OSX codebase seems not to be the best place for me to start.

I've been happily running Palemoon for a couple of months. I'd switch fully if I could run the 1password plugin. I looked to switch as I'm increasingly unhappy with Mozilla's direction and choices. Reading about how they're doing away with their extension format to a more restrictive chrome-like format, and abandoning heavyweight themes pushed me to search for alternatives.

Palemoon is wonderfully stable, it's faster than current FF running similar extensions. It's Firefox before they started ruining it! I'm very happy to have discovered it, even though I'm temporarily on Windows

I can even run my favourite, long abandoned, theme!

...is to create a new browser product that will start with a clean slate.

New browser? One of the biggest draws, along with no australis, for Palemoon is that it's Firefox derived and you can run many Firefox plugins without all the junk and bad ideas Firefox started putting in. More inline.

Some of the rationale behind this:

Lack of community development

Despite our clear and open invitation for more people to get involved in both core development and extensions, the uptake has been (really) slow.

That's usual. You perhaps need banner ad style shouting for volunteers on the homepage and forum banner rather than gentle invitations somewhere in the hierarchy? Yes I know it's there, but unless someone is actively looking at getting involved, like I was, they'll not choose those menu options, and so not get to the github issues list. Is github the master list, or forums?

I learnt of this issue from HN today, not from a few visits a week to the palemoon site and forums over the last 2 months, messing around with scripts, themes and extensions, or reading about the state of OSX and Linux builds. I'd have hoped to have seen a "Please help, we're drowning" message once or twice. Or every time in 24pt.

If it hadn't been pinged to HN, I don't know if I'd ever have noticed. How many forum users perhaps could help but never go near /development and so don't know?

It sounds like the project is at a potential breaking point. I know I'm a bit wary of getting involved - I've not coded on OSX for ages, C++ for longer, and I remember trying to get involved with Firefox sometime during 1.x days. It was such a pain to build and an ugly codebase, that I gave up and went and did something a lot more straightforward.

I'm particularly wary as I've long forgotten production quality, security aware programming. I can refresh of course, but the hackers have advanced quite a bit too, so I don't know if I can be secure enough in a reasonable space of time.

Has anyone tried putting up a page of low hanging fruit, a list of languages or skills needed, or less technical areas that need some help? Issue triage, docs, or whatever? Prominent, unmissable link off the homepage?

A refresh of the homepage wouldn't go amiss "How to Get Involved, We need your help" wouldn't be a bad place to start.

I'm trying to be helpful, not telling you that you're doing it wrong. I realise I'm new around these parts, and I hope you won't take offence - none is meant. First message, and I'm in your house complaining about the colour scheme and furniture No, don't kick me out yet!

Missed the mark

... Unfortunately, that code was destroyed by Mozilla so a minor rebase isn't possible either to try and weave that code in (which would still be a huge task to accomplish - that a small handful of developers would not be able to easily tackle).

No chance of digging up a copy on some random mirror? There's been a lot of official and unofficial mirrors over the years.

Complications in the Mozilla code
... Mozilla code has become extremely heavily reliant on templates, classes, overloading, virtualization of functions and many, many stub and redirect functions to "pass the buck" to the correct module to process things in

Ah, I am remembering now why I gave up C++, and especially hate working on other people's new to OO C++. Overload all the things!

Should I have second thoughts about getting involved now, before it's too late?

Are you refactoring as you go?

...I know nothing about Windows coding, so I'll skip...

This re-forking would be done on the last stable version of Mozilla code that hasn't had a sledgehammer put to it yet and that offers the features and capabilities we as a project would still want (i.e.: Sync 1.1, XPCOM binary components in extensions, XUL, XBL, complete theme support, etc.).

This new browser fork would:

• Be using (a changed version of) Goanna.
• Be compatible with the current Web by far and large.
• Retain our UI.
• Not be able to directly load Firefox extensions, but be closely compatible, only requiring small changes in extensions to release them for it.

Extension compatibility seems to be a big selling point of switching to PM.

Given how many extension authors have abandoned FF, and how frequently they've had the goalposts moved needing them to update (not forgetting the 6 week release schedule causing regular attrition and abandonment), I'm not sure offering another branch to support is going to sell well.

Fact is I can use abandoned extensions and themes happily. I know a lot of what attracted me to Palemoon was reading about many people being able to use features, themes and plugins Firefox abandoned when they switched to Australis. It seems to be what people write about liking Palemoon, along with not being Google ChromeCopy Australis.

If it's trivial I can probably unpack and hack as I have for FF in the past. That's not a route for everyone of course.

I'm confused though. If you're forking a later version of Mozilla code, shouldn't it still be able to use Mozilla format extensions and themes, perhaps at a later version than you use currently? Can you refactor to get that extension compatibility back? What's the problem with themes and extensions in the version you plan to use?

Now, the real issue. What's happening with multiple years of security exploits and fixes? I assumed you've pulled in the various FF security fixes over the years? Won't you have to redo all those again, with another fork on different code?

I can't find mention of Palemoon security team - is there one?

This is an important consideration since XUL, bootstrap and SDK are being deprecated or already considered "legacy" (read: obsolete) by Mozilla and will be phased out completely. Instead of trying to remain compatible with a range of wildly different Firefox extension versions for a dying platform, it would make sense to evolve the extension ecosystem into something that would be specific to this new browser, with focused development on a stable and unique framework, removing all of the compatibility headaches we've seen recently as well as making things easy for extension developers to maintain their work for us.

You may not like it, but, that was still part of your selling point, and could become more of one. If Firefox release their chromealike new extensions, it's not yet known if things like noscript will stop working. That would be a deal breaker for many. It's not known how many extension developers will bother with yet more hassle from FF.

They've already announced the end of "heavyweight" themes. Which I expect when it drops will cause more FF users to search alternatives. Will theme format or compatibility be impacted in the new fork?

Nuking all their plugin ecosystem could push many new users your way if you get a little visibility! There's been quite a bit of unhappiness in the various Moz forums at many of these changes.

If Firefox abandons their old historic plugin format, what's wrong with it becoming yours by default?

If you're making a deliberate choice to diverge, what chance getting semi-commercial plugins like 1password and such involved?

[*]Possibly offer WebRTC as an option if there is enough demand for it. If so, this will still remain low-key and not heavily maintained.[/list]

Plugin if it must exist please. It opens up attack surface that many won't want.

I hope you find a way to encourage more to get involved, and go prod some of the old mozilla and firefox forums to get some of the old theme and extension authors interested.

I guess I should go skim the rest of the dev forum...

[gpower2]

I've been using Palemoon for over 2 years now and I am really happy with the decisions the developers have made this far. Good job guys!

However, I am a bit confused with this thread, and let me explain why. With Palemoon v26.x and the new Goanna engine, I thought that Palemoon was becoming a new self-sustained project, without having to rely on Firefox code anymore. Of course it is understandable that since most of the code base is Firefox's, it would be unavoidable to completely be Firefox independent, but I thought that this would only apply to bug fixes in the old Firefox code, or perhaps features that are based directly on that. It seems that this is not the case, since this thread suggests that Palemoon cannot implement new browser features without Firefox implementing them first.

My suggestion would be to make a comprehensive guide of the Palemoon code so far, and discuss the inner architecture of it, in order to establish a new roadmap for Palemoon and finally be independent from Firefox and Mozilla. For example, Mozilla is experimenting with e10s, Servo and possibly other roads to follow. I believe that Palemoon is mature enough to follow its own experimental roads. Break down the code layers and tiers that make up Palemoon, and start discussing about the current architecture, its advantages and flaws, and make decisions for the future. It's my personal belief that rebasing from a newer Firefox branch would add a LOT of new bugs and incompatibilities with current Palemoon codebase, making it really hard and time consuming to mold all these into a working, stable merged codebase.

I think that most developers are discouraged from entering Palemoon code, because they don't know where to begin with. But if there was a code guide of where to look for each feature, I think that it would make things simpler and more enticing for new developers to play with and commit to the Palemoon codebase.

So, to recap my above incoherent thoughts, my suggestions are:

• Palemoon should stop relying on Firefox codebase for new web features and support
• Palemoon should have a codebase guide, in order for a new developer to be able to easily and quickly get familiar with the code parts he wants and needs to
• Palemoon should start designing its own inner architecture by learning from mistakes of the past, both its own and Firefox

As for the code tracker that was mentioned in previous posts, I totally support GitHub, since its issue tracker is quite flexible and powerful, while being simple at the same time. No need for the ancient and overrated bugzilla tracker.

Finally, I will totally support whatever decisions you make, since I respect all your hard work for providing us with a great browser, and also because I have come to respect your coding skills and knowledge. I just wanted to put my 2 cents.

[Moonchild]

However, I am a bit confused with this thread, and let me explain why. With Palemoon v26.x and the new Goanna engine, I thought that Palemoon was becoming a new self-sustained project, without having to rely on Firefox code anymore. Of course it is understandable that since most of the code base is Firefox's, it would be unavoidable to completely be Firefox independent, but I thought that this would only apply to bug fixes in the old Firefox code, or perhaps features that are based directly on that. It seems that this is not the case, since this thread suggests that Palemoon cannot implement new browser features without Firefox implementing them first.

Just a quick reply on this point, to help with the confusion:

We are completely independent, but you have to understand that the Mozilla code base is a tightly-knotted behemoth. So while our future is independent, and we can implement new features without relying on Firefox code for the same, our legacy of code and what we build on is not. That also includes technologies deep in the core that are rather inflexible and in some respects implemented just plain wrong to be used as a base for evolving code. The actual complexity of our code is directly tied to what Mozilla has put in in the past, and if new features build on existing features or frameworks, then it's not that simple. Mozilla's code is not clearly segregated or modularized; features are very heavily intertwined.

[gpower2]

We are completely independent, but you have to understand that the Mozilla code base is a tightly-knotted behemoth. So while our future is independent, and we can implement new features without relying on Firefox code for the same, our legacy of code and what we build on is not. That also includes technologies deep in the core that are rather inflexible and in some respects implemented just plain wrong to be used as a base for evolving code. The actual complexity of our code is directly tied to what Mozilla has put in in the past, and if new features build on existing features or frameworks, then it's not that simple. Mozilla's code is not clearly segregated or modularized; features are very heavily intertwined.

I totally understand that, I just think that the effort should be put in trying to un-interwine these features, in order to make the code more flexible and easier to sustain and evolve, and not in continuing this obsolete architecture. Of course, if you believe that rebasing to a newer version would make this procedure easier (considering that this newer version have solved some of these problems), then by all means you should do that ASAP.

[dark_moon]

gHacks make a news about this topic here: http://www.ghacks.net/2016/03/16/the-fu ... pale-moon/

[Moonchild]

gHacks make a news about this topic here: http://www.ghacks.net/2016/03/16/the-fu ... pale-moon/

We know. see earlier in this thread.

[dark_moon]

Oh sorry. My mistake

[CharmCityCrab]

But you are trying to do the impossible. You don't have the manpower and funds to replace mainstream browsers. Let me give you a comparison. I like Linux, but I still boot into Windows from time to time. It's because there aren't enough manpower and funds and third party support behind Linux to completely replace Windows.

Let ordinary people use Chrome, Firefox. IE, Edge or whatever shite the big corporations put out.

Target geeks that understand Pale Moon and what it is about. Money doesn't seem to be your biggest problem. Kick back, relax, offer yourself some slack.

[...]If something breaks in Pale Moon (in the future) I will just fire up Firefox. It's faster than booting into Windows. Just like Linux can't replace Windows, Pale Moon can't replace corporate browsers. Don't target mainstream “dumb” users. Develop Pale Moon because you love it, not because you need to implement new technologies.

I have to respectfully, but strongly disagree, with this suggested approach. For the most part, I want one browser. I think that is how most people feel. That I already occasionally need to use something else for some things, and a third thing for a specific message forum, is already an imposition. I tolerate it because of how much I love Pale Moon's interface and features and mission, and because I know to a large degree these incompatibilities are not Pale Moon's fault, but the fault of the website owners and poor practices on the part of the major browsers creating a difficult environment.

However, tolerating it occasionally because I realize it's not the browser's fault is very different from if the browser deliberately were to decide to take the tact that it didn't want to remain compatible with a large percentage of the modern web, and essentially became designed with the assumption that people would use another browser for a large minority, or even majority of their web surfing.

Your example of how you take a similar approach of splitting time between Linux and Windows actually is one of the reasons I use Windows instead of Linux, and in my view why Linux is still at under a 1% marketshare on PCs. I don't want to be rebooting my PC every time I want to run a different application, and not to be able to run them simultaneously. I also don't want to be booting different browsers to visit different pages and not be able to have one set of histories and features and ways of navigating around. I think this is a majority view.

If Pale Moon decides that is it's desired approach, it truly will be limiting itself to techies.

A browser's aim should be to be compatible with the entire web to the best of it's ability and to be the only browser people who use it need.

If I were to find that I needed to use some other browser to do like 40% of what I do on the web, and Pale Moon had no intention of trying to make itself more compatible with more sites, I would drop Pale Moon and adopt some other browser I could use for everything, and just focus my time on adopting the right settings and add-ons or whatever to make that as close as I could to my preferences rather than split my time between two browsers.

[CharmCityCrab]

Just to follow on to my post from moments ago, if it comes down to a realization on the part of the developers that we absolutely need to do what was proposed in the original post to keep compatibility and increase compatibility with the modern web, then I am in favor of it.

If that's the bottom line, let's do it.

Greater compatibility is a good thing, as long as we preserve the same interface and options and the same themes and the same core extensions (Forks or things that offer the same things in a different way under the hood are fine as long as the functionality is the same) and options.

Heck, I said I'd be in favor of going over to building the browser around Webkit, so obviously I'm flexible on the technology under the hood!

The caveats are essentially just that I don't know if it's as simple as one choice would definitely make us more compatible with the web and the other wouldn't. I also worry about perception if we have to sort of merge in more Mozilla stuff again, and what that suggests about our ability to continue to adapt in the future when Mozilla is further away from us or gone.

But if it comes down to this is the only way to fix the incompatibilities that I am encountering more and more, and future incompatibilities, with websites, then I say do it.

I want Pale Moon to be able to do what the major browsers do and be able to visit the sites I choose and have them work to the greatest degree possible.

[Moonchild]

I also worry about perception if we have to sort of merge in more Mozilla stuff again, and what that suggests about our ability to continue to adapt in the future when Mozilla is further away from us or gone.

As I stated before, this would be a one last time re-base; similar to what we've done before with 12, 15, 20 and 24, just more work, and talking about months instead of weeks of work to make it happen, but essentially not very different. Mozilla has started taking a sledgehammer approach in the most recent versions because they either can't or don't want to keep their beloved Gecko in good health. Or both.
It's pretty much a given that Mozilla is in decline. Regardless if their plans with Servo pan out or not, further adoption of the most recent code from Mozilla is not an option and if they dump gecko completely, then there's obviously no common ground

I think the real question here is: what is more important; web compatibility or extension compatibility? A no-brainer for me, really. A fully-tooled-out browser is irrelevant if it fails at its core task. So either the core task has to be brought up to speed with your help on the current code base, or we have to get the essential web technologies of today another way.

EDIT: and before you scream "You're killing extensions like Mozilla", please take a few moments to gather your thoughts about what has been said before in this thread. Compatibility fixes would likely be small for the new product. The most-used extensions would be taken care of by us and whomever wants to step up to help; the rest will be up to the community as a whole to look at and work on. Even if you're "not a coder" you can still read, learn, and tinker until it works

[CharmCityCrab]

I think the real question here is: what is more important; web compatibility or extension compatibility? A no-brainer for me, really. A fully-tooled-out browser is irrelevant if it fails at its core task. So either the core task has to be brought up to speed with your help on the current code base, or we have to get the essential web technologies of today another way.

Web compatibility is more important to me. In the end, Pale Moon is a web browser. It's task is to browse the web. If it isn't compatible with web sites, it's not fulfilling it's primary and most basic task. So that is where I would prefer the emphasis to be- web compatibility.

As long as the UI is maintained and the type of customizations, options, and theming I use to get the UI I want are still there or are available some other way, and there's an ad-blocker of some sort, I'm good (Please don't adopt Firefox's "backarrow welded to the location bar". That is, hilariously, my biggest concern about this move at this point. It ruins my preferred "less obnoxious version of a 1998 browser" look. ).

I'll be honest, I've got all these other extensions, but I think I can live without them. I had to send in my Android phone for repairs, and am using a temp phone, and when setting things up for Firefox for Android (Wherein I found that for some reason Firefox sync wasn't working properly, leaving me with a blank browser), I just installed UBlock Origin, subscribed to all their filter lists for various things that seemed useful (Essentially for all the ads, privacy, and tracking stuff; apart from the local filter lists for sites in languages I don't speak), and called it a day. I'm not really missing there other ones, though when my regular phone gets fixed, I will probably reinstall some of them just because they're there and they help my web experience a little.

I don't know if I'm a typical user or not in that regard.

Web compatibility and the ability to get the UI the way I want it and block the content I don't want on the web, plus good security, speed, features, and it's a good experience for me.

I think you expressed that very well in the post I'm replying to. I didn't quote it all, but that was the clearest explanation I've heard.

Sounds like you guys should go ahead and do this if no one steps forward and volunteers to get the current code up to where it needs to be for the best possible web compatibility.

Attached is what my UI looks like, a customization of the Past Modern Revisited theme, using various options and one about:config thing to mold that into exactly what I like. Other people's taste and needs may vary.

[Jigsy]

There will be plenty of opportunity and time for extension developers to add Pale Moon specific compatibility if we go this route.

There's a part of me going "Why would they?"

That said, I only use one add-on (which I really need) which allows me to refresh tabs automatically at different specified intervals; something Opera had... until they removed it.

[Moonchild]

There will be plenty of opportunity and time for extension developers to add Pale Moon specific compatibility if we go this route.

There's a part of me going "Why would they?"

The same reasons why we have seen a growing number of users?
And why wouldn't they, unless they want to be 100% exclusive to Mozilla Firefox (which will see their extension unsupported soon enough anyway...)?

[sugis]

Throwing in my 2¢, as a medium-time user and fairly new contributor.
The path to first contribution was a relatively long and arduous one, compared to most other OSS projects I've contributed to. There is a *lot* that you need to understand to get even barely off the ground -- understanding the ESR24 MXR site, exactly which pieces of mozconfig you should / shouldn't have, verifying that any particular change which may fix a problem in one place doesn't break something else (normally something covered by automated testing), and a very particular and touchy build system. (It is entirely possible that since my first project was working on fixing the Mac build, I was overexposed to the peculiarities of the build system and this is not a normal experience. Just trying to relate mine.)

Moonchild and the other developers were all very patient and helpful getting me up to speed. But it was still frustrating to have to assemble various bits of documentation both about Pale Moon and the old Firefox releases, and sift through which do and don't apply to the current codebase (there's tons of information about both Firefox ESR24 and Pale Moon <= 25 for which it's unclear if it is still accurate), just even to get your first local build built.

I am not trying to blame anyone, you guys clearly run development in a way that works for the developers, but maybe some time spent sprucing up a "Your First Week as a Pale Moon 26 Contributor" document, and keeping it actively maintained, could reduce the barrier to attracting new contributors. Some more infrastructure could help too, e.g. a Jenkins which validates each proposed change does not break the various builds (debug vs nondebug, Windows vs Linux vs Mac, etc) -- although I totally get that that costs both time and money that the project may not have today.


From the user side, I personally feel that one of Pale Moon's core differentiating features is that it is *not* Firefox or Chrome -- and if it ends up just being a poor Chrome clone like Firefox aspires to be, you'll lose your core userbase. So let's not let that happen That said, if a significant amount of time is being spent porting extensions -- maybe the solution there is to stop the bleeding, and stop porting extensions / themes with core resources. Focus on making Pale Moon extensions something independently valuable and encouraging external developers to get on board.

[New Tobin Paradigm]

From the user side, I personally feel that one of Pale Moon's core differentiating features is that it is *not* Firefox or Chrome -- and if it ends up just being a poor Chrome clone like Firefox aspires to be, you'll lose your core userbase. So let's not let that happen

Again, why would anyone even think this would remotely be something that would happen in any reality. Do people seriously think any of us would let that fly? Consider what has already been said and anyone please point out the parts where this was actually stated directly or implied. Because if one believes there is even one chance in hell of that being the outcome of anything.. Then.. Really.. I dunno.

That said, if a significant amount of time is being spent porting extensions -- maybe the solution there is to stop the bleeding, and stop porting extensions / themes with core resources. Focus on making Pale Moon extensions something independently valuable and encouraging external developers to get on board.

As the Administrator of the Pale Moon Add-ons Site and Team Leader of the Add-ons Team.. There is still a responsibility, I feel, to kickstart with a handful of core extensions that many consider absolutely necessary. But you are quite correct, as I have stated, that our focus is on a service platform to provide the foundation of where to get extensions and enable those making them to share them. This is our job and our focus. But not gonna keep everyone hanging.

I constantly hear the phrase "I don't know how to code but xxx". While those people mean well.. It must be pointed out that no one is born knowing how to code. Do you think all those years ago when browser extensions were a new thing that anyone knew how to code them? No they learned and given the lack of documentation back in those days they did so rather blindly. We have so many advantages today that were not around then. It is easier than ever to get that knowledge. Now I will concede that not everyone is gonna be a master coder. Quite frankly, I am not a master coder. I have coded and continue to learn more. Until I joined this project I didn't have much of a reason to put any of that knowledge into practical use. Over time I have gotten better and learned more.

So when people use a similar phrase.. My default response is.. Learn. Please learn. Just tinker about, figure things out, get a feel for it then use that to help everyone else. This is what I did. Has it and does it continue to be a challenge? Oh of course it does but I also learned that it is part of the fun. Being a pure consumer can be ok but I wanted something more. I wanted to help contribute and support the future (maybe even drive the future a tiny bit) so I learned and continue to learn. On a personal level this project has done much for me and I quite frankly want to continue doing much for it.

So I shall continue, we shall continue, all of us. Will you join us?

[lyceus]

I am sorry for being silent for a long time, as some personal stuff made be away from the PC for whole weeks.

I just say that the topic caught me by surprise via Slashdot, I expected that the troubles in the coding area were in a level that could be fixable. Since I welcome the idea of a reboot of Pale Moon, I must point the main idea that was expressed in slashdot that is actually useful: Which version of Firefox ESR is the one that will be used for the reboot? and this will enough for not need a reboot in the near future?

I fear that the web in the long run will become a collection of mini apps and from my experience in support, people just want their "MTV of the 2010s: Netflix/You Tube", the Google services, Facebook and some social media page working smooth and the rest is forgettable. The main glut in support questions comes from small websites, that (mis)implement the HTML5 features as coders usually stretch the boundaries of the specification, poking features that seem to work in some specific browser.

Whit all this I want to suggest to give a try to some alternatives in engines in parallel to refork a newer version of Firefox. Maybe this can be done using a small example like the minibrowser project that is somewhere buried in the forum, which just render simple pages. This would be a small and effective sample to see which path is the best for the future Pale Moon, instead to try to made a full browser implementation from zero.

As for coding help dept, I used to get some courses in Java at the university and I tried to chew C+ but I am really too rusty, as the last time I used eclipse SDK was in 2007. So really is difficult for me to help in this area, but if you need help in other areas please tell us.

[Al6bus]

It might be worth parallelly to do rebuilds (add our features and bug fixes) of latest firefox versions for ordinary users?? little effort @ simply works

[Moonchild]

I expected that the troubles in the coding area were in a level that could be fixable.

It is fixable, but we need more help to be able to do this. I've given this a lot of thought before offering up the idea, evaluating what we have, what we missed, what the web is using and evolving into, what are essential technologies and what is future-proof for at least the foreseeable future as regards the web. The roadblocks we are looking at are pretty big, and are caused by the very rapid (and breaking) changes that occurred in web technologies in 2014 (which have considerably slowed down since). Not impossible, but of a magnitude that re-basing is a more likely viable alternative than trying to push through as we are now, considering the number of people actively involved at this time.

It's a balancing act: people, resources, web requirements, development speed, compatibility, etc. etc.

Which version of Firefox ESR is the one that will be used for the reboot? and this will enough for not need a reboot in the near future?

I'm looking at ESR38 for this as a rough base. It still provides all necessary desired tools without leaning too heavy on going towards things like DRM and removal of essentials.
It will be enough. It will HAVE to be enough, because another reboot will simply not be possible after this without losing our essence.
So if we rebase, we'll have to be on the ball for keeping up with actually required web technologies. There is an essential difference though, in that our community is larger and more active, and we have a lot more knowledge of the inner workings of the Mozilla code to make the right calls than we did 2 years ago.

from my experience in support, people just want their "MTV of the 2010s: Netflix/You Tube", the Google services, Facebook and some social media page working smooth and the rest is forgettable.

If people just want a few services, then they should use specific clients for those services that are targeted specifically by those services. Pale Moon is obviously not a good match for those people, since a generic application will never be specialized 100%.

It might be worth parallelly to do rebuilds (add our features and bug fixes) of latest firefox versions for ordinary users?? little effort @ simply works

"ordinary users"? You think Pale Moon users are somehow "special"?
Our features are our own, building on our code. You can't just slap those onto other browsers So it's not "little effort", nor would be publishing another completely different product in parallel.

[Moonraker]

One of the fundamental reasons i like to use pale moon is that it sticks to the original concept of what a browser is and that is to simply navigate from one website to another.
However the corporate "3" have decided to try and cram as much stuff into their browsers as possible.
Media player.
App player

i could go on but i think we can see where those browsers are heading..In fact the term "browser" would become obsolete and operating system would be a far more fitting adjective in the future.

[Andrew Gilbertson]

I am not trying to blame anyone, you guys clearly run development in a way that works for the developers, but maybe some time spent sprucing up a "Your First Week as a Pale Moon 26 Contributor" document, and keeping it actively maintained, could reduce the barrier to attracting new contributors.

This, times several hundred thousand. Possibly a couple of million.

The fact of the matter is that the browser is a HUGE project. Even adding some "this is where we *think* the problem lies, you might want to start by setting some breakpoints in this area" to some of the issues would probably be helpful.

Some more infrastructure could help too, e.g. a Jenkins which validates each proposed change does not break the various builds (debug vs nondebug, Windows vs Linux vs Mac, etc) -- although I totally get that that costs both time and money that the project may not have today.

Although a good idea, I suspect that maintaining and administrating a Jenkins instance is enough additional overhead that until there are several more developers who are up to speed on the browser's codebase, it's a non-starter. Once there's a sufficient number of developers contributing, then perhaps Jenkins or some other continuous integration tool should be (re)considered.