Intent to implement and ship: navigator.languages and languagechange

Hi dev-platform, As of today, I intend to land patches to implement navigator.languages and the languagechange event (on the Window object). This feature will not live behind a flag given that it is not complex nor controversial. Bug : https://bugzilla.mozilla.org/show_bug.cgi?id=889335 Spec: htt

Re: Proposed W3C Charter: CSS Working Group

On Fri, May 9, 2014 at 2:22 AM, L. David Baron wrote: > http://www.w3.org/Style/2013/css-charter.html Can we expect CSS to move to asynchronous decision making as practiced in e.g. WebApps at some point? The idea one has to attend teleconferences and fly to meetings seems ever less tenable. -

Re: Intent to implement: WebGL 2.0

On Fri, May 9, 2014 at 1:48 AM, Jonas Sicking wrote: > Based on what has been discussed in this thread so far, specifically that: > * We expect each new version of WebGL to be fully backwards compatible. Do we? I certainly hope that is the case, but it did not seem like a given or stated requirem

Re: nsRefPtr vs RefPtr

2014-05-11 23:40 GMT-04:00 Boris Zbarsky : > On 5/11/14, 7:50 PM, Chris Pearce wrote: > >> Should we be preferring mozilla::RefPtr in new code? >> >> Should we be replacing nsRefPtr with mozilla::RefPtr? >> > > I would err on "no" for both, given https://bugzilla.mozilla.org/ > show_bug.cgi?id=820

Query about MimeType objects (was Fwd: Intro email)

Hi all Dann (see below) had a query about the MimeType objects returned by NavigatorPlugins.mimeTypes. Does anyone here have any advice about dealing with those? Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills Begin forwarde

Re: Proposed W3C Charter: CSS Working Group

On May 12, 2014, at 11:06 AM, Anne van Kesteren wrote: > On Fri, May 9, 2014 at 2:22 AM, L. David Baron wrote: >> http://www.w3.org/Style/2013/css-charter.html > > Can we expect CSS to move to asynchronous decision making as practiced > in e.g. WebApps at some point? The idea one has to atten

Re: Query about MimeType objects (was Fwd: Intro email)

Hi Chris, The spec might: . HTH Ms2ger On 05/12/2014 12:18 PM, Chris Mills wrote: Hi all Dann (see below) had a query about the MimeType objects returned by NavigatorPlugins.mimeTypes. Does anyone here have any advice about dealing with t

Re: Proposed W3C Charter: CSS Working Group

On 12/05/2014 13:04 , Dirk Schulze wrote: The CSS WG already decided to use asynchronous decision making as one possibility at TPAC 2013. I am in favor for this process but it was also decided that it is not the main possibility for decision making and won’t replace F2Fs (yet). So far, this possi

Re: Proposed W3C Charter: CSS Working Group

On Monday 2014-05-12 11:04 +, Dirk Schulze wrote: > On May 12, 2014, at 11:06 AM, Anne van Kesteren wrote: > > On Fri, May 9, 2014 at 2:22 AM, L. David Baron wrote: > >> http://www.w3.org/Style/2013/css-charter.html > > > > Can we expect CSS to move to asynchronous decision making as practi

Re: Proposed W3C Charter: CSS Working Group

On Mon, May 12, 2014 at 1:54 PM, L. David Baron wrote: > It is part of the charter as one possibility: > > # In addition to decisions made on teleconferences or face to face > # meetings, decisions may also be made by a call for consensus on > # the public mailing list; consensus to be deter

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 3:42 AM, Benoit Jacob wrote: > 2014-05-11 23:40 GMT-04:00 Boris Zbarsky : > >> On 5/11/14, 7:50 PM, Chris Pearce wrote: >> >>> Should we be preferring mozilla::RefPtr in new code? >>> >>> Should we be replacing nsRefPtr with mozilla::RefPtr? >>> >> >> I would err on "no" fo

Rendering meeting, *next* Monday 2:30pm PDT

The Rendering meeting is about all things Gfx, Image, Layout, and Media. It takes place every second Monday, at 2:30pm PDT. The next meeting will take place *next* Monday, May 19th at 2:30 PM US/Pacific Please add to the agenda: https://wiki.mozilla.org/Platform/GFX/2014-May-19#Agenda ; curre

FYI: intermittent build farm capacity reductions during data center move starts May 19

As you heard in today's project meeting, IT's consolidation of data centers will save us $900K/yr!! Yay! There will be some impact to the build farm as the move actually happens, and this posting outlines them. The impact to engineering will be a slight capacity reduction in the build far for the

Re: Intent to implement and ship: navigator.languages and languagechange

I'm in favor of this! / Jonas On Mon, May 12, 2014 at 12:46 AM, Mounir Lamouri wrote: > Hi dev-platform, > > As of today, I intend to land patches to implement navigator.languages > and the languagechange event (on the Window object). > This feature will not live behind a flag given that it is n

FYI: intermittent build farm capacity reductions during data center move starts May 19

As you heard in today's project meeting, IT's consolidation of data centers will save us $900K/yr!! Yay! There will be some impact to the build farm as the move actually happens, and this posting outlines them. The impact to engineering will be a slight capacity reduction in the build far for the

Re: nsRefPtr vs RefPtr

On 2014-05-12, 9:36 AM, Kyle Huey wrote: Since bug 806279 it's fairly trivial to extend CC support to new pointer and container types. Just implement ImplCycleCollectionUnlink and ImplCycleCollectionTraverse. The possibly bigger difficulty he

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 1:03 PM, Ehsan Akhgari wrote: > On 2014-05-12, 9:36 AM, Kyle Huey wrote: >>> >>> Since bug 806279 >>> it's fairly trivial to extend CC support to new pointer and container types. Just implement ImplCycleCo

Adding a recommendation that one-argument constructors be explicit to the C++ style guide

Background: in C++, one-argument constructors are implicit. What this means is that given this class declaration: class Foo { public: Foo(int arg); passAFoo(const Foo& arg); }; This bit of C++: Foo foo(5); foo.passAFoo(10); will compile and construct a temporary Foo that it

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On Mon, May 12, 2014 at 1:07 PM, Boris Zbarsky wrote: > Background: in C++, one-argument constructors are implicit. > > What this means is that given this class declaration: > > class Foo { > public: > Foo(int arg); > > passAFoo(const Foo& arg); > }; > > This bit of C++: > > Foo fo

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

On 05/12/2014 03:07 PM, Boris Zbarsky wrote: So I'd like to propose that our C++ style require one-arg constructors to be marked explicit unless there's a clear comment explaining why the constructor is implicit. I agree 100%, especially when we're talking about things that aren't value types

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

Me too. Implicit type conversion through one-arg constructors is the source of subtle bugs. -dave On 05/12/2014 01:16 PM, Kyle Huey wrote: > On Mon, May 12, 2014 at 1:07 PM, Boris Zbarsky wrote: >> Background: in C++, one-argument constructors are implicit. >> >> What this means is that given t

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

I would make the mistake, so I'm all for it. Cheers, David On 12/05/14 22:07, Boris Zbarsky wrote: > > So I'd like to propose that our C++ style require one-arg constructors > to be marked explicit unless there's a clear comment explaining why the > constructor is implicit. > > Thoughts? > > -

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: > We should get rid of RefPtr, just like we did the MFBT refcounting classes. > > The main thing stopping a mechanical search and replace is that the > two smart pointers have different semantics around > already_AddRefed/TemporaryRef :(

Re: Adding a recommendation that one-argument constructors be explicit to the C++ style guide

+1 Aaron On 5/12/14 2:07 PM, Boris Zbarsky wrote: Background: in C++, one-argument constructors are implicit. What this means is that given this class declaration: class Foo { public: Foo(int arg); passAFoo(const Foo& arg); }; This bit of C++: Foo foo(5); foo.passAFoo(10)

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: > On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: >> We should get rid of RefPtr, just like we did the MFBT refcounting classes. >> >> The main thing stopping a mechanical search and replace is that the >> two smart pointers have diffe

Re: nsRefPtr vs RefPtr

On Mon, May 12, 2014 at 04:46:18PM -0700, Kyle Huey wrote: > On Mon, May 12, 2014 at 2:46 PM, Mike Hommey wrote: > > On Mon, May 12, 2014 at 09:36:22AM -0700, Kyle Huey wrote: > >> We should get rid of RefPtr, just like we did the MFBT refcounting classes. > >> > >> The main thing stopping a mecha

Intent to implement and ship: navigator.hardwareConcurrency

Primary eng emails caban...@adobe.com, bugm...@eligrey.com *Proposal* http://wiki.whatwg.org/wiki/NavigatorCores *Summary* Expose a property on navigator called hardwareConcurrency that returns the number of logical cores on a machine. *Motivation* All native platforms expose this property, It's

Re: Intent to implement and ship: navigator.hardwareConcurrency

On 5/12/2014 7:03 PM, Rik Cabanier wrote: *Concerns* The original proposal required that a platform must return the exact number of logical CPU cores. To mitigate the fingerprinting concern, the proposal was updated so a user agent can "lie" about this. In the case of WebKit, it will return a max

Re: Intent to implement and ship: navigator.hardwareConcurrency

On Mon, May 12, 2014 at 10:15 PM, Joshua Cranmer 🐧 wrote: > On 5/12/2014 7:03 PM, Rik Cabanier wrote: > >> *Concerns* >> >> The original proposal required that a platform must return the exact >> number >> of logical CPU cores. To mitigate the fingerprinting concern, the proposal >> was updated so