|Terminating xulrunner?||Mike Hommey||1/12/14 4:34 PM|
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,
- 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
|Re: Terminating xulrunner?||Simon Kornblith||1/12/14 5:48 PM|
As a XULRunner app developer, as long as firefox -app application.ini continues to work I think I could learn to live with this.
|Re: Terminating xulrunner?||Mark Finkle||1/12/14 8:59 PM|
Your proposal sounds somewhat similar to the way the webapprt is being delivered too. I think that's a good thing.
> dev-platform mailing list
|Re: Terminating xulrunner?||Dave Townsend||1/12/14 9:32 PM|
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.
|Re: Terminating xulrunner?||Neil||1/13/14 1:48 AM|
Mike Hommey wrote:How would this affect the ability to build Firefox against the sdk?
Warning: May contain traces of nuts.
|Re: Terminating xulrunner?||Martin Stransky||1/13/14 2:10 AM|
Well, Fedora is going to ship standalone Firefox instead of the FF+XL
combo and retire the xulrunner package.
|Re: Terminating xulrunner?||Benjamin Smedberg||1/13/14 5:32 AM|
On 1/12/2014 7:34 PM, Mike Hommey wrote:
>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.
|Re: Terminating xulrunner?||ajvi...@gmail.com||1/14/14 12:55 AM|
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.
|Re: Terminating xulrunner?||Mike Hommey||1/14/14 1:48 AM|
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.
|Re: Terminating xulrunner?||Mark Finkle||1/14/14 6:16 AM|
----- Original Message -----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.
|Re: Terminating xulrunner?||mka...@gmail.com||1/14/14 9:34 AM|
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.
|Re: Terminating xulrunner?||mka...@gmail.com||1/14/14 9:37 AM|
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?
|Re: Terminating xulrunner?||Alex Vincent||1/14/14 8:49 AM|
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
-- 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:
"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
|Re: Terminating xulrunner?||Benjamin Smedberg||1/14/14 11:06 AM|
On 1/14/2014 12:34 PM, mka...@gmail.com wrote: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.
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
|Re: Terminating xulrunner?||mka...@gmail.com||1/14/14 11:30 AM|
On Tuesday, January 14, 2014 1:06:19 PM UTC-6, Benjamin Smedberg wrote: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.
|Re: Terminating xulrunner?||Benjamin Smedberg||1/14/14 11:40 AM|
On 1/14/2014 2:30 PM, mka...@gmail.com wrote: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.
|Re: Terminating xulrunner?||mka...@gmail.com||1/14/14 11:55 AM|
On Tuesday, January 14, 2014 1:40:13 PM UTC-6, Benjamin Smedberg wrote:
> > If we could solve the stub problem, I don't see why this can't be a perfect replacement for xulrunner.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.
|Re: Terminating xulrunner?||ajvi...@gmail.com||1/14/14 12:17 PM|
On Sunday, January 12, 2014 4:34:54 PM UTC-8, Mike Hommey wrote: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?
|Re: Terminating xulrunner?||Benjamin Smedberg||1/14/14 12:51 PM|
On 1/14/2014 3:17 PM, ajvi...@gmail.com wrote: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.
|Re: Terminating xulrunner?||Philipp Wagner||1/15/14 12:28 PM|
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:
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.
sounds good, even though I don't get the whole story in bug 755724, the
discussion there is rather extensive :-)
If the application doesn't need to use it I don't see any problem with it.
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 :-)
|Re: Terminating xulrunner?||Philipp Wagner||1/15/14 2:24 PM|
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
- 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.
|Re: Terminating xulrunner?||WaltS||1/16/14 7:13 AM|
You can close this bug as WONTFIX, since the stand alone profile
manager, which I use is built on xulrunner.
[214675 ï¿½ Remove Profile Manager
[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.
|Re: Terminating xulrunner?||David Rajchenbach-Teller||1/16/14 7:18 AM|
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).
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
|Re: Terminating xulrunner?||gio...@mozilla-hispano.org||1/20/14 10:02 PM|
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.
|Re: Terminating xulrunner?||Till Schneidereit||1/21/14 3:23 AM|
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