Idea for a new browser product

[Moonchild]

Switching to Webkit/Blink is a no-go. It would remove any and all options for us to have extensions at all, won't allow customization, would just be passively flowing with the tide of whatever direction Google goes in, doesn't provide a compelling reason as to why people should choose Pale Moon to begin with (which was one of the original questions put up). Aside from that, Blink is terrible in some respects, and one of the main things I fond way too jarring just looking at the visual presentation is that it is not a smooth scrolling engine, and I doubt it can be made into one. Add to that the constant stability issues and memory hunger, and it becomes less and less of a choice. Even so, adisib made an essential point about monoculture, too.

Switching to Servo is similarly undesirable. Why would we want to switch to an engine written in a company-constructed language that isn't complete? Can we even be our own entity then? Nope. We'd just be forced to follow Mozilla step for step because they hold all the keys and controls.

Any sort of engine switching would inherently lead to the loss of our customization, because we are using that very engine to construct our interface.

And yes, we'd have to rip out Telemetry again, and re-do a number of other things; this won't be an overnight product, and it'll have to be done thoroughly. e10s is partially in our code base already - it's been a slow, ongoing thing for I think close to a decade. We don't have to rip it out, but we can easily choose to simply not use it. Removal of dead code can be done at leisure over time, "whenever we run into it". So, that's something we can put on the back-burner and won't be a blocker for making this happen.

[New Tobin Paradigm]

You guys are continuing to get hung up on trivialities and misconceptions. What we want is what we already have and the more complete ES6 and HTML5 and CSS. Yes there would be some duplication of past work like ripping out Telemetry, Crash Reporter, and Maintenance Service without the huge refactoring barrier for sourcing newer code while remaining stable. As for duplication it won't be so bad because we know where to do that so there isn't as much research required because we have done it before.

People mention Australis.. Is there Australis (beyond surface style) in current Thunderbird? No. Is there Australis in SeaMonkey? No. Why? Because as I already explained their application specific code never had it and that application specific code is what, on top of the platform, is what makes it specifically what they are. This would be true for this theoretical new product. It would not be forking Firefox (code in /browser) no that would be ditched. We would rip our /browser code and make it run to provide our pure front end.

Webkit/Blink nor Servo is gonna be a thing.. There is no point.. Servo.. same thing...

So it looks like I should simplify this down for you since some are missing the point of the more wordy and accurate post Moonchild made.

TL;DR: We are running into roadblocks in our current code tree. Ones that could be overcome with more community contributions. We want a contingency for the future should the community continue to be minimally contributive to offer what users want. We also want everything we have being XUL, XBL, XPCOM, Theming, all the technologies we currently employ. It would be a new product to shed expectations and perceptions of a product that most assume is .. never mind the fact that it is wrong.. that most assume is outdated Firefox with poor standards support. We want to focus on providing the tools not doing everything for everyone in regards of extensions (going to happen either way from here on). What we would PREFER is for everyone to come together and help out with something we already have but if that isn't going to happen we need something to fall back on. This is still an idea, a concept, a theory of how to do that.

[snertev]

I've followed the discussion of the Seamonkey's devs about the future of the suite on their IRC channel, included Kairo's flame with Tobin (well, it was impossible not to read it in a public channel ) and they have suggested to base the new SM on FF 45 ESR (or something so) and then develop the suite from that point.

If the current proposal of Moonchild is something similar, by stripping everything undesired off, go ahead and do it as fast as possible.

In fact, there will be a very short time in which the unsatisfied FF user base will search for a modern sane Mozilla browser, before giving in to Google Chrome or a Chromium derivative one.

And I'd add that, whenever technically possible, you should include EME, WebRTC and so on, at least as user's options. I'm old enough to remember when many Linux distros were utilizing (and many are still utilizing) proprietary GIF, MP3, video codecs and much more downloaded from some external server, just to give to the user what he neeeds.

[New Tobin Paradigm]

KaiRo's solution is to do a Classic Theme Restorer type of deal on top of Firefox specific Application Code ala Cyberfox.. This is NOT at all what we are purposing here.. I really wish people would read and comprehend this fact. Also.. EME is never going to happen. It can't and won't for anyone not Mozilla, Google, or Microsoft (you could include Opera and Apple but why bother).

EDIT:
SO... We take a later codebase.. We Delete the browser folder.. Which contains everything when compiled into FIREFOX makes it FIREFOX.. We take our codebase we copy the browser folder and we paste it in the new tree.. We fix compile errors and any scripting syntax errors and THUS we have a new product. YES.. This process is exceptionally more complex and there is much more to do in the platform code than I am making it out to be but we have to start somewhere so you can get a grasp on what would be done at its MOST BASIC.

KaiRo's solution for SeaMonkey is just have it be Firefox so everything in browser is the same and just bundle one massive or several smaller extensions that in effect do a similar job as CTR. This is a BAD solution..

[snertev]

KaiRo's solution is to do a Classic Theme Restorer type of deal on top of Firefox specific Application Code ala Cyberfox.. This is NOT at all what we are purposing here.. I really wish people would read and comprehend this fact. Also.. EME is never going to happen. It can't and won't for anyone not Mozilla, Google, or Microsoft (you could include Opera and Apple but why bother).

Uhm, I see.

However, featurewise, the "new" browser may not be worth the effort.

Moonchild said it would "Be compatible with the current Web by far and large." and, IMO, the key word in his statement is "current". Just as an example, let's say the re-based Pale Moon browser will be ready in 6-12 months. In the meanwhile, the web will evolve, with new standards emerging and older ones declining.

It would be a fight against obsolescence, by using a browser base already 6-12 or even more months older when the first "stable" release of the new browser will be ready, although a lot less old than the current FF-24 ancestor.

Don't get me wrong,I really appreciate Pale Moon as a software and as a (kind) community. Nevertheless, I see a lot of "wasted" work hours (please note the quotation marks) in such a project. What will it happen when, within 6-12 or more months, there will be the next "web great thing" (ES8?) that should be included in the new Pale Moon browser?

I've contributed as a marketer/evangelist/project manager to Open Source/Free Software projects larger than Mozilla since 2000, in which huge multinational corporations (Sun, Oracle, IBM) were involved, and I perfectly know how many hours every year a volunteer must contribute to be really effective.

TL:DR: a re-based Pale Moon is a good short term solution, but it may not be worth the effort in the long term, since obsolescence is just around the corner, without enough manpower.

P.S. I would surely support such a fight against obsolescence of a genuine Gecko/Goanna browser. It would be surely a hard challenge, but a fascinating one too.

[eskaton]

If the talent pool for developers doesn't exist here within the forum (and it must not since you've asked for help multiple times), is there a way to appeal to developers outside our bubble?

[New Tobin Paradigm]

What will happen in 6-12 months if we do nothing. Another goal with this theoretical new project would be to more closely align with the massive amount of documentation Mozilla has already wrote and we have a snapshot of. Which means less work would be needed to get people started. Those who are already getting pushed out of Mozilla development would be far more familiar with the new product target than Pale Moon's current codebase. That could lessen the barrier for people who are vaguely familiar with the internals of the codebase. Also, new developments in the web are being built on top of what we missed the mark on. So that fight against obsolescence is one we have always been apart of.. So nothing new there except with this it wouldn't be such a guerrilla fight with the codebase more of a strategic style where we go in do and accomplish what we need to do and continue on if you want to put it in those terms.

So it is more possible to do the things we do already but without many of those barriers without sacrificing customisablity and extensibility or UI. All with the knowledge we have now of both the successes and the pitfalls we have had and that we learned from.

Yes, when we continued on the codebase we have it was uber stable which is one of the most important things but it was also in a major transitional state code wise in conventions and style. We have also made our own major modifications that made things better on our current codebase without the experience we have now.. I tend to believe that the end result of this theoretical concept would be not only as good as what we have now but far superior because of what we have learned and you would get something better. It would have to be.. or else we wouldn't be considering it.

[trava90]

I think most everything has been covered by Moonchild's and Tobin's excellent posts, but I will add the following:

One common misconception is that you "have to be a programmer" to contribute to Open Source. You don't - but you must be willing to learn how stuff works, ask pointed questions, and spend time tinkering and using trial-and-error to figure out how it works if there are no ready answers.

As Moonchild stated, you must be willing to learn. For myself, I knew absolutely zero about programming, Mozilla code, etc. when I first started providing the Linux builds. But by jumping in and reading resources online, tinkering with the code, and using trial-and-error I have learned a lot since then. Also, if you'd like to jump in and help don't be afraid to ask questions! Moonchild has has always been willing to stop and take a look at what I'm working on and offer assistance and suggestions whenever I've had questions regarding anything.

I tend to believe that the end result of this theoretical concept would be not only as good as what we have now but far superior because of what we have learned and you would get something better. It would have to be.. or else we wouldn't be considering it.

I agree with this statement 110%. While it would take a lot of work to bring this to fruition, and we would have to do some "double work" (such as removing telemetry, crash reporter, etc. again), all that time spent would be offset by the fact that it would be in many ways easier (and therefore take less time) to port code to our code base.

[LmaoZedong]

What about switching to Blink engine? It seems customization is a possibility, Vivaldi and some other browsers have proved that, but is not as extensive as Gecko´s one.

Is Servo done?

[trava90]

@LmaoZedong,

See Moonchild's post above.

[New Tobin Paradigm]

Allow me to further clarify .. ONE AGAIN.. Our future and whatever path we take is going to still have specific requirements and parameters. It is gonna be a mozilla-like codebase.. It is gonna have a gecko-like rendering engine (Goanna) it will have XUL, XBL, all the technologies everyone wants and needs. What this will not be is a trident shell, a webkit shell, a blink shell, or whatever servo is gonna be.. No, does not and would not support all the bits of technology to be a product we and you could use and be proud of. If you think this is gonna happen.. Just stop because it isn't going to ever be that. So get that out of your heads.

NOW.. The discussion can continue about this STILL theoretical concept that we MAY pursue in the future.

[freefrog]

Switching to Servo is similarly undesirable. Why would we want to switch to an engine written in a company-constructed language that isn't complete? Can we even be our own entity then? Nope. We'd just be forced to follow Mozilla step for step because they hold all the keys and controls.

Obviously, we wouldn't switch before it's complete. We'd spend the time now to implement XPCOM/XUL/XBL so we don't lose customization. As far as "keys and controls" how does Gecko differ? Both are open source and maintained by Mozilla...

You guys are continuing to get hung up on trivialities and misconceptions.

What you're seeing is people uncomfortable with two proposed options, both requiring a lot of work, and neither of which (ostensibly) address the long term sustainability of the project. They also see the futility of calling for new help in a project's own forum.

snertev is exactly right:

TL:DR: a re-based Pale Moon is a good short term solution, but it may not be worth the effort in the long term, since obsolescence is just around the corner, without enough manpower.

Why don't the leaders comment on which option (to re-base or not) is most sustainable given our situation:

• There's no reason to expect the level of community involvement to increase
• We are heavily dependent on ported code to stay current

The following appears to be true:

• the further we diverge from Mozilla's code the more manpower we require to port from them
• re-basing maximizes code convergence and minimizes the necessary manpower
• the only option to move forward without new manpower is to re-base
• little effort is being made to acquire new manpower.

Isn't it obvious, then, that re-basing is the only option that keeps Pale Moon (or "new product") current as long as possible?

[palenew]

This may or may not interest the dev team. Just thought i'd leave it here.

https://www.phoronix.com/scan.php?page= ... er-Engines
https://kver.wordpress.com/2015/07/02/f ... onclusion/

Maybe you can work on the same browser? maybe you can make another one taking into consideration the things kde fiber was/is trying to do currently.

[win7-7]

Rebasing to later Mozilla code can bring some benefits ( ES6, HTML5, javascript performance improvements etc.) but I have some questions:

Will customizability be exactly same as currently?

Will stability be as good as it is currently?

large amount/ many of add-ons should still work after this?

Will Add-on SDK have current Pale Moon Add-on SDK API's in addition of newer Mozilla API's from newer base? So nothing will be lost and most of currently functioning Add-on SDK add-ons will continue to function in addition of some newer add-ons that depend on newer API's to work?

[squarefractal]

I don't really understand the negativity expressed here by some of the community members.

Obviously, we wouldn't switch before it's complete. We'd spend the time now to implement XPCOM/XUL/XBL so we don't lose customization.

You have to understand that implementing XUL, XBL and XPCOM in Servo would be even more of a mammoth task than the current issues.

I see a lot of "wasted" work hours (please note the quotation marks) in such a project. What will it happen when, within 6-12 or more months, there will be the next "web great thing" (ES8?) that should be included in the new Pale Moon browser?

Well, web standards are not the only factor for the rebasing -- support for newer OSes and libraries are something that will benefit the Pale Moon codebase, apart from web compatibility. In addition, as has been stated multiple times by Moonchild, Travis and Tobin, it'll help reduce the effort required for porting patches.

Will customizability be exactly same as currently?
Will stability be as good as it is currently?

The rebasing effort does not mean that customisability and stability are on the chopping block.

[New Tobin Paradigm]

I think something else is being lost here.. The mere fact that HAD ESR31 been stable.. we very well might have gone down that road (I was specifically prepped for that) and we would have just been doing this two years ago. Something else that is being lost here though I have mentioned several times and Moonchild has a few.. We know so much more now than we did two years ago especially about taking our own initiatives and going our own way. We know the codebase and build system better and we know where everything is. The amount of development from the last jump to ESR24 (for Pale Moon 24) until now is wholly and completely unpredicted and kind of unreal looking back not only in this project but of ANY mozilla-style, mozilla-forked, mozilla-rebuilt project on the face of this planet second only to Mozilla its self.

Waterfox is a str8 up x64 rebuild of Firefox. Cyberfox is less of a fork than Pale Moon was on its first day. What else.. pxefirefox or something.. Another rebuild. Tenfourfox and classiczilla.. They only made it build for ancient Mac OS systems but not any real development there... The list goes on... We are in such a different class even when we were just a minor rebuild with some reverts and extras tacked on (Pale Moon 4-20 era). Why would you expect anything different than what we have given all of you already.

So yeah.. We already told you.. Pale Moon will stay Pale Moon nothing is changing here.. This whole thing is for a new project idea to move forward on. If you simply thought.. Yeah, we are gonna rebase and call it Pale Moon and leave everyone high and dry.. That isn't the case here.. But what we want to do.. Is go forward ONE WAY or ANOTHER.. This is the "ANOTHER". You can make it not necessary by focusing on helping the "ONE WAY".

So I hope that puts THAT to rest and I seriously hope that is the last I need to say on it.

[Al6bus]

blink, blink, maybe blink...

another chromium clone?? It's over nine thousand! we love pm for its own goanna (gecko, servo...) engine.
maybe go opera (blink) way on relationships for chrome? Live some more time under firefox camouflage, struggle with compatibility takes too many effort.

sorry, bad english

[libertyernie]

I think this seems like a good idea. Starting from a codebase that has more recent code than Pale Moon's might make developers from outside the project less skeptical about it. And giving the new product a different name is a very good idea - to reflect the differences "under the hood".

Have you reached out to the tenfourfox author at all, to see if your plan would result in a codebase he would be willing to work off of?

[CharmCityCrab]

Allow me to further clarify .. ONE AGAIN.. Our future and whatever path we take is going to still have specific requirements and parameters. It is gonna be a mozilla-like codebase.. It is gonna have a gecko-like rendering engine (Goanna) it will have XUL, XBL, all the technologies everyone wants and needs. What this will not be is a trident shell, a webkit shell, a blink shell, or whatever servo is gonna be.. No, does not and would not support all the bits of technology to be a product we and you could use and be proud of. If you think this is gonna happen.. Just stop because it isn't going to ever be that. So get that out of your heads.

NOW.. The discussion can continue about this STILL theoretical concept that we MAY pursue in the future.

So, this hypothetical browser is the Pale Moon browser folder pasted into a new tree from a later version of Firefox with all the incompatibilities and bugs that joining those two things together might create fixed as best as possible (To summarize what you said in another new post). Same UI, still the Goanna web engine, etc., but it'd perhaps something better able to render the current and future web because of key rendering and speed improvements that occurred after Pale Moon forked off that we'd be forking back in from Mozilla, yes?

Okay, so, if that's the case, I don't understand entirely why *on the user end* this is any different from any other major Pale Moon release. I understand it's a different process behind the scenes, but it seems like to me that this could just be Pale Moon 30 or something, and people could just upgrade through the normal processes. It'd be a major milestone, but not really a change to the goals of the project or the underlying basics of the browser "in a nutshell" even though it'd be significant to people going through the actual code.

The idea of this is fine, but I don't see a reason for a re-brand or to not just make this available through the normal update process (Not that it was said explicitly that it would be a re-brand or not made available as a normal update- but it seemed to be hinted at at times). You've got half a million users. Any shift to a new name and not going through the normal update is going to result in a loss of many of the more casual of those users, and is a loss of your brand and name recognition, which is very hard to grow fresh without a lot cash to advertise or a lot of influence to get tech media coverage. I think you guys could do this and keep it Pale Moon. The majority of people probably think what you're describing in this thread is basically what you do anyway, even though it's not.

And then as limited resources shifted to this, if you left Pale Moon going along current lines past the "ship" date of the new browser, you're going to be stretched even thinner. People aren't going to know which browser to maintain themes and extensions for either, etc.. It doesn't entirely make sense to say you don't have enough coders for one browser, so now you're going to maintain two to alleviate that problem. Totally different story if the "second browser" is really just an alpha or a beta that will be the next Pale Moon milestone after it's ready, of course.

To me, if this is what you guys want to do, I would make sure when it goes gold, it's Pale Moon.

One concern is that if and when this would go gold, I would recommend having a very extensive set of extensions ready to go. If it's going to harder to access the Mozilla repos and just install, we need to have the Pale Moon add-on sites totally ready to be *the* source for Pale Moon add-ons. When people's old add-ons break on the update, or they start new profiles and want to reinstall them, and they show up here, we should be able to point them to similar add-ons on the Pale Moon website- not send them to Mozilla and ask them to do a bunch of stuff to try to get one of those add-ons to work.

Another concern long-term is that it seems like a move back towards relying on a dying browser (Firefox), which will be long moved on by the time you get there. It's tying ourselves to a sinking ship, in a way. We should be moving our way and not their way (Perhaps, I'm just brainstorming).

If the goal is to bring in everyone who's going to jump ship from Firefox and try to make the underpinnings more familiar for people who can contribute code to the Pale Moon project (Or whatever it's called by then) and for extensions to be forked (Although they will have been rewritten in Firefox's new code by then and incompatible, most likely), you may want to check with those people first and make sure you can get them before you do things to get them that may not get them. Would devs for other forked browsers and Mozilla volunteers jump? It can't be assumed without asking.

I also just... This is a valiant effort. But I'm pessimistic in some ways. I believe in you guys. I think Gecko is going to be dead soon, though. I think everyone will be coding websites for Webkit/Blink. If anyone is going to be starting a new product, a shell that looks like the old Netscape or Firefox 2-3 with Webkit and some extension and theming tech and better privacy and security than Google and Safari offer is more likely to work on the sites people need (Worth keeping in mind is that Webkit is based on KHTML, it's not just the Apple or the Google rendering engine, it started as part of a Linux browser). A new browser starting from Gecko seems like wasted effort. Unless you guys just "reconfigure" this plan as an update of the existing PM browser, which would seem better somehow, at least perception wise.

Also, doing this may create a perception that you need to do this to get a workable modern secure browser and will need to do this again every few years, and, if that's the case, again it's tying us to Mozilla, which....

Well, like I said, I think all this is fine. I just, for an entirely new project, would not personally go in this direction. If I did this as an update, it'd just be an update. And some long-term thinking may need to be done about whether this browser can continue when there is no more Firefox or it's written in it's own code with it's own engine, and you have to find and fix bugs and secure things and write rending engines for HTML6 and HTML7 and every other new thing that comes along yourselves, from scratch, because you are the only ones left on the Gecko tree and there's nothing left to fold in later (In light of hinting that we need to do this fold for better HTML5 compatibility).

We already kind of don't have an upstream, we are the upstream. But that'll be really be true when Firefox disappears. And if we need them again to catch up now, where will we be when we need them to catch up later and they don't exist? The security bulletins from Mozilla will be totally irrelevant. Web sites will be off in a direction that is hard to keep up with rendering wise... I just don't know.

It's a tough decision for you guys.

I support you all and love what you do.

But you definitely want to consider all the angles on this one.

[Thrawn]

Okay, so, if that's the case, I don't understand entirely why *on the user end* this is any different from any other major Pale Moon release.

I second this idea. Pale Moon used to follow Firefox releases more closely, albeit cherry-picking. This would just be another (large) round of that, wouldn't it?

I think Gecko is going to be dead soon, though.

Well, if Firefox does go away, then there will be yet more need for PM. On the downside, it would certainly be more work to maintain PM without even crumbs from Mozilla; on the upside, it would mean less "PM is outdated Firefox" attitudes. Perhaps PM would even attract more FOSS attention in that scenario.