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.
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, headers
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
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 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 were
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 in a
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. This may
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 :
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
On Wed, Sep 4, 2013 at 11:34 PM, ay...@mozilla.com 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
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 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 ===
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
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
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,
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 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.
+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
On Thu, Sep 5, 2013 at 7:40 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
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.
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
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 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 practice,
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
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
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
25 matches
Mail list logo
