Re: Why is Mozreview hassling me about squashed commits?

On Mon, Apr 4, 2016 at 9:23 PM, Mark Côté <mc...@mozilla.com> wrote: > On 2016-04-04 10:07 AM, Eric Rescorla wrote: > > On Sun, Apr 3, 2016 at 10:09 PM, L. David Baron <dba...@dbaron.org> > wrote: > > > >> On Saturday 2016-04-02 18:51 -0300, Eric Rescorla

Re: Why is Mozreview hassling me about squashed commits?

On Sun, Apr 3, 2016 at 10:09 PM, L. David Baron <dba...@dbaron.org> wrote: > On Saturday 2016-04-02 18:51 -0300, Eric Rescorla wrote: > > 1. I write a bunch of code, committing along the way, so I have a lot of > > commits named "Checkpoint" and "Fix bug&qu

Re: Why is Mozreview hassling me about squashed commits?

On Sun, Apr 3, 2016 at 9:32 PM, Karl Tomlinson <mozn...@karlt.net> wrote: > Eric Rescorla writes: > > > I don't believe I am asking for this, just auto-squash on submit. I > > certainly understand if it's your position that you have higher > priorities, > &g

Re: Why is Mozreview hassling me about squashed commits?

n't believe I am asking for this, just auto-squash on submit. I certainly understand if it's your position that you have higher priorities, that's fine, but it's not fine to remove the ability to do squashed reviews before something like that lands. -Ekr > > > On Sat, Apr 2, 2016 at 9:3

Why is Mozreview hassling me about squashed commits?

"This is a squashed review request, containing the sum of all commits in the series. It is intended only to provide an overview of a series of commits. At the moment, you *can*leave review comments here, which will be mirrored to Bugzilla, but they will not affect the review status of individual

Re: Removing the Chromium event loop

On Wed, Mar 30, 2016 at 2:03 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > On Wed, Mar 30, 2016 at 1:48 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd <nfr...@mozilla.com> wrote: >> >> > On We

Re: Removing the Chromium event loop

On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd wrote: > On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg > wrote: > > I've been unhappy with the fact that our event loop uses refcounted > objects > > by default. *Most* runnables are pure-C++ and

Re: Triage Plan for Firefox Components

olbox, Firefox, Fennec > and the pieces of platform we're using to ship. > > While there's not a 'Gecko' component in bugzilla, it does cover the > components there which are Gecko. > > -- Emma > > On Tue, Mar 29, 2016 at 3:16 PM, Eric Rescorla <e...@rtfm.com> wro

Re: Triage Plan for Firefox Components

I'm trying to figure out the scope of this proposal. Are you expecting it to apply merely to Firefox or to Gecko as well? -Ekr On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries wrote: > tl;dr > > In Quarter Two I'm implementing the work we’ve been doing to improve > triage,

Re: #include sorting: case-sensitive or -insensitive?

On Mon, Mar 28, 2016 at 3:31 PM, Masatoshi Kimura wrote: > On 2016/03/29 7:18, Jared Wein wrote: > > We need to be careful with shuffling around #includes as there can be > > ordering dependencies that are not obvious at a glance. > > Especially, #include "Foo.h" should be

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

On Thu, Mar 3, 2016 at 11:39 PM, Lars Hansen wrote: > On Fri, Mar 4, 2016 at 1:41 AM, Richard Barnes > wrote: > > > Another good reason for blocking this for now is that it lets Javascript > > circumvent the 5usec granularity of performance.now() and do

Re: Proposed W3C Charter: Hardware Security Working Group

Richard, Is an browser actually interested in implementing the output of this WG? -Ekr On Tue, Mar 1, 2016 at 3:32 PM, Richard Barnes wrote: > Mozilla should oppose the formation of this working group. The charter > fails to specify concrete deliverables, and many of

Re: Intent to implement and ship: FIDO U2F API

On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir wrote: > Hi, > > Great news about you making progress on this ! > > Since I read here and there that you are working with Firefox & Chrome U2F > support consistency in mind, what's your take on TLS Channel ID (Token >

Re: Intent to implement and ship: FIDO U2F API

Mozilla/Firefox implementation... Not really. See above. They can decide that, even if questionable...) > Well, it's worth noting that while they are different mechanisms, U2F + pinning offers much of the MITM protection that Token Binding provides, and Firefox already pins Google services. -Ekr

Re: Just Autoland It

On Fri, Jan 29, 2016 at 6:22 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > On 28/01/16 06:31 PM, Eric Rescorla wrote: > >> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc <gsz...@mozilla.com> >> wrote: >> >> I'd like to thank everyon

Re: Just Autoland It

On Fri, Jan 29, 2016 at 8:12 AM, Dave Townsend <dtowns...@mozilla.com> wrote: > On Fri, Jan 29, 2016 at 7:27 AM, Eric Rescorla <e...@rtfm.com> wrote: > > More generally, I keep seeing comments (especially from GPS) about > > trying to push people towards some wor

Re: Bug Program Next Steps

On Fri, Jan 29, 2016 at 3:53 PM, Kyle Huey wrote: > On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries wrote: > >> We believe that the number of outstanding, actionable bugs is the best >> metric of code quality available, and that how this number changes over

Re: Just Autoland It

ly seem odd to us. So, if > your bug report could articulate why you want something and how many people > would benefit (e.g. "the layout team all does this"), it would help us > better empathize with your position and would increase the chances of your > request getting priorit

Re: Just Autoland It

On Thu, Jan 28, 2016 at 8:25 AM, Honza Bambas wrote: > On 1/28/2016 6:30, Karl Tomlinson wrote: > >> Honza Bambas writes: >> >> On 1/25/2016 20:23, Steve Fink wrote: >>> For navigation, there's a list of changed files at the top (below the fixed summary pane) that

Re: Moving FirefoxOS into Tier 3 support

On Mon, Jan 25, 2016 at 9:34 AM, Nathan Froyd wrote: > On Mon, Jan 25, 2016 at 12:30 PM, Ehsan Akhgari > wrote: > > > For example, for a long time b2g partners held back our minimum supported > > gcc. Now that there are no such partner requirements,

Re: Just Autoland It

On Mon, Jan 25, 2016 at 1:58 PM, Mike Hommey wrote: > On Mon, Jan 25, 2016 at 11:23:59AM -0800, Steve Fink wrote: > > Heh. Your list of UI complaints is very similar to mine. Some comments: > > > > > > On 01/25/2016 04:26 AM, Honza Bambas wrote: > > >Writing both as a patch

Re: Just Autoland It

<https://chromium-cq-status.appspot.com/>. The commit queue will wait automatically for the tree to reopen. 4. Wait for an email from commit-...@chromium.org with success or failure. -Ekr On Sat, Jan 23, 2016 at 8:07 AM, Eric Rescorla <e...@rtfm.com> wrote:

Re: Just Autoland It

On Sat, Jan 23, 2016 at 10:20 AM, Gregory Szorc wrote: > On Fri, Jan 22, 2016 at 1:45 PM, Boris Zbarsky wrote: > > > On 1/22/16 3:52 PM, Gregory Szorc wrote: > > > >> I would say that pushing cherry-picked commits for review that depend on > >> other commits

Re: Just Autoland It

On Sat, Jan 23, 2016 at 4:42 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Sat, Jan 23, 2016 at 4:01 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Sat, Jan 23, 2016 at 10:20 AM, Gregory Szorc <g...@mozilla.com> wrote: >> >>&

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:31 AM, Bobby Holley wrote: > On Mon, Jan 4, 2016 at 9:11 AM, Richard Barnes > wrote: > > > Hey Daniel, > > > > Thanks for the heads-up. This is a useful thing to keep in mind as we > work > > through the SHA-1 deprecation. >

Re: Heads-up: SHA1 deprecation (for newly issued certs) causes trouble with local ssl-proxy mitm spyware

On Mon, Jan 4, 2016 at 9:47 AM, Mike Hoye wrote: > On 2016-01-04 12:31 PM, Bobby Holley wrote: > >> By "this sort of software" do you mean "Firefox"? Because that's what 95% >> of our users experiencing this are going to do absent anything clever on >> our end. We clearly need

Re: WebUSB

On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson <m...@mozilla.com> wrote: > On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > > On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > >> (4

Re: WebUSB

On Mon, Dec 14, 2015 at 8:15 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Mon, Dec 14, 2015 at 11:09 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> This is certainly something one could consider, but it it seems like it >> confers a major >> advant

Re: WebUSB

On Mon, Dec 14, 2015 at 8:02 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Mon, Dec 14, 2015 at 9:29 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson <m...@mozilla.com> wrote: >> >>> On Thu, De

Re: WebUSB

r On Fri, Dec 4, 2015 at 2:25 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Fri, Dec 4, 2015 at 1:56 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> >>

Re: WebUSB

On Wed, Dec 2, 2015 at 2:13 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Wed, Dec 2, 2015 at 10:00 AM, Eric Rescorla <e...@rtfm.com> wrote: > >> On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> >> I

Re: Intent to implement and ship: FIDO U2F API

On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla <e...@rtfm.com> wrote: > >> Are you thinking of something like WebUSB? >> (https://reillyeon.github.io/webusb/)? This is something we'v

Re: Intent to implement and ship: FIDO U2F API

On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin wrote: > > > There are probably other questions Mozilla Core Team should ask to > > > themselves : > > > > > > - Having a greater/larger HID Support, outside the FIDO U2F scope ? > > > (This allows web services to

Re: Dan Stillman's concerns about Extension Signing

falls afoul of the threat model point I made below. > With add-on singing fully implemented, if (when) malicious add-ons get > automatically signed, you'll have several more effective tools to deal with > them, compared to the status quo. > Yes. -Ekr > Gavin > > On Nov 27, 2015,

Re: Dan Stillman's concerns about Extension Signing

On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch wrote: > On 27/11/2015 23:46, dstill...@zotero.org wrote: > >> The issue here is that this new system -- specifically, an automated >> scanner sending extensions to manual review -- has been defended by >> Jorge's saying,

Re: Dan Stillman's concerns about Extension Signing

he basic facts I asked for need to be restricted, and those are all that is needed to evaluate the question at hand. -Ekr > > On Sat, Nov 28, 2015 at 10:35 AM, Eric Rescorla <e...@rtfm.com> wrote: > > On Sat, Nov 28, 2015 at 2:06 AM, Gijs Kruitbosch < > gijskruitbo...@gmail.com

Re: Dan Stillman's concerns about Extension Signing

How odd that your e-mail was in response to mine, then. -Ekr On Sat, Nov 28, 2015 at 11:34 AM, Gavin Sharp <ga...@gavinsharp.com> wrote: > I wasn't suggesting that you had made that incorrect assumption. > > Gavin > > On Sat, Nov 28, 2015 at 10:31 AM, Eric Rescorla

Re: Dan Stillman's concerns about Extension Signing

On Sat, Nov 28, 2015 at 5:28 PM, Mike Hoye <mh...@mozilla.com> wrote: > On 2015-11-28 2:40 PM, Eric Rescorla wrote: > >> How odd that your e-mail was in response to mine, then. >> >> Thanks, super helpful, really moved the discussion forward, high five. Glad I

Re: Dan Stillman's concerns about Extension Signing

On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari wrote: > On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp > wrote: > > > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham > wrote: > > > But the thing is, members of our security group

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc wrote: > On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey wrote: > > > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote: > > > I support going back to a giant monolithic repository if we can

Re: Merging comm-central into mozilla-central

Thanks for clarifying. Based on this, it seems like another way to solve this would be to simply stop worrying about breaking comm-central. Wouldn't that be even easier? -Ekr On Fri, Oct 23, 2015 at 3:38 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Fri, Oct 23, 2015 at 11:13

Re: Merging comm-central into mozilla-central

On Fri, Oct 23, 2015 at 11:45 AM, Bobby Holley wrote: > On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer  > wrote: > > Except that to demand contributors don't care about comm-central would be > > to demand of your employees that they should be jerks

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander wrote: > > > On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey wrote: > >> Hi, >> >> I started a thread with the same subject almost two years ago. The >> motivation hasn't changed, but the context surely

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 3:18 PM, Nicholas Alexander <nalexan...@mozilla.com> wrote: > > > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander < >> nalexan...@mozi

Re: Decommissioning "dumbmake"

On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > What's needed here is a dependency management system that > > simply builds what's ne

Re: PSA: Local static analysis builds on Linux and Mac OS X

On Wed, Oct 14, 2015 at 6:37 PM, Martin Thomson wrote: > On Wed, Oct 14, 2015 at 6:32 PM, Gregory Szorc wrote: > > As you stated, this helps detect errors earlier during development, which > > is a huge win. Is there a good reason configure doesn't enable the

Re: NPAPI plugin use case: native chipcard reader

On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch wrote: > Are you effectively saying that you use crypto for signing financial > transactions, and the PIN is used for authenticating the user but not > involved in the actual signature/crypto algorithm? Therefore, if a

Re: NPAPI plugin use case: native chipcard reader

On Mon, Oct 12, 2015 at 5:01 AM, Gijs Kruitbosch <gijskruitbo...@gmail.com> wrote: > On 12/10/2015 12:34, Eric Rescorla wrote: > >> On Mon, Oct 12, 2015 at 4:22 AM, Gijs Kruitbosch < >> gijskruitbo...@gmail.com> >> wrote: >> >> Are you effectively

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

Note: I'm not taking a position on the language feature, just between your two designs. -Ekr On Sun, Oct 11, 2015 at 5:34 AM, Eric Rescorla <e...@rtfm.com> wrote: > > On Sun, Oct 11, 2015 at 4:28 AM, Aryeh Gregor <a...@aryeh.name> wrote: > >> On Sun, Oct 11, 20

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

On Sun, Oct 11, 2015 at 4:28 AM, Aryeh Gregor wrote: > On Sun, Oct 11, 2015 at 2:09 PM, Aryeh Gregor wrote: > > A new language feature could be used to solve this: allow conversion > > operators to behave differently based on how the variable is declared. > >

Re: Disabling C++ tests by default?

On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey wrote: > On Thu, Oct 01, 2015 at 10:10:39PM -0700, Gregory Szorc wrote: > > Currently, the Firefox build system builds C++ tests by default. This > adds > > extra time to builds for something that a significant chunk of developers >

Re: Disabling C++ tests by default?

On Fri, Oct 2, 2015 at 9:08 AM, Randell Jesup wrote: > >On Thu, Oct 1, 2015 at 10:25 PM, Mike Hommey wrote: > > > >> On Thu, Oct 01, 2015 at 10:10:39PM -0700, Gregory Szorc wrote: > >> > Currently, the Firefox build system builds C++ tests by > >> > default.

Re: Disabling C++ tests by default?

On Fri, Oct 2, 2015 at 3:31 PM, Mike Hommey <m...@glandium.org> wrote: > On Fri, Oct 02, 2015 at 10:01:45AM -0700, Eric Rescorla wrote: > > > Because the win is small, it shouldn't be a priority, but requiring > > > something like --enable-cpp-tests should

Re: NPAPI plug-in use case: live video broadcast

On Tue, Sep 29, 2015 at 3:44 AM, Oliver Lietz wrote: > > > > > > > Firefox WebRTC supports H.264. > Yes but only Baseline profile and not with high quality. > I believe that OpenH264 has started to add some high profile features, but yes, it's not currently HP. Focus is for

Re: NPAPI plug-in use case: live video broadcast

On Fri, Sep 25, 2015 at 3:20 PM, <li...@nanocosmos.de> wrote: > On Saturday, September 19, 2015 at 8:15:50 PM UTC+2, Eric Rescorla wrote: > > On Sat, Sep 19, 2015 at 11:09 AM, Oliver Lietz <oli...@gmail.com> wrote: > > > > > Hi, > > > our nanoStrea

Re: Intent to ship: Directory picking and directory drag-and-drop

On Tue, Sep 22, 2015 at 7:07 AM, Jonas Sicking <jo...@sicking.cc> wrote: > > On Sep 21, 2015 11:57, "Eric Rescorla" <e...@rtfm.com> wrote: > > > > On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> > wrote: > >> > >

Re: Intent to ship: Directory picking and directory drag-and-drop

On Mon, Sep 21, 2015 at 8:48 PM, Eric Shepherd <esheph...@mozilla.com> wrote: > Eric Rescorla wrote: > > I think there are some fairly obvious issues here, including: > > - There are obvious sensitive files you shouldn't upload under > basically any conditions. >

Re: Intent to ship: Directory picking and directory drag-and-drop

On Mon, Sep 21, 2015 at 3:58 PM, Jonathan Watt <jw...@jwatt.org> wrote: > On 21/09/2015 19:57, Eric Rescorla wrote: > >> On Mon, Sep 21, 2015 at 11:23 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> Note that this, similarly to clipboard integration, is al

Re: Intent to ship: Directory picking and directory drag-and-drop

This seems like a fantastically dangerous feature and ripe for abuse. Are we doing anything in the UI to make very clear to users what's going on? Is there going to be a way to disable it? -Ekr On Mon, Sep 21, 2015 at 8:37 AM, Jonathan Watt wrote: > Targeting Firefox 44 we

Re: Intent to ship: Directory picking and directory drag-and-drop

feature Flash has, including features we think are bad. -Ekr > That said, if there are ways we can improve the UI here to further > explain to users what is going on, then that sounds good to me. > > / Jonas > > > > On Mon, Sep 21, 2015 at 8:49 AM, Eric Rescorla

Re: NPAPI plug-in use case: live video broadcast

On Sat, Sep 19, 2015 at 11:09 AM, Oliver Lietz wrote: > Hi, > our nanoStream plugin supports live encoding and streaming with > h264/aac/rtmp from live camera sources and capture devices. > We needed to replace this with a native extension on Chrome. > WebRTC is a possible

Re: You can now freely mix declarations and statements in all Mozilla C code

On Wed, Sep 9, 2015 at 5:41 PM, Nicholas Nethercote wrote: > Hi, > > In C89 you can't mix declarations and statements, i.e. you have to > declare local variables at the top of a block. C99 relaxed this > annoying restriction, but MSVC did not add support for it for a long

Re: Use of 'auto'

On Tue, Aug 4, 2015 at 8:55 PM, Jeff Walden jwalden+...@mit.edu wrote: On 08/02/2015 07:17 AM, smaug wrote: MakeAndAddRef would have the same problem as MakeUnique. Doesn't really tell what type is returned. For the MakeUnique uses I've added (doubtless many more have popped up since),

Re: Collecting web platform features implementation status

On Thu, Jul 16, 2015 at 7:26 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-07-16 9:21 PM, Martin Thomson wrote: On Thu, Jul 16, 2015 at 5:44 PM, Benjamin Kelly bke...@mozilla.com wrote: FWIW, I've sent an intent to implement for the Streams API, but I won't be able to

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tue, Jul 7, 2015 at 6:03 AM, Kartikaya Gupta kgu...@mozilla.com wrote: I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

I am in favor of getting rid of aFoo. -Ekr P.S. At the risk of convincing people I am crazy and thus discounting my opinion above, I rather prefer foo_ to mFoo, but this seems like more a matter of taste. On Mon, Jul 6, 2015 at 8:55 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue,

Re: Linked Data must die. (was: Linked Data and a new Browser API event)

On Thu, Jul 2, 2015 at 11:47 AM, Gordon Brander gbran...@mozilla.com wrote: This thread has been fun to follow. There are only 2 hard problems in Comp Sci and naming things is one of them ;). Just wanted to quickly chip in: during our lively discussion about naming, let’s not forget Postel’s

Re: Secure contexts required for new web platform features

On Wed, Jul 1, 2015 at 11:35 AM, L. David Baron dba...@mozilla.com wrote: On Tuesday 2015-06-30 17:00 -0400, Richard Barnes wrote: Second, when we implement new web platform features, they will be enabled only on secure contexts. Exceptions can be granted, but will need to be justified as

Re: Proposed W3C Charter: WebRTC Working Group

FWIW, this is a consensus charter that came out of a long discussion that we were in. It's not perfect, but I believe it's generally sound... -Ekr On Fri, Jun 12, 2015 at 2:27 PM, L. David Baron dba...@dbaron.org wrote: The W3C is proposing a revised charter for: Web Performance Working

Re: Replacing PR_LOG levels

As I said earlier, I agree with Jesup. If people insist on not adding above debug, at least please allow individual modules to use a number that is DEBUG+1 on their own this is relevant for a lot of the media stuff which actually has its own logging and just shims to PR_LOG anyway). -Ekr On

Re: Replacing PR_LOG levels

On Fri, May 22, 2015 at 3:36 PM, Eric Rahm er...@mozilla.com wrote: The above will also be surprising since it will work differently than other modules, making the same sorts of debugs appear at different levels. This would be expecially confusing to people not frequently working in the

Re: Replacing PR_LOG levels

On Fri, May 22, 2015 at 11:46 AM, Randell Jesup rjesup.n...@jesup.org wrote: As part of the effort to improve logging in gecko we'd like to introduce a new set of unified log levels. *PR_LOG_DEBUG + 1 aka log level 5* Various bits of code invented a log level that was less important than

Re: Replacing PR_LOG levels

On Fri, May 22, 2015 at 1:02 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Sat, May 23, 2015 at 4:46 AM, Randell Jesup rjesup.n...@jesup.org wrote: Various bits of code invented a log level that was less important than debug (I would call this verbose). This was not specified in

Re: Changing the style guide's preference for loose over strict equality checks in non-test code (was: Re: PSA: The mochitest ise() function is dead, please use is() instead)

On Thu, May 14, 2015 at 9:14 AM, Martin Thomson m...@mozilla.com wrote: On Thu, May 14, 2015 at 5:17 AM, Gijs Kruitbosch gijskruitbo...@gmail.com wrote: On 14/05/2015 01:21, Martin Thomson wrote: On Wed, May 13, 2015 at 4:54 PM, Matthew N. mattn+firefox-...@mozilla.com wrote: In

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 9:39 AM, Florian Bösch pya...@gmail.com wrote: On Mon, May 4, 2015 at 6:33 PM, Adam Roach a...@mozilla.com wrote: You have made some well-thought-out contributions to conversations at Mozilla in the past. I'm a little sad that you're choosing not to participate in

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 10:52 AM, Florian Bösch pya...@gmail.com wrote: On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla e...@rtfm.com wrote: This would be more useful if you explained what they considered the cost of converting to HTTPS so, so we could discuss ways to ameliorate that cost. I

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 12:59 PM, Florian Bösch pya...@gmail.com wrote: On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla e...@rtfm.com wrote: I'm going to refer you at this point to the W3C HTML design principles of priority of constituencies (http://www.w3.org/TR/html-design-principles

Re: Intent to deprecate: Insecure HTTP

On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan quanxunz...@gmail.com wrote: On Tue, May 5, 2015 at 6:04 AM, Martin Thomson m...@mozilla.com wrote: On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert dholb...@mozilla.com wrote: (I think there's a strong case for disabling *persistent* fullscreen

Re: What's the plan to implement UDP sockets in Worker?

the confusion -Ekr Cheers, Josh On 2015-05-03 2:26 PM, Eric Rescorla wrote: The difficulty is that this is not a safe piece of functionality to expose to unprivileged code. -Ekr On Sat, May 2, 2015 at 8:03 PM, Josh Matthews j...@joshmatthews.net wrote: On 2015-05-02 10:33 AM, Yonggang Luo

Re: What's the plan to implement UDP sockets in Worker?

The difficulty is that this is not a safe piece of functionality to expose to unprivileged code. -Ekr On Sat, May 2, 2015 at 8:03 PM, Josh Matthews j...@joshmatthews.net wrote: On 2015-05-02 10:33 AM, Yonggang Luo wrote: I am looking into it. I have not been able to find any prior art on

Re: Intent to deprecate: Insecure HTTP

On Thu, Apr 30, 2015 at 5:57 PM, diaf...@gmail.com wrote: Here's two relevant Bugzilla bugs: Self-signed certificates are treated as errors: https://bugzilla.mozilla.org/show_bug.cgi?id=431386 Switch generic icon to negative feedback for non-https sites:

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

On Fri, Apr 24, 2015 at 7:05 AM, Mike Hoye mh...@mozilla.com wrote: On 2015-04-24 12:07 AM, Eric Rescorla wrote: Who said anything about excluded? It's simply much easier to discuss detailed topics in a small real-time setting. If there are community members who are well-prepared

Re: Tiles Design Questions (was Re: Improving trust and transparency for Suggested Tiles)

On Thu, Apr 23, 2015 at 3:18 PM, Robert Kaiser ka...@kairo.at wrote: Martin Thomson schrieb: On Thu, Apr 23, 2015 at 12:33 PM, e...@mozilla.com wrote: Do you have suggestions on where each of the 4 topics I posted should be discussed? In a meeting, where a small number of participants

Re: Excessive inbound bustage

On Tue, Apr 21, 2015 at 8:39 AM, jmath...@mozilla.com wrote: On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto wrote: On 21/04/2015 08:25, Gabor Krizsanits wrote: Maybe because I usually work on core, and such confidence is hard to reach there, but I'd like to think at

Re: Excessive inbound bustage

On Tue, Apr 21, 2015 at 12:14 PM, Ms2ger ms2...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2015 06:07 PM, Eric Rescorla wrote: On Tue, Apr 21, 2015 at 8:39 AM, jmath...@mozilla.com wrote: On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto

Re: Excessive inbound bustage

I think perhaps part of the question is what the purpose of m-i versus try is. My general algorithm is that you should get your patch to the point where you have tested it locally and have reasonable confidence that there are no portability issues and then it's fine to land it on m-i without try.

Re: Intent to deprecate: Insecure HTTP

On Tue, Apr 14, 2015 at 7:01 AM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham g...@mozilla.org wrote: Yep. That's the system working. CA does something they shouldn't, we find out, CA is no longer trusted (perhaps for a time). Or do you have an

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

+1 On Tue, Apr 14, 2015 at 3:59 PM, Justin Dolske dol...@mozilla.com wrote: On 4/14/15 8:40 AM, Dave Townsend wrote: I've gotten used to just ignoring these fields and reading the bugs instead. I wouldn't feel any loss if they were just removed from display entirely. +1. The fields are

Re: Intent to deprecate: Insecure HTTP

On Mon, Apr 13, 2015 at 10:40 AM, DDD david.a.p.ll...@gmail.com wrote: I think that you'll need to define a number of levels of security, and decide how to distinguish them in the Firefox GUI: - Unauthenticated/Unencrypted [http] - Unauthenticated/Encrypted [https ignoring untrusted cert

Re: PSA: mozilla::Pair is now a little more flexible

On Mon, Mar 16, 2015 at 5:44 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-03-15 11:26 PM, Seth Fowler wrote: On Mar 15, 2015, at 6:26 PM, Joshua Cranmer [image: ] pidgeo...@gmail.com wrote: In general, std::pair should be preferred over mozilla::Pair unless you need the

Re: PSA: mozilla::Pair is now a little more flexible

On Sun, Mar 15, 2015 at 12:33 PM, Seth Fowler s...@mozilla.com wrote: On Mar 15, 2015, at 12:01 PM, Eric Rescorla e...@rtfm.com wrote: I'm not sure I want to get in a long argument about this, but I'm not convinced this is good advice. I don’t really care what we do - keep in mind, I

Re: PSA: mozilla::Pair is now a little more flexible

On Fri, Mar 13, 2015 at 10:54 AM, Seth Fowler s...@mozilla.com wrote: On Mar 13, 2015, at 6:14 AM, Eric Rescorla e...@rtfm.com wrote: Sorry if this is a dumb question, but it seems like std::pair is fairly widely used in our code base. Can you explain the circumstances in which you

Re: PSA: mozilla::Pair is now a little more flexible

Sorry if this is a dumb question, but it seems like std::pair is fairly widely used in our code base. Can you explain the circumstances in which you think we should be using mozilla::Pair instead? Ekr On Thu, Mar 12, 2015 at 5:53 PM, Seth Fowler s...@mozilla.com wrote: I thought I’d let

Re: Intent to deprecate: persistent permissions over HTTP

On Thu, Mar 12, 2015 at 12:31 PM, Aryeh Gregor a...@aryeh.name wrote: On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: 2) If the only common real-world MITM threat is via a compromise adjacent to the client (e.g., wireless), there's no reason to restrict

Re: Intent to deprecate: persistent permissions over HTTP

On Sat, Mar 7, 2015 at 11:48 AM, Aryeh Gregor a...@aryeh.name wrote: On Fri, Mar 6, 2015 at 7:27 PM, Anne van Kesteren ann...@annevk.nl wrote: A large number of permissions we currently allow users to store persistently for a given origin. I suggest we stop offering that functionality

Re: Proposed W3C Charter: WebRTC Working Group

+1 On Fri, Mar 6, 2015 at 3:13 PM, Adam Roach a...@mozilla.com wrote: On 3/2/15 12:53, L. David Baron wrote: The W3C is proposing a revised charter for: Web Real-Time Communications Working Group http://www.w3.org/2015/02/webrtc-charter.html

Re: Permission UI

On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun fbr...@mozilla.com wrote: The good news is that most of the complicated bits are already implemented. See about:permissions. That seems like a good start, although it

Re: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images

Well, the first step would be to do plugin power saving at all. -Ekr On Sat, Feb 7, 2015 at 8:38 PM, Jet Villegas jville...@mozilla.com wrote: We should pick this up too. --Jet -- Forwarded message -- From: Jet Villegas W3C w...@junglecode.net Date: Sat, Feb 7, 2015 at

Re: Content Vault Feasibility RFC

This kind of feature comes up frequently, but to the best of my knowledge (which I believe is fairly up to date) it is not known how to build a robust version of this. To generalize the problem a bit, we have two pieces of software running on the user's computer: A: A confined process running in

Re: HEADS-UP: Disabling Gecko Media Plugins on older Linux kernels (bug 1120045)

On Fri, Jan 30, 2015 at 5:51 PM, Bobby Holley bobbyhol...@gmail.com wrote: I think the point here is that we want to free ourselves from needing the chemspill over OpenH264 memory hazards if we find them (since the code is relatively new). Note that with OpenH264 memory issues, we actually

<    1   2   3   >