Re: Implementing a Chrome DevTools Protocol server in Firefox

[Michael Smith]

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 reverse engineering here (for the most part), all 
protocol messages are specified in a machine-readable JSON format which 
includes inline documentation [0] --- this is what the cdp Rust library 
consumes. The spec is versioned and the authors do seem to follow a 
proper process of introducing new features as "experimental", 
stabilizing mature ones, and deprecating things before they're removed.


There's the Chrome DevTools Protocol viewer which provides a 
human-readable view [1], or if you prefer, the Rustdoc generated from 
the cdp crate [2] which carries over all the same information from the 
specification JSON.


Exposing a typed Rust interface is intended to help us avoid "breaking 
stuff without realizing". Other projects like Node.js have also adopted 
the CDP and an ecosystem of applications have grown around it which 
provide a counterweight against random breakages on Chrome's end.


As far as standardization goes, I'm aware of the RemoteDebug.org [3] 
initiative which has been trying to standardize parts of the CDP as a 
cross-browser remote debugging protocol. From what I recall from 
conversations with others I believe Edge is also interested in this, as 
they're introducing their own CDP implementation/compatibility layer.


On 8/30/2017 17:20, Eric Rescorla wrote:
> I assume this is going to involve TLS (generally this is a 
requirement for H2). In Firefox, this is done with NSS. Does Tokio/Hyper 
cleanly separate out the TLS stack so that you can do that?


The Chrome DevTools Protocol actually only runs over HTTP/1.1 and 
WebSockets, without TLS (binding to a port on a local interface, so 
transport security is less of a concern). My reference to HTTP/2 
concerned the possibility of Servo wanting to support that protocol, 
which would necessitate an upgrade to the future hyper version that will 
support it, which in turn would mean pulling Tokio into Servo.


On 8/30/2017 18:04, Josh Matthews wrote:
> One clarification - while all of the Servo codebase exists in 
mozilla-central/servo/, only the dependencies used by Stylo are vendored 
in third-party/rust. That means that neither hyper nor tokio are 
vendored in mozilla-central at the moment, or part of any 
mozilla-central build.


Isn't it vendored into third_party/rust/hyper [4] on mozilla-central?

-Michael

[0] https://github.com/ChromeDevTools/devtools-protocol/tree/master/json
[1] https://chromedevtools.github.io/devtools-protocol/
[2] https://www.spinda.net/files/mozilla/cdp/doc/cdp/tools/index.html
[3] https://remotedebug.org/
[4] http://searchfox.org/mozilla-central/source/third_party/rust/hyper
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Josh Matthews]

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, and consequently this is already 
present in the Firefox tree. The current release of hyper is built on 
top of Tokio, so upgrading hyper, either as maintenance or to take 
advantage of the forthcoming HTTP/2 support, would require pulling in 
Tokio anyway. The current release of rust-websocket, from which Servo 
derives its WebSockets implementation, also supports Tokio.


One clarification - while all of the Servo codebase exists in 
mozilla-central/servo/, only the dependencies used by Stylo are vendored 
in third-party/rust. That means that neither hyper nor tokio are 
vendored in mozilla-central at the moment, or part of any 
mozilla-central build.


Cheers,
Josh
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Eric Rahm]

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
> > 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 tree-wide).  Option (b) is also more likely to lead to
> > overly long lines that require wrapping.
>
> NSS had a lot of option (b) and we agreed that it was bad for these
> reasons.  You also have to agree not to do this, another thing that
> NSS was infested with:
>
>   nsresult ShortFunction(witharg, and another);
>   void   Function2  (HasOnlyOne* arg);
>
> Does clang-format even *do* this?  AlignConsecutiveDeclarations is the
> closest I could find to a directive that would do this sort of crazy
> alignment, but that seems more likely to govern my example than
> argument lists.  For the record, we should not enable that either.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Michael Smith]

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 commands 
(client-to-server RPC) and events (server-initiated push). These can be 
implemented individually, so we can pick and choose which parts of the 
protocol to tackle and in what order.


Supporting an entire devtools suite as a client (i.e. "use Chrome 
devtools with Firefox") would *not* be an initial target. Instead I've 
been looking toward adding enough support so that some of the 
third-party testing and automation tooling which exists for the CDP can 
be used with Firefox.


Sonar [0], for example, is a web linting tool which uses the CDP. The 
surface area it touches is not all that large [1], consisting of 
straightforward operations like opening and closing tabs, navigating to 
URLs, clearing the cache, and observing page load and network events. 
We've also looked at the WebPageTest agent implementation for Chrome 
[2]: its core functionality also requires navigating between URLs and 
observing page load and network events.


I'm aware of other places where the CDP is used to collect performance 
and profiling data as well as console output, as part of internal 
automated testing. This is testing that isn't being done with Firefox, 
but could be if we supported a limited subset of the protocol. There's a 
common set of functionality here which covers much of the use cases 
developers have in the wild, without having to touch potentially-hairier 
parts such as layout inspection.


*** So, desired outcome #1: be compatible with enough of the Chrome 
DevTools Protocol that we're a better target for testing and automation. 
This complements the recent work in implementing a headless mode.


There are also editors and editor plugins which use the CDP to provide 
HTML/CSS live preview and JS debugging support. I mentioned Brackets in 
my original post, and similar plugins exist for Atom, VS Code, Sublime 
(see [3]). The more developers that adopt these, the more that are 
building web pages with Chrome as the primary target (or Edge, which is 
also adding support). But if Firefox had a CDP implementation which 
supported the subset these tools need, we would suddenly become 
compatible with them. The subset that VS Code's plugin touches [4] looks 
very approachable.


*** Desired outcome #2: be compatible with enough of the Chrome DevTools 
Protocol that we're a better target for web development. This 
complements recent additions to the Firefox DevTools (eg. the CSS Grid 
Inspector) which can be used as points of differentiation once we've 
arrived on the playing field.


On 8/30/2017 15:25, Jet Villegas wrote:

For example, we've been exposing new API's for Layout geometry to the
front-end and devtools, and would like to do more of that sort of tight
integration with our Layout engine.


Implementing parts of the Chrome DevTools Protocol wouldn't mean ripping 
out the Firefox one: we can keep doing tight, Firefox-specific 
integrations with our own devtools.


Where it makes sense, we might replace parts used by the Firefox 
devtools with CDP equivalents---perhaps in conjunction with the 
RemoteDebug.org initiative [5], which is trying to standardize a common 
remote debugging protocol from parts of the CDP. The Console and JS 
Debugger seem like good targets for this, and Debugger.html can already 
communicate with CDP-based servers. But this would, I think, be further 
down the line from the goal of integrating with clients outside the browser.


*** Desired outcome #3: Firefox's CDP server implementation supports 
external (remote) clients, but is designed in such a way that it can be 
applied efficiently to internal use-cases where appropriate. This has 
informed the development direction of the cdp/tokio-cdp Rust libraries.


-Michael

[0] https://sonarwhal.com/
[1] https://github.com/sonarwhal/sonar/issues/377#issuecomment-314929118
[2] 
https://github.com/WPO-Foundation/wptagent/blob/master/internal/devtools.py

[3] https://remotedebug.org/integrations/
[4] 
https://github.com/Microsoft/vscode-chrome-debug/blob/c77829dad40c8f2f783a0ae23d61ef79cbbc/test/debugProtocolMocks.ts#L24-L77

[5] https://remotedebug.org/

On 8/30/2017 15:25, Jet Villegas wrote:

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 ability to emulate Chromium's behavior when attached to devtools.
For example, we've been exposing new API's for Layout geometry to the
front-end and devtools, and would like to do more of that sort of tight
integration with our Layout engine. I'm not su

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Karl Dubost]

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 currently Browser Testing and Tools Working Group Charter which does 
only Web Driver API. David is a co-chair there.
https://www.w3.org/2016/05/browser-testing-tools-charter.html

The 2011 charter was open on more APIs
https://www.w3.org/2011/08/browser-testing-charter.html


But I had a slight memory of a long time ago attempt, which indeed didn't take 
off. 
There was this talk at XTech 2008 by Mike Smith (W3C)
https://www.w3.org/2008/Talks/05-07-smith-xtech/slides.pdf

Also this talk at the 2008 W3C Technical Plenary 
by Chaals (Opera then) 
on standardizing Scope (Opera Dragonfly Inspection API) 
"Standards API and Debuggers"
https://www.w3.org/2008/10/1022-dragonfly-chaals/talk.html
https://www.w3.org/2008/10/22-tp-minutes.html
http://operasoftware.github.io/scope-interface/


But I don't remember if there was a workshop or anything and it just didn't 
build up steam.


-- 
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Mike Hommey]

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?"
> > 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 switch/match statement.
> >
> > I've never actually seen else-for, but I imagine it would be used for:
> > if (!foo) {
> > } else for (i = 0; i < foo->bar; i++) {
> > }
> >
> > I don't think this pattern has enough value to be acceptable as
> > shorthand. BUT, I didn't know it was a thing until now, so I'm
> > naturally biased against it.
> >
> 
> I'm with Jeff here. Not even once.
> 
> if (!foo) {
> } else {
>   for(...) {
> 
> }
> }
> 
> As it happens, the style guide agrees with us, so I'm happy to quote it ;)
> 
> "else should only ever be followed by { or if; i.e., other control keywords
> are not allowed and should be placed inside braces."

... because it was added today after this thread:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style$compare?locale=en-US&to=1296847&from=1263305

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Eric Rescorla]

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 something".
>
> Else-if is generally used for chaining, often effectively as an
> advanced switch/match statement.
>
> I've never actually seen else-for, but I imagine it would be used for:
> if (!foo) {
> } else for (i = 0; i < foo->bar; i++) {
> }
>
> I don't think this pattern has enough value to be acceptable as
> shorthand. BUT, I didn't know it was a thing until now, so I'm
> naturally biased against it.
>

I'm with Jeff here. Not even once.

if (!foo) {
} else {
  for(...) {

}
}

As it happens, the style guide agrees with us, so I'm happy to quote it ;)

"else should only ever be followed by { or if; i.e., other control keywords
are not allowed and should be placed inside braces."

-Ekr





-Ekr


> On Wed, Aug 30, 2017 at 2:58 PM,   wrote:
> > 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 (...) {
> >   ...
> > } else for (...) {
> >   ...
> > }
> >
> > I can see arguments for&against both, so I'm not too sure which one
> should win. :-)
> > WDYT?
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Eric Rescorla]

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 browser pages.
>
> Originally built for the Chrome DevTools, it has seen wider adoption with
> outside developers. In addition to Chrome/Chromium, the CDP is supported by
> WebKit, Safari, Node.js, and soon Edge, and an ecosystem of libraries and
> tools already exists which plug into it, for debugging, extracting
> performance data, providing live-preview functionality like the Brackets
> editor, and so on. We believe it would be beneficial if these could be
> leveraged with Firefox as well.
>
> The initial implementation we have in mind is an alternate target for
> third-party integrations to connect to, in addition to the existing Firefox
> DevTools Server. The Servo project has also expressed interest in adding
> CDP support to improve its own devtools story, and a PR is in flight to
> land a CDP server implementation there [1].
>
> I've been working on this project with guidance from Jim Blandy. We've
> come up with the following approach:
>
> - A complete, typed Rust implementation of the CDP protocol messages and
> (de)serialization lives in the "cdp" crate [2], automatically generated
> from the protocol's JSON specification [3] using a build script (this
> happens transparently as part of the normal Cargo compilation process).
> This comes with Rustdoc API documentation of all messages/types in the
> protocol [4] including textual descriptions bundled with the specification
> JSON. The cdp crate will likely track the Chrome stable release for which
> version of the protocol is supported. A maintainers' script exists which
> can find and fetch the appropriate JSON [5].
>
> - The "tokio-cdp" crate [6] builds on the types and (de)serialization
> implementation in the cdp crate to provide a server implementation built on
> the Tokio asynchronous I/O system. The server side provides traits for
> consuming incoming CDP RPC commands, executing them concurrently and
> sending back responses, and simultaneously pushing events to the client.
> They are generic over the underlying transport, so the same backend
> implementation could provide support for "remote" clients plugging in over
> HTTP/WebSockets/JSON or, for example, a browser-local client communicating
> over IPDL.
>
> - In Servo, a new component plugs into the cdp and tokio-cdp crates and
> acts on behalf of connected CDP clients in response to their commands,
> communicating with the rest of the Servo constellation. This server is
> disabled by default and can be started by passing a "--cdp" flag to the
> Servo binary, binding a TCP listener to the loopback interface at the
> standard CDP port 9222 (a different port can be specified as an option to
> the flag).
>
> - The implementation we envision in Firefox/Gecko would act similarly: a
> new Rust component, disabled by default and switched on via a command line
> flag, which binds to a local port and mediates between Gecko internals and
> clients connected via tokio-cdp.
>
> We chose to build this on Rust and the Tokio event loop, along with the
> hyper HTTP library and rust-websocket which plug into Tokio.
>
> Rust and Cargo provide excellent facilities for compile-time code
> generation which integrate transparently into the normal build process,
> avoiding the need to invoke scripts by hand to keep generated artifacts in
> sync. The Rust ecosystem provides libraries such as quote [7] and serde [8]
> which allow us to auto-generate an efficient, typed, and self-contained
> interface for the entire protocol. This moves the complexity of ingesting,
> validating, and extracting information from client messages out of the
> Servo- and Gecko-specific backend implementations, helps to ensure they
> conform correctly to the protocol specification, and provides a structured
> way of upgrading to new protocol versions.
>
> As for Tokio, the event loop and Futures-based model of concurrency it
> offers maps well to the Chrome DevTools Protocol. RPC commands typically
> execute simultaneously, returning responses in order of completion, while
> the server continuously generates events to which the client has
> subscribed. Under Tokio we can spawn multiple lightweight Tasks, dispatch
> messages to them, and multiplex their responses back over the single client
> connection. The Tokio event loop is nicely self-contained to the one or,
> optionally, more threads it is allocated, so the rest of the application
> doesn't need to be aware of it.
>
> 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, and consequently this is already prese

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

[gsquelart]

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&case=true®exp=true&path=*.cpp

So I'll add a clarification in the coding style page, that `else` should only 
be followed by `{` or `if`.

On Thursday, August 31, 2017 at 10:41:41 AM UTC+12, 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 something".
> 
> Else-if is generally used for chaining, often effectively as an
> advanced switch/match statement.
> 
> I've never actually seen else-for, but I imagine it would be used for:
> if (!foo) {
> } else for (i = 0; i < foo->bar; i++) {
> }
> 
> I don't think this pattern has enough value to be acceptable as
> shorthand. BUT, I didn't know it was a thing until now, so I'm
> naturally biased against it.
> 
> On Wed, Aug 30, 2017 at 2:58 PM,   wrote:
> > 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 (...) {
> >   ...
> > } else for (...) {
> >   ...
> > }
> >
> > I can see arguments for&against both, so I'm not too sure which one should 
> > win. :-)
> > WDYT?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[David Burns]

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  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 browser pages.
>
> Originally built for the Chrome DevTools, it has seen wider adoption with
> outside developers. In addition to Chrome/Chromium, the CDP is supported by
> WebKit, Safari, Node.js, and soon Edge, and an ecosystem of libraries and
> tools already exists which plug into it, for debugging, extracting
> performance data, providing live-preview functionality like the Brackets
> editor, and so on. We believe it would be beneficial if these could be
> leveraged with Firefox as well.
>
> The initial implementation we have in mind is an alternate target for
> third-party integrations to connect to, in addition to the existing Firefox
> DevTools Server. The Servo project has also expressed interest in adding
> CDP support to improve its own devtools story, and a PR is in flight to
> land a CDP server implementation there [1].
>
> I've been working on this project with guidance from Jim Blandy. We've
> come up with the following approach:
>
> - A complete, typed Rust implementation of the CDP protocol messages and
> (de)serialization lives in the "cdp" crate [2], automatically generated
> from the protocol's JSON specification [3] using a build script (this
> happens transparently as part of the normal Cargo compilation process).
> This comes with Rustdoc API documentation of all messages/types in the
> protocol [4] including textual descriptions bundled with the specification
> JSON. The cdp crate will likely track the Chrome stable release for which
> version of the protocol is supported. A maintainers' script exists which
> can find and fetch the appropriate JSON [5].
>
> - The "tokio-cdp" crate [6] builds on the types and (de)serialization
> implementation in the cdp crate to provide a server implementation built on
> the Tokio asynchronous I/O system. The server side provides traits for
> consuming incoming CDP RPC commands, executing them concurrently and
> sending back responses, and simultaneously pushing events to the client.
> They are generic over the underlying transport, so the same backend
> implementation could provide support for "remote" clients plugging in over
> HTTP/WebSockets/JSON or, for example, a browser-local client communicating
> over IPDL.
>
> - In Servo, a new component plugs into the cdp and tokio-cdp crates and
> acts on behalf of connected CDP clients in response to their commands,
> communicating with the rest of the Servo constellation. This server is
> disabled by default and can be started by passing a "--cdp" flag to the
> Servo binary, binding a TCP listener to the loopback interface at the
> standard CDP port 9222 (a different port can be specified as an option to
> the flag).
>
> - The implementation we envision in Firefox/Gecko would act similarly: a
> new Rust component, disabled by default and switched on via a command line
> flag, which binds to a local port and mediates between Gecko internals and
> clients connected via tokio-cdp.
>
> We chose to build this on Rust and the Tokio event loop, along with the
> hyper HTTP library and rust-websocket which plug into Tokio.
>
> Rust and Cargo provide excellent facilities for compile-time code
> generation which integrate transparently into the normal build process,
> avoiding the need to invoke scripts by hand to keep generated artifacts in
> sync. The Rust ecosystem provides libraries such as quote [7] and serde [8]
> which allow us to auto-generate an efficient, typed, and self-contained
> interface for the entire protocol. This moves the complexity of ingesting,
> validating, and extracting information from client messages out of the
> Servo- and Gecko-specific backend implementations, helps to ensure they
> conform correctly to the protocol specification, and provides a structured
> way of upgrading to new protocol versions.
>
> As for Tokio, the event loop and Futures-based model of concurrency it
> offers maps well to the Chrome DevTools Protocol. RPC commands typically
> execute simultaneously, returning responses in order of completion, while
> the server continuously generates events to which the client has
> subscribed. Under Tokio we can spawn multiple lightweight Tasks, dispatch
> messages to them, and multiplex their responses back over the single client
> connection. The Tokio event loop is nicely self-contained to the one or,
> optionally, more threads it is allocated, so the rest of the application
> doesn't need to be aware of it.
>
> Use of Tokio is becoming a standard in the Rust ecosystem---it's wort

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

[Jeff Gilbert]

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 switch/match statement.

I've never actually seen else-for, but I imagine it would be used for:
if (!foo) {
} else for (i = 0; i < foo->bar; i++) {
}

I don't think this pattern has enough value to be acceptable as
shorthand. BUT, I didn't know it was a thing until now, so I'm
naturally biased against it.

On Wed, Aug 30, 2017 at 2:58 PM,   wrote:
> 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 (...) {
>   ...
> } else for (...) {
>   ...
> }
>
> I can see arguments for&against both, so I'm not too sure which one should 
> win. :-)
> WDYT?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jet Villegas]

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 ability to emulate Chromium's behavior when attached to devtools.
For example, we've been exposing new API's for Layout geometry to the
front-end and devtools, and would like to do more of that sort of tight
integration with our Layout engine. I'm not sure we could guarantee bug
compatibility when a Chrome devtool requires similar-but-not-quite
functionality. In other words, it sounds like your proposed protocol
emulation is feasible, but I'm less certain we can live up to the expected
semantics of things going over that wire.

--Jet





On Wed, Aug 30, 2017 at 2: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 browser pages.
>
> Originally built for the Chrome DevTools, it has seen wider adoption with
> outside developers. In addition to Chrome/Chromium, the CDP is supported by
> WebKit, Safari, Node.js, and soon Edge, and an ecosystem of libraries and
> tools already exists which plug into it, for debugging, extracting
> performance data, providing live-preview functionality like the Brackets
> editor, and so on. We believe it would be beneficial if these could be
> leveraged with Firefox as well.
>
> The initial implementation we have in mind is an alternate target for
> third-party integrations to connect to, in addition to the existing Firefox
> DevTools Server. The Servo project has also expressed interest in adding
> CDP support to improve its own devtools story, and a PR is in flight to
> land a CDP server implementation there [1].
>
> I've been working on this project with guidance from Jim Blandy. We've
> come up with the following approach:
>
> - A complete, typed Rust implementation of the CDP protocol messages and
> (de)serialization lives in the "cdp" crate [2], automatically generated
> from the protocol's JSON specification [3] using a build script (this
> happens transparently as part of the normal Cargo compilation process).
> This comes with Rustdoc API documentation of all messages/types in the
> protocol [4] including textual descriptions bundled with the specification
> JSON. The cdp crate will likely track the Chrome stable release for which
> version of the protocol is supported. A maintainers' script exists which
> can find and fetch the appropriate JSON [5].
>
> - The "tokio-cdp" crate [6] builds on the types and (de)serialization
> implementation in the cdp crate to provide a server implementation built on
> the Tokio asynchronous I/O system. The server side provides traits for
> consuming incoming CDP RPC commands, executing them concurrently and
> sending back responses, and simultaneously pushing events to the client.
> They are generic over the underlying transport, so the same backend
> implementation could provide support for "remote" clients plugging in over
> HTTP/WebSockets/JSON or, for example, a browser-local client communicating
> over IPDL.
>
> - In Servo, a new component plugs into the cdp and tokio-cdp crates and
> acts on behalf of connected CDP clients in response to their commands,
> communicating with the rest of the Servo constellation. This server is
> disabled by default and can be started by passing a "--cdp" flag to the
> Servo binary, binding a TCP listener to the loopback interface at the
> standard CDP port 9222 (a different port can be specified as an option to
> the flag).
>
> - The implementation we envision in Firefox/Gecko would act similarly: a
> new Rust component, disabled by default and switched on via a command line
> flag, which binds to a local port and mediates between Gecko internals and
> clients connected via tokio-cdp.
>
> We chose to build this on Rust and the Tokio event loop, along with the
> hyper HTTP library and rust-websocket which plug into Tokio.
>
> Rust and Cargo provide excellent facilities for compile-time code
> generation which integrate transparently into the normal build process,
> avoiding the need to invoke scripts by hand to keep generated artifacts in
> sync. The Rust ecosystem provides libraries such as quote [7] and serde [8]
> which allow us to auto-generate an efficient, typed, and self-contained
> interface for the entire protocol. This moves the complexity of ingesting,
> validating, and extracting information from client messages out of the
> Servo- and Gecko-specific backend implementations, helps to ensure they
> conform correctly to the protocol specification, and provides a structured
> way of upgrading to new protocol versions.
>
> As for Tokio, the event loop and Futures-based model of concurrency it
> offers maps well

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

[gsquelart]

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 (...) {
  ...
} else for (...) {
  ...
}

I can see arguments for&against both, so I'm not too sure which one should win. 
:-)
WDYT?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Implementing a Chrome DevTools Protocol server in Firefox

[Michael Smith]

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 
with outside developers. In addition to Chrome/Chromium, the CDP is 
supported by WebKit, Safari, Node.js, and soon Edge, and an ecosystem of 
libraries and tools already exists which plug into it, for debugging, 
extracting performance data, providing live-preview functionality like 
the Brackets editor, and so on. We believe it would be beneficial if 
these could be leveraged with Firefox as well.


The initial implementation we have in mind is an alternate target for 
third-party integrations to connect to, in addition to the existing 
Firefox DevTools Server. The Servo project has also expressed interest 
in adding CDP support to improve its own devtools story, and a PR is in 
flight to land a CDP server implementation there [1].


I've been working on this project with guidance from Jim Blandy. We've 
come up with the following approach:


- A complete, typed Rust implementation of the CDP protocol messages and 
(de)serialization lives in the "cdp" crate [2], automatically generated 
from the protocol's JSON specification [3] using a build script (this 
happens transparently as part of the normal Cargo compilation process). 
This comes with Rustdoc API documentation of all messages/types in the 
protocol [4] including textual descriptions bundled with the 
specification JSON. The cdp crate will likely track the Chrome stable 
release for which version of the protocol is supported. A maintainers' 
script exists which can find and fetch the appropriate JSON [5].


- The "tokio-cdp" crate [6] builds on the types and (de)serialization 
implementation in the cdp crate to provide a server implementation built 
on the Tokio asynchronous I/O system. The server side provides traits 
for consuming incoming CDP RPC commands, executing them concurrently and 
sending back responses, and simultaneously pushing events to the client. 
They are generic over the underlying transport, so the same backend 
implementation could provide support for "remote" clients plugging in 
over HTTP/WebSockets/JSON or, for example, a browser-local client 
communicating over IPDL.


- In Servo, a new component plugs into the cdp and tokio-cdp crates and 
acts on behalf of connected CDP clients in response to their commands, 
communicating with the rest of the Servo constellation. This server is 
disabled by default and can be started by passing a "--cdp" flag to the 
Servo binary, binding a TCP listener to the loopback interface at the 
standard CDP port 9222 (a different port can be specified as an option 
to the flag).


- The implementation we envision in Firefox/Gecko would act similarly: a 
new Rust component, disabled by default and switched on via a command 
line flag, which binds to a local port and mediates between Gecko 
internals and clients connected via tokio-cdp.


We chose to build this on Rust and the Tokio event loop, along with the 
hyper HTTP library and rust-websocket which plug into Tokio.


Rust and Cargo provide excellent facilities for compile-time code 
generation which integrate transparently into the normal build process, 
avoiding the need to invoke scripts by hand to keep generated artifacts 
in sync. The Rust ecosystem provides libraries such as quote [7] and 
serde [8] which allow us to auto-generate an efficient, typed, and 
self-contained interface for the entire protocol. This moves the 
complexity of ingesting, validating, and extracting information from 
client messages out of the Servo- and Gecko-specific backend 
implementations, helps to ensure they conform correctly to the protocol 
specification, and provides a structured way of upgrading to new 
protocol versions.


As for Tokio, the event loop and Futures-based model of concurrency it 
offers maps well to the Chrome DevTools Protocol. RPC commands typically 
execute simultaneously, returning responses in order of completion, 
while the server continuously generates events to which the client has 
subscribed. Under Tokio we can spawn multiple lightweight Tasks, 
dispatch messages to them, and multiplex their responses back over the 
single client connection. The Tokio event loop is nicely self-contained 
to the one or, optionally, more threads it is allocated, so the rest of 
the application doesn't need to be aware of it.


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, and consequently this is already 
present in the Firefox tree. The current release of hyper is built on 
top of Tokio, so upgrading hyper, either as maintenance or to take 
advan

Re: Coding style: Argument alignment

[Eric Rescorla]

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 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 news about that soon.
>>
>
> This is probably obvious, but there are chunks of non-third-party C++ in
> the tree that follow other styles (e.g., media/mtransport is Google style
> guide style) so please be careful not to reformat those.
>
> Yeah, I have been maintaining this list:
> https://dxr.mozilla.org/mozilla-central/source/.clang-format-ignore
> (partially regenerated from https://dxr.mozilla.org/
> mozilla-central/source/tools/rewriting/ThirdPartyPaths.txt)
>
>
I note that this doesn't seem to include media/mtransport/*.

-Ekr

Sylvestre
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Sylvestre Ledru]

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
> > 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 news about that soon.
>
>
> This is probably obvious, but there are chunks of non-third-party C++ in the 
> tree that follow other styles (e.g., media/mtransport is Google style guide 
> style) so please be careful not to reformat those.
Yeah, I have been maintaining this list:
https://dxr.mozilla.org/mozilla-central/source/.clang-format-ignore
(partially regenerated from 
https://dxr.mozilla.org/mozilla-central/source/tools/rewriting/ThirdPartyPaths.txt)

Sylvestre

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Eric Rescorla]

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 working on that but we delayed it to avoid doing it during
> the 57 work.
>
> We will share more news about that soon.
>

This is probably obvious, but there are chunks of non-third-party C++ in
the tree that follow other styles (e.g., media/mtransport is Google style
guide style) so please be careful not to reformat those.

-Ekr


> > 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 post-clang-format patch showed the whole list
> > as changed (due to any change to the list triggering reformatting the
> > whole thing to our style). I think it would be better for productivity
> > not to have to explain artifacts of clang-format during review, and at
> > this point the way to avoid it would be to make sure the base revision
> > is already clang-formatted.
> >
> Could you report a bug? We wrote a few patches upstream to improve
> the support of our coding style.
>
>
> Thanks,
> Sylvestre
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Ethan Tseng]

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
https://addons.mozilla.org/en-US/firefox/addon/no-resource-uri-leak/

--
Ethan Tseng
Engineering Manager, Mozilla

On Wed, Aug 30, 2017 at 11:36 AM, Chung-Sheng Fu  wrote:

> Hi everyone,
>
>
> == Background ==
>
> Firefox and add-ons use the resource:// scheme to load resources
> internally, but some of the information is available to sites the browser
> connects to as well.
>
> This means a web page can run internal scripts and inspect internal
> resources of Firefox Browser, including the default preferences, which
> could be a serious security and privacy issue.
>
> == Threats ==
>
> For example, a script on Browserleaks
>  highlights what Firefox reveals
> when queried by a simple script running on the site (you can find the code
> in https://browserleaks.com/firefox#more).
>
> The file firefox.js passes preference names and values to the pref()
> function.
>
> Example: http://searchfox.org/mozilla-central/rev/
> 48ea452803907f2575d81021e8678634e8067fc2/browser/app/
> profile/firefox.js#575
>
> Web sites can easily collect Firefox default preferences by overriding
> this pref() function and using the script “resource:///defaults/
> preferences/firefox.js”.
>
> Furthermore, some default values of preferences differ between build
> configurations, such as platform and locale, which means web sites could
> identify individual users using this information.
>
> == Solution ==
>
> In order to fix these issues, we changed the behavior of loading
> resource:// URIs in bug 863246
> , which has been
> landed in NIghtly 57.  Now, web content is not able to access resource://
> URIs by default, unless the resource:// URI is declared
> contentaccessible=yes in the manifests.
>
> For Mozilla developers who need to load resource:// URIs in the web
> content, here are some tips.
>
>1.
>
>Simple resource files: add them to CONTENT_ACCESSIBLE_FILES in
>moz.build
>
> 
>and they will be located in resource://content-accessible/.  Currently
>we have these files moved:
>1.
>
>   resouce://gre/res/ImageDocument.css =>
>   resource://content-accessible/ImageDocument.css
>   2. resource://gre/res/TopLevelImageDocument.css =>
>   resource://content-accessible/TopLevelImageDocument.css
>   3. resource://gre/res/TopLevelVideoDocument.css =>
>   resource://content-accessible/TopLevelVideoDocument.css
>   4. resource://gre-resources/viewsource.css =>
>   resource://content-accessible/viewsource.css
>   2.
>
>Folders:
>1.
>
>   Move your folder to resource://content-accessible/.  If not
>   applicable,
>   2.
>
>   Add the contentaccessble=yes flag in jar.mn where you define the
>   URI mapping, e.g., about:newtab
>   
> 
>   and jsonview
>   
> 
>   .
>
>
> == Follow-up ==
>
> If there is anything which was impacted by this change and not caught by
> us, or you are not sure how to deal with resource:// URIs in your case,
> please file a bug and set it as depending on bug 863246
> .  We will try the
> best to resolve the compatibility issue.
>
>
> Best regards,
>
> Chung-Sheng Fu
>
>
>
> ___
> SecEng mailing list
> sec...@mozilla.org
> https://mail.mozilla.org/listinfo/seceng
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Martin Thomson]

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 -style=Mozilla -dump-config`
says `AlignTrailingComments: true` so, this is something you might
see:

static const uint8_t x[] = {
  a, // this only
  b, // has short
  c  // names
};

static const uint8_t x[] = {
  a,   // this no longer
  b,   // has short
  c,   // names, and
  0xff // everything has to change
};

However, I think that the benefits of clang-format greatly outweigh
this type of minor niggle.  It's relatively rare that this pollutes
blame, and there are ways to skip these changes.  And I can see how
it's easier to read than the alternative.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Nicolas B. Pierron]

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 doing it during
the 57 work.

We will share more news about that soon.


When this will happen, would we reformat all trees at once?
In particular, I am asking about back-porting security patches.

--
Nicolas B. Pierron
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Henri Sivonen]

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 working on that but we delayed it to avoid doing it during the
> 57 work.
>
> We will share more news about that soon.

Cool. Thanks.

> 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 post-clang-format patch showed the whole list
> as changed (due to any change to the list triggering reformatting the
> whole thing to our style). I think it would be better for productivity
> not to have to explain artifacts of clang-format during review, and at
> this point the way to avoid it would be to make sure the base revision
> is already clang-formatted.
>
> Could you report a bug? We wrote a few patches upstream to improve
> the support of our coding style.

It's not a bug: The constructors were not formatted according to our
style to begin with, so an edit triggered clang-format formatting them
to our style.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Argument alignment

[Sylvestre Ledru]

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 news about that soon.

> 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 post-clang-format patch showed the whole list
> as changed (due to any change to the list triggering reformatting the
> whole thing to our style). I think it would be better for productivity
> not to have to explain artifacts of clang-format during review, and at
> this point the way to avoid it would be to make sure the base revision
> is already clang-formatted.
>
Could you report a bug? We wrote a few patches upstream to improve
the support of our coding style.


Thanks,
Sylvestre

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform