Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Emma Humphries]

My thanks to everyone who had commented on this so far. I’m replying to
your questions and comments in this email so that we don’t have a threading
catastrophe.

First, several of you mentioned the typo where I wrote qa-verify when the
flag is qe-verify. The policy document has the correct flag name.

Second, this is not process for the sake of process, but so that Program
and Release Management, PI, and engineering leadership can quickly assess
what is happening with features.

Please note that Program / Release Management did not come up with this
policy on our own.  The Firefox engineering teams were simultaneously
looking to create a similar policy to further alleviate releases where a
feature is inadvertently not tested or enabled.  A recent item was the
Retained Display list not be turned on.

There’s also some question about what qe-verify means. It can be requested
by anyone with editbugs and granted by anyone with editbugs. And `+` does
not mean the bug is verified, but that QA will verify the the fix and set
the bug’s resolution to VERIFIED. I’ve updated that in the document (at
https://github.com/mozilla/bug-handling/commit/9b461160df743262aa6ecb7e6a033872ce393ff1
).

Liz Henry points out we should be clear in the policy what VERIFIED means
here for testing and sign-off.

:mossop asked about the Trello board, it’s at
https://trello.com/b/8k1hT2vh/firefox (if you need access, please ask
:elan) and we use the board to track features of note so that we know to
communicate them through release notes and other channels. Since we’re
using a flag to indicate features behind a pref, we can use queries to
indicate features that need to go on that board.

Nick Alexander mentioned that features which interact with the OS, mobile
OSes (Android and iOS) are all or nothing. This policy does not mean you
must release behind a pref. But if you are releasing a feature that depends
on a change to your OS, the bug for the feature must note that. That sort
of change may not be atomic in nature, so early warning and notification of
Project and Release Management, and PI is important.

Jared Wein asked in the thread; MattN, and Mark Banner asked in Issues (
https://github.com/mozilla/bug-handling/issues/4, and
https://github.com/mozilla/bug-handling/issues/4) about feature work
involving large numbers of bugs associated with a [meta] bug. Mark’s
suggestion where the flag is associated with the meta bug, but not the
dependent bugs is most likely the way to go.

Ritu Kothari and D. Baron asked about managing features across release
trains. The behind-pref may need to be a status flag instead of a simple
flag since the target version field only indicates when a bug landed in M-C
and bugs supporting a feature may land across multiple releases. I’ve
started a discussion of this at
https://github.com/mozilla/bug-handling/issues/5.

Several of you note that we’ve overloaded preferences. And perhaps we
should think about releasing features under a feature flag system. I think
that would afford us a way to move features toggling to the pref panes
(even if we keep feature flags in a namespaced area in prefs.)

Finally, I need to talk more with Shield/Normandy about this and make sure
I’m not sabotaging you.

Thank you all for your feedback and for helping us ship high quality code.

— Emma

On Wed, May 2, 2018 at 4:57 PM Emma Humphries  wrote:

> Hello,
>
> We control enabling many features and changes to Firefox using preferences.
>
> Program and Release management as well as PI need a better view of this.
>
> We've written a new policy which you can read on our nascent bug-handling
> mini-site:
>
> https://github.com/mozilla/bug-handling/blob/master/policy/feature-flags.md
>
> To summarize, when you are releasing a feature that "rides behind a flag",
> on the bug for the feature:
>
> * set the behind-pref flag to +
> * set the qa-verify flag to ?
> * note the bug in the Firefox Feature Trello board
>
> We expect qa-verify to be set to + before enabling prefs on features.
>
> We'll be going over this at two upcoming meetings, with Reese's and JoeH's
> teams.
>
> There are two, known open questions to resolve on the policy:
>
> * Features developed over multiple releases with individual patches not
> verifiable by external testing (passing unit tests, but not integration
> tests) such as Hello and WebRTC
> * Features are often turned on in Nightly, ignoring prefs using compiler
> directives, and kept off in Beta and Release. Is this the right thing to
> do, or should we be flipping prefs from on to off when going from Nightly
> to Beta and forwards?
>
> The bug handling documentation is a GitHub repo to enable web publishing,
> please follow up there, using Issues and PRs, rather than to this email.
>
> I want to acknowledge and thank: Liz Henry, Ritu Kothari, Resse Morris,
> Erin Lancaster, Ryan VM, Thomas Elin, and Adam Roach for their comments and
> feedback on this.
>
> Thank you!
>
> -- Emma Humphries
>

Re: Intent to implement: AudioWorklet

[Nils Ohlmeier]

Looks like the existing WebAudio issue 
https://github.com/WebAudio/web-audio-api/issues/1471 

is where this should get resolved (for people who haven’t switched over there 
yet).

Best regards
  Nils Ohlmeier

> On May 2, 2018, at 09:05, hongc...@chromium.org wrote:
> 
> It's great to see the intent for the AudioWorklet, but also I can see the GC 
> observability is still being discussed here.
> 
> Karl, can you open a new spec issue if you think this needs another look from 
> AudioWG and TAG?
> 
> -Hongchan
> 
> 
> On Wednesday, May 2, 2018 at 8:17:30 AM UTC-7, Boris Zbarsky wrote:
>> On 5/2/18 5:21 AM, Karl Tomlinson wrote:
>>> [[AudioNode Lifetime]] https://github.com/WebAudio/web-audio-api/issues/1471
>> 
>> I've read through that thread, but I'm still a little unclear on where
>> thing stand.  With the latest proposal, can there be observable
>> situations where the output sound depends on GC timing?
>> 
>> If so, that doesn't sound acceptable.  It also sounds to me like Alex
>> Russell in
>> https://github.com/WebAudio/web-audio-api/issues/1471#issuecomment-362604396
>> didn't believe there was an observable sound difference possible.  If
>> one is possible, we should communicate this to him very clearly
>> 
>> -Boris
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



signature.asc
Description: Message signed with OpenPGP
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Devices and Sensors Working Group

[Kyle Machulis]

Filling in some of the gaps here:

WakeLock API is still used on android, afaik so we don't let the phone turn
off while playing media.

We ship the Vibration API on android, have since FxOS. Not much happening
there these days, other than some discussion about permissions around it.

We still have battery code around Firefox, but the API isn't exposed to
content. I think we're still trying to figure out whether to just
completely remove it.

DeviceOrientation is shipped everywhere, weirdly enough. There's a bug to
fix that for platforms where we don't have info about it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1037982

On Thu, May 3, 2018 at 11:02 PM, Anne van Kesteren  wrote:

> On Fri, May 4, 2018 at 2:07 AM, L. David Baron  wrote:
> > On the flip side, sensor APIs are offered by mobile (and to some
> > degree desktop) operating systems and widely used by apps running on
> > them, and there's clear demand for having them on the Web.  So I
> > think it seems worth having a clear venue for that discussion, which
> > would suggest that it's good to have the discussion in the scope of
> > the working group.
>
> This is true for a number of APIs not offered by the web, many of
> which don't have standardization efforts or a viable path to be
> exposed (or were standardized and then dropped due to issues, e.g.,
> batteries).
>
>
> > I'm inclined to think that if we want to suggest changes to address
> > this security/privacy issue, we should be suggesting clarifying the
> > success criteria for the working group so that these issues are
> > clearly considered, and making it more explicitly OK for the group
> > to decide not to produce some of its deliverables.
> >
> > The final paragraph of section "1. Goals" already says a bit here,
> > as does the third paragraph of "2.1 Success Criteria", but perhaps
> > there's more to say, perhaps by making not producing a spec
> > explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"?
> > And perhaps something in there should also explicitly mention the
> > difficulty of properly informing the user in order to obtain
> > informed consent for the real risks underlying the sensors, or
> > something like that?
> >
> > Or do you instead think that some of the deliverables should be
> > removed from the charter because they're not likely to succeed?  If
> > so, which?
>
> I hadn't looked in detail yet, but they're doing quite a lot of APIs. Of
> those
>
>   Generic Sensor API
>   Geolocation Sensor
>
> might be the least controversial as its a new API for an existing
> feature, but I have not looked in detail whether this is a straight
> mapping or not. If Google's Layered APIs initiative
> (https://github.com/drufball/layered-apis) is successful that might
> also be a better way to go about things.
>
>   Wake Lock API
>
> We've explored this for FxOS. In terms of mozilla/standards-positions
> I guess this would be non-harmful.
>
>   Battery Status API
>
> We've unshipped this: harmful.
>
>   Network Information API
>
> I'm pretty sure Mozillians have raised issues with this in the past
> and we don't intend to ship it. I suspect harmful.
>
>   DeviceOrientation Event specification
>
> We ship this on Android I think, but per earlier dev-platform threads
> we're not exactly happy with it.
>
>   Proximity Sensor
>   Ambient Light Sensor
>   Accelerometer
>   Gyroscope
>   Magnetometer
>   Orientation Sensor
>
> These are the ones my initial comment was for. As I understand it the
> proposed defense is to restrict these to foreground top-level browsing
> contexts without user prompt. It's unclear to what extent they are
> throttled. If they are throttled, they are less or not useful for
> AR/VR. If they are not throttled, they are an interesting
> fingerprinting vector. It's unclear to me how a standardization group
> is going to help resolve that and I don't think we'd want them to make
> that trade-off for us.
>
> There's also Vibration API and HTML Media Capture and I'm not sure
> what the state of those is. Neither seems particularly problematic.
>
> Hope that helps,
>
>
> --
> https://annevankesteren.nl/
> ___
> 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: event.srcElement

[Boris Zbarsky]

Summary: A .srcElement property on events that is an alias of .target. 
It's originally an IE-ism that now everyone but us supports.


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

Standard: https://dom.spec.whatwg.org/#dom-event-srcelement

Target release: Firefox 62

Preference: None.  This is behind a nightly-only ifdef right now; I am 
planning to remove the ifdef.


Concerns: The main worry here is whether sites use this for UA-detection 
and would take "IE-only" codepaths if it's present.  We have been 
shipping this in nightly since it landed partway through the 60 cycle, 
and haven't run into any issues so far...


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

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

[Boris Zbarsky]

On 5/4/18 3:34 AM, Karl Tomlinson wrote:

Not sure I understand your question, but the observable behavior
described by this section, or specifically "Before an AudioNode is
deleted, it will disconnect itself from any other AudioNodes"


Right.  So that observably influences the sound produced or some such, 
sounds like?



Yes, the source of the observable GC problem is very much in the
spec now, and tracked by the [[AudioNode Lifetime]] issue.


Understood.

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

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Jared Wein]

I have a bug that will introduce a pref/feature-flag, but that is just one
bug that blocks a meta bug. The meta bug covers the whole feature.

Should these flags get set on the meta bug or on the bug that introduces
the pref? Testing the specific bug that introduces the pref won't provide
much coverage, but setting the flag on the meta bug may be confusing since
there will be no patches landed on that bug.

I also agree that updating the Trello tracking board is inconvenient (and I
also don't know where to find it). Could we just have a Bugzilla query for
this information?

Thanks,
Jared

On Thu, May 3, 2018 at 4:45 PM, Jonathan Kew  wrote:

> On 03/05/2018 00:57, Emma Humphries wrote:
>
> To summarize, when you are releasing a feature that "rides behind a flag",
>> on the bug for the feature:
>>
>> * set the behind-pref flag to +
>> * set the qa-verify flag to ?
>> * note the bug in the Firefox Feature Trello board
>>
>> We expect qa-verify to be set to + before enabling prefs on features.
>>
>
> I don't see a flag "qa-verify" in bugzilla; was this possibly a typo for
> "qe-verify"?
>
> Thanks,
>
> JK
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Should web specifications try to describe object lifetimes? [was Intent to implement: AudioWorklet]

[Karl Tomlinson]

Boris Zbarsky writes:

> So if there is in fact a problem still remaining, convincing Alex
> that it's there is pretty valuable.  Having him convinced it
> doesn't exist is actively harmful as far as getting it fixed goes.

Thank you.  Alex sounds like a very valuable person to get on side.

We may still have some time on our hands, but I'm not sure how long
to pursue the WG about this before we aim to get Alex involved.

Neither Chrome 66 nor current Chromium [[processor source code]]
support AudioWorkletNodes with lifetimes based on input
connections in a way that is compatible with the spec and so
Chrome or the spec will change at some point.

It would be nice, however, to resolve these issues before Chrome
ships such changes.

Hongchan has assigned himself to the [[AudioNode Lifetime]] spec
bug, and so I'm happy for him to have a go, if he is planning to
fix it.

> If there is no difference in observable behavior, what would a
> normative requirement mean?

Good question.  I will find that useful at some point.

> Karl Tomlinson wrote:
>> If the whole normative AudioNode lifetime section were dropped
>> then this would clearly be an implementation issue rather than a
>> spec issue.
>
> Assuming there is no observable behavior involved (other than
> memory usage), right?

Not sure I understand your question, but the observable behavior
described by this section, or specifically "Before an AudioNode is
deleted, it will disconnect itself from any other AudioNodes", is
the source of observable behavior on GC.  Removing this section
would remove the core problem.

The rest of the section describes conditions that would keep an
AudioNode alive, and describes when AudioNodes are no longer
required.  These portions are not _necessary_, as nothing
elsewhere indicates that AudioNodes should ever be removed, but
there seem to be differing opinions on the importance of these
clauses.  (Compare e.g. [[PermissionStatus listeners]],
[[WebSocket listeners]])

>> The history here is:
>
> Thank you for the summary.  That was helpful.  One thing I'm not
> 100% clear on at this point: are there spec issues that can lead
> to observable GC, or are we just talking about implementation bugs
> that make GC observable now?

Yes, the source of the observable GC problem is very much in the
spec now, and tracked by the [[AudioNode Lifetime]] issue.

Once that is resolved, I'm hoping that a spec change to support
something like [[silence tracking]] can make AudioWorklet suitable
for custom AudioNodes.

[[processor source code]]
https://chromium.googlesource.com/chromium/src/+blame/9d4a34cadf1b7d85f4ad0b709374aaaf59325a8d/third_party/WebKit/Source/modules/webaudio/AudioWorkletNode.cpp#110

[[PermissionStatus listeners]]
https://github.com/w3c/permissions/issues/170

[[WebSocket listeners]]
https://html.spec.whatwg.org/#garbage-collection-3

[[AudioNode Lifetime]]
https://github.com/WebAudio/web-audio-api/issues/1471

[[silence tracking]]
https://github.com/WebAudio/web-audio-api/issues/1453
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Devices and Sensors Working Group

[Anne van Kesteren]

On Fri, May 4, 2018 at 2:07 AM, L. David Baron  wrote:
> On the flip side, sensor APIs are offered by mobile (and to some
> degree desktop) operating systems and widely used by apps running on
> them, and there's clear demand for having them on the Web.  So I
> think it seems worth having a clear venue for that discussion, which
> would suggest that it's good to have the discussion in the scope of
> the working group.

This is true for a number of APIs not offered by the web, many of
which don't have standardization efforts or a viable path to be
exposed (or were standardized and then dropped due to issues, e.g.,
batteries).


> I'm inclined to think that if we want to suggest changes to address
> this security/privacy issue, we should be suggesting clarifying the
> success criteria for the working group so that these issues are
> clearly considered, and making it more explicitly OK for the group
> to decide not to produce some of its deliverables.
>
> The final paragraph of section "1. Goals" already says a bit here,
> as does the third paragraph of "2.1 Success Criteria", but perhaps
> there's more to say, perhaps by making not producing a spec
> explicitly OK in both "2.1 Success Criteria" and "3. Deliverables"?
> And perhaps something in there should also explicitly mention the
> difficulty of properly informing the user in order to obtain
> informed consent for the real risks underlying the sensors, or
> something like that?
>
> Or do you instead think that some of the deliverables should be
> removed from the charter because they're not likely to succeed?  If
> so, which?

I hadn't looked in detail yet, but they're doing quite a lot of APIs. Of those

  Generic Sensor API
  Geolocation Sensor

might be the least controversial as its a new API for an existing
feature, but I have not looked in detail whether this is a straight
mapping or not. If Google's Layered APIs initiative
(https://github.com/drufball/layered-apis) is successful that might
also be a better way to go about things.

  Wake Lock API

We've explored this for FxOS. In terms of mozilla/standards-positions
I guess this would be non-harmful.

  Battery Status API

We've unshipped this: harmful.

  Network Information API

I'm pretty sure Mozillians have raised issues with this in the past
and we don't intend to ship it. I suspect harmful.

  DeviceOrientation Event specification

We ship this on Android I think, but per earlier dev-platform threads
we're not exactly happy with it.

  Proximity Sensor
  Ambient Light Sensor
  Accelerometer
  Gyroscope
  Magnetometer
  Orientation Sensor

These are the ones my initial comment was for. As I understand it the
proposed defense is to restrict these to foreground top-level browsing
contexts without user prompt. It's unclear to what extent they are
throttled. If they are throttled, they are less or not useful for
AR/VR. If they are not throttled, they are an interesting
fingerprinting vector. It's unclear to me how a standardization group
is going to help resolve that and I don't think we'd want them to make
that trade-off for us.

There's also Vibration API and HTML Media Capture and I'm not sure
what the state of those is. Neither seems particularly problematic.

Hope that helps,


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