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
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
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
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,
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
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
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,
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
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
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
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
- 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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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,
26 matches
Mail list logo
