Re: Terminating xulrunner?
On 2016-11-28 9:32 PM, edunl...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Sunday, January 12, 2014 at 7:34:54 PM UTC-5, 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. > > 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 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Sunday, January 12, 2014 at 7:34:54 PM UTC-5, 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. > > 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 My Firefox Thunderbird will not open correctly because it wants XUL Runner to be 45.5.0. Can you help me? edunlap ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 On Tue, Jan 21, 2014 at 7:02 AM, gio...@mozilla-hispano.org wrote: 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 01/12/2014 07:34 PM, 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. 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 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Tue, Jan 14, 2014 at 12:55:03AM -0800, ajvinc...@gmail.com wrote: 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. 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
- 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 mfin...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On Tuesday, January 14, 2014 1:40:13 PM UTC-6, Benjamin Smedberg wrote: 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: 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. 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
On 1/14/2014 3:17 PM, ajvinc...@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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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. 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
As a XULRunner app developer, as long as firefox -app application.ini continues to work I think I could learn to live with this. On Sunday, January 12, 2014 7:34:54 PM UTC-5, 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. 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
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. On Sun, Jan 12, 2014 at 8:59 PM, Mark Finkle mfin...@mozilla.com wrote: 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-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
