-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/23/2014 12:45 AM, Ehsan Akhgari wrote:
> On 2014-12-22 6:35 PM, L. David Baron wrote:
>> On Monday 2014-12-22 18:21 -0500, Ehsan Akhgari wrote:
>>> On 2014-12-22 6:07 PM, L. David Baron wrote:
On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari
On Mon, Dec 22, 2014 at 3:35 PM, L. David Baron wrote:
> On Monday 2014-12-22 18:21 -0500, Ehsan Akhgari wrote:
> > On 2014-12-22 6:07 PM, L. David Baron wrote:
> > >On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote:
> > >>On 2014-12-22 4:56 PM, L. David Baron wrote:
> > >>>I think removing i
On 2014-12-22 6:35 PM, L. David Baron wrote:
On Monday 2014-12-22 18:21 -0500, Ehsan Akhgari wrote:
On 2014-12-22 6:07 PM, L. David Baron wrote:
On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote:
On 2014-12-22 4:56 PM, L. David Baron wrote:
I think removing implicit conversions to T* will
On Monday 2014-12-22 18:21 -0500, Ehsan Akhgari wrote:
> On 2014-12-22 6:07 PM, L. David Baron wrote:
> >On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote:
> >>On 2014-12-22 4:56 PM, L. David Baron wrote:
> >>>I think removing implicit conversions to T* will make a lot of code
> >>>in the tree
On 2014-12-22 6:07 PM, L. David Baron wrote:
On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote:
On 2014-12-22 4:56 PM, L. David Baron wrote:
I think removing implicit conversions to T* will make a lot of code
in the tree uglier (".get()" everywhere). That might, in turn,
encourage people t
On Mon, Dec 22, 2014 at 04:56:12PM -0500, L. David Baron wrote:
> (And, on that subject, I think development practice in
> MFBT has been too readily adding new and different things instead of
> moving the existing things from XPCOM into MFBT and then improving
> them incrementally.)
That essential
On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote:
> On 2014-12-22 4:56 PM, L. David Baron wrote:
> >I think removing implicit conversions to T* will make a lot of code
> >in the tree uglier (".get()" everywhere). That might, in turn,
> >encourage people to do worse things to avoid having to w
On 2014-12-22 4:56 PM, L. David Baron wrote:
On Monday 2014-12-22 16:10 -0500, Jeff Muizelaar wrote:
We were talking about this problem and it was a bunch of work to figure out the
conclusion so I decided to write a summary:
Replacing already_AddRefed with nsRefPtr causes allows two new things
On Monday 2014-12-22 16:10 -0500, Jeff Muizelaar wrote:
> We were talking about this problem and it was a bunch of work to figure out
> the conclusion so I decided to write a summary:
>
> Replacing already_AddRefed with nsRefPtr causes allows two new things:
>
> nsRefPtr getT();
>
> 1. T* p = g
On Mon, Dec 22, 2014 at 1:12 PM, Ehsan Akhgari
wrote:
> On 2014-12-22 4:10 PM, Jeff Muizelaar wrote:
>
>> We were talking about this problem and it was a bunch of work to figure
>> out the conclusion so I decided to write a summary:
>>
>> Replacing already_AddRefed with nsRefPtr causes allows two
On 2014-12-22 4:10 PM, Jeff Muizelaar wrote:
We were talking about this problem and it was a bunch of work to figure out the
conclusion so I decided to write a summary:
Replacing already_AddRefed with nsRefPtr causes allows two new things:
nsRefPtr getT();
1. T* p = getT(); // this is unsafe
We were talking about this problem and it was a bunch of work to figure out the
conclusion so I decided to write a summary:
Replacing already_AddRefed with nsRefPtr causes allows two new things:
nsRefPtr getT();
1. T* p = getT(); // this is unsafe because the destructor runs immediately and
p
I am pleased to announce the final release of MozillaBuild 1.11.0. All
users are encouraged to upgrade as soon as possible due to the included
Mercurial security fix.
http://ftp.mozilla.org/pub/mozilla.org/mozilla/libraries/win32/MozillaBuildSetup-Latest.exe
Important changes since version 1.10.0:
On 2014-12-18 10:37 PM, Jean-Yves Avenard wrote:
Hi
On Friday, December 19, 2014, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote:
That should be it! The plugin is transparent, unless it finds an
error in which case you'll get a normal error diagnostic.
That is weird then. Becau
Just a friendly reminder that over the coming weeks, there will be
reduced full-time sheriff coverage due to the holidays and vacations.
Please make an effort to keep an eye on your pushes to ensure that any
issues are resolved in a timely fashion and minimally impact others.
Thanks!
-Ryan &
On 12/22/2014 5:01 PM, Ehsan Akhgari wrote:
> There are numerous add-ons that depend on nsIDownloadManager,
> unfortunately: Do we have a plan for them?
From the add-ons point of view, the mere removal of nsIDownloadManager
from mozilla-central is a bookkeeping operation.
With regard to add-ons
On 2014-12-22 11:32 AM, Paolo Amadini wrote:
Now that Firefox for Android migrated to the new Downloads.jsm API,
we're going to remove the legacy nsIDownloadManager implementation
from the mozilla-central repository.
This will happen gradually, probably over the next month or two. At the
time of
Now that Firefox for Android migrated to the new Downloads.jsm API,
we're going to remove the legacy nsIDownloadManager implementation
from the mozilla-central repository.
This will happen gradually, probably over the next month or two. At the
time of the Downloads.jsm implementation, a migration
On 12/19/2014 8:19 PM, Jason Orendorff wrote:
> Maybe it's time to retire this feature.
I'd be fine with this.
One of the confusing aspects of these warnings is that they are enabled
or disabled by default based on whether the build is a debug build
("javascript.options.strict" vs "javascript.opt
19 matches
Mail list logo
