Terminating xulrunner?

[Mike Hommey]

Hi,

Let's face it: xulrunner is hardly maintained, we barely build and test
it on automation, and the result is that it is often broken for long
periods of time.

I propose that we just stop pretending, and terminate xulrunner,
considering the following:
- Xulrunner is lagging behind Firefox: DLL block list, startup telemetry,
etc.
- Since bug 755724, running firefox -app application.ini is 99% the same
as running xulrunner application.ini, except for a few details that
should be considered bugs. Before that bug, it was quite different,
as browser-specific files were available to the xul application.
- There is no reason we can't generate the sdk from firefox instead of
xulrunner. Moreover that would make firefox-specific interfaces
available in the sdk that aren't currently (which may or may not be a
good thing, arguably)
- We could include the xulrunner and xulrunner-stub executables as part
of firefox. xulrunner-stub is small and self-contained, and xulrunner
could be replaced by something that calls firefox -app. Or we could
make the firefox executable check under what name it's called and act
accordingly.

Thoughts?

Mike

[Simon Kornblith]

As a XULRunner app developer, as long as firefox -app application.ini continues to work I think I could learn to live with this.

[Mark Finkle]

Your proposal sounds somewhat similar to the way the webapprt is being delivered too. I think that's a good thing.

----- Original Message -----

> I propose that we just stop pretending, and terminate xulrunner,
> considering the following:
> - Xulrunner is lagging behind Firefox: DLL block list, startup telemetry,
> etc.
> - Since bug 755724, running firefox -app application.ini is 99% the same
> as running xulrunner application.ini, except for a few details that
> should be considered bugs. Before that bug, it was quite different,
> as browser-specific files were available to the xul application.
> - There is no reason we can't generate the sdk from firefox instead of
> xulrunner. Moreover that would make firefox-specific interfaces
> available in the sdk that aren't currently (which may or may not be a
> good thing, arguably)
> - We could include the xulrunner and xulrunner-stub executables as part
> of firefox. xulrunner-stub is small and self-contained, and xulrunner
> could be replaced by something that calls firefox -app. Or we could
> make the firefox executable check under what name it's called and act
> accordingly.

> Thoughts?

> Mike

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Dave Townsend]

I sadly agree. While I still think there is value in XULRunner existing as
a standalone runtime I don't think it is worth taking any time away from
other work and it would be better to stand up and declare it dead instead
of pretending like it is going to be around long-term.

[Neil]

Mike Hommey wrote:

>I propose that we just stop pretending, and terminate xulrunner
>
>

How would this affect the ability to build Firefox against the sdk?

--
Warning: May contain traces of nuts.

[Martin Stransky]

Well, Fedora is going to ship standalone Firefox instead of the FF+XL
combo and retire the xulrunner package.

ma.

On 01/13/2014 01:34 AM, Mike Hommey wrote:
> Hi,
>
> Let's face it: xulrunner is hardly maintained, we barely build and test
> it on automation, and the result is that it is often broken for long
> periods of time.
>

[Benjamin Smedberg]

On 1/12/2014 7:34 PM, Mike Hommey wrote:
> Hi,

>
> I propose that we just stop pretending, and terminate xulrunner,
> considering the following:

This has in fact been the plan for a while now. The only reason we
continue to do any regular XULRunner builds at all is because we do need
to publish an SDK, and currently the Firefox build does not produce a
SDK as a build product. As soon as somebody fixes bug 672509 and we get
releng to deploy that, we can turn of the XULRunner builds.

--BDS

[ajvi...@gmail.com]

Wow. All this just as I'm trying to get XULRunner repaired and stabilized for good with automated tests. I put a lot of effort into reviving the damn thing, and I'm close to getting it working again on the Mac. (More to the point, I'm obsessed with getting it working on the Mac again - and I know I'm getting close. There are heartbeats, I'm telling you.)

I'm willing to own XULRunner and actively maintain it. People on this thread know I've been an advocate for it, and that I've submitted several patches to bring it back. I have been working with XULRunner for two years.

If you are going to kill XULRunner off entirely in favor of firefox -app, then do it, *get it over with*, and write a "XULRunner Considered Harmful" blog post on planet mozilla.

I don't know. Maybe building an SDK based on Firefox is the right thing; honestly, I just want something that works. But I put a lot of effort into this over the last two years.

[Mike Hommey]

FWIW, I packaged xulrunner in Debian in 2006 and have been maintaining
it since then. Iceweasel (rebranded Firefox) has been built against
xulrunner since 2008. I put a lot of effort into xulrunner over the
last eight years. It's time to face the truth and let go.

Mike

[Mark Finkle]

----- Original Message -----

> > I don't know. Maybe building an SDK based on Firefox is the right
> > thing; honestly, I just want something that works. But I put a lot of
> > effort into this over the last two years.

> FWIW, I packaged xulrunner in Debian in 2006 and have been maintaining
> it since then. Iceweasel (rebranded Firefox) has been built against
> xulrunner since 2008. I put a lot of effort into xulrunner over the
> last eight years. It's time to face the truth and let go.

I will be sad to see XULRunner go too. It's the reason I started using Mozilla-tech, and eventually joined Mozilla.

We've know something for a long time: If Mozilla is not using a tech/project in Firefox, support for the tech/project will wither.

However, sometimes we can create a different version of the tech/project that *is* used by Firefox and therefore much better supported by Mozilla. It's not a guarantee, but it helps. That's why I loved seeing | firefox --app | happen and continue to evolve. The new webapprt is a strong replacement for Prism/Chromeless. We even started an Android embedding widget (GeckoView) to power Firefox for Android.

[mka...@gmail.com]

I have a couple concerns.

1. It makes it much more difficult to ship a site specific browser that can be installed alongside Firefox (especially if that browser might need to be different than the installed Firefox, like based on the ESR). It would seem that the best method would be to take a firefox install, remove any bits that are "Firefox" and install that. I'm not sure legal would like that.

2. It creates licensing issues. Previously, we would ship XULRunner and there were no Firefox trademarks involved. If we are shipping actual Firefox with modifications for our application, I would assume it would have to go through Firefox legal.

I think the stub to launch the app is a must have. I do not want to ship firefox.exe to customer that need a site specific browser and create an icon that launches firefox with -app. I need to be able to deliver them a named EXE just like any other application.

[mka...@gmail.com]

One more thought.

How will updating work?

If you are running an app with application.ini, it's not going to get it's updates through the Firefox update service, even though you have Firefox installed.

So you'll have to somehow rebundle Firefox with your application and send that as an update?

[Alex Vincent]

Guys, I get it. I'm not happy about it, especially having wasted a lot of
the last two years on it, but I get it.

"One day, the beast cast its eye on its unruly cousin, and lost his
patience. Many fine people tried to spare the cousin, but the beast
swallowed its cousin whole. Its belch was like a volcano erupting, and
traveled as fast as the fox itself. Even so, many lamented at the time the
loss of a dream... unwisely in the eyes of several high priests. For the
betterment of all, the reconciliation was swift to arrive and comforting to
all."

-- not every passage from the Book of Mozilla can be a happy one.

I'm idly wondering when I became timeless, the guy who fights the wisdom of
his peers most futilely. :-) (I know him, so I can say that.)


On Tue, Jan 14, 2014 at 6:16 AM, Mark Finkle <mfi...@mozilla.com> wrote:

>
>
> ------------------------------

>
> > I don't know. Maybe building an SDK based on Firefox is the right
> > thing; honestly, I just want something that works. But I put a lot of
> > effort into this over the last two years.
>

> FWIW, I packaged xulrunner in Debian in 2006 and have been maintaining
> it since then. Iceweasel (rebranded Firefox) has been built against
> xulrunner since 2008. I put a lot of effort into xulrunner over the
> last eight years. It's time to face the truth and let go.
>
> I will be sad to see XULRunner go too. It's the reason I started using
> Mozilla-tech, and eventually joined Mozilla.
>
> We've know something for a long time: If Mozilla is not using a
> tech/project in Firefox, support for the tech/project will wither.
>
> However, sometimes we can create a different version of the tech/project
> that *is* used by Firefox and therefore much better supported by Mozilla.
> It's not a guarantee, but it helps. That's why I loved seeing | firefox
> --app | happen and continue to evolve. The new webapprt is a strong
> replacement for Prism/Chromeless. We even started an Android embedding
> widget (GeckoView) to power Firefox for Android.
>
>

--
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

[Benjamin Smedberg]

On 1/14/2014 12:34 PM, mka...@gmail.com wrote:
> I have a couple concerns.
>
> 1. It makes it much more difficult to ship a site specific browser that can be installed alongside Firefox (especially if that browser might need to be different than the installed Firefox, like based on the ESR). It would seem that the best method would be to take a firefox install, remove any bits that are "Firefox" and install that. I'm not sure legal would like that.
>
> 2. It creates licensing issues. Previously, we would ship XULRunner and there were no Firefox trademarks involved. If we are shipping actual Firefox with modifications for our application, I would assume it would have to go through Firefox legal.

You could build and ship exactly what you need. You could keep building
XULRunner builds yourself, or do generic-branding builds of Firefox. Or
do a repack to remove the Firefox-specific files from a Firefox install.
Certainly without branding issues it's not a problem anyway, right?

I would never recommend using a shared Firefox install for other apps,
just as I removed support for a shared XULRunner instance long ago. You
should always ship the files you need directly.

> How will updating work?
>
> If you are running an app with application.ini, it's not going to get it's updates through the Firefox update service, even though you have Firefox installed.
>
> So you'll have to somehow rebundle Firefox with your application and send that as an update?

Update has always been up to the app developer; we have never had an
auto-update system for XULRunner or XR-based apps. You'd create your
update packages, set an update server URL in your app, and do all that
yourself.

--BDS

[mka...@gmail.com]

On Tuesday, January 14, 2014 1:06:19 PM UTC-6, Benjamin Smedberg wrote:
> Or
> do a repack to remove the Firefox-specific files from a Firefox install.
> Certainly without branding issues it's not a problem anyway, right?

So in my testing, this worked perfectly.

If we could solve the stub problem, I don't see why this can't be a perfect replacement for xulrunner.

There should be something like minefield-stub.exe that reads application.ini and can simply replace firefox.exe.

It shouldn't invoke firefox.exe.

That would allow all the customization of the EXE needed and there wouldn't be any Firefox branding.

[Benjamin Smedberg]

On 1/14/2014 2:30 PM, mka...@gmail.com wrote:
> On Tuesday, January 14, 2014 1:06:19 PM UTC-6, Benjamin Smedberg wrote:
>> Or
>> do a repack to remove the Firefox-specific files from a Firefox install.
>> Certainly without branding issues it's not a problem anyway, right?
> So in my testing, this worked perfectly.
>
> If we could solve the stub problem, I don't see why this can't be a perfect replacement for xulrunner.

I don't think we need to solve the stub problem to implement this plan;
I'll take patches which compile a generic stub into the SDK. firefox.exe
is after basically the stub already with embedded icons and whatnot.

--BDS

[mka...@gmail.com]

The reason the stub is important is because of Windows jumplists.

Even if you use a resource editor to change all of the internals of the Firefox executable, if Firefox is installed on that machine, you'll end up with "Firefox" and the firefox logo on the jump list and when you select "Firefox" it will try to start Firefox using the loaded instance. So you'll get a profile manager XUL error if you've removed all the Firefox cruft.

We need a stub executable to make sure this never happens.

Mike

[ajvi...@gmail.com]

On Sunday, January 12, 2014 4:34:54 PM UTC-8, Mike Hommey wrote:
> - We could include the xulrunner and xulrunner-stub executables as part
> of firefox. xulrunner-stub is small and self-contained, and xulrunner
> could be replaced by something that calls firefox -app. Or we could
> make the firefox executable check under what name it's called and act
> accordingly.

As I stated earlier, if we get this going quickly, I have no long-term objection. That said, it's almost time for an ESR cycle on mozilla-central, and that is cause for concern.

I'd like to get a clarified list of requirements for the Firefox SDK:

* Will we support a stub executable?
* Will we support an install-app capability in the SDK?
* Will Mac SDK users be able to create .app files that actually work?
* Will they have a XUL.framework in them?
* Will we still publish headers, binary tools, etc. in a convenient package for component developers to use?
* Can we import Philipp Kewisch's wonderful remote debugger extension, so that Firefox can remotely debug the XULRunner app? (By the way, that works in XR apps now.)
* Will we have automated regression tests run daily to make sure the SDK is still viable?
* What obvious requirements am I missing from this list?
* Can we get everything in place and make an ESR SDK as well?

[Benjamin Smedberg]

On 1/14/2014 3:17 PM, ajvi...@gmail.com wrote:
> I'd like to get a clarified list of requirements for the Firefox SDK:
>
> * Will we support a stub executable?

If somebody writes a patch to include a stub executable in the SDK, I
will accept that patch. If you include automated tests for it, I'll
count that as a form of "support". But if it breaks, we wouldn't close
the tree or block the release on it.

> * Will we support an install-app capability in the SDK?

If you want to include those scripts in the SDK, I'll review it.

> * Will Mac SDK users be able to create .app files that actually work?

I don't know. If somebody does the work, sure!

> * Will they have a XUL.framework in them?

Probably not.

> * Will we still publish headers, binary tools, etc. in a convenient package for component developers to use?

We will continue to publish the SDK.

> * Can we import Philipp Kewisch's wonderful remote debugger extension, so that Firefox can remotely debug the XULRunner app? (By the way, that works in XR apps now.)

Maybe?

> * Will we have automated regression tests run daily to make sure the SDK is still viable?

Probably not. Even if somebody wrote the test framework, this is low
priority compared with other tasks that automation or releng have.

> * Can we get everything in place and make an ESR SDK as well?

I don't think it matters. The SDK isn't supposed to change between
security dot releases, so typically you wouldn't need a new one; you'd
just keep using the base version for the life of the ESR release. But at
the same time, if the SDK is a byproduct of the Firefox build, we'll get
it "for free" with the Firefox ESR builds.

--BDS

[Philipp Wagner]

Hi,

Am 13.01.2014 01:34, Mike Hommey wrote:
> Let's face it: xulrunner is hardly maintained, we barely build and test
> it on automation, and the result is that it is often broken for long
> periods of time.
>
> I propose that we just stop pretending, and terminate xulrunner,
> considering the following:

Thanks Mike for getting this topic started, even though I kind of
settled very well with the status quo and was hoping sleeping dogs would
not be woken up :-) But it had to happen at some point, so let's make
sure we come out of this whole discussion with a better solution than we
have right now. I totally agree with Mark that the lession we've learned
in the past is clear:

Am 14.01.2014 15:16, Mark Finkle wrote:
> We've know something for a long time: If Mozilla is not using a
> tech/project in Firefox, support for the tech/project will wither.

My use case is kind of a typical XULRunner-based application. I have
custom application code and distribute a private (self-build, unpatched
but localized) XULRunner copy with it. It runs on Windows and Linux. I
don't see any problems with using a custom copy of Firefox instead of
XULRunner for my use case at first sight.

> - Since bug 755724, running firefox -app application.ini is 99% the same
> as running xulrunner application.ini, except for a few details that
> should be considered bugs. Before that bug, it was quite different,
> as browser-specific files were available to the xul application.

sounds good, even though I don't get the whole story in bug 755724, the
discussion there is rather extensive :-)

> - There is no reason we can't generate the sdk from firefox instead of
> xulrunner. Moreover that would make firefox-specific interfaces
> available in the sdk that aren't currently (which may or may not be a
> good thing, arguably)

If the application doesn't need to use it I don't see any problem with it.

> - We could include the xulrunner and xulrunner-stub executables as part
> of firefox. xulrunner-stub is small and self-contained, and xulrunner
> could be replaced by something that calls firefox -app. Or we could
> make the firefox executable check under what name it's called and act
> accordingly.

The functionality of xulrunner-stub is really nice and I'd be glad if it
could be retained. To me making Firefox check under which name it was
called and act then like xulrunner-stub sounds like the solution which
has the largest chance of staying supported. I'm volunteering to help
out with patches here if it is clear which way we want to go. The
simplest solution probably would be to just keep the xulrunner-stub code
as it is somewhere, maybe behind a ./configure option, for those people
who need it.

Another thing that kind of comes together with xulrunner-stub is the
redit.exe tool (in xulrunner/tools/redit) to replace the icon of an EXE
file. Again, it would be nice if it could stay in the tree somewhere,
but otherwise I'd just take it to some github repo and be fine with it.

Since it seems that all other parts that I need are there already I'll
give this whole thing a try next week and report back how things go. An
open question right now would be how the updater will handle things.

As a closing remark, since this discussion is not prompted by any
immediate problem with XULRunner from what I understand, I'd be happy if
things could stay the way they are until we come up with some
alternatives or decide that a particular problem will have no
alternative solution. Just don't rip out the code as first step :-)

Philipp

[Philipp Wagner]

Am 15.01.2014 23:08, Marcio Galli wrote:
> Something to check, that resides between engineering and legal, is how
> easy it will be for a third-party to ship the Firefox code (with the
> --app). While I understand that no UI is to be shown, I believe that
> we need to check legal aspects regarding the use of Firefox code -
> it's restrictions and consequences, let s say to bump a case - think
> of a bug in Gecko or something else that would lift behavior from
> Firefox bits and pieces with trademarks.

My understanding (and I'm not a Mozilla lawyer or anything, so it would
be good for someone from the legal team to give final answers here):

- Distributing an unmodified, official Firefox build should not be a
problem, even if you use it just to start another application using the
--app switch).

- Building a custom, possibly modified version of Firefox as "XULRunner
replacement" and distributing that should not be a problem if built with
the "unofficial" branding (the default), since this branding should not
contain any trademarks.

Philipp

[WaltS]

User thoughts.

You can close this bug as WONTFIX, since the stand alone profile
manager, which I use is built on xulrunner.

[214675 � Remove Profile Manager
UI](https://bugzilla.mozilla.org/show_bug.cgi?id=214675)

[Profile Manager |
MDN](https://developer.mozilla.org/en-US/docs/Profile_Manager)

Maybe that page should be also be removed from MDN. That way I won't be
able to keep recommending it to users.

I think having a stand alone profile manager is a great idea though. I
use it to run Nightly alongside the Beta with separate profiles for
each. I also use it for Thunderbird release and Daily.

[David Rajchenbach-Teller]

Having proper support for multi-profile is great, by opposition to the
current "hidden on the command line" support, but I believe that this
discussion deserves its own thread (and its own bug).

Cheers,
David

On 1/16/14 4:13 PM, WaltS wrote:
> User thoughts.
>
> You can close this bug as WONTFIX, since the stand alone profile
> manager, which I use is built on xulrunner.
>
> [214675 � Remove Profile Manager
> UI](https://bugzilla.mozilla.org/show_bug.cgi?id=214675)
>
> [Profile Manager |
> MDN](https://developer.mozilla.org/en-US/docs/Profile_Manager)
>
> Maybe that page should be also be removed from MDN. That way I won't be
> able to keep recommending it to users.
>
> I think having a stand alone profile manager is a great idea though. I
> use it to run Nightly alongside the Beta with separate profiles for
> each. I also use it for Thunderbird release and Daily.
>
>
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[gio...@mozilla-hispano.org]

Hi,

I have some questions, and would be nice if someone could answer. I will really appreciate.

* Mozilla will not provide more Xulrunner builds (runtime)?
* If not, developers will be able to compile Xulrunner builds from Mozilla code?
* Will Mozilla continues the Xulrunner development?
* What happens with Xulrunner based apps? *This is the more important to me*

Maybe those questions are explained before, but could be great if someone could answer some of them.

Regards,
Gio

[Till Schneidereit]

Hi Gio,

please read the previous messages in this thread: they contain answers to
all these questions. In fact, they're pretty much all answered right in the
first message[1].

[1]:
https://groups.google.com/d/msg/mozilla.dev.platform/o99wQZBjIJw/4eBoWbjEzjAJ

[edun...@gmail.com]

My Firefox Thunderbird will not open correctly because it wants XUL Runner to be 45.5.0. Can you help me? edunlap

[edun...@gmail.com]

My Firefox Thunderbird needs XUL Runner to be 45.5.0 or it won't let me see my incoming emails. Can you help me?
edunlap

[Mike Hoye]

On 2016-11-28 9:32 PM, edun...@gmail.com wrote:
> My Firefox Thunderbird will not open correctly because it wants XUL Runner to be 45.5.0. Can you help me?

Unfortunately, XULRunner hasn't been under active development since
mid-2015, and was never officially supported.

I suggest downloading and reinstalling the most recent version of
Thunderbird, available here:

https://www.mozilla.org/en-US/thunderbird/

This may resolve your issue. You can email me directly if it doesn't,
and I'll see if I can direct you to the right people in the Thunderbird
community.

- mhoye