This was done. My eyes are still bleeding from the review.
On 9/4/13 5:36 PM, Andreas Gal wrote:
Can you delete this boilerplate from existing makefiles if not already
done? That will prevent people from adding it since people look at
examples when adding new makefiles.
Andreas
Mike Hommey wr
Can you delete this boilerplate from existing makefiles if not already
done? That will prevent people from adding it since people look at
examples when adding new makefiles.
Andreas
Mike Hommey wrote:
Hi,
Assuming it sticks, bug 912293 made it unnecessary to start Makefile.in
files with th
Hi,
Assuming it sticks, bug 912293 made it unnecessary to start Makefile.in
files with the usual boilerplate:
DEPTH = @DEPTH@
topsrcdir = @top_srcdir@
srcdir = @srcdir@
VPATH = @srcdir@
relativesrcdir = @relativesrcdir@
include $(DEPTH)/config/autoconf.mk
All of the above can now be
On Wed, Sep 04, 2013 at 11:35:19AM -0700, Gregory Szorc wrote:
> On 9/4/13 3:04 AM, Mike Hommey wrote:
> >On Wed, Sep 04, 2013 at 10:57:26AM +0100, L. David Baron wrote:
> >>>The way the tier build works is that we effectively make export in all
> >>>directories of a same tier before make libs. In
In bug 883920, I converted these two macros into more contemporary templates.
What was
NS_HOLD_JS_OBJECTS(this, nsFoo);
or
nsContentUtils::HoldJSObjects(this, NS_CYCLE_COLLECTION_PARTICIPANT(nsFoo));
can now just be
mozilla::HoldJSObjects(this);
What was
NS_DROP_JS_OBJECTS(this, nsFoo);
On 9/2/13 13:36, Joshua Cranmer 🐧 wrote:
I don't think there *is* a sane approach that satisfies everybody.
Either you break "UTF8-just-works-everywhere", you break legacy
content, you make parsing take inordinate times...
I want to push on this last point a bit. Using a straightforward UTF-8
On Thu, Sep 5, 2013 at 7:40 AM, Ehsan Akhgari wrote:
> On 2013-09-04 12:18 AM, Robert O'Callahan wrote:
>
>> I like to put "virtual" on all methods that are virtual, even when it's
>> not
>> strictly necessary because the method overrides a virtual method of the
>> parent class.
>>
>> Other peopl
+1 for always using virtual (useful documentation without having to check the
super class), even with MOZ_OVERRIDE (just style).
Also +1 for /* static */ on method definitions (when they are declared static)
because that is useful information. /* virtual */ on definitions, I don't find
useful b
On 2013-09-04 12:18 AM, Robert O'Callahan wrote:
I like to put "virtual" on all methods that are virtual, even when it's not
strictly necessary because the method overrides a virtual method of the
parent class.
Other people disagree, especially when the method has MOZ_OVERRIDE on it as
well.
On 09/04/2013 09:43 AM, Jan Odvarko wrote:
It's currently possible to get registered event listeners for
specific target (element, window, xhr, etc.)
using nsIEventListenerService.getListenerInfoFor
Is there any API that would allow to get also mutation observers?
no
Should I file a bug
On 9/4/13 3:04 AM, Mike Hommey wrote:
On Wed, Sep 04, 2013 at 10:57:26AM +0100, L. David Baron wrote:
The way the tier build works is that we effectively make export in all
directories of a same tier before make libs. In practice, this means
xpcom had access to every header in platform already,
Because you don't know the underlying type of, say, uint32_t, it's historically
been difficult to printf them. Common approaches included just assuming %u
would work (and wouldn't generate format-mismatch compiler warnings), or using
%lu and casting to (unsigned long). Bleh.
C99's has macros
On 09/04/2013 05:24 AM, Benjamin Smedberg wrote:
>> MOZ_OVERRIDE implies virtual, you get a compile error when you put
>> MOZ_OVERRIDE on a non virtual
> It does? That surprises me (it certainly wasn't the original intent of
> NS_OVERRIDE). There are certainly cases where we want to override non-
On 28/08/2013 19.17, sam foster wrote:
> However, although Downloads.jsm itself is importable from toolkit,
> DownloadsCommon.jsm - which implements a lot of the goodies around it - is
> not. Looking though it I see only a couple of methods and
> specific-to-desktop-UI references that would pre
On 03/09/2013 18.08, teramako wrote:
> I want to notify to the user when the download is finished.
>
> on nsIDownloadManager, I write like following:
>
> Services.downloads.addListener({
> onDownloadStateChange: function (state, download) {
>if (download.state === Services.downloads.DOWNLOAD
On 9/4/2013 12:45 AM, Chris Pearce wrote:
On 04-Sep-13 4:18 PM, Robert O'Callahan wrote:
I like to put "virtual" on all methods that are virtual, even when
it's not
strictly necessary because the method overrides a virtual method of the
parent class.
Other people disagree, especially when the
On Wed, Sep 4, 2013 at 11:34 PM, wrote:
> I'm working on bug 853356 which requires to pass new permissions
> 'audio-capture' and 'video-capture' together to permission prompt dialog
> via getUserMedia.
>
> My current implementation is to replaced the string 'type' [1] with a
> string array 'types
cc :dougt and :roc.
- Original Message -
From: ay...@mozilla.com
To: dev-platform@lists.mozilla.org
Sent: Wednesday, September 4, 2013 7:34:51 PM
Subject: Pass more than one permissions to prompt dialog.
Hi,
I'm working on bug 853356 which requires to pass new permissions
'audio-capture'
Hi,
I'm working on bug 853356 which requires to pass new permissions
'audio-capture' and 'video-capture' together to permission prompt dialog via
getUserMedia.
My current implementation is to replaced the string 'type' [1] with a string
array 'types'.
interface nsIContentPermissionRequest : n
On Wed, Sep 04, 2013 at 10:57:26AM +0100, L. David Baron wrote:
> > The way the tier build works is that we effectively make export in all
> > directories of a same tier before make libs. In practice, this means
> > xpcom had access to every header in platform already, and any tier built
> > before
On Wednesday 2013-09-04 18:45 +0900, Mike Hommey wrote:
> On Wed, Sep 04, 2013 at 10:28:21AM +0100, L. David Baron wrote:
> > On Wednesday 2013-09-04 00:31 -0700, Gregory Szorc wrote:
> > > Assuming it sticks, bug 896797 just landed in inbound and changes
> > > how EXPORTS/headers are installed. Th
On Wed, Sep 04, 2013 at 10:28:21AM +0100, L. David Baron wrote:
> On Wednesday 2013-09-04 00:31 -0700, Gregory Szorc wrote:
> > Assuming it sticks, bug 896797 just landed in inbound and changes
> > how EXPORTS/headers are installed. This may impact your developer
> > workflow if you modify EXPORTS
On Wednesday 2013-09-04 00:31 -0700, Gregory Szorc wrote:
> Assuming it sticks, bug 896797 just landed in inbound and changes
> how EXPORTS/headers are installed. This may impact your developer
> workflow if you modify EXPORTS in a moz.build file to add/remove
> headers.
>
> Previously, headers we
FWIW, I like to write both virtual and MOZ_OVERRIDE.
I care a lot about always using MOZ_OVERRIDE when applicable. For virtual
(when MOZ_OVERRIDE is present) I suppose it is more of a matter of tastes.
Always explicitly writing both virtual and MOZ_OVERRIDE is a simpler rule
than marking virtual on
On Wednesday 2013-09-04 14:28 +1000, Cameron McCormack wrote:
> Bobby Holley wrote:
> >+1. EIBTI.
>
> I agree, though MOZ_OVERRIDE does imply that the function is virtual
> already, so it may not be so necessary there.
I also support repeating virtual as good documentation.
The introduction of M
On Wed, Sep 04, 2013 at 12:31:02AM -0700, Gregory Szorc wrote:
> Assuming it sticks, bug 896797 just landed in inbound and changes
> how EXPORTS/headers are installed. This may impact your developer
> workflow if you modify EXPORTS in a moz.build file to add/remove
> headers.
>
> Previously, heade
Assuming it sticks, bug 896797 just landed in inbound and changes how
EXPORTS/headers are installed. This may impact your developer workflow
if you modify EXPORTS in a moz.build file to add/remove headers.
Previously, headers were installed incrementally as part of make
directory traversal. In
27 matches
Mail list logo