Re: Implementing a Chrome DevTools Protocol server in Firefox

On 8/30/2017 15:56, David Burns wrote: > Do we know if the other vendors would see value in having this spec'ed properly so that we have true interop here? Reverse engineering  seems like a "fun" project but what stops people from breaking stuff without realising? Fortunately we're not

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 8/30/17 2:55 PM, Michael Smith wrote: Use of Tokio is becoming a standard in the Rust ecosystem---it's worth mentioning that Mozilla funds Tokio development [9] and employs some of its primary developers. Servo currently depends on an older version of the hyper HTTP client/server library,

Re: Coding style: Argument alignment

Okay sounds like there's agreement on a). Thanks everyone! -e On Tue, Aug 29, 2017 at 11:40 PM, Martin Thomson wrote: > On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron > wrote: > > I think I do this because (b) has the disadvantage that more code > >

Re: Implementing a Chrome DevTools Protocol server in Firefox

On 8/30/2017 15:25, Jet Villegas wrote: Can you summarize the desired outcomes? [...] This is potentially a very large API surface to support, and I'm skeptical about our ability to emulate Chromium's behavior when attached to devtools. The Chrome DevTools Protocol is split up into separate

Re: Implementing a Chrome DevTools Protocol server in Firefox

Michael, Le 31 août 2017 à 07:56, David Burns a écrit : > Do we know if the other vendors would see value in having this spec'ed > properly so that we have true interop here? Yeah I had the same train of thoughts than David when I read the initial message. There is

Re: Coding style: `else for` or `else { for... }`?

On Wed, Aug 30, 2017 at 06:26:18PM -0600, Eric Rescorla wrote: > On Wed, Aug 30, 2017 at 4:41 PM, Jeff Gilbert wrote: > > > IMO: Never else-for. (or else-while) > > > > Else-if is a reasonable continuation of concept: "Well it wasn't that, > > what if it's this instead?" >

Re: Coding style: `else for` or `else { for... }`?

On Wed, Aug 30, 2017 at 4:41 PM, Jeff Gilbert wrote: > IMO: Never else-for. (or else-while) > > Else-if is a reasonable continuation of concept: "Well it wasn't that, > what if it's this instead?" > Else-for is just shorthand for "well it wasn't that, so let's loop > over

Re: Implementing a Chrome DevTools Protocol server in Firefox

On Wed, Aug 30, 2017 at 3:55 PM, Michael Smith wrote: > Hi everyone, > > Mozilla DevTools is exploring implementing parts of the Chrome DevTools > Protocol ("CDP") [0] in Firefox. This is an HTTP, WebSockets, and JSON > based protocol for automating and inspecting running

Re: Coding style: `else for` or `else { for... }`?

Only negative reactions to `else for` so far, and it's only used a couple of times in our code: http://searchfox.org/mozilla-central/search?q=else%5B+%5D%2B(do%7Cfor%7Cswitch%7Cwhile)%5B+%5D=true=true=*.cpp So I'll add a clarification in the coding style page, that `else` should only be

Re: Implementing a Chrome DevTools Protocol server in Firefox

Do we know if the other vendors would see value in having this spec'ed properly so that we have true interop here? Reverse engineering seems like a "fun" project but what stops people from breaking stuff without realising? David On 30 August 2017 at 22:55, Michael Smith

Re: Coding style: `else for` or `else { for... }`?

IMO: Never else-for. (or else-while) Else-if is a reasonable continuation of concept: "Well it wasn't that, what if it's this instead?" Else-for is just shorthand for "well it wasn't that, so let's loop over something". Else-if is generally used for chaining, often effectively as an advanced

Re: Implementing a Chrome DevTools Protocol server in Firefox

Can you summarize the desired outcomes? e.g., 1. people using devtools in Chrome can also debug Firefox 2. devtools for Chrome can be ported to Firefox 3. devtools for Firefox can be used with Chrome 4. ... This is potentially a very large API surface to support, and I'm skeptical about our

Coding style: `else for` or `else { for... }`?

Let's keep the flames alive! Should we always put braces after an `else`, with the only exception being another `if`? Or should we also have exceptions for the other control structures (while, do, for, switch)? A. if (...) { ... } else { for (...) { ... } } B. if (...) { ... }

Implementing a Chrome DevTools Protocol server in Firefox

Hi everyone, Mozilla DevTools is exploring implementing parts of the Chrome DevTools Protocol ("CDP") [0] in Firefox. This is an HTTP, WebSockets, and JSON based protocol for automating and inspecting running browser pages. Originally built for the Chrome DevTools, it has seen wider adoption

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 9:29 AM, Sylvestre Ledru wrote: > Le 30/08/2017 à 17:25, Eric Rescorla a écrit : > > > > On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru > wrote: > >> >> Le 30/08/2017 à 08:53, Henri Sivonen a écrit : >> > Regardless of the

Re: Coding style: Argument alignment

Le 30/08/2017 à 17:25, Eric Rescorla a écrit : > > > On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru > wrote: > > > Le 30/08/2017 à 08:53, Henri Sivonen a écrit : > > Regardless of the outcome of this particular style issue, where are we >

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 1:21 AM, Sylvestre Ledru wrote: > > Le 30/08/2017 à 08:53, Henri Sivonen a écrit : > > Regardless of the outcome of this particular style issue, where are we > > in terms of clang-formatting all the non-third-party C++ in the tree? > > We have been

Re: [seceng] Changed the loading behavior of resource:// URI since Nightly 57

It means there is no need to use the "No Resource URI Leak" add-on [1] anymore. [1] No Resource URI Leak: Deny resource:// access to Web content: We fill the hole to defend against fingerprinting. Very important to Firefox privacy. A direct workaround for bugzil.la/863246

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 5:21 PM, Sylvestre Ledru wrote: > Could you report a bug? We wrote a few patches upstream to improve > the support of our coding style. This isn't a bug either, but I've noticed that alignment anywhere can cause collateral changes. `clang-format

Re: Coding style: Argument alignment

On 08/30/2017 07:21 AM, Sylvestre Ledru wrote: Le 30/08/2017 à 08:53, Henri Sivonen a écrit : Regardless of the outcome of this particular style issue, where are we in terms of clang-formatting all the non-third-party C++ in the tree? We have been working on that but we delayed it to avoid

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 10:21 AM, Sylvestre Ledru wrote: > > Le 30/08/2017 à 08:53, Henri Sivonen a écrit : > > Regardless of the outcome of this particular style issue, where are we > in terms of clang-formatting all the non-third-party C++ in the tree? > > We have been

Re: Coding style: Argument alignment

Le 30/08/2017 à 08:53, Henri Sivonen a écrit : > Regardless of the outcome of this particular style issue, where are we > in terms of clang-formatting all the non-third-party C++ in the tree? We have been working on that but we delayed it to avoid doing it during the 57 work. We will share more

Re: Coding style: Argument alignment

Regardless of the outcome of this particular style issue, where are we in terms of clang-formatting all the non-third-party C++ in the tree? I've had a couple of cases of late where the initializers in a pre-existing constructor didn't follow our style, so when I changed the list a tiny bit, the

Re: Coding style: Argument alignment

On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron wrote: > I think I do this because (b) has the disadvantage that more code > changes require touching additional lines, which is both changes > blame and is extra work (although it's not extra work if we're using > clang-format