Re: Intent to deprecate: MacOS 10.6-10.8 support

[Mike Hommey]

On Tue, May 10, 2016 at 10:58:25PM -0400, Lawrence Mandel wrote:
> On Fri, May 6, 2016 at 6:43 AM, Xidorn Quan  wrote:
> 
> > On Fri, May 6, 2016 at 8:24 PM, Mike Hommey  wrote:
> >
> > > On Fri, May 06, 2016 at 06:01:12PM +1000, Xidorn Quan wrote:
> > > >
> > > > It's Firefox 48, three versions after ESR 45, which is roughly halfway
> > > > before the next ESR.
> > >
> > > 48 is the first version that will *not* have 10.6-10.8 support.
> >
> >
> > On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:
> > > The blog post just says "August 2016". Firefox 48 is scheduled for
> > > release August 2. Can you confirm that means we can start removing
> > > 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
> >
> > This post reads to me that we start dropping 10.6~10.8 since Firefox 49, so
> > Firefox 48 should be the last one with that support. Am I missing something
> > here?
> >
> 
> The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
> and 10.8 in August, 2016." This means that we will end support with the
> Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.

That's why the post should have given a version number instead of an
ambiguous date.

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Lawrence Mandel]

On Fri, May 6, 2016 at 6:43 AM, Xidorn Quan  wrote:

> On Fri, May 6, 2016 at 8:24 PM, Mike Hommey  wrote:
>
> > On Fri, May 06, 2016 at 06:01:12PM +1000, Xidorn Quan wrote:
> > >
> > > It's Firefox 48, three versions after ESR 45, which is roughly halfway
> > > before the next ESR.
> >
> > 48 is the first version that will *not* have 10.6-10.8 support.
>
>
> On Mon, May 2, 2016 at 2:28 PM, Ralph Giles  wrote:
> > The blog post just says "August 2016". Firefox 48 is scheduled for
> > release August 2. Can you confirm that means we can start removing
> > 10.6-10.8 support in mozilla-central now, which will be Firefox 49?
>
> This post reads to me that we start dropping 10.6~10.8 since Firefox 49, so
> Firefox 48 should be the last one with that support. Am I missing something
> here?
>

The post states "Mozilla will end support for Firefox on OS X 10.6, 10.7,
and 10.8 in August, 2016." This means that we will end support with the
Firefox 48 release. i.e. Firefox 48 will not support OS X 10.6-10.8.

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

Re: Reverting to VS2013 on central and aurora

[Robert Strong]

On Tue, May 10, 2016 at 6:55 PM, Lawrence Mandel 
wrote:

> On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg 
> wrote:
>
> > I agree that we should drop support for non-SSE2. It mattered 7 years ago
> > (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> > doesn't matter now.
> >
> > We do need to avoid updating these users to a build that will crash, and
> do
> > the same "unsupported" messaging we're doing for old versions of MacOS.
> > Gregory, will you own that? You will probably need to add CPU feature
> > detection to the update URL/params for 47, or use some kind of system
> addon
> > to shunt these users off the main update path.
> >
>
> Benjamin - We're likely going to want to do this again in the future. Not
> that Greg isn't capable but is there someone more familiar with the update
> system who can step in to get this done?
>
The majority of this involves getting whether the CPU supports SSE. The app
update part involves inserting the value into the url.

Having said that, I've already started looking at this today. It would be
good to know whether this info will be needed on other platforms at some
point as well.

Robert


>
> Lawrence
>
>
> >
> > --BDS
> >
> >
> > On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:
> >
> > > On 2016-05-06 12:26 AM, Gregory Szorc wrote:
> > >
> > >> FWIW, the crashes we've seen so far are from incorrectly emitted movss
> > >> instructions. This instruction is part of the original SSE instruction
> > >> set,
> > >> which was initially unveiled by Intel on the Pentium 3 in 1999 and
> later
> > >> by
> > >> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
> > >> need
> > >> Firefox to run on processors manufactured in the 90s.
> > >>
> > > Per an IRC conversation with chutten, Firefox users on CPUs that do not
> > > support SSE are 0.015% of our user base. (compared to 0.4% for
> no-SSE2).
> > A
> > > third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> > > etc), this work provides continuity of support to 0.01% of our users.
> > >
> > > - mhoye
> > >
> > >
> > > 09:59  So, to put it clearly and precisely, of the Firefox
> > > Population in release and beta who are reporting at least base
> telemetry
> > > collection on machines running supported configurations, only 0.01%
> > cannot
> > > definitively say they have SSE.
> > > 10:00  (according to a 1% random sample as stored in the
> > > longitudinal dataset)
> > >
> > > ___
> > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Xidorn Quan]

On Wed, May 11, 2016 at 11:51 AM, Lawrence Mandel 
wrote:
>
> On Tue, May 10, 2016 at 7:29 PM, Xidorn Quan 
> wrote:
>
>> On Wed, May 11, 2016 at 6:45 AM, Gregory Szorc  wrote:
>>
>> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  wrote:
>> >
>> > > There is a compiler bug in VS2015 that results in SSE instructions
>> being
>> > > emitted when they shouldn't be. Since Firefox still needs to remain
>> > > compatible with ancient hardware that doesn't support SSE, this is
>> > causing
>> > > crashes on Firefox built with VS2015 (see bug 1265615).
>> > >
>> > > The good news is glandium found a pretty minimal reproduce case and
>> > > reported the bug to Microsoft.
>> > >
>> > > The bad news is the issue still reproduces in the latest pre-release
>> > > version of the Visual C++ toolchain.
>> > >
>> > > The worse news is we'll have to revert to building Firefox 48 (current
>> > > Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
>> > > track. Aurora will likely land soon. Central might take a few days,
>> as I
>> > > believe VS2013 is a bit broken on central at the moment.
>> > >
>> >
>> > We have a change in plans.
>> >
>> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
>> > SSE instructions isn't an issue.
>> >
>> > But we need to teach the updater to advertise CPU features in the
>> Firefox
>> > version before we drop SSE so we don't update users to a binary that
>> won't
>> > work. Since Firefox 48/Aurora is currently using VS2015, that would mean
>> > teaching Firefox 47/Beta new tricks. Since we're already in the middle
>> of
>> > the Beta cycle and there is no major user benefit to shipping VS2015
>> builds
>> > at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
>> > build the updater support into Firefox 48/Aurora. Firefox 49/Nightly
>> will
>> > continue to build with VS2015 and will be the first Firefox version to
>> > require SSE.
>> >
>> > Bug 1271755 is our tracker for requiring SSE to run Firefox.
>> >
>>
>> As we are dropping another set of users in Firefox 48 in addition to OS X
>> 10.6~10.8, could we reconsider making Firefox 48 a half-ESR as I proposed
>> in [1]?
>>
>> [1]
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/gXZj0rQWEfI/RIeuLYTvAAAJ
>
>
> What you're suggesting is to continue providing support for these
> platforms for a longer period of time. The intention is to stop supporting
> these platforms. We have already made the decision (and in the case of OSX
> announced it). I don't think we have good cause to change this decision at
> this point.
>

We have to do that for ESR 45 anyway, right? That means people would have
to either abandon their platform, or downgrade to ESR 45 for a longer
period security support. I'm proposing that we make 48 a special version
which ends support at the same time ESR 45 does, so that people can keep in
Firefox 48 and continue receiving security fixes for a while as long as we
are still supporting an even older version which supports those platforms.

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

Re: Reverting to VS2013 on central and aurora

[Lawrence Mandel]

On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg 
wrote:

> I agree that we should drop support for non-SSE2. It mattered 7 years ago
> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> doesn't matter now.
>
> We do need to avoid updating these users to a build that will crash, and do
> the same "unsupported" messaging we're doing for old versions of MacOS.
> Gregory, will you own that? You will probably need to add CPU feature
> detection to the update URL/params for 47, or use some kind of system addon
> to shunt these users off the main update path.
>

Benjamin - We're likely going to want to do this again in the future. Not
that Greg isn't capable but is there someone more familiar with the update
system who can step in to get this done?

Lawrence


>
> --BDS
>
>
> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye  wrote:
>
> > On 2016-05-06 12:26 AM, Gregory Szorc wrote:
> >
> >> FWIW, the crashes we've seen so far are from incorrectly emitted movss
> >> instructions. This instruction is part of the original SSE instruction
> >> set,
> >> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
> >> by
> >> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
> >> need
> >> Firefox to run on processors manufactured in the 90s.
> >>
> > Per an IRC conversation with chutten, Firefox users on CPUs that do not
> > support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2).
> A
> > third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> > etc), this work provides continuity of support to 0.01% of our users.
> >
> > - mhoye
> >
> >
> > 09:59  So, to put it clearly and precisely, of the Firefox
> > Population in release and beta who are reporting at least base telemetry
> > collection on machines running supported configurations, only 0.01%
> cannot
> > definitively say they have SSE.
> > 10:00  (according to a 1% random sample as stored in the
> > longitudinal dataset)
> >
> > ___
> > 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: Reverting to VS2013 on central and aurora

[Lawrence Mandel]

On Tue, May 10, 2016 at 7:29 PM, Xidorn Quan  wrote:

> On Wed, May 11, 2016 at 6:45 AM, Gregory Szorc  wrote:
>
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  wrote:
> >
> > > There is a compiler bug in VS2015 that results in SSE instructions
> being
> > > emitted when they shouldn't be. Since Firefox still needs to remain
> > > compatible with ancient hardware that doesn't support SSE, this is
> > causing
> > > crashes on Firefox built with VS2015 (see bug 1265615).
> > >
> > > The good news is glandium found a pretty minimal reproduce case and
> > > reported the bug to Microsoft.
> > >
> > > The bad news is the issue still reproduces in the latest pre-release
> > > version of the Visual C++ toolchain.
> > >
> > > The worse news is we'll have to revert to building Firefox 48 (current
> > > Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> > > track. Aurora will likely land soon. Central might take a few days, as
> I
> > > believe VS2013 is a bit broken on central at the moment.
> > >
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
> >
> > But we need to teach the updater to advertise CPU features in the Firefox
> > version before we drop SSE so we don't update users to a binary that
> won't
> > work. Since Firefox 48/Aurora is currently using VS2015, that would mean
> > teaching Firefox 47/Beta new tricks. Since we're already in the middle of
> > the Beta cycle and there is no major user benefit to shipping VS2015
> builds
> > at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
> > build the updater support into Firefox 48/Aurora. Firefox 49/Nightly will
> > continue to build with VS2015 and will be the first Firefox version to
> > require SSE.
> >
> > Bug 1271755 is our tracker for requiring SSE to run Firefox.
> >
>
> As we are dropping another set of users in Firefox 48 in addition to OS X
> 10.6~10.8, could we reconsider making Firefox 48 a half-ESR as I proposed
> in [1]?
>
> [1]
>
> https://groups.google.com/d/msg/mozilla.dev.platform/gXZj0rQWEfI/RIeuLYTvAAAJ


What you're suggesting is to continue providing support for these platforms
for a longer period of time. The intention is to stop supporting these
platforms. We have already made the decision (and in the case of OSX
announced it). I don't think we have good cause to change this decision at
this point.

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

Re: Reverting to VS2013 on central and aurora

[Lawrence Mandel]

On Tue, May 10, 2016 at 7:05 PM, Ehsan Akhgari 
wrote:

> On 2016-05-10 4:45 PM, Gregory Szorc wrote:
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  wrote:
> >
> >> There is a compiler bug in VS2015 that results in SSE instructions being
> >> emitted when they shouldn't be. Since Firefox still needs to remain
> >> compatible with ancient hardware that doesn't support SSE, this is
> causing
> >> crashes on Firefox built with VS2015 (see bug 1265615).
> >>
> >> The good news is glandium found a pretty minimal reproduce case and
> >> reported the bug to Microsoft.
> >>
> >> The bad news is the issue still reproduces in the latest pre-release
> >> version of the Visual C++ toolchain.
> >>
> >> The worse news is we'll have to revert to building Firefox 48 (current
> >> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> >> track. Aurora will likely land soon. Central might take a few days, as I
> >> believe VS2013 is a bit broken on central at the moment.
> >>
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
>
> Firstly, great to hear this!
>
> But since the topic of when to drop support for legacy platforms seems
> to be coming up a few times per week these days, it would be helpful to
> document somewhere how the decision to drop support for processors not
> supporting SSE was reached.  Do we have data covering what number of
> users will be affected by this change?  Do we have guidelines on what's
> the threshold for supporting other similar legacy configs?
>
> It would be helpful to see some information about this shared here.
>
> I don't know how this specific decision was reached but I did speak with
Chris Cooper and Peter Dolanjski about developing criteria/guidelines for
support today. I don't expect us to have something this month but we will
flesh this out as part of the ongoing conversation about platform support.

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

Re: Intent to Use Counter: Everything

[Jonas Sicking]

On Tue, May 10, 2016 at 1:31 PM, Mike Taylor  wrote:

> On 5/10/16 3:05 PM, Jack Moffitt wrote:
>
>> 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.
>>
>
> Interesting, my own interests are naturally skewed towards finding the
> moz-isms and understanding how and when we can get rid of them (if ever).
> But I can see how understanding DOM API usage is more relevant when
> building a new browser engine.


There are lots of moz-isms in the DOM as well.

The moz-isms aren't as easy to spot in the DOM since there's much less of a
history of prefixing DOM-API names, but they certainly exist.

And there are definitely cases when we'd like to deprecate APIs even if
they aren't moz-isms. Two recent examples are showModalDialog and the XSLT
API.

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

Request Feedback - Submitting Canvas Frames, WebVR Compositor

[Kearwood "Kip" Gilbert]

Hello All,

In order to support features in the WebVR 1.0 API 
(https://mozvr.com/webvr-spec/) and to improve performance for WebVR, I would 
like to implement an optimized path for submitting Canvas and OffscreenCanvas 
frames to VR headsets.  The WebVR 1.0 API introduces "VR Layers", explicit 
frame submission, and presenting different content to the head mounted display 
independently of the output the regular 2d monitor.  I would like some feedback 
on a proposed “VR Compositor” concept that would enable this.

What would be common between the “VR Compositor” and the regular “2d 
Compositor”?
- TextureHost and TextureChild would be used to transfer texture data across 
processes.
- When content processes crash, the VR Compositor would continue to run.
- There is a parallel between regular layers created by layout and “VR Layers”.
- There would be one VR Compositor serving multiple content processes.
- The VR Compositor would not allow unprivileged content to read back frames 
submitted by other content and chrome ux.
- Both compositors would exist in the “Compositor” process, but in different 
threads.

What is different about the “VR Compositor”?
- The VR Compositor would extend the PVRManager protocol to include VR Layer 
updates.
- The VR Compositor will not obscure the main 2d output window or require 
entering full screen to activate a VR Headset.
- In most cases, there will be no visible window created by the VR Compositor 
as the VR frames are presented using VR specific API’s that bypass the OS-level 
window manager.
- The VR Compositor will not run synchronously with a refresh driver as it can 
simultaneously present content with mixed frame rates.
- Texture updates submitted for VR Layers would be rendered as soon as 
possible, often asynchronously with other VR Layer updates.
- VR Layer textures will be pushed from both Canvas elements and 
OffscreenCanvas objects, enabling WebVR in WebWorkers.
- The VR compositor will guarantee perfect frame uniformity, with each frame 
associated with a VR headset pose frame explicitly passed into 
VRDisplay.SubmitFrame.  No frames will be dropped, even if multiple frames are 
sent within a single hardware vsync.
- For most devices (i.e. Oculus and HTC Vive), the VR Compositor will perform 
front-buffer rendering.
- VR Layers asynchronously move with the user’s HMD pose between VR Layer 
texture updates if given geometry and a position within space.
- The VR Compositor implements latency hiding effects such as Asynchronous Time 
Warp and Pose Prediction.
- The VR Compositor will be as minimal as possible.  In most cases, the VR 
Compositor will offload the actual compositing to the VR device runtimes.  
(Both Oculus and HTC Vive include a VR compositor)
- When the VR device runtime does not supply a VR Compositor, we will emulate 
this functionality.  (i.e. for Cardboard VR)
- All VR hardware API calls will be made exclusively from the VR Compositor’s 
thread.
- The VR Compositor will implement focus handling, window management, and other 
functionality required for Firefox to be launched within environments such as 
Oculus Home and SteamVR.
- To support backwards compatibility and fall-back views of 2d web content 
within the VR headset, the VR compositor could provide an nsWidget / nsWindow 
interface to the 2d compositor.  The 2d compositor output would be projected 
onto the geometry of a VR Layer and updated asynchronously with HMD poses.
- The VR Compositor will not allocate unnecessary resources until either WebVR 
Content is accessed or the browser is launched from within a VR-only 
environment such as Oculus home, SteamVR, or GearVR.

Early WIP patches of implementation of the WebVR 1.0 API are in Bug 1250244.  I 
expect the first implementation to be minimal, but lay the foundation that will 
eventually become the VR Compositor.  

Thanks for giving this a review — I look forward to your feedback!

Cheers,

 - Kearwood “Kip” Gilbert


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

Re: Reverting to VS2013 on central and aurora

[Gregory Szorc]

On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc  wrote:

> There is a compiler bug in VS2015 that results in SSE instructions being
> emitted when they shouldn't be. Since Firefox still needs to remain
> compatible with ancient hardware that doesn't support SSE, this is causing
> crashes on Firefox built with VS2015 (see bug 1265615).
>
> The good news is glandium found a pretty minimal reproduce case and
> reported the bug to Microsoft.
>
> The bad news is the issue still reproduces in the latest pre-release
> version of the Visual C++ toolchain.
>
> The worse news is we'll have to revert to building Firefox 48 (current
> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> track. Aurora will likely land soon. Central might take a few days, as I
> believe VS2013 is a bit broken on central at the moment.
>

We have a change in plans.

bsmedberg says we can require SSE. So that means the VS2015 bug emitting
SSE instructions isn't an issue.

But we need to teach the updater to advertise CPU features in the Firefox
version before we drop SSE so we don't update users to a binary that won't
work. Since Firefox 48/Aurora is currently using VS2015, that would mean
teaching Firefox 47/Beta new tricks. Since we're already in the middle of
the Beta cycle and there is no major user benefit to shipping VS2015 builds
at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
build the updater support into Firefox 48/Aurora. Firefox 49/Nightly will
continue to build with VS2015 and will be the first Firefox version to
require SSE.

Bug 1271755 is our tracker for requiring SSE to run Firefox.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Mike Taylor]

On 5/10/16 3:05 PM, Jack Moffitt wrote:

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.


Interesting, my own interests are naturally skewed towards finding the 
moz-isms and understanding how and when we can get rid of them (if 
ever). But I can see how understanding DOM API usage is more relevant 
when building a new browser engine.



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.


¿Porqué no los dos?

Right now no source of data will tell us if it's safe to remove 
:-moz-dir() once we ship :dir(), for example.


https://bugzilla.mozilla.org/show_bug.cgi?id=1270406

And as Steve already replied, making decisions based on CSS (or JS) 
served to browsers with different UA strings can be problematic. If 
you're Safari Mobile, you'll end up with a lot more WebKit-isms than if 
you're Fennec.


But yes, I absolutely agree we should Use Counter DOM APIs as well.


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?


I don't have any strong opinions on where the data lives.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Use Counter: Everything

[Steve Fink]

On 05/10/2016 01:05 PM, Jack Moffitt wrote:

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?


Why is this an either/or? Both seem valuable.

Multiple data sources provide opportunities to detect discrepancies 
between them. (eg, say feature-detection triggers a hit count in one 
browser's collection mechanism and not another's.) I agree that a 
unified reporting facility would be useful. But I'd bet we'd learn 
*something* by looking at where our numbers mismatch other browsers'.


Another example: consider the case where UA detection prevents the usage 
of a CSS property. If everyone avoids a particular CSS property on 
Firefox only, perhaps there is a real reason for it that we should 
figure out. Maybe we need to evangelize the fact that we now support 
property X, or have fixed the bug causing it to be blacklisted.


___
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: Intent to Use Counter: Everything

[Mike Taylor]

On 5/10/16 2: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.


Link to bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1271752

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Use Counter: Everything

[Mike Taylor]

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

Re: Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

err [1] is https://wiki.mozilla.org/Telemetry/Experiments and [2] is
https://wiki.mozilla.org/QA/Telemetry/Developing_a_Telemetry_Experiment
:)

On Tue, May 10, 2016 at 10:53 AM, Kartikaya Gupta  wrote:
> Just to close the loop on this, I went ahead and updated the wiki
> pages at [1] and [2] to reflect that some parts of the process are
> more optional than they originally seemed. I also tried to generally
> make the documentation simpler to follow and less
> redundant/contradictory. Finally, I filed bug 1271440 for the missing
> piece to allow developers to self-sign their experiment addons.
>
> Hopefully these changes will make it easier to build and deploy
> experiments in the future.
>
> Cheers,
> kats
>
> On Wed, Apr 20, 2016 at 3:31 PM, Jared Hirsch <6...@mozilla.com> wrote:
>> Hi all,
>>
>> I wrote a telemetry experiment last year[1], and I also found the process
>> challenging to navigate.
>>
>> I found that many important details were undocumented, but were mentioned in
>> review comments, so I added what I could to the telemetry experiment wiki
>> page and to MDN.
>>
>> My experiment gathered new data, and sent it to a new, one-off server
>> endpoint. This definitely required more discussion than the typical
>> experiment. That said, I do think there are ways the process could be
>> improved for all experiments.
>>
>> Here are a few suggestions for improving the current process:
>> - document how to use Experiments.jsm on MDN
>> - document the schema of the Telemetry Experiment-specific manifest.json
>> file
>> - write and maintain at least one up-to-date, thoroughly commented example
>> experiment
>> - merge (parts of) the telex QA page[2] into the main page (the link is
>> buried in the main page)
>> - update and possibly merge the code docs[3] into the main wiki page
>>
>> To expand on the last bullet point: the code docs suggest using a special
>> python build script to assemble the final .xpi, but that's no longer
>> accurate, as experiments now need to be signed. Further, each experiment has
>> to be *manually* signed, because AMO signing tools will not auto-sign an
>> add-on with the special telex emType. A bug has been filed[4] to enable
>> auto-signing for experiments, but it hasn't moved since November. Might be
>> worth pushing on it.
>>
>> Each of these missing pieces makes shipping an experiment a little bit
>> harder than it has to be. Adding them all up, the process as a whole can
>> seem difficult for a first-time experiment author (at least, it did for me
>> and evidently for Kats as well).
>>
>> I hope these suggestions are helpful.
>>
>> Cheers,
>>
>> Jared
>>
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1174937
>> [2] https://wiki.mozilla.org/QA/Telemetry
>> [3]
>> http://hg.mozilla.org/webtools/telemetry-experiment-server/file/tip/README.rst
>> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1220097
>>
>> On Wed, Apr 20, 2016 at 8:05 AM, Kartikaya Gupta  wrote:
>>>
>>> On Wed, Apr 20, 2016 at 10:26 AM, Benjamin Smedberg
>>>  wrote:
>>> > The goal of this is for experiments to be fairly lightweight.
>>> >
>>> > Can you talk about where the problems were? The only signoffs that are
>>> > currently required are code review (no surprise there) and
>>> > acknowledgement from a release driver.
>>>
>>> This sounds reasonable, but the page at
>>> https://wiki.mozilla.org/Telemetry/Experiments (taken at face value,
>>> which is what I did as it was my first foray into this) indicates
>>> otherwise. Perhaps most of my issues could be resolved just by
>>> updating the documentation on that page. For example, it says "Product
>>> approval is required to run an experiment." and is unclear about what
>>> is "user-facing" vs not. It also says to talk to you *before* building
>>> an experiment, which I did (bug 1251052 comment 1), only to then find
>>> out that step was not necessary, so that was extra unnecessary
>>> latency. The doc also says "QA should verify the experience on the
>>> staging server", so I went through that process - it was almost no
>>> work on my part since QA had a template for it already but it still
>>> took nonzero time. The addon signing step is also not yet automated,
>>> as far as I could tell, even though the bug referenced in the doc is
>>> resolved fixed, so that adds an additional dependency and round-trip
>>> to somebody who can sign it.
>>>
>>> > For pref flips in particular, we've talked about extending the
>>> > experiment system so that you don't have to write an addon at all:
>>> > that you can just specify pref values in the experiment manifest. That
>>> > would require engineering work and a little bit of new signing work
>>> > that is currently not planned; but if somebody wants to do that work,
>>> > I would be willing to mentor.
>>>
>>> This sounds great, and would be really nice. If it's not a huge amount
>>> of work I would be willing to take this on. Is there a bug on 

Re: Telemetry experiments need to be easier (on Nightly)

[Kartikaya Gupta]

Just to close the loop on this, I went ahead and updated the wiki
pages at [1] and [2] to reflect that some parts of the process are
more optional than they originally seemed. I also tried to generally
make the documentation simpler to follow and less
redundant/contradictory. Finally, I filed bug 1271440 for the missing
piece to allow developers to self-sign their experiment addons.

Hopefully these changes will make it easier to build and deploy
experiments in the future.

Cheers,
kats

On Wed, Apr 20, 2016 at 3:31 PM, Jared Hirsch <6...@mozilla.com> wrote:
> Hi all,
>
> I wrote a telemetry experiment last year[1], and I also found the process
> challenging to navigate.
>
> I found that many important details were undocumented, but were mentioned in
> review comments, so I added what I could to the telemetry experiment wiki
> page and to MDN.
>
> My experiment gathered new data, and sent it to a new, one-off server
> endpoint. This definitely required more discussion than the typical
> experiment. That said, I do think there are ways the process could be
> improved for all experiments.
>
> Here are a few suggestions for improving the current process:
> - document how to use Experiments.jsm on MDN
> - document the schema of the Telemetry Experiment-specific manifest.json
> file
> - write and maintain at least one up-to-date, thoroughly commented example
> experiment
> - merge (parts of) the telex QA page[2] into the main page (the link is
> buried in the main page)
> - update and possibly merge the code docs[3] into the main wiki page
>
> To expand on the last bullet point: the code docs suggest using a special
> python build script to assemble the final .xpi, but that's no longer
> accurate, as experiments now need to be signed. Further, each experiment has
> to be *manually* signed, because AMO signing tools will not auto-sign an
> add-on with the special telex emType. A bug has been filed[4] to enable
> auto-signing for experiments, but it hasn't moved since November. Might be
> worth pushing on it.
>
> Each of these missing pieces makes shipping an experiment a little bit
> harder than it has to be. Adding them all up, the process as a whole can
> seem difficult for a first-time experiment author (at least, it did for me
> and evidently for Kats as well).
>
> I hope these suggestions are helpful.
>
> Cheers,
>
> Jared
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1174937
> [2] https://wiki.mozilla.org/QA/Telemetry
> [3]
> http://hg.mozilla.org/webtools/telemetry-experiment-server/file/tip/README.rst
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1220097
>
> On Wed, Apr 20, 2016 at 8:05 AM, Kartikaya Gupta  wrote:
>>
>> On Wed, Apr 20, 2016 at 10:26 AM, Benjamin Smedberg
>>  wrote:
>> > The goal of this is for experiments to be fairly lightweight.
>> >
>> > Can you talk about where the problems were? The only signoffs that are
>> > currently required are code review (no surprise there) and
>> > acknowledgement from a release driver.
>>
>> This sounds reasonable, but the page at
>> https://wiki.mozilla.org/Telemetry/Experiments (taken at face value,
>> which is what I did as it was my first foray into this) indicates
>> otherwise. Perhaps most of my issues could be resolved just by
>> updating the documentation on that page. For example, it says "Product
>> approval is required to run an experiment." and is unclear about what
>> is "user-facing" vs not. It also says to talk to you *before* building
>> an experiment, which I did (bug 1251052 comment 1), only to then find
>> out that step was not necessary, so that was extra unnecessary
>> latency. The doc also says "QA should verify the experience on the
>> staging server", so I went through that process - it was almost no
>> work on my part since QA had a template for it already but it still
>> took nonzero time. The addon signing step is also not yet automated,
>> as far as I could tell, even though the bug referenced in the doc is
>> resolved fixed, so that adds an additional dependency and round-trip
>> to somebody who can sign it.
>>
>> > For pref flips in particular, we've talked about extending the
>> > experiment system so that you don't have to write an addon at all:
>> > that you can just specify pref values in the experiment manifest. That
>> > would require engineering work and a little bit of new signing work
>> > that is currently not planned; but if somebody wants to do that work,
>> > I would be willing to mentor.
>>
>> This sounds great, and would be really nice. If it's not a huge amount
>> of work I would be willing to take this on. Is there a bug on file for
>> it?
>>
>> > Data review is required only if an experiment collects new data. My
>> > goal is for this to be fast and straightforward, but IIRC it wasn't
>> > necessary at all for your recent experiment. There is no legal review
>> > required for experiments unless I raise a question during data review.
>>
>> Again, the