Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jack Moffitt]

> I entirely agree that the current Firefox protocol is also proprietary.
> However I also assumed that it's considered an internal implementation
> detail rather than something we would expect people to interoperate with. If
> that wasn't the case then I apologise: I should have complained earlier :)

We would like a console and debugger for Servo, and those seemed
pretty common. We did an initial implementation of the Firefox
protocol, but hat protocol changed out from under us, and some of the
work we did broke and wasn't not easily fixable.

At the very least there is a desire to interoperate between Servo and
Firefox and the current protocol isn't very helpful for this. The
Chrome one has a huge advantage of being documented, even if not all
the semantics are. I was also under the impression that the design of
the Chrome protocol is better than the Firefox one because you can
ingest the JSON messages and only handle the things you want. It seems
like that would make it more robust to future changes.

Is there another alternative besides CDP you'd like to propose? I
think there's a strong case that doing something besides the current
Firefox protocol is a good idea, and the CDP seems to have some nice
qualities. Is there an alternative that is also suitable, or is the
preference that we simultaneously get involved in standardizing CDP
(or at least ensuring that all parties are amenable to doing that
work)?

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

Re: New minimum Rust version policy for Firefox

[Jack Moffitt]

Specifically for webrender (and anything else under the servo org on
GitHub), you can just file a bug and assign to edunham and we'll fix
that up.

jack.

On Thu, Aug 31, 2017 at 10:25 AM, Kartikaya Gupta  wrote:
> Do we have a policy on CI coverage for vendored rust libraries? I'm
> concerned for example that we depend on a number of third-party rust
> libraries that don't do CI builds against rust stable and so it's
> possible they might break. I discovered that webrender CI for example
> is currently only building against 1.17.0 and nightly. I don't think
> we've actually encountered breakage from this but just wondering.
>
> in third_party/rust$ find . -name ".travis.yml" | xargs grep -l
> "rust:" | xargs grep -L -- "stable"
> ./cfg-if/.travis.yml
> ./dtoa/.travis.yml
> ./itoa/.travis.yml
> ./mime/.travis.yml
> ./num/.travis.yml
> ./ordered-float/.travis.yml
> ./semver-0.1.20/.travis.yml
> ./synstructure/.travis.yml
> ./thread-id/.travis.yml
> ./unicode-width/.travis.yml
> ./unicode-xid/.travis.yml
> ./uuid/.travis.yml
>
> Cheers,
> kats
>
> On Tue, Aug 1, 2017 at 2:58 PM, Bobby Holley  wrote:
>> This is great - thanks Ralph!
>>
>> On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles  wrote:
>>
>>> We've formalized a new plan for when we update the minimum-required Rust
>>> version for building Firefox. Starting later this week we'll require the
>>> latest stable Rust two weeks after it is released.
>>>
>>> This means we'll start requiring Rust 1.19.0 August 3rd. If you compile
>>> mozilla-central and haven't run './mach bootstrap' recently, I suggest
>>> doing so now to update.
>>>
>>> I've posted a full schedule
>>> 
>>> of when the minimum version will change for m-c, and what version of Rust
>>> will be required to build each Firefox release. These are expectations to
>>> aid in planning; we may delay particular bumps if there are issues or a
>>> code freeze, but the expectation is that we'll need to update our
>>> development environments by those dates.
>>>
>>> We expect ESR releases will stay on the Rust version of the corresponding
>>> stable release.
>>>
>>> This change is based on several meetings and discussions with contributors
>>> over the last two months. Rust is evolving quickly, and those working on
>>> Rust code need to know what release to target. Previously we updated the
>>> target version every few releases, whenever someone argued there was a
>>> sufficiently compelling feature. Negotiating that every time was
>>> distracting. Having a planned schedule lets everyone coordinate their work.
>>> Updating Rust regularly helps us iterate and improve the language,
>>> participating in the incredible momentum of the Rust developer community.
>>>
>>> Waiting two weeks gives contributors some time to update their
>>> environments. This is especially relevant to those who don't always have a
>>> fast network connection, or work on tier-3 targets where using upstream
>>> Rust packages isn't possible.
>>>
>>> This doesn't affect our policy for official Firefox builds, just developer
>>> builds and downstream packagers. I've written up details of the policy
>>> , along with
>>> motivation and considered alternatives. Please read that before responding
>>> if you have concerns. I'll update the page next week in response to any
>>> persuasive arguments and move the minimum-version proposal to the current
>>> policy section.
>>>
>>> Thanks for you time, and let me know if you have any questions.
>>>
>>> Ralph Giles
>>>
>>> ___
>>> dev-builds mailing list
>>> dev-bui...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-builds
>>>
>>>
>> ___
>> 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: Editing vendored crates take #2

[Jack Moffitt]

There is this bug which the Cargo team is planning to work on to help
with these problems, but it hasn't been implemented yet that I know
of.

https://github.com/rust-lang/cargo/issues/2649#issuecomment-279615299

jack.

On Fri, Apr 28, 2017 at 11:28 AM, Bobby Holley  wrote:
> I definitely made this work at some point:
> https://hg.mozilla.org/try/rev/18dc070e0308
>
> The main difference with what you seem to be doing is that my version
> points directly into third-party/rust, which I think is preferable anyway.
>
> On Fri, Apr 28, 2017 at 10:05 AM, Josh Matthews 
> wrote:
>
>> Back in February there was a discussion about how hard it is to modify
>> vendored Rust crates for Stylo. I can't actually find any solution to that
>> problem - the general idea appears to be "add a [replace] section to a
>> Cargo.toml and run cargo update", but I have not been able to make that
>> work yet. Given that the version of mozilla-central that I'm using contains
>> a vendored copy of rust-cssparser 0.12.2, here's what I have tried:
>>
>> * added the following to servo/Cargo.toml and toolkit/library/rust:
>> [replace]
>> "rust-cssparser:0.12.2" = { path = "/Users/jdm/src/rust-cssparser" }
>>
>> * run `cd servo/Cargo.toml && cargo update -p cssparser`
>> * run `cd toolkit/library/rust && cargo update -p cssparser`
>>
>> This ends up modifying the Cargo.lock files to use the most recent version
>> from crates.io (0.12.4) instead of my local copy. Has anybody been able
>> to make this work? Can we please document the exact steps to follow? There
>> have been multiple people asking in #servo how to do this recently and
>> nobody seems to have done it successfully.
>>
>> Cheers,
>> Josh
>> ___
>> 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: Quantum Flow Engineering Newsletter #5

[Jack Moffitt]

I was not saying the plans don't make sense, only that the ordering
turns out to be unfortunate. I am also not suggesting we modify the
plan, as the WebRender trajectory is not conducive to being a blocker
for any work planed for 57 (as has been pointed out). I do think
people should keep WebRender in mind and not overly design for 57, or
at least not put in constraints we can't undo easily once they are not
necessary.

Regarding the percentage of users who have GPUs, I would suggest we
keep in mind that since we want to win back users to Firefox we
shouldn't be judging new engine features by the small population of
current users, but by the population of users who might switch. If we
build an engine that is a lot better for people with GPUs, you can
expect those people will be more motivated to try it out. Our target
audience is much larger than our existing users, and may have quite
different hardware profiles.

jack.

On Tue, Apr 18, 2017 at 5:22 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> On 2017-04-18 1:53 PM, Justin Dolske wrote:
>>
>>
>> On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt <j...@metajack.im
>> <mailto:j...@metajack.im>> wrote:
>>
>> > Another really nice effort that is starting to unfold and I'm super 
>> excited
>> > about is the new Photon performance project
>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>>, which is a
>> focused
>> > effort on the front-end performance.  This includes everything from
>> > engineering the new UI with things like animations running on the
>> > compositor in mind from the get-go, being laser focused on guaranteeing
>> > good performance on key UI interactions such as tab opening and 
>> closing,
>> > and lots of focused measurements and fixes to the browser front-end.
>>
>> I think the order of operations here is unfortunate. What we'd prefer
>> is that WebRender land first, and then Photon be designed around what
>> is possible in the GPU-backed world.
>>
>>
>> That's a complete non-starter. Photon work is already underway, and
>> there's a _ton_ of work to do for the 57 release.
>
> If I can clarify a bit, the main goal of Photon isn't to be a showcase
> of WebRender capabilities.  The main goal of that project is to get a
> much more responsive UI than what we currently have.  Obviously for the
> implementation we would love to use every bit of power that Gecko
> provides, but we can't rely on anything that will not be 100% certainly
> be part of the 57 release.  The last time I checked with the graphics
> team, at this point it's completely unclear whether Quantum Render is
> going to make it, and as such, it's not reasonable for us to depend on
> anything that WebRender provides for Photon, because if QR wouldn't make
> it to 57 then we wouldn't have a backup plan.
>
> All in all we have a lot of ongoing projects and they each have
> different scales and different degrees of risk associated with them, and
> we are trying hard to be really careful on what project depends on what
> other project to try to protect ourselves from cases where project X
> doesn't make it in time taking project Y down with it.  :-)  Photon is
> such an important piece of the puzzle that making it depend on anything
> that isn't super certain is extremely risky, and without Photon the
> entire release plan for the whole Quantum is going to be jeopardized,
> and that isn't an acceptable risk.
>
> I hope this helps make the plans make more sense.  If they still don't,
> I'm happy to answer more questions!
>
> Cheers,
> Ehsan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #5

[Jack Moffitt]

> Another really nice effort that is starting to unfold and I'm super excited
> about is the new Photon performance project
> , which is a focused
> effort on the front-end performance.  This includes everything from
> engineering the new UI with things like animations running on the
> compositor in mind from the get-go, being laser focused on guaranteeing
> good performance on key UI interactions such as tab opening and closing,
> and lots of focused measurements and fixes to the browser front-end.

I think the order of operations here is unfortunate. What we'd prefer
is that WebRender land first, and then Photon be designed around what
is possible in the GPU-backed world. This ordering means that Photon
will be optimized for operations that all the other engines already
optimize, whereas the WebRender-first order would get us UI that is
previously out of reach for web content. It would be an excellent way
to show off WebRender's benefits since we can't expect web content to
adapt immediately. We have some experimental results from browser.html
that showed there are plenty of cases where Servo gave smooth
performance for real animations the developers wanted to create that
weren't smooth in other engines.

I imagine there are other pieces that benefit both backends, but I
thought I'd point out that specifically for compositor backed
operations, the set of those is quite different between current Gecko
and WebRender.

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

Re: Should cheddar-generated headers be checked in?

[Jack Moffitt]

I think running bindgen at build time will be the best practice. That
is certainly what stylo and the spidermonkey bindings are aiming for.
This capability of bindgen is pretty new, so it will take a while
before the Rust community adapts.

jack.

On Wed, Feb 22, 2017 at 8:49 AM, Ted Mielczarek  wrote:
> On Wed, Feb 22, 2017, at 07:11 AM, Henri Sivonen wrote:
>> Looking at mp4parse, the C header is generated:
>> https://searchfox.org/mozilla-central/source/media/libstagefright/binding/mp4parse_capi/build.rs
>> But also checked in:
>> https://searchfox.org/mozilla-central/source/media/libstagefright/binding/include/mp4parse.h
>>
>> Is this the best current practice that I should follow with encoding_rs?
>>
>> See also:
>> https://users.rust-lang.org/t/how-to-retrieve-h-files-from-dependencies-into-top-level-crates-target/9488
>> (unanswered at the moment)
>
> I don't think we have a best practice for this currently. We hit the
> opposite issue with bindgen, and I've been informed that we need to run
> bindgen at build time because the bindings are ABI-specific. Given that
> the C API here is under your complete control, it seems like it's
> possible to generate a cross-platform header that doesn't have those
> issues, so you could certainly check it in. The only question there is
> how much hassle it will be for you to maintain a checked-in copy.
>
> Alternately you could just generate it at build time, and we could pass
> the path to $(DIST)/include in a special environment variable so you
> could put the header in the right place.
>
> -Ted
> ___
> 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: Notes about implementing DOM APIs in Rust

[Jack Moffitt]

> I do not recall dismissing exposing COM-compatible vtables from Rust.

We must implement COM interfaces in Rust for Windows platform things*
already. Specifically I have macros that generate IUnknown which for
Windows COM includes AddRef, Release, and QueryInterface. For COM
interfaces with single inheritance, this isn't too bad. mystor has
also been hacking on similar things

jack.

* Specifically I've been doing it to get DirectWrite working
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Performance Working Group

[Jack Moffitt]

Many of the proposed output specifications for this seem quite useful
for the kinds of work we are doing in Servo. While this is aimed at
web developers, it seems very useful for browser vendors to be
measuring things the same way. Having standard ways of doing this
means we'll be able to get more accurate cross browser comparisons.

This seems like something we should support.

jack.

On Fri, Jun 3, 2016 at 5:57 PM, L. David Baron  wrote:
> The W3C is proposing a revised charter for:
>
>   Web Performance Working Group
>   https://w3c.github.io/charter-webperf/
>   https://lists.w3.org/Archives/Public/public-new-work/2016Jun/0001.html
>
> Mozilla has the opportunity to send comments or objections through
> Thursday, June 30.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> 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: Intent to Use Counter: Everything

[Jack Moffitt]

We have the Chrome popularity data, and we have the Edge team's data
which covers the CSS spectrum quite well. I think it would be far more
useful to start covering the DOM API spectrum.

For example, it's pretty clear from existing data sources which CSS
properties Servo should focus on. But we have very little data for
which DOM APIs are important.

What value does having even more CSS property data provide above and
beyond the value that can be extracted from the existing sources? Is
that value greater than the value we could extract by focusing on data
that doesn't currently exist?

I assume the answer to the first question is that it gives us data
that doesn't exist about -moz prefixed properties. Regarding the
second question, my opinion is that we can get a lot more benefit from
covering other areas than CSS. I'm curious to hear more informed
opinions on this than my own.

As to where this should live, it seems unfortunate that we would end
up with three repositories of data: Chrome's use counters, Edge's
platform status, and now a Mozilla one. Is it not possible to
consolidate this collection effort?

jack.

On Tue, May 10, 2016 at 1:11 PM, Mike Taylor  wrote:
> Having recently discovered UseCounters.conf[1], I'd like to add use counters
> for all CSS properties, starting with prefixed props. And likewise for
> Moz-prefixed DOM props and methods.
>
> Ultimately, I'd like us to have a Firefox equivalent to
> https://www.chromestatus.com/metrics/css/popularity to help us make
> decisions around removing support for non-standard-isms without breaking the
> web.
>
> (https://platform-status.mozilla.org/ seems like a good home for this kind
> of data)
>
> Before I start writing patches, is there any reason to not do this?
>
> [1] https://dxr.mozilla.org/mozilla-central/source/dom/base/UseCounters.conf
>
> --
> Mike Taylor
> Web Compat, Mozilla
> ___
> 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: Static analysis for "use-after-move"?

[Jack Moffitt]

I apologize if this seemed flippant. I sent it sincerely to show that
such an analysis is possible, and it makes up one of the key features
of Rust. I have no idea how feasible this is to implement in C++, but
I suspect it must be hard as it is one of the main motivations for
Rust.

jack.

On Wed, Apr 27, 2016 at 6:04 PM, Jack Moffitt <j...@metajack.im> wrote:
> On Wed, Apr 27, 2016 at 5:29 PM, Kyle Huey <m...@kylehuey.com> wrote:
>> Can we catch this pattern with a compiler somehow?
>
> Yes. Example:
>
> foo.rs:
>
> struct Foo {
> x: u64,
> }
>
> fn do_bar(foo: Foo) {
> }
>
> fn main() {
> let foo = Foo {
> x: 0,
> };
> do_bar(foo);
> if foo.x == 0 {
> // do stuff
> }
> }
>
>
> $ rustc foo.rs
> foo.rs:13:8: 13:13 error: use of moved value: `foo.x` [E0382]
> foo.rs:13 if foo.x == 0 {
>  ^
>
> jack.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Static analysis for "use-after-move"?

[Jack Moffitt]

On Wed, Apr 27, 2016 at 5:29 PM, Kyle Huey  wrote:
> Can we catch this pattern with a compiler somehow?

Yes. Example:

foo.rs:

struct Foo {
x: u64,
}

fn do_bar(foo: Foo) {
}

fn main() {
let foo = Foo {
x: 0,
};
do_bar(foo);
if foo.x == 0 {
// do stuff
}
}


$ rustc foo.rs
foo.rs:13:8: 13:13 error: use of moved value: `foo.x` [E0382]
foo.rs:13 if foo.x == 0 {
 ^

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

Re: Linux distro readiness for Rust in Gecko

[Jack Moffitt]

> I've been assuming that Firefox would use the Rust "stable" channel
> compiler on the Firefox "release" channel, but I don't know if that
> has ever been really *decided* anywhere. Has it been decided?

Your assumption is correct. For gecko integration related work we use
the stable version of the language. However, this is explicitly not a
policy of Servo, where we make use of all the new features we can get
our hands on. These are not in conflict today*, but may someday be.
We'll handle that issue if we get there.

jack.

* rust-url can actually compile either way for example. We often
handle this by supporting both through the use of Cargo features
(amounting to conditional compilation).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust as build requirement was Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

[Jack Moffitt]

> On the other hand, in that same thread, metajack said, "The current plan is
> to have Rust (in the form of rust-url replacing nsUrlParser) riding the
> trains later this quarter."

And indeed, Rust is now riding the trains with the moov parser. It's
not required for the build yet, but Nightly (and soon Aurora)
dsitributions will both have it.

You can see this by looking at telemetry for MEDIA_RUST_MP4PARSER_SUCCESS.

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