Re: Intent to ship: Support for color-adjust CSS property

A note from the developer docs team: when you do this, please be sure that you both share the information about the existence of the preference to the bug about adding the feature -- and be sure to add dev-doc-needed to the bug for removing the preference. If there's not a bug for some reason,

Re: Coding style for C++ enums

Based on all the feedback so far I think the best compromise is to use enum classes with the "e" prefix on the values. As was mentioned, the "e" prefix is useful to distinguish between enum values and function pointer passing at call sites, but is a small enough prefix that it shouldn't be too

Re: Coding style for C++ enums

I agree in the extreme with Jeff here. Foo::Bar, in an expression context, cannot be anything other than a value. For me, at least, I have never noticed this adding any overhead in reviews - it’s immediately obvious what’s happening. I suspect that if it *does* add overhead for you, you’ll find

Re: Triage Plan for Firefox Components

My personal gmail is : anna.j.hite On Friday, April 8, 2016 11:53 PM, Douglas Turner wrote: Emma, Thanks for doing this. I'm not sure whether something like this would work for platform engineering, but we'll keep an eye how things develop with Firefox and might

BMO Version Upgrade Testing and Feedback Needed by April 25th, 2016

Greetings, The Mozilla Bugzilla Team (B-Team) is happy to announce the test release of the next version of bugzilla.mozilla.org (BMO) based on the upstream Bugzilla code base. Although we have backported a lot of cool stuff over the years from upstream, it is still beneficial for Mozilla to run a

Re: Coding style for C++ enums

On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley wrote: > On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert wrote: >> I propose that if you're in a part of the codebase where you can't >> tell if it's an enum or a function pointer (regardless of the fact >>

Why do we still need to include Qt widget in mozilla-central?

Hello. mozilla-central has dropped a lot of platform supports after Gecko 1.9, especially OS/2 which was contributed by some volunteers. However, there is still Qt widget. Looks like that nobody isn't working on Qt widget but when I reorganizing some code, like WidgetEvent related code, I

Re: Coding style for C++ enums

On Mon, Apr 11, 2016 at 1:46 PM, Seth Fowler wrote: > I'd honestly prefer to see this discussion drag on a little longer. The > original email was on Friday, so given that most participants on this list > aren't actively debating C++ coding style on the weekend, we've actually

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

On 4/11/16 4:06 PM, Lawrence Mandel wrote: On Monday, 11 April 2016, Mike Taylor wrote: On 4/11/16 5:04 PM, Mats Palmgren wrote: He touched 283 bugs in the last 48 hours, most of which are FIXED. If anyone in the QA org reads this list, maybe they could reach out and

Re: Coding style for C++ enums

On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert wrote: > I'm not sure how this is compromise. We were already supposed to use > enum classes with new code. > > Every additional glyph incurs mental load. Code should instead be > written so these things are not necessary to

Re: Coding style for C++ enums

On Mon, Apr 11, 2016 at 5:58 PM, Jeff Gilbert wrote: > On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley > wrote: > > On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert > wrote: > >> I propose that if you're in a part of the codebase

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

He seems to have gotten the message: https://bugzilla.mozilla.org/show_bug.cgi?id=1255526#c21 On Mon, Apr 11, 2016 at 6:47 PM, Mark Côté wrote: > Tagging the comments as spam will autoban the account after a certain > number. It will also autocollapse the comments. > > Mark >

Re: Triage Plan for Firefox Components

This also has the effect of being somewhat confusing for the docs team, since we may use your priority labels when planning the order in which to work. Having a standardized system would make our lives easier and improve the quantity and quality of the material we produce to document y'all's work.

[Firefox Desktop] Issues found: April 4th to 8th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA team last week, *April 4th - April 8th* (week 14). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: Coding style for C++ enums

On 04/11/2016 09:01 PM, Milan Sreckovic wrote: Maybe there was a reason we didn’t have this in the style guide as a single choice. My guess is that, even though there has been the Mozilla coding style forever, we haven't traditionally been too strict about following it, so no one cared too

Re: Coding style for C++ enums

Maybe there was a reason we didn’t have this in the style guide as a single choice. — - Milan > On Apr 11, 2016, at 11:00 , Kartikaya Gupta wrote: > > Based on all the feedback so far I think the best compromise is to use > enum classes with the "e" prefix on the values.

Re: Coding style for C++ enums

> All caps actually makes long names *longer* because you now need to > add underscores to separate words, rather than using sentence case. > For example eSentenceCase is the same length as SENTENCE_CASE, but if > you tack on another word the "e" prefix is shorter. Presumably this > line-wrapping

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Sent them an email. On Mon, Apr 11, 2016 at 3:26 PM, Emma Humphries wrote: > Ah, I was looking at open bugs. > > Okay, he's either got a script running or something similar. > > On Mon, Apr 11, 2016 at 3:04 PM, Mats Palmgren wrote: > >> On 2016-04-11 23:32,

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Good intentions or not, we need to stop this activity. Mark - What's our usual approach to address bug spam? Lawrence On Monday, 11 April 2016, Mats Palmgren wrote: > On 2016-04-11 23:32, Emma Humphries wrote: > >> Here's the open bugs they have touched http://mzl.la/1Q3w24o

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Tagging the comments as spam will autoban the account after a certain number. It will also autocollapse the comments. Mark On 2016-04-11 6:35 PM, Lawrence Mandel wrote: > Good intentions or not, we need to stop this activity. > > Mark - What's our usual approach to address bug spam? > >

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

On 4/11/16 5:04 PM, Mats Palmgren wrote: He touched 283 bugs in the last 48 hours, most of which are FIXED. If anyone in the QA org reads this list, maybe they could reach out and teach him how to more effectively contribute? (I see "[bugday-20160323]" from

Re: Coding style for C++ enums

I'd honestly prefer to see this discussion drag on a little longer. The original email was on Friday, so given that most participants on this list aren't actively debating C++ coding style on the weekend, we've actually had less than one full working day of discussion on this issue so far. Let me

W3C Proposed Recommendation: Battery Status API

A W3C Proposed Recommendation is available for the membership of W3C (including Mozilla) to vote on, before it proceeds to the final stage of being a W3C Recomendation: Battery Status API https://www.w3.org/TR/battery-status/ deadline: Tuesday, April 26, 2016 If there are comments you

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

On 2016-04-11 23:32, Emma Humphries wrote: Here's the open bugs they have touched http://mzl.la/1Q3w24o He touched 283 bugs in the last 48 hours, most of which are FIXED. Many comments are identical, for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1240762

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Ah, I was looking at open bugs. Okay, he's either got a script running or something similar. On Mon, Apr 11, 2016 at 3:04 PM, Mats Palmgren wrote: > On 2016-04-11 23:32, Emma Humphries wrote: > >> Here's the open bugs they have touched http://mzl.la/1Q3w24o >> > > He touched

Re: Coding style for C++ enums

I'm not sure how this is compromise. We were already supposed to use enum classes with new code. Every additional glyph incurs mental load. Code should instead be written so these things are not necessary to explicitly state. *That* is the code we should be trying to write. In well-written code,

Fwd: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Has anyone contacted the commenter and found out what he's trying to do? I've received bugmail for a lot of comments like the one below today; I assume others have too. They're not very helpful, especially given their length. It seems like he's intending to be helpful, but got some bad advice.

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

Here's the open bugs they have touched http://mzl.la/1Q3w24o I realized this morning at the Project Meeting that we still have Monday's listed as bug triage days and I think there's some supporting structure around it that we need to give it. Let me think about that, so we can keep y'all from

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

On Monday, 11 April 2016, Mike Taylor wrote: > On 4/11/16 5:04 PM, Mats Palmgren wrote: > >> He touched 283 bugs in the last 48 hours, most of which are FIXED. >> > > If anyone in the QA org reads this list, maybe they could reach out and > teach him how to more effectively

Re: Coding style for C++ enums

On 2016-04-11 19:47, Seth Fowler wrote: Let me suggest again (especially since I'm not sure my previous email reached this list yet) that rather than compromise on the "e" prefix, we compromise on all caps for values, which is just as readable without placing even more pressure on our