Re: Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

Hi! On Thursday, August 18, 2016 at 9:26:37 AM UTC+9, Chris Peterson wrote: > On 8/17/2016 5:03 PM, Karl Dubost wrote: > > Chris, > > > > Le 18 août 2016 à 02:21, Chris Peterson a écrit : > >> Here is a status report from the Chrome team about their current and > >> future "interventions": > >>

Re: Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

On 8/17/2016 5:03 PM, Karl Dubost wrote: Chris, Le 18 août 2016 à 02:21, Chris Peterson a écrit : Here is a status report from the Chrome team about their current and future "interventions": https://docs.google.com/document/d/1vqM_Dbi-V7LtdOwb2IGjgor9Fvl5k_FvO2DJGr4CaSQ/ An intervention is

Re: Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

Chris, Le 18 août 2016 à 02:21, Chris Peterson a écrit : > Here is a status report from the Chrome team about their current and future > "interventions": > https://docs.google.com/document/d/1vqM_Dbi-V7LtdOwb2IGjgor9Fvl5k_FvO2DJGr4CaSQ/ > An intervention is when a user agent decides to deviate s

RFC: Implementing tools/process for tracking push end-to-end times and other Mozilla CI metrics

Hey all, I've been prototyping a new tool for monitoring the performance of our infrastructure called "Infraherder" (in particular focusing on tracking the end-to-end time from push submission to a full set of test/build results being available) and I'm at the point where I'd like to get some i

Re: Visualizing Crash Data in Bugzilla

I love this, and it's encouraging me to try an experiment with web extensions to help with triaging bugs. -- Emma On Tue, Aug 16, 2016 at 3:29 PM, Bob Clary wrote: > This is *way* cool! The historical feedback for the signatures is very > compelling. I recommend everyone try it out and that we

Taskcluster and tree closures

The TaskCluster team's goal is to provide a reliable efficient system to support software engineers working to make Mozilla's products awesome. Tree closures prevent engineers from getting that work done. The team treats tree closure downtime as a critical metric and treating any bugs that arise as

Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

Here is a status report from the Chrome team about their current and future "interventions": https://docs.google.com/document/d/1vqM_Dbi-V7LtdOwb2IGjgor9Fvl5k_FvO2DJGr4CaSQ/ An intervention is when a user agent decides to deviate slightly from a standardized behavior in order to provide a grea

Re: Intent to put Permission API's .revoke() method behind a pref

I support putting .revoke() behind a pref (I would like to go further and remove it since I find it problematic, but a pref is a start). On 8/17/16 3:34 AM, Anne van Kesteren wrote: On Wed, Aug 17, 2016 at 9:13 AM, Marcos Caceres wrote: We should maybe also pref .query() too... wdyt? The ma

Re: Intent to put Permission API's .revoke() method behind a pref

On August 17, 2016 at 5:02:07 PM, Anne van Kesteren (ann...@annevk.nl) wrote: > On Wed, Aug 17, 2016 at 6:48 AM, wrote: > > There is consensus that .query() is beneficial, so that one can remain. > > Is there really? Well, the use case at least: that a developer should not need to actually invoke

Re: Non-standard stuff in the /dom/ directory

On 17 August 2016 at 13:07, Benjamin Francis wrote: > As discussed in the public B2G Weekly > meetings, the B2G community want > to remove ~30 APIs (~10 of which they have already removed) from Gecko, but > keep ~3 chrome-only APIs and the Gonk widget layer

Re: Non-standard stuff in the /dom/ directory

On 17 August 2016 at 05:05, Kyle Huey wrote: > s/moved out/deleted/ > > This is a complicated subject caught in a variety of internal > politics. I suggest you raise it with your management chain ;) It's really not that complicated and there's no need to be so Machiavellian about it :) As dis

Re: Intent to put Permission API's .revoke() method behind a pref

On Wed, Aug 17, 2016 at 5:34 PM, Anne van Kesteren wrote: > Interesting, I guess I didn't realize that covered more than just > query(). If we ship a subset of an API it probably would help to be > clear, indeed. Well, it only mentioned .query() explicitly, but then said "other parts will be impl

Re: Intent to put Permission API's .revoke() method behind a pref

On Wed, Aug 17, 2016 at 9:13 AM, Marcos Caceres wrote: > Well, it covers the 80% case (specially on mobile, where tabs are not > at useful). But yeah... the model is not there :( That is a good point. When isolated to a browsing context it's still very useful information for website UX. > We s

Re: Intent to put Permission API's .revoke() method behind a pref

On Wed, Aug 17, 2016 at 5:02 PM, Anne van Kesteren wrote: > The main problem with query as I see it is that since we haven't > agreed on what permissions are keyed on, an application cannot really > do anything with the answer it gets from query. E.g., communicating > the answer with other open ta

Re: Intent to put Permission API's .revoke() method behind a pref

On Wed, Aug 17, 2016 at 6:48 AM, wrote: > There is consensus that .query() is beneficial, so that one can remain. Is there really? The main problem with query as I see it is that since we haven't agreed on what permissions are keyed on, an application cannot really do anything with the answer i