I suggest you ...

Fork Firefox, apply the planned changes to the fork, leave Firefox as is

The fork would be what Mozilla currently plans Firefox to become. However the current Firefox would remain available so users can choose.

If the fork goes as planned and XPCOM- and XUL-based add-ons are no longer significant in 2, 3 or 4 years, Mozilla could leave Firefox to the community in a similar way as SeaMonkey.

If the fork doesn't work out well and users keep preferring the old Firefox, nothing would be lost because Firefox is still there.

155 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Markus PoppMarkus Popp shared this idea  ·   ·  Admin →

    15 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  · 

        Don't fork Firefox. Fork you. In the ass!

      • Anonymous commented  · 

        There is already a fork - Pale Moon

      • LadisLadis commented  · 

        Microsoft managed it. The new Trident web engine is only in Edge and Edge has a simple menu item "Open in IE" as the solution about compatibility with old webs. Now they can focus on clean Edge with Trident after removing all compatibility modes and people can still open specific webs (e.g. needing plugins) in IE, which is still supported by security updates (a fraction of manpower needed). BTW Edge also supports Chrome's extension (in its dev version). PS: I'm for a new name for the fork, because FF is connected with extensions being able to do anything, but on the other hand the huge sloppines caused by all tabs running in one process.

      • wyatt8740wyatt8740 commented  · 

        This would be a ton of maintenance work. I'd like it, but I feel that just dropping webextensions or integrating webextensions WITHOUT removing XUL are better options.

      • strelstrel commented  · 

        Better, leave Firefox as was.

      • Richard A. LandkamerRichard A. Landkamer commented  · 

        I have been using Session Manager for about 3 years, which appears to have been abandoned by Michael Kraft, its owner/developer. Or perhaps Mr. Kraft is trying to sell this product to some other developer or software company, who could make this product work on Firefox release 40.0 and above.

        Your suggestion to "Fork Firefox, apply the planned changes to the fork, leave Firefox as is" would most likely enable me to continue using Session Manager on the current release of Firefox. As matters currently stand, I cannot upgrade to any release of Firefox after 39.0.3, which is the last Firefox release that still works with Michael Kraft's Session Manager.

        Richard A. Landkamer

      • Anonymous commented  · 

        > Also, by the time we release Servo, the WebExtension API will have been field-tested, and there will already be an add-on ecosystem.

        Yes, an ecosystem for Chrome webextensions. Why is the permissive addon model not considered to the servo browser?

      • David Rajchenbach-TellerDavid Rajchenbach-Teller commented  · 

        Well, at some point, we wish to transition Firefox from Gecko (written in C++ and JS, with all the limitations of C++ and JS) to Servo (written in Rust, and much better suited to recent and upcoming architectures). We know for sure that the XUL/XPCOM add-on model will not be ported to Servo because it would take us about three gazillion man-years. Whether the new browser is called Firefox or something else has not been decided, nor has the calendar, so that's basically what you suggest, except it won't be a fork but possibly a clean-slate reimplementation.

        Now, we plan to transition add-ons long before we transition the engine. While this is not the only reason for the transition, having a clean API means that WebExtension-based add-ons will be usable with Servo automatically. Also, by the time we release Servo, the WebExtension API will have been field-tested, and there will already be an add-on ecosystem.

      • Markus PoppMarkus Popp commented  · 

        "Are you suggesting we create a new browser and drop Firefox?"

        As per my suggestion: not drop Firefox, unless it becomes obsolete in the distant future.
        But it may make sense for Mozilla to start a 2nd browser which doesn't need to carry the legacy stuff with it while continuing to maintain the old Firefox for quite some time (until it may be left to the community to continue development, if there is demand for it).

        I don't know how much effort it would take to maintain 2 browsers for some time. But I guess web platform updates apply to both in the same way, so this shouldn't double the development efforts. The advantage is that the new browser could much more easily drop things which have become outdated over time, including XPCOM- and XUL-based addons.

      • Anonymous commented  · 

        @Philipp Kewish

        It's not an effective use of developer resources to clone Chrome either, but here we are.

      • Haider Rehman ButtHaider Rehman Butt commented  · 

        @Phillip Kewisch

        Few resources are needed to maintain Firefox as is.

        Mozilla should make a new browser and promote it more.

      • Philipp KewischPhilipp Kewisch commented  · 

        I don't see how this is helpful. Forking Firefox wouldn't be an effective use of developer resources.

      Feedback and Knowledge Base