Proposed W3C Charter: WebAssembly Working Group

On Wednesday 2017-05-24 09:30 -0400, L. David Baron wrote: > The W3C gave advance notice that a charter is under development for > a new working group: > > WebAssembly Working Group > https://w3c.github.io/charter-drafts/webassembly.html > https://github.com/w3c/charter-drafts/ > https://l

Re: More Rust code

On Mon, Jul 10, 2017 at 5:39 PM, Nicholas Nethercote wrote: > On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley > wrote: > >> >> In other words, I think we should encourage people to consider Rust for >> new code, but also make sure that we have a thoughtful and informed >> discussion about whether

Re: More Rust code

On 7/10/17 4:48 PM, Xidorn Quan wrote: The first thing comes to my mind is crash reports. It currently doesn't always include useful panic message from Rust, see for example [1] and [2]. Also for Stylo, we generate lots of code (including using bindgen and mako template system, bindgen is usua

Re: More Rust code

On Tue, Jul 11, 2017 at 9:48 AM, Xidorn Quan wrote: > Tooling around debug info in Rust code still isn't great. > The good news is that tooling issues are generally among the easier ones to solve. Even the existing Rust code that is present in Firefox will require at least some of these things t

Re: More Rust code

On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley wrote: > > In other words, I think we should encourage people to consider Rust for > new code, but also make sure that we have a thoughtful and informed > discussion about whether a use-case makes sense and how best to support it. > Definitely! I del

Re: More Rust code

On Mon, Jul 10, 2017 at 11:41 PM, smaug wrote: > > - Interop with existing components can be difficult. IPDL codegen rust >> bindings could be a big help. >> > > ipdl? or do you mean idl? or perhaps webidl? > bkelly suggested that item to me on Twitter :) Probably all three of those are relevan

Re: More Rust code

On Mon, Jul 10, 2017, at 08:29 PM, Nicholas Nethercote wrote: > Firefox now has multiple Rust components, and it's on track to get a bunch > more. See https://wiki.mozilla.org/Oxidation for details.> > I think this is an excellent trend, and I've been thinking about how to > accelerate it. Here'

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

>On Monday, July 10, 2017 at 3:28:07 PM UTC+12, Randell Jesup wrote: >I added these stats originally, and they are now mostly superseded by the >stats provided by VideoPlaybackQuality. So I support their removal (in fact >I suggested to Tim that he remove them). > >Adding telemetry to learn how oft

Re: Switching to per-channel profiles

On Tue, Jun 27, 2017 at 01:48:33PM -0400, Ehsan Akhgari wrote: On 06/27/2017 01:36 PM, Milan Sreckovic wrote: I don't know how common this workflow is for others, but I do find I often need to use release/beta to "fix" experimental preferences when things go wrong. For features that are behind

Re: Switching to per-channel profiles

>What happens when users do that? Because they do. > >A variety of kinda-horrible things will happen. > >The two copied profiles will compete for the Sync client record. That means >sent tabs will appear on one or the other, the Tabs from Other Devices list >will flip-flop between each of the two d

Re: More Rust code

On 07/10/2017 09:04 PM, zbranie...@mozilla.com wrote: One more thought. There's a project that fitzgen told me about that aims to allow for components to communicate between JS and Rust using Streams. If we could get to the point where instead of WebIDL/XPIDL we could just plug streams between

Re: More Rust code

One more thought. There's a project that fitzgen told me about that aims to allow for components to communicate between JS and Rust using Streams. If we could get to the point where instead of WebIDL/XPIDL we could just plug streams between JS/CPP and Rust in Gecko, I believe the scope of Gecko

Re: More Rust code

On Mon, Jul 10, 2017 at 08:29:59PM +1000, Nicholas Nethercote wrote: I think this is an excellent trend, and I've been thinking about how to accelerate it... - Interop with existing components can be difficult. IPDL codegen rust bindings could be a big help. So far, this has been my biggest is

Re: Bulk Closing Intermittents

This was the first time we bulk closed these bugs, and there will be some glitches. I don't consider this to be a blocker on continuing this work. Next time we do this, it won't be 5,000+ bugs. OrangeBot runs on Sundays, so we can do the cleanup on Monday. The long term goal is to stop using Bugz

Re: Bulk Closing Intermittents

Dylan, Thank you for clarifying that difference. That was sloppy of me to describe that as a DBA operation. -- Emma On Mon, Jul 10, 2017 at 7:25 AM, Dylan Hardison wrote: > > > > > On Jul 7, 2017, at 19:35, Emma Humphries wrote: > > > > The first batch of intermittent bugs to close has 5,130

Re: More Rust code

There are obvious benefits to writing new things in Rust. In general, the main barrier to doing so is the extent to which they may interact with existing C++ code, and the adequacy of our tooling for managing that interaction. In London last year, we had a meeting to discuss how we wanted to use R

Re: Embedding Firefox or Gecko in 2017

cnico7 2017 July 6 at 12:47 I had the idea of using firefox with marionette protocol in order to interact with the engine and to use a custom plugin in order to hide all the design (menus, tab bars,...). This idea has many drawbacks : it is slow at launching

Re: More Rust code

Hi, This year I've been working on three new components[0] and I considered Rust for both. At the time, when asked people on #rust and #developers, the answer was that oxidation targets should have very simple APIs, because getting anything more complex than strings/ints between rust and cpp/js i

Re: More Rust code

I am organizing a second rust training in Paris in September or October (amongst others) The registration has been sent to the French staff last week. Will be shared with the European staff at the end of the week. Le lun. 10 juil. 2017 à 12:30, Nicholas Nethercote a écrit : > Hi, > > Firefox no

Re: More Rust code

On Mon, Jul 10, 2017 at 9:41 AM, smaug wrote: > ipdl? or do you mean idl? or perhaps webidl? > Also, xpconnect doesn't deal with rust, and our chrome code still heavily > relies on idl+xpconnect. > I have written https://bugzilla.mozilla.org/show_bug.cgi?id=1293362, which while I'm not actively

Re: Bulk Closing Intermittents

> > On Jul 7, 2017, at 19:35, Emma Humphries wrote: > > The first batch of intermittent bugs to close has 5,130 tickets. I have a > script to close these, but to close these without bug spam requires DBA > intervention. This is not a correct statement. DBAs do not modify bugzilla data. Instead

Re: More Rust code

On 07/10/2017 01:29 PM, Nicholas Nethercote wrote: Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a provocative

Re: Bulk Closing Intermittents

It might be a good idea to integrate this process with the OrangeFactor Robot, to avoid race conditions like what happened on bug 1328486 (it was bulk-closed, and then a couple of hours later the OF robot reported that there were two failures this week - but the bug remained closed). Cheers, kats

Re: More Rust code

On 10.07.2017 12:29, Nicholas Nethercote wrote: > > What are the obstacles? Here are some that I've heard. > > - Lack of Rust expertise for both writing and reviewing code. We have some > pockets of expertise, but these need to be expanded greatly. I've heard > that there has been some Rust train

More Rust code

Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a provocative goal worth considering: "when writing a new compiled

Re: Intent to ship: Frames timing functions

Since sending this intent to ship, questions have been raised over the suitability of the frames() name.[1] In order to allow the standards discussion to play out without being bound by shipping implementations, Chrome have decided to abort shipping their implementation to the release channel for

Re: Intent to unship: moz*Frames attributes of HTMLVideoElement

On Fri, Jul 7, 2017 at 5:57 PM, Ehsan Akhgari wrote: > Yes indeed. (I just commented the same about unshipping another feature in > a different thread, so I won't repeat literally all of the same points here, > but they all apply here too!) I created https://wiki.mozilla.org/WebAPI/ExposureGuid

Re: Leakage of amount of storage used

On Mon, Jul 10, 2017 at 8:54 AM, Shawn Huang wrote: > I wondered that it's easy to find the identity by collecting how much space > all other origins take up together. It's possible that the size of other > origins that user has visited could change next time. Unless users don't > browse other sit