Telemetry Histogram Expiry

[telemetry-alerts]

The following histograms will be expiring on 2017-09-20, and should be removed 
from the codebase, or have their expiry versions updated:

* DOCUMENT_WITH_EXPANDED_PRINCIPAL expires in version 58.0a1 (watched by 
dev-platform@lists.mozilla.org) - Number of documents encountered using an 
expanded principal.

This is an automated message sent by Cerberus. See 
https://github.com/mozilla/cerberus for details and source code.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylo now the default configuration for mozilla-central

[Bobby Holley]

On Tue, Sep 5, 2017 at 4:15 PM, L. David Baron  wrote:

> On Tuesday 2017-09-05 14:55 -0700, Chris Peterson wrote:
> > We can stop testing the "stylo-disabled" test platforms on Mac and
> Windows
> > after we ship Stylo to Release. We can remove them entirely after we ship
> > Stylo on Android.
>
> I think removing those test platforms should also depend on shipping
> Stylo for XUL, and for that matter, getting rid of all the code in:
> nsIDocument::UpdateStyleBackendType:
> https://searchfox.org/mozilla-central/rev/4d8e389498a08668cce9ebf6232cc9
> 6be178c3e4/dom/base/nsDocument.cpp#13525-13552
> and making it always return StyleBackendType::Servo (or deleting the
> function, of course).  Otherwise we risk taking substantial
> regressions in the CSS code backing much of our user interface.
>

Yes, this sounds like the right thing to do.


> -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

Intent to ship: PerformanceObserver

[Hiroyuki Ikezoe]

As of Firefox 57 I intend to turn PerformanceObserver on by default. 
It's been enabled on nightly by default for 16 months. Chrome has 
already shipped it since 52, WebKit has implemented it since January 
2017, but not shipped yet.  Edge has not implemented it yet, but as far 
as I know they have been interested in.


Bugs to turn on by default on all channels: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1386021


Link to standard: https://w3c.github.io/performance-timeline/

Testing: All web platform tests for PerformanceObserver that do not 
require Navigation Timing 2 
.


hiro

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

Re: Stylo now the default configuration for mozilla-central

[L. David Baron]

On Tuesday 2017-09-05 14:55 -0700, Chris Peterson wrote:
> We can stop testing the "stylo-disabled" test platforms on Mac and Windows
> after we ship Stylo to Release. We can remove them entirely after we ship
> Stylo on Android.

I think removing those test platforms should also depend on shipping
Stylo for XUL, and for that matter, getting rid of all the code in:
nsIDocument::UpdateStyleBackendType:
https://searchfox.org/mozilla-central/rev/4d8e389498a08668cce9ebf6232cc96be178c3e4/dom/base/nsDocument.cpp#13525-13552
and making it always return StyleBackendType::Servo (or deleting the
function, of course).  Otherwise we risk taking substantial
regressions in the CSS code backing much of our user interface.

-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)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylo now the default configuration for mozilla-central

[Chris Peterson]

On 2017-09-05 1:10 PM, J. Ryan Stinnett wrote:

Assuming bug 1330412 sticks, Stylo will be the default configuration for
mozilla-central for all platforms except Android.  Thanks to everyone
involved with Stylo that helped us reach this stage!


Awesome! Thanks for flipping the switch, Ryan.



To ensure the old style system remains functional as a fallback,
separate "Stylo
disabled" test platforms have been added. We will also have a small subset
of the population using the old style system via experiments.


Just to be clear, the "stylo-disabled" test platforms will ride the 
trains to Beta and Release to ensure that Gecko's old style system has 
complete test coverage, in case we need to disable Stylo and revert to 
the old style system at the last minute of Beta 57.


We can stop testing the "stylo-disabled" test platforms on Mac and 
Windows after we ship Stylo to Release. We can remove them entirely 
after we ship Stylo on Android.

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

Stylo now the default configuration for mozilla-central

[J. Ryan Stinnett]

Assuming bug 1330412 sticks, Stylo will be the default configuration for
mozilla-central for all platforms except Android.  Thanks to everyone
involved with Stylo that helped us reach this stage!

Nightly users should not notice much change, since there was already an
active experiment that enabled Stylo for most of the Nightly population.

To ensure the old style system remains functional as a fallback,
separate "Stylo
disabled" test platforms have been added. We will also have a small subset
of the population using the old style system via experiments.

As always, if you encounter any issues that could be Stylo related, you can
check Stylo status in about:support.  Please file a bug[1] in Core :: CSS
Parsing and Computation with "Stylo: " in the subject, or stop by #servo on
IRC.

[1]:
https://bugzilla.mozilla.org/enter_bug.cgi?component=CSS%20Parsing%20and%20Computation=Core_desc=Stylo%3A%20

- Ryan
___
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

[Jim Blandy]

As an offer of help, from a group whose charter covers this work, that's
very welcome. I felt that I was being shepherded into something on behalf
of others for whom I cannot speak, which was uncomfortable!

For my own sake, I am disinclined to participate in a standardization
effort outside of the usual institutions. I think we could benefit from the
experience of people who have produced web standards before. I'm not
well-connected enough yet to anticipate what folks will say, but I'll
suggest the Browser Testing Tools WG when the opportunity comes up.


On Tue, Sep 5, 2017 at 5:32 AM, James Graham  wrote:

> On 04/09/17 23:34, Jim Blandy wrote:
>
>> On Mon, Sep 4, 2017 at 7:36 AM, David Burns  wrote:
>>
>>> I don't think anyone would disagree with the reasons for doing this. I,
>>>
>> like James who brought it up earlier, am concerned that we from the emails
>> appear to think that implementing the wire protocol would be sufficient to
>> making sure we have the same semantics.
>>
>> LOL, give us a little credit, okay? The authors of the email do not think
>> that. We want to have a properly written specification and conformance
>> tests. I think you're reading "we have no interest in established
>> standardization processes" when what we wrote was "the process is in very
>> early stages".
>>
>> Do you think the Browser Testing Tools WG is the right body to work on a
>> JS
>> debugging and console protocol, used by interactive developer tools? That
>> seems like a surprising choice to me.
>>
>
> It is certainly not the only possible venue, but if you want to do the
> work at the W3C then it's probably the easiest way to get things going from
> a Process point of view, since this kind of protocol would be in the
> general remit of the group, and the rechartering could add it specifically.
> Certainly the people currently in the group aren't the right ones to do the
> work, but adding new participants to work specifically on this would be
> trivial.
>
> Also - at least as far as I know -  this is not where the current
>> participants in the discussion (Kenneth Auchenberg or Christian Bromann,
>> to
>> name two) have been working. Is having a previously uninvolved standards
>> committee take up an area in which current activity is occurring elsewhere
>> considered friendly and cooperative behavior? It seems unfriendly to me. I
>> would like to avoid upsetting the people I'm hoping to work closely with.
>>
>
> I think you have misinterpreted the intent here. I don't think anyone is
> interested in doing a hostile takeover of existing work. But there is
> concern that the work actually happens. Pointing at remotedebug.org,
> which has been around since 2013 without producing any specification
> materials, isn't helping assuage my concerns, and I guess others are having
> a similar reaction. It is of course entirely possible that there's work
> going on that we can't see. But my interpretation of David's email is that
> he is trying to offer you options, not force you down a certain path. The
> W3C is not always the right venue to work in, but it is sometimes sought
> out by organisations who would likely participate in this work because of
> its relatively strong IPR policy.
>
> I should stress that irrespective of venue I would expect this
> standardisation effort to take years; people always underestimate the work
> and time required for standards work. It will certainly require us to
> commit resources to make it happen.
>
> ___
> 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: Proposal: Unified Bootstrap Stages for Gecko

[Mike Conley]

Hey gandalf,

Using WICG for browser start-up makes sense to me.

We should also consider adding a milestone for the "hero element" for
the browser. There's some discussion fragments in bug 1369417 about this
(which I see you're already involved in! Great!), captured from a very
caffeinated discussion with jmaher, florian and a few other folks in SF
this past all-hands.

At any rate, this all sounds strictly better than what ts_paint
currently captures. We just need to ensure that we measure paint times
when they're presented to the user (so after composite), and using the
timestamps on the MozAfterPaint events themselves[1] (and not taking a
timestamp at the event-servicing time, as this adds noise and padding to
the timestamp).

So, uh, thumbs up from me. :)

-Mike

[1]:
http://searchfox.org/mozilla-central/rev/f2a1911ad310bf8651f342d719e4f4ca0a7b9bfb/dom/webidl/NotifyPaintEvent.webidl#36

On 2017-08-31 6:51 PM, zbranie...@mozilla.com wrote:
> Gecko has a pretty substantial number of metrics used for measuring startup 
> performance.
> 
> We have probes in Telemetry [0], StartupTimeline [1], various uses of 
> MozAfterPaint, both in talos tests [2] and in production code [3][4].
> We also have first paint in compositor [5], before-first-paint [6], 
> timeToNonBlankPaint [7] which should not be confused with firstNonBlankPaint 
> [8] and probably a number of other probes that register different timestamps 
> and are used all around to mean different things. Some measure layout, others 
> composition. Many of them are misused by capturing the timestamp in the 
> callback to event listener fired asynchronously post-event.
> We end up seeing huge swings in some "first-paint" [9] that are not 
> reproducible in another "first-paint" [10], and we know that things like 
> WebRender may not affect some of our "first-paint" because it measures only 
> part of paint that WebRender doesn't affect[11].
> 
> It doesn't help that some of them are chrome-only while others are available 
> in content.
> 
> I believe that, while we can recognize the complexity of the systems in play 
> and how this complexity explains why different probes ended up being 
> constituted, this situation is counter productive to our ability to 
> understand the performance implication of our changes in product.
> 
> I'd like to suggest establishing a single set of timestamps with unique names 
> to represent various stages of the product launch.
> Those timestamps would be described based on the user-perceived results and 
> as such serve us as best-effort approximations of the impact of any change on 
> the user-perceived experience.
> 
> In particular, my proposal is based on WICG Paint Timing proposal [12] and 
> establishes the 5 major timestamps to be executed at the latest event that 
> contributes to the user-perceived outcome.
> For example, when selecting when to mark "xPaint" event, we will use the 
> consumer notion of the term "paint" and mark it after *all* operations 
> required for the paint to happen are done - layout, composition, rendering 
> and paint.
> 
> My proposal is also based on the work on negotiated performance milestones 
> established for Firefox OS project [13].
> 
> The proposed milestones are:
> 
> 1) firstPaint
> 
> This milestone happens when the first paint that is influenced by the data 
> for the measured object is completed by the engine (and likely submitted to 
> the graphic driver).
> 
> In the context of an HTML document, the first paint that is affected by the 
> document's background or title is completed.
> 
> 2) firstContentfulPaint
> 
> The first contentful paint of browser.xul happens when the first paint that 
> includes layout of DOM data from browser.xul is completed.
> 
> 3) visuallyCompletedPaint
> 
> This milestones is achieved after the first paint with the above-the-fold 
> part of the DOM ready is submitted. This event may require the document to 
> inform the engine that all the items in the visual field are ready, and the 
> next paint captures the timestamp.
> 
> 4) chromeInteractive
> 
> This milestone is achieved when the app reports the UI to be ready to be 
> interacted with. The definition of what constitutes of the UI being ready is 
> up to the app, and may just include the URL bar being ready to receive URL 
> input, or may wait for all core parts of the product to have event handlers 
> attached (urlbar, tabbar, main menu etc.)
> This milestone may be reached before (3), but not after (5).
> 
> 5) fullyLoaded
> 
> This milestone also may require data from the document and it should mark the 
> timestamp when all startup operations are completed.
> This should include delayed startup operations that may have waited for 
> previous stages to be achieved, but should not wait for non-startup delayed 
> operations like periodic updates of data from AMO etc.
> 
> The last milestone is a good moment to reliably measure memory consumption 
> (possibly after performing GC), take a 

Re: Implementing a Chrome DevTools Protocol server in Firefox

[James Graham]

On 04/09/17 23:34, Jim Blandy wrote:

On Mon, Sep 4, 2017 at 7:36 AM, David Burns  wrote:

I don't think anyone would disagree with the reasons for doing this. I,

like James who brought it up earlier, am concerned that we from the emails
appear to think that implementing the wire protocol would be sufficient to
making sure we have the same semantics.

LOL, give us a little credit, okay? The authors of the email do not think
that. We want to have a properly written specification and conformance
tests. I think you're reading "we have no interest in established
standardization processes" when what we wrote was "the process is in very
early stages".

Do you think the Browser Testing Tools WG is the right body to work on a JS
debugging and console protocol, used by interactive developer tools? That
seems like a surprising choice to me.


It is certainly not the only possible venue, but if you want to do the 
work at the W3C then it's probably the easiest way to get things going 
from a Process point of view, since this kind of protocol would be in 
the general remit of the group, and the rechartering could add it 
specifically. Certainly the people currently in the group aren't the 
right ones to do the work, but adding new participants to work 
specifically on this would be trivial.



Also - at least as far as I know -  this is not where the current
participants in the discussion (Kenneth Auchenberg or Christian Bromann, to
name two) have been working. Is having a previously uninvolved standards
committee take up an area in which current activity is occurring elsewhere
considered friendly and cooperative behavior? It seems unfriendly to me. I
would like to avoid upsetting the people I'm hoping to work closely with.


I think you have misinterpreted the intent here. I don't think anyone is 
interested in doing a hostile takeover of existing work. But there is 
concern that the work actually happens. Pointing at remotedebug.org, 
which has been around since 2013 without producing any specification 
materials, isn't helping assuage my concerns, and I guess others are 
having a similar reaction. It is of course entirely possible that 
there's work going on that we can't see. But my interpretation of 
David's email is that he is trying to offer you options, not force you 
down a certain path. The W3C is not always the right venue to work in, 
but it is sometimes sought out by organisations who would likely 
participate in this work because of its relatively strong IPR policy.


I should stress that irrespective of venue I would expect this 
standardisation effort to take years; people always underestimate the 
work and time required for standards work. It will certainly require us 
to commit resources to make it happen.

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